Inside Claude: When One AI System Becomes a Team

Imagine asking Claude a difficult research question — one that genuinely requires reading hundreds of sources.

Imagine asking Claude a difficult research question — one that genuinely requires reading hundreds of sources. Which companies in a particular index have a board member with a background in semiconductors, say.

One AI agent could search them one after another. It would get there eventually, but the job would be slow, and something else would go wrong along the way: its working memory would fill up. By the two hundredth company it would be carrying so much accumulated reading that the original question starts to get crowded out.

Now think about how a research team would handle the same request. One lead researcher reads the question and divides it into smaller assignments. Several researchers investigate those assignments at the same time, each keeping their own notes. When they are done, the lead reads what they found and writes the answer.

Nothing about that is clever. It is how any group of people handles a job too big for one person. But notice the two things it buys, because they are different from each other:

• The work happens at the same time rather than one after another.
• Each researcher has their own notebook, so no single person has to hold everything.

Now the vocabulary. In AI architecture, the lead is usually called an orchestrator, and the specialists it sends work to are called subagents. The notebook is the context window we met in Chapter 2. That is the whole idea, and it is the idea this chapter is about.

One product, two designs

Here is what makes this chapter worth a chapter rather than a paragraph. Claude does deep research, and Claude writes software. Both are agentic. Both use tools in a loop. And they are built differently — deliberately.

• Research divides the work among several agents: a lead that plans, and subagents that search at the same time.
• Coding stays mostly in a single agent working through one continuous loop, with subagents used only for particular bounded jobs.

Why the asymmetry? Hold the question. By the end of the chapter the answer will seem obvious, and it is the most useful thing in this book.

Research: a lead and its specialists

Go back to that hard research question. The reason one agent struggles is not that it lacks intelligence. It is that the work is enormous and mostly repetitive: the same kind of lookup, hundreds of times, across hundreds of sources.

What the lead does

The lead agent receives the question and does the thinking that cannot be divided up:

• It works out what is actually being asked, and forms a research strategy.
• It writes that plan down somewhere durable. This is not housekeeping: a context window is finite, and a long investigation will exceed it. If the context gets trimmed, a plan written to memory survives.
• It decides how much effort the question deserves, and sends out that many specialists.
• It waits, collects what they return, and writes the answer.
• If gaps remain, it sends out more.

What the specialists do

Each subagent gets a specific assignment and works independently. The crucial property is the notebook: each has its own context window. Ten subagents exploring ten aspects of a question have, between them, ten times the working memory of a single agent. The system is not merely faster. It can hold more.

Anthropic's account describes giving each subagent four things:

• a clear objective;
• the format the answer should come back in;
• guidance on which tools and sources to prefer;
• explicit boundaries, so it does not duplicate another subagent's work.

That fourth item turns out to matter enormously, and we will come back to it.

Two kinds of at-the-same-time

The design divides work twice over. The lead sends out several subagents at once rather than one after another; and each subagent calls several tools at once rather than waiting for each result before requesting the next.

Anthropic reports that this cut research time on complex queries by up to ninety per cent. Not because any individual step got faster — because the waiting stopped happening in single file.

Citations as a separate job

Once the research is assembled, a dedicated agent goes back over the compiled report and works out which claim came from which source.

Separating this from the writing is a genuinely good piece of design, and worth stealing. Attributing a claim is a different task from making one. It needs different attention. Giving it its own pass means neither gets done carelessly, and it is the reason the answers come back with links you can actually follow.

What it bought

On Anthropic's own internal research evaluations, a multi-agent arrangement — a Claude Opus 4 lead with Claude Sonnet 4 subagents — outperformed a single Claude Opus 4 agent by 90.2 per cent.

Source: Anthropic, “How we built our multi-agent research system”, engineering blog, 2025. Full citation in Sources and Further Reading.

Note the model mix, because that is a pattern you can copy directly. The more capable model does the planning and the writing. The cheaper, faster model does the searching. The expensive reasoning happens once; the repetitive work gets farmed out to something cheaper. We will build a system this way in Chapter 14.

What it cost

This is the part usually left out of enthusiastic write-ups, and it matters more than the performance figure does.

Source: Anthropic, “How we built our multi-agent research system”, engineering blog, 2025. Full citation in Sources and Further Reading.

Read that table carefully, and read it as what it is: measurements of one company's system on one company's tasks. It does not say that multi-agent systems cost fifteen times more. The actual cost varies enormously with the architecture, the number of agents, the models chosen and the task. What the table tells you is the order of magnitude of the jump, and that the jump is real.

Anthropic also reports something more interesting: on these tasks, how many tokens were spent explains about eighty per cent of the variation in how well the system performed. Read plainly, a great deal of the improvement comes from simply doing more work. And more work costs more money.

Which leads to the constraint that should govern every decision of this kind:

Dividing work among several agents is worth it when the task is valuable enough to justify spending substantially more computation on it.

A research question that informs a real decision clears that bar comfortably. Answering “what time is it in Tokyo” with a research team does not.

Deciding how hard to try

Because the cost is real, the system has rules about how much to spend. Anthropic describes building guidance like this into the instructions:

Source: Anthropic, “How we built our multi-agent research system”, engineering blog, 2025. Full citation in Sources and Further Reading.

Deciding how hard to try is itself part of the design. Without rules like these, Anthropic reports that early versions of the system sent out fifty subagents for questions that needed one.

Coding: why the same approach does not work

Now the interesting half. If dividing work among specialists helps research this much, why not use it to write software?

Anthropic's own answer, stated plainly in their engineering account, is that multi-agent arrangements struggle with coding tasks, because coding involves a high degree of interdependency between the pieces of work.

Think about why, using the research team again. If one researcher is looking into company A and another into company B, what the first one learns does not change what the second one needs to find out. They can work in complete ignorance of each other and the results still combine cleanly.

Code is the opposite. Change the name of a function and every place that calls it must change too. Rename a field and the database migration, the tests and the documentation all have to move together. Two agents editing the same codebase without knowing what the other is doing do not produce twice the work. They produce a conflict — or worse, code that compiles perfectly and is subtly wrong.

So the architecture changes shape.

One agent, one continuous loop

A coding agent such as Claude Code works predominantly as a single agent in a tool loop. It reads files, forms a plan, makes edits, runs the tests, reads the failures and tries again. All of it in one accumulating context, because every step depends on the last.

And remember the observation from Chapter 9: code can be checked automatically. That is what makes the single loop so effective here. The agent does not need a second opinion. It needs a compiler. The test suite is a more reliable judge than any reviewer, and it is available on demand.

Where specialists still help

Subagents are not absent from coding. They are used for work that is genuinely separable, and Claude Code's documentation is specific about the distinction.

Send a specialist when the task produces a lot of output nobody needs to keep — reading through log files, trawling documentation; when you want to restrict what it can touch, such as a reviewer that may read but never write; when the work is self-contained and comes back as a summary; or when several independent tasks can run at once.

Stay in the main loop when the task needs back-and-forth refinement; when several phases share a lot of context; when the change is small and targeted; or when speed matters, since a fresh subagent has to go and gather its own context before it can do anything.

That is one of the clearest statements of this trade-off you will find anywhere, and it generalises well beyond code. The shipped defaults are instructive too: they cap both how deep delegation may nest and how many subagents may run at once, at small numbers. Both are adjustable, but somebody decided that unlimited delegation was a bug rather than a feature.

The benefit that is not speed

Notice that most of the reasons to use a specialist while coding have nothing to do with going faster. They are about protecting the main context.

A context window is a budget. If the agent reads ten thousand lines of log output looking for one error, that budget has been spent on noise, and the plan it was carefully holding may be squeezed out. Send a specialist instead: it reads the logs in its own context and returns the one line that mattered. The main agent stays focused.

This reframes what subagents are for. In research they buy parallelism. In coding they buy attention. Both are real benefits, and they are not the same benefit — which means the question “should I add another agent?” has more than one good answer.

Choosing a handler, or running a project

You will hear systems like this described as router-based. It is worth being precise here, because two words get used interchangeably and they mean different things.

Routing means looking at a request, working out what kind it is, and sending it to the right handler. A short question goes to a small fast model; a hard one goes to the most capable. A billing question goes to the billing specialist. The router does not do the work. It decides who does.

Orchestration means a coordinator that takes one task, breaks it into parts, hands the parts out, and assembles the result. It does not merely dispatch. It plans, waits, combines and decides whether to go round again.

What Anthropic documents for research is orchestration: the lead agent is doing far more than choosing a recipient. But routing decisions live inside it — most visibly in the choice to put a capable model at the lead and cheaper models underneath. That is a routing decision based on difficulty, and it is where much of the cost saving comes from.

Hold the distinction, because Chapter 13 builds on it: a router chooses a handler; an orchestrator runs a project.

Everything that went wrong on the way

The most valuable part of Anthropic's account is not the successes. It is the catalogue of failures, because they are the failures anyone building something like this will meet.

• Delegation running away. Early versions sent out fifty or more subagents for simple queries. Effort has to be bounded explicitly.
• Searching without end. Agents hunting indefinitely for sources that did not exist. Knowing when to stop is a design problem, not a behavioural one.
• Duplicated and missed work. A vague instruction such as “research the semiconductor shortage” produced several subagents reading the same three articles while leaving whole areas untouched.
• Poor judgement about sources. Agents preferring search-optimised content farms over authoritative material.
• Small changes, large effects. A minor edit to an instruction producing big, unpredictable shifts in behaviour.
• Detail draining away. Information lost as findings passed through several stages — described, aptly, as a game of telephone.
• Waiting on the slowest member. When execution is synchronous, the whole system moves at the speed of its slowest part.
• The same question taking different paths. Which makes debugging genuinely hard.

Every one of those is a consequence of adding agents. Not one of them exists in a single-agent system. That is the honest cost of the architecture.

The lessons worth keeping

From the same account, the practices that made it work:

• Say exactly what you want. Every specialist needs an objective, an output format, guidance on tools, and a boundary. Vague delegation is the root of most of the failures above.
• Bound the effort. Put the scaling rules in writing so the system spends proportionately.
• Design the tools carefully. Agents choose tools by reading their descriptions, so a badly described tool is worse than a missing one. Anthropic reports that a dedicated agent whose only job was to test and rewrite tool descriptions cut task completion time by forty per cent. (Anthropic, 2025.)
• Start broad, then narrow. Short general searches first, then focus — which is how a competent human researcher works too.
• Write things down outside the context. A plan in durable storage outlives the context window that created it.
• Pass a pointer, not the pile. A specialist that stores its findings somewhere and returns a reference keeps the lead's context clear.
• Test early and small. Twenty real test cases now beat a perfect evaluation suite later.
• Fail softly. An agent should adapt when a tool errors rather than halting the whole run.

So here is what this chapter was really for. The same company, building the same kind of technology, reached two opposite conclusions about how many agents to use — and was right both times. What decided it was not ambition or budget. It was whether the work came apart into pieces that did not need each other. Which means the interesting question is not how many agents can I use? It is: does this particular job come apart?