Responsibilities, not sizes

Architecture reviews often open with the wrong question: Is this agent too big? Should we split it into smaller agents? The question assumes Thoughtware is a size hierarchy, with cognitive units as atoms, skills as molecules, and agents as organisms. That picture produces endless refactors and no clearer ownership. Teams split coherent capabilities because a file crossed an arbitrary threshold. They promote fixed sequences to "agents" because three model calls appeared in a row. They merge several judgments into one prompt because one call feels cleaner on a diagram.

The right question is different: which responsibility does this boundary own? A skill may span thousands of lines and dozens of model calls. A compact loop may still be an agent if it owns a goal and decides what happens next. Size is an implementation detail. Responsibility is the architectural cut.

Helpful context: Decide, perform, pursue names the three responsibilities. Two different boundaries separates the cognitive unit cut from the skill cut. This page closes the "how big?" debate.

The sizing smell

When teams optimize for size they typically make three predictable mistakes. They split one coherent skill into fragile micro-services because "it felt large." The procedure was known. The seams were tested. The split broke procedure evaluation and duplicated orchestration logic across services that now disagree on ordering.

They label a fixed DAG an "agent" because it chains three LLM calls. Nothing in the sequence owns a goal, revises strategy from evidence, or declares when work is good enough. The label borrowed marketing language, not architecture.

They merge several open judgments into one prompt because "one call is cleaner." That creates a composite cognitive units: one name, several failure modes, no pointable suite for the judgment that actually failed. See not a composite cognitive units.

Each move hides cost, seams, authority, and evaluation addresses. Responsibility maps replace headcount maps.

What ownership looks like

If the boundary owns one open judgment, the name is cognitive unit. Extent is declared in the contract. A long template does not make the judgment larger, and a short template does not make it smaller. AssessMealPracticality owns whether a candidate fits an evening. That responsibility does not grow because the household context block grew.

If the boundary owns a known capability, the name is skill. Procedure evaluation covers seams and order. The invoice extraction skill in The cognitive unit may be large in code and still own a single perform responsibility: extract structured invoice fields with validation and persistence. That is not "many agents." That is one capability packaged for reuse.

If the boundary owns progress toward a goal, the name is agent. Loop policy and stop conditions define sufficiency. A small agent that must revise strategy from evidence remains an agent. A large skill with branching cognitive unit calls remains a skill if the control structure was substantially known before execution.

Meal Companion and enterprise examples

The Meal Planning skill may call GenerateCandidates, ComposeWeek, CritiquePlan, and ten deterministic checks. Heavy, yes. Still perform, not pursue, if the agent already declared the goal and the skill's job is a bounded capability inside that pursuit. JudgeWeekdayPracticality stays a cognitive unit regardless of template length. Its suite binds to that judgment alone. The Meal Planning Agent stays an agent even if its loop code fits on one screen, because it owns whether the plan is ready to shop and when to escalate. Walk the same week with size glasses on and the temptation is to split the skill at every cognitive unit call or merge the agent loop into the skill because "it is all meal planning anyway." Walk it with responsibility glasses on and the cuts stay stable.

Enterprise examples reward the same discipline. Invoice verification composes retrieve, interpret, calculate, judge materiality, and persist. Several cognitive units decide field meanings and policy readings. One skill performs the extraction capability with known ordering and recovery. A queue-clearing module pursues the goal of processed invoices with human review on contested terrain. Nobody asks whether the extraction skill is "too big" in lines. They ask whether it owns one capability, whether seams are evaluated, and whether pursuit stays outside the skill boundary where case shape diverges.

Why sizing persists

Sizing persists because it is measurable. Token dashboards exist on day one. Responsibility maps require naming decisions, which is slower and socially harder. A leader can compare two cost numbers without reading contracts. They cannot compare two responsibility maps without attending to ownership.

Sizing also flatters demo culture. A single long call looks like progress in a screen recording. Ten named cognitive units with procedure evaluation look like overhead until the second week of operations, when local repair saves regeneration budget and a support ticket names the exact judgment that failed. Thoughtware treats that trade honestly. The upfront naming cost buys substitution, local repair, authority design, and evaluation addresses that compound over months. Teams that invest in responsibility naming early find that incident response accelerates because operators can point to the exact boundary that failed rather than triaging an opaque blob of model output.

Ask what responsibility a boundary owns, not how many lines it contains.

The cognitive unit · Ch. 16

From sizing meetings to responsibility maps

The replacement for "too big?" is "what does this own?" A responsibility map draws goals at the top, skills beneath, cognitive units beneath skills, and deterministic code beside the layers it gates. Known paths become skills even when large. Agents hold goal pursuit where evidence can change what work happens next. Compounds split when judgments multiply, not when lines do. If two open decisions hide behind one name, the split continues until each cognitive unit matches one wrong-answerable edge.

In practice, a five-minute review on any AI feature follows a pattern: list every box in the diagram and write one sentence for each, "This owns ___." If that sentence cannot be completed with decide, perform, or pursue language, the box is probably mislabelled. Any skill that also declares when the overall goal is complete has smuggled pursuit. Any agent that re-implements a known procedure inline has rediscovered perform work. Any cognitive unit name that contains "and" has hidden several judgments behind one API.

Leaders will ask for a number. The useful answer is two numbers and a map: token spend per capability and incident count per named judgment, with the responsibility map that explains which owner to fix when either number moves. Without the map, the number drives arbitrary splits. With the map, the number supports prioritization: which cognitive unit suite needs investment, which skill seam fails in production, which agent stop rule misfires on edge cases. Sizing questions also appear in vendor review. Asking which responsibility a vendor's "agent" owns reveals more than asking how many tools it exposes. Maps reveal maturity. Line counts reveal budget anxiety.

What to do next

The corrective to sizing habits is a responsibility map: goals, skills, cognitive units, and code arranged by ownership rather than weight. Known paths deserve skill packaging even when large, and agents stay reserved for goal pursuit. Compounds split when judgments multiply, not when lines do, and whiteboard boxes labelled by size give way to boxes labelled by verb.

See what is an agent and where the cognitive unit ends and the agent begins.

Read next: What is a skill.