One agent or several: when splitting pays off

A research task runs slowly and tool results keep filling the context, so it is natural to ask: why not let a lead agent split the task and send several subagents to search in parallel? You can, but the split buys something specific: wall-clock time from parallelism and contexts kept apart from each other. You pay with more tokens, more hand-offs, and the information lost in those hand-offs. The more independent and read-only the subquestions are, the more a split pays; when steps depend on each other or the parts must share the same unstated decisions, a single agent is usually more reliable. Compare the two designs at the same token and tool budget.

Draft, pending review. The site owner has not reviewed this note yet; facts, emphasis and wording may change. Check the primary sources linked in the text before relying on it.

What multi-agent actually changes

Common building blocks already lists orchestrator-workers, parallelization and related structures, so this note does not repeat them. It asks one question: when the same task moves from "one agent finishes it in one context" to "a coordinator plus several subagents", what concretely changes?

What does not change matters as well. Subagents usually run on the same model and tend to share its blind spots, so sending more of them does not make their errors independent. More agents also do not mean more verification unless you design a review step on purpose.

The cost is not only tokens

The token and latency bill is worked out in the example below (every context carries its own fixed prompt, and planning and synthesis can only run serially). Here are four costs that are harder to see:

• Hand-off loss. A subagent compresses more than ten thousand tokens of raw results into a 1k summary, and the fact the coordinator needs may be in the part that was cut.
• Conflicting implicit decisions. Every action carries unstated choices, such as how to define "holiday" or which version of a notice to use. When several subagents choose independently, the combined result can contradict itself.
• Error propagation. When a subagent returns a wrong fact, the coordinator usually has no source text to check it against and writes it straight into the conclusion.
• Harder evaluation and debugging. The same input can take a different path each run; when the final answer is wrong, you first have to work out which agent made the mistake, and at which step.

What the primary sources say

Anthropic's Research system (2025-06-13)

Anthropic's engineering post describes its multi-agent research system: a lead agent makes a plan, sends several subagents to search in parallel, then synthesises. The most quoted sentence, in the section on the benefits of a multi-agent system, says that a multi-agent system with Claude Opus 4 as lead and Claude Sonnet 4 subagents "outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval". The example given is finding all board members of the companies in the S&P 500 Information Technology sector, which the single agent failed to do with slow, sequential searches.

What the sentence does not say matters as much: it gives no absolute scores for either side, does not say whether 90.2% is a relative gain or percentage points, does not say whether the two sides had the same token budget or number of tool calls, and the eval set is not public. By the post's own account, the two sides probably did not spend the same tokens: on BrowseComp, three factors explained 95% of the performance variance, and token usage alone explained 80% (the other two were the number of tool calls and the model choice); agents typically use about 4× more tokens than chat, and multi-agent systems about 15×. The authors conclude that multi-agent systems work mainly because they can spend enough tokens, so they only suit tasks valuable enough to pay for those tokens. The post also says plainly that domains requiring all agents to share the same context, or with many dependencies between agents, are not a good fit today, and that most coding tasks have fewer truly parallel parts than research.

Cognition: don't split yet (2025-06-12)

In Don't Build Multi-Agents, Walden Yan of Cognition makes the opposite engineering call. He imagines splitting "build a Flappy Bird clone" between two subagents, one for the background and one for the bird: one might produce a Super Mario-style background and the other a bird that neither looks nor moves like the game's, leaving the coordinator two halves that do not fit. He proposes two principles: share context, and share full agent traces rather than single messages; actions carry implicit decisions, and conflicting decisions produce bad results. His default is a single-threaded linear agent, with a model that compresses history when the task gets too long (which he admits is hard to get right), rather than a parallel split.

This is an argument from engineering experience with no controlled numbers. It does not fully contradict the Anthropic post: one is about read-heavy research that can run in parallel, the other about long tasks that must produce one consistent artifact.

MAST: how multi-agent systems fail

Cemri et al., Why Do Multi-Agent LLM Systems Fail? (v1 March 2025, v3 October 2025; listed among NeurIPS 2025 Datasets and Benchmarks Track papers, though the arXiv page does not record it), collected 1642 execution traces from 7 open-source multi-agent frameworks and annotated why they failed. The MAST taxonomy was built by 6 experts through a grounded-theory analysis of more than 150 traces; agreement was checked by 3 annotators over three rounds on 15 traces, reaching κ = 0.88; an LLM annotator (o1) then labelled the full dataset, agreeing with human labels at κ = 0.77.

MAST has 14 failure modes in three categories. According to Figure 1 of v3: system design issues (ignoring task or role specifications, repeating steps, not knowing when to stop, and so on) make up 44.2%; inter-agent misalignment (not asking for clarification, derailing from the task, withholding key information, and so on) 32.3%; task verification (premature termination, missing or incorrect verification) 23.5%. The introduction reports failure rates between 41% and 86.7% across these systems. It measures why multi-agent systems fail; it does not compare them with a single agent at equal budget.

Budget-controlled comparisons (2025–2026)

• Kim et al. of Google Research, Google DeepMind and MIT, in v3 (April 2026) of Towards a Science of Scaling Agent Systems (preprint), ran 260 configurations across 6 agent benchmarks, 5 architectures (a single agent and 4 multi-agent variants) and 3 model families, and state that they standardised tools, prompts and compute (v1 and v2 had 4 benchmarks and 180 configurations, so cite the version). The change relative to a single agent ranges from +80.8% on decomposable financial analysis to −70.0% on the sequential planning task PlanCraft; on PlanCraft, all 4 multi-agent variants got worse (−39% to −70%). Their regression also shows that once the single-agent baseline exceeds roughly 45%, adding agents has negative returns.
• Tran and Kiela of Stanford, in Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets (preprint, April 2026), fix the "thinking token" budget and compare a single agent with 5 multi-agent architectures on FRAMES and MuSiQue 4-hop. Except at the lowest budget of 100 tokens, where almost no reasoning happens, the single agent is best or statistically indistinguishable from the best at every budget; the paper also says it spends fewer thinking tokens. A multi-agent design becomes competitive only after heavy masking or replacement of context tokens, and that test used a single model (Qwen3-30B-A3B) and compared only against the sequential multi-agent variant. They also point out that artifacts in API budget control (particularly for Gemini 2.5) and in the benchmarks themselves can inflate the apparent gains of multi-agent designs. Note that this is text-only multi-hop reasoning without tools.
• Gao et al., Single-agent or Multi-agent Systems? Why Not Both? (May 2025), compare the two across several agent applications and report that the advantage of multi-agent over single-agent shrinks as models get stronger.

Taken together, the most consistent conclusion is: when a task splits into independent information streams, a split may help; when steps are strongly sequential or a single agent already does well, a split often hurts. As of 2026-10-15, neither of the first two preprints carries formal publication information on arXiv; their exact percentages depend on their own budget definitions and baselines, so do not transfer them directly to your task.

Work it through: three subquestions, split or not

All numbers below are teaching assumptions for seeing the mechanism, not measurements of any system.

Task: find this year's holiday opening rules for three libraries, A, B and C (reusing the library example from Deep Research). The three subquestions are independent.

• Each subquestion needs 4 tool calls; each call (one model step plus the tool's return) takes 10 seconds and returns 4k tokens.
• Each context carries a fixed 3k prompt (system prompt, tool descriptions, task); the final answer is 2k, and writing it is one more 10-second step.
• In the multi-agent version, the coordinator plans for 10 seconds and writes a 0.5k brief per subagent; each subagent returns a 1k summary; the coordinator then spends 10 seconds synthesising.
• Tokens count each piece of content once per context it enters, which amounts to assuming re-reads are cached. A real bill also depends on whether every step re-reads the whole context: the longer a single agent's context, the more each re-read costs.

Time drops to 60 seconds, but not to a third: planning and synthesis cannot run in parallel. Tokens rise by about 34%, from the repeated fixed prompts, the briefs and the summaries.

Now the chance of a correct answer. Suppose the final answer needs one key fact from each subquestion. Let $s_1$ be the probability that the single agent, in a long context mixing 12 results, finds and keeps each fact; let $s_2$ be the same probability for a subagent whose short context holds only its own 4 results; let $d$ be the probability that a summary drops the fact. All three facts must be right:

$$ P_{\rm single}=s_1^{\,3},\qquad P_{\rm multi}=\big(s_2\,(1-d)\big)^{3}. $$

Take $s_1=0.90$ and $s_2=0.95$. The single agent gets $0.9^3=0.729$. With $d=0.02$, the multi-agent version gets $(0.95\times0.98)^3\approx0.807$ and the split wins; with $d=0.10$, it gets $0.855^3\approx0.625$ and the split loses. They break even when $s_2(1-d)=s_1$, that is $d^*=1-0.90/0.95\approx5.3\%$.

The formula shows that any accuracy gain from splitting comes entirely from $s_2>s_1$, that is, from short contexts missing less than a long one. If the single agent already uses its context well ($s_1=s_2$), any $d>0$ makes the multi-agent version worse. This points the same way as Tran and Kiela's argument.

Now change one condition: the subquestions become sequential. First check whether library A switched to the city's new notice, then use that notice to check library B, then library C. The parallel width drops to 1, and the multi-agent time becomes $10+40+10+40+10+40+10=160$ seconds, slower than the single agent's 130; tokens stay around 71k; and A's finding is retold twice, through "summary → coordinator → next brief". The split keeps only one benefit, context isolation, and costs an extra 30 seconds and about 18k tokens.

Change a different condition: the three subquestions are independent again, but each must decide whether "holiday" includes the eve of a public holiday (many libraries close early that day). If the brief does not say, and each subagent independently picks one reading with probability 0.8 and the other with 0.2, the three results use a consistent definition with probability only $0.8^3+0.2^3=0.52$. A single agent makes this decision once, so its results are consistent by construction, though possibly consistently wrong. The fix is to put the definition into every brief, or to check definitions explicitly during synthesis, not to add another agent.

How to choose: start from the shape of the task

The basis for each row:

• The first row is the breadth-first querying that Anthropic says suits multi-agent systems best; the second matches the degradation Kim et al. saw on PlanCraft; the last matches the saturation point of about 45% they report.
• The third row is Cognition's argument. They describe Claude Code as of June 2025: subagents usually only answered questions and did not write code in parallel with the main agent.
• Fourth row: Anthropic describes subagents as "intelligent filters", and Cognition also says a subagent's investigation need not stay in the main agent's history.
• The fifth row is engineering advice; I did not find a dedicated controlled experiment.
• The evidence for the sixth row is mixed: MAST finds that systems with explicit verifiers fail less overall, but many verifiers only do surface checks (such as whether code compiles); Kim et al. measure error amplification of 17.2× for independent agents versus 4.4× for a centralised design, but in their regression that controls for other metrics, the amplification factor itself is not significant.

How to evaluate: equal budget, inspect hand-offs, follow traces

Align the budget first. At minimum, fix total tokens (input and output recorded separately), the number of tool calls and a wall-clock limit, then compare success; ideally compare at several budget points and plot a curve. If the multi-agent version lets each subagent search twice as much (8 calls per branch), it takes about 100 seconds and about 119k tokens; then give the single agent the same 24 calls (about 250 seconds, 101k tokens) before comparing, or the gain may simply be extra spending. Record actual consumption, not the requested budget; Tran and Kiela found that the two can disagree.

Use the same task set for paired comparisons. Run both designs on every task, several times each, and look at paired differences and their spread rather than two averages; see Controlled comparisons and slices. Anthropic's experience is that about 20 real queries were enough early on to see large changes; research outputs were graded by an LLM judge with a rubric covering factual accuracy, citation accuracy, completeness, source quality and tool efficiency, alongside manual testing, because people find edge cases that evals miss.

Check every hand-off. Record briefs and summaries as spans in the trace, and on a sample check whether each fact the answer needs appears in the subagent's raw tool results, and whether it appears in its summary.

trace_id=demo-41
lead.plan            → brief_A, brief_B, brief_C
  sub_A  tool×4      → summary_A (1k)   key fact: in sources, not in summary   ← hand-off loss
  sub_B  tool×4      → summary_B (1k)   key fact: not in sources at all        ← not found
  sub_C  tool×4      → summary_C (1k)   key fact: in both
lead.synthesize      ← summary_A..C

"In the sources, not in the summary" is hand-off loss: change the summary format or pass file references instead (Anthropic has subagents store their outputs in external systems and return lightweight references). "Not in the sources at all" is a search problem, and more agents will not fix it. The MAST categories make a usable labelling vocabulary.

Debug by following the trace, not by asking the model. Parent and child spans should connect the coordinator and every subagent; see Agent observability for the fields. Pinpointing which agent failed at which step is hard in itself: Zhang et al.'s Who&When (ICML 2025) tests automated attribution on failure logs from 127 multi-agent systems, and the best method identifies the responsible agent only 53.5% of the time and the failing step only 14.2% of the time. Treat an LLM's attribution as a lead; confirm the cause with a controlled replay, for example by swapping one subagent's summary for a correct version and checking whether the final answer becomes correct.

What you can and cannot conclude

Read next: how to write the split structures in Common building blocks, question queues and evidence records in Deep Research, full cost accounting in Choosing an agent model, and when to bring in a person in Human-in-the-Loop.