Subagents are not an org chart

There is a number in Anthropic's research that sells agent swarms very effectively. A system with a Claude Opus lead agent delegating to Claude Sonnet subagents beat a single Opus agent by 90.2% on their internal research evaluation.

There is a second number, from the same organisation, that should stop you reaching for it: multi-agent implementations typically use three to ten times more tokens than a single agent doing equivalent work.

And there is a sentence, in Anthropic's own guidance on when to use multi-agent systems, that almost nobody quotes:

"A well-designed single agent with appropriate tools can accomplish far more than many developers expect."

That is the company with the strongest commercial reason to tell you to run ten agents, telling you to start with one. It is worth understanding why.

What a subagent actually is

Strip away the language of teams and crews and the mechanism is narrow and mechanical.

A subagent is a separate instance of the model with its own context window, its own system prompt, and its own restricted list of tools. The lead agent gives it a defined task. It goes away and works — often consuming tens of thousands of tokens exploring, reading, discarding — and comes back with a condensed summary, typically one to two thousand tokens.

The asymmetry is the whole idea. The lead agent never sees the forty thousand tokens of dead ends. It sees the conclusion. Its own context stays clean enough to keep reasoning about the actual problem.

Why a clean context is worth paying for

The reason this helps is a property of the models themselves, and it is worth knowing because it explains most agent behaviour people find mysterious.

Anthropic describes an attention budget that depletes as tokens accumulate. Transformers relate every token to every other token — an n² relationship — so as a context grows, "a model's ability to capture these pairwise relationships gets stretched thin." The published effect has a name: context rot. Recall accuracy declines as the token count rises.

So a long session is not neutral. Every irrelevant search result, every file you read once and never needed again, every abandoned approach — all of it is still sitting there, competing for attention with the thing you actually care about.

That is the problem a subagent solves. Not "more workers". Less noise in the context that matters.

The split almost everyone gets wrong

Here is the part that makes this article worth writing, because it is counterintuitive and it is where most teams lose the benefit.

The natural way to divide work between agents is by role. A planner. An implementer. A tester. A reviewer. It is how you would staff a team of people, it maps onto job titles everyone recognises, and it is the structure most agent frameworks encourage.

Anthropic names it as a failure:

"Problem-centric decomposition" — dividing work by role type — creates "lost context at each handoff" and negates multi-agent benefits.

The mechanism is easy to see once you look. Your planner builds up a rich understanding of the problem and then hands over three paragraphs. Your implementer rebuilds that understanding from scratch, badly, and hands over a diff. Your tester has no idea which parts were risky and which were obvious. Each boundary throws away exactly the context that made the previous stage useful — and Anthropic's blunt description of the result is that "agents spend more tokens on coordination than on actual work."

The alternative is to split by context: by which body of information each piece of work needs. Three subagents each searching a different subsystem is a good split, because none of them needs what the others read. A planner and an implementer is a bad split, because the implementer needs everything the planner learned.

The three cases where it genuinely wins

Anthropic's guidance names three, and they are all versions of the same idea.

Context protection. When a subtask floods the working context with information that later steps will never use — log files, search results, whole directories read to answer one question. Send it away, get the answer back.

Parallelisation. Independent research or verification running at the same time. Ten searches across a codebase, each with its own context, finishing in the time of one.

Specialisation. Genuinely different tool sets or domains, where a narrow tool list makes each agent's choices easier. Anthropic's context-engineering guidance is explicit that bloated tool sets "lead to ambiguous decision points about which tool to use" — a smaller list is not just tidier, it works better.

And the cases where it does not

The same guidance is equally clear about what to keep in one agent:

• Sequential phases of one task. Planning, then implementation, then testing, all of the same piece of work.
• Tightly coupled components that need constant back-and-forth.
• Anything requiring shared state that has to stay synchronised.

There is also a specific failure worth naming, because it is expensive and it looks like success. Anthropic calls it the early victory problem: verification subagents that mark work as passing after minimal testing, without comprehensive validation.

If that sounds familiar, it is the same hole we hit in the Firefox result: a checker with no real definition of correct will approve almost anything. Adding a "reviewer agent" does not create a referee. It creates a second opinion from the same model, which is worth much less than it feels like.

What it costs, and when that is worth it

Take the numbers seriously, because they decide the answer more often than the architecture does.

That last figure is the interesting one. The gains were not mysterious emergent teamwork — they came largely from how much thinking the architecture allowed, spread across independent context windows. Which means the honest framing of a multi-agent system is: you are buying more reasoning, and you are paying for it by the token.

So the question is never "should we use agents". It is whether this particular answer is worth ten times the compute. For a research task, an audit, a review that would otherwise take a person two days — obviously yes. For something that runs a thousand times a day on routine inputs — obviously no, and the people who find that out in production find it out on the invoice.

How we would start

Start with one agent and better tools. Most of what people reach for a second agent to fix turns out to be a bad tool list or a vague system prompt. That is cheaper to fix and it makes any later split work better.

Split only when you can name the context you are protecting. If the answer to "what is this subagent keeping out of the main window?" is vague, the split is decoration.

Give each subagent the smallest tool list that does its job. Ambiguity about which tool to use is a real, measured cost.

Never split work that has to keep talking to itself. If two parts need to negotiate, they belong in one context.

Budget for it before you build it. Three to ten times is the published range. Decide in advance what an answer is worth.

The honest summary

Subagents are a context management technique that happens to look like an organisation chart. Treating the resemblance as the point — hiring a planner, a coder, a tester, a reviewer — reproduces the coordination overhead of a human team without any of the things that make human teams work.

Split by what each piece needs to know, not by what you would call the job. And be sure the answer is worth what it costs, because this is the one part of AI where the bill arrives in proportion to the thinking.

Frequently asked questions