A multi-agent system splits a task across several model instances: a lead model plans, other instances do parts of the work, and the lead combines the results. Whether that beats a single agent is contested. Anthropic reported a large gain for research tasks in June 2025,[1] and one day earlier Cognition published an argument that you should usually not build this way.[2] This guide sets the two side by side, explains why both can be correct, and ends with a decision checklist.
Sources were opened on 2026-10-13: the two June 2025 posts, Anthropic's Claude Code subagent documentation, and Anthropic's December 2024 guide to agents. Both June 2025 posts predate the current model generation, and neither reports results we reproduced. Statements labelled "our reading" are interpretation, not measurement.
Quick answer
- Use parallel subagents when the work is broad, read-heavy and splits into independent branches, such as researching several sub-questions, and when the result is valuable enough to pay for roughly 15x the tokens of a chat.[1]
- Use a single agent when steps depend on each other and decisions must stay consistent, which describes most code changes.[1][2]
- Use subagents for context hygiene, not parallelism, when a side task would flood the main conversation with output you will not reuse.[3]
What the orchestrator-worker pattern is
Anthropic's December 2024 guide defines orchestrator-workers as a workflow in which "a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results." What separates it from simple parallelisation is that the "subtasks aren't pre-defined, but determined by the orchestrator based on the specific input."[4] The same guide recommends "finding the simplest solution possible, and only increasing complexity when needed," and notes that optimising a single call with retrieval and in-context examples is usually enough for many applications.[4]
Anthropic's June 2025 post describes its Research feature in these terms: "a multi-agent architecture with an orchestrator-worker pattern," with a lead agent that plans and delegates to parallel subagents, and a separate agent that attributes claims to sources.[1]
What Anthropic measured
The post reports three results worth separating:
| Claim | Reported figure | Where it applies |
|---|---|---|
| Quality | Multi-agent system (Claude Opus 4 lead, Claude Sonnet 4 subagents) outperformed single-agent Claude Opus 4 by 90.2% | Anthropic's internal research eval |
| Cost | Agents use about 4x the tokens of chat; multi-agent systems about 15x | Anthropic's own systems |
| Speed | Parallel tool calling cut research time by up to 90% for complex queries | Complex research queries |
Source: Anthropic, 2025-06-13.[1] These are Anthropic's figures on an internal eval; the post does not offer a way to reproduce them.
One finding is easy to miss. On the BrowseComp benchmark, the post says token usage alone explained 80% of performance variance, and that token usage, number of tool calls and model choice together explained 95%.[1] Our reading is that a share of the multi-agent gain is spending more tokens on the problem, which is what parallel agents each with a fresh context window do. That would mean the gain is partly bought, not free, and it is consistent with the 15x cost figure.
Anthropic also states where the pattern fits: it is suited to "valuable tasks that involve heavy parallelization," and is less suited to domains that need shared context or have many dependencies between agents. The post adds that "most coding tasks involve fewer truly parallelizable tasks than research," and that "LLM agents are not yet great at coordinating and delegating to other agents in real time."[1]
The case against
Cognition's post names two principles: "Share context, and share full agent traces, not just individual messages," and "Actions carry implicit decisions, and conflicting decisions carry bad results."[2]
Its example is a request to build a Flappy Bird clone, split into two subtasks. One subagent built a background that resembled Super Mario Bros. and the other built a bird that did not look like a game asset and did not move like the original. The final agent then had to reconcile both. When the original task was shared with both subagents the styles still mismatched, because neither could see the other's work.[2]
Cognition's recommendation is to treat the two principles as defaults, use a single-threaded linear agent for most tasks, and use subagents sparingly. It describes Claude Code as keeping subagents to narrow, well-defined questions and avoiding parallel subagent work.[2] That description is a June 2025 snapshot and should not be taken as a statement about Claude Code today.
Why both can be right
Read together, the two posts describe different task shapes:
| Property | Research (Anthropic) | Building code (Cognition) |
|---|---|---|
| Branches | Independent questions | Coupled pieces of one artefact |
| What a worker returns | Findings to be synthesised | Work that must fit with other work |
| Cost of an inconsistent choice | A redundant or weaker source | Parts that do not fit together |
| Reading versus writing | Mostly reading | Writing |
This table is our interpretation of the two posts, not a result either reports. The practical trade-off is that a worker returning a summary loses the reasoning behind it, which matters little when the lead only needs facts and matters a great deal when the worker has made design decisions the other workers must respect.
How Claude Code configures subagents
Anthropic's Claude Code documentation describes the mechanics, read on 2026-10-13:[3]
- "Each subagent runs in its own context window with a custom system prompt, specific tool access, and independent permissions."
- A subagent does not see your conversation history, the skills you have invoked or the files Claude has already read. A fork is the exception: "a subagent that inherits the entire conversation so far instead of starting fresh."
- Delegation can be automatic, based on each subagent's description, or explicit through a natural-language request or an @-mention.
- Tool access is an allowlist (
tools) or a denylist (disallowedTools). Some tools are removed from every subagent regardless. - By default a subagent can spawn its own subagents, up to three layers below the main conversation, and setting
CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTHto1turns nesting off.
The page lists use cases that have nothing to do with parallel speed-up: keeping exploration out of the main conversation, limiting tools, reusing configurations, and routing tasks to cheaper models such as Haiku. It advises using a subagent when a side task "would flood your main conversation with search results, logs, or file contents you won't reference again."[3] This is the safest use of the feature by Cognition's logic: a subagent that answers a narrow question and returns only the answer does not make design decisions that conflict with anything.
Operational costs Anthropic reported
Anthropic lists problems that appear once the system is in production:[1]
- Errors compound. Agents are stateful, so Anthropic built resumption from checkpoints rather than restarts, plus retry logic.
- Debugging is harder. Agents are non-deterministic, so the team added production tracing.
- Deployments interrupt running work. It used rainbow deployments to shift traffic gradually.
- Lead agents wait synchronously for each batch of subagents, which limits steering. Asynchronous execution is named as a future direction.
For evaluation, Anthropic started with about 20 queries representing real usage, used an LLM judge with a rubric (factual accuracy, citation accuracy, completeness, source quality, tool efficiency), and kept human testing because it caught issues automation missed.[1] For building your own, see our guide to building LLM evals for your application.
Decision checklist
Choose a single agent first. Add subagents only if you can answer yes to the relevant item:
- Is the work breadth-first? Several independent questions, each answerable without seeing the others' results.
- Is it mostly reading? Workers that only gather information cannot make conflicting design decisions.
- Does a worker's output fit in a summary? If the lead needs the worker's reasoning, a summary will lose it.
- Is the result worth the tokens? Budget for something near the reported 15x on the first version, then measure your own figure. See tokens, context windows and what a request costs.
- Can you evaluate it? Without a small eval set, you cannot tell whether the added complexity helped. Compare against a single-agent baseline on the same queries.
- Have you limited what each worker can do? Narrow tool access and permissions reduce the damage of a worker going wrong; see how AI agents work and how to secure them.
If a task fails items 1 to 3, a single agent with good context management, or one agent that delegates only narrow lookups, is the design both sources support. The cost side of using smaller models for workers is covered in model routing and cascades.
What remains uncertain
- Anthropic's 90.2% figure comes from an internal eval with Claude Opus 4 and Sonnet 4. We did not test whether it holds for current models or other tasks.
- Cognition's post is an argument with one worked example, not a benchmark.
- Neither post tests the same task in both designs, so the "different task shapes" explanation is our reading of why they disagree.
- Tools change quickly. The Claude Code behaviour above was current on 2026-10-13 and may differ by the time you read this.
