The vendor number, and why it is not enough
The most quoted figure comes from a vendor publication in June 2025: a stronger lead agent combined with weaker subagents outperformed by 90.2% the same strong model working alone.
Three things go with it, and the same source states all three:
- The evaluation is internal, and the task was finding the board members of the IT sector of a stock index. That is a breadth-type, parallelisable search — the most favourable case there is for a multi-agent setup.
- The token cost: agents use roughly four times as many tokens as a conversation; multi-agent systems fifteen times as many.
- And the most important one: "token usage by itself explains 80% of the variance."
That last sentence effectively says that most of the improvement does not come from the architecture, but from the fact that more computation was spent.
(Internal, unpublished evaluation, with no published methodology or sample size — that is how it has to be cited.)
The counter-evidence: at an equal token budget
A paper from April 2026 asked exactly this question: what is left of the difference once you fix the compute cost?
Their wording, verbatim: the strong results reported for multi-agent systems are "often confounded by increased inference compute. When compute is normalised, single-agent systems match or outperform multi-agent ones."
Measured across three model families, with several multi-agent architectures and an identical thinking-token budget: the single-agent system consistently matched or beat the multi-agent one on multi-step reasoning tasks.
And there is a theoretical basis behind it, plus a prediction that is precisely the thesis of this article:
A multi-agent setup becomes competitive when the single-agent system's context utilisation degrades — or when you spend more compute.
In other words: the value is not the parallelism, it is that the subtask runs in a clean window.
Context degradation, measured
If the thesis is clean context, then we have to show how much the dirty kind costs.
The headline finding of a measurement series covering 18 models, word for word: models do not use context uniformly — their performance becomes increasingly unreliable as input length grows.
And the sharpest partial result: even a single out-of-place item degrades things compared with the baseline.
There is independent, quantified confirmation of this too. A function-calling benchmark measures the multi-turn task separately in a base and a long-context variant, on the same models:
| Multi-turn, base | Multi-turn, long context | Drop | |
|---|---|---|---|
| The top of the field | 63–81% | 56–70% | −0.5 to −10.5 points, model by model |
(Own calculation from public leaderboard data. The median across the seven models measured is 8 points; only one model saw a drop as small as 0.5 points — the effect is model-dependent.)
This is the quantified basis of the article's thesis: longer context, independently of step count, is a measurable loss in itself.
On top of that comes the long-known finding that models make better use of information placed at the beginning and the end of the context than in the middle — plus an explanation worth remembering: the model has an attention budget, and every added token spends some of it.
This is where it becomes clear what a subagent actually does: it works in its own clean window, burning tokens on the order of tens of thousands — and hands back a condensed summary of 1,000–2,000 tokens. What enters the main agent's context is not the work, it is the result.
When is it worth it?
There is measurement for this as well. A 2025 study looked at tasks along two dimensions: depth (how long the reasoning chain is) and breadth (how many different capabilities it takes).
The finding: the advantage of a multi-agent setup grows along both dimensions, and more strongly with depth.
Translated into a practical rule: splitting pays off when the subtasks are independent and require different capabilities. If they build on each other, it does not.
When is it not?
The best source here is the primary documentation, which spells out the negative cases:
DO NOT USE A SUBAGENT IF
- the task needs frequent back-and-forth or
iterative refinement;
- several stages SHARE significant context
(planning, implementation and testing together);
- it is a quick, targeted change;
- latency matters.
And one technical detail that follows from this: the subagent starts in a fresh, isolated window. It cannot see the history of the conversation, it cannot see what you have read so far. That is exactly its advantage — and exactly why it is expensive when the task needs shared context.
What it is good at, from the same documentation: preserving context (the exploration stays out of the main conversation), cost control (the subtask can go to a faster, cheaper model), restriction (the subagent gets fewer tools), and specialisation (a focused system prompt).
Two vendors, one day apart
The best illustration of how little consensus there is on this subject.
12 June 2025: one tool vendor publishes a piece titled "Don't build multi-agent systems". It sets out two principles: share context, and not just the messages but the full trace; and actions carry implicit decisions, and conflicting decisions produce bad results. Its sharpest sentence: running multiple agents together in 2025 "only yields fragile systems".
13 June 2025 — the next day: another vendor publishes its 90.2% multi-agent result.
(The first piece contains no measured number — it is experience and a position. The second cites an internal eval. Neither is an independent measurement.)
Coordination failures, measured
Finally, the numbers on what goes wrong if you do split the task. The same study of 1,642 annotated runs that produced the failure taxonomy:
Inter-agent misunderstanding accounts for 32.3% of failures. Within that:
| Failure mode | Share |
|---|---|
| Reasoning–action mismatch (it states what it will do, then does something else) | 13.2% |
| Task derailment | 7.4% |
| Fails to ask for clarification | 6.8% |
| Conversation resets | 2.2% |
| Ignoring another agent's input | 1.9% |
| Withholding information (the "lost handover") | 0.8% |
On top of that comes step repetition at 15.7% — the measure of duplicated work.
And the study's own framing, worth quoting: despite the enthusiasm for multi-agent systems, "their performance gains on popular benchmarks are often minimal."
The how-to
1. ASK FIRST: IS IT INDEPENDENT?
If the subtasks build on each other, do not split.
Measurement says the gain comes with independence.
2. A SUBAGENT RETURNS A RESULT, NOT WORK
A 1-2 thousand token summary. If it hands back the
whole trace, you lost the clean-context advantage.
3. GIVE IT THE WHOLE TASK
It starts in a fresh, isolated window: it cannot see
what you know. What you do not write down is not there.
4. GIVE IT FEWER TOOLS, NOT MORE
Narrowing is free here, and it improves selection
accuracy.
5. A CHEAPER MODEL FOR THE SUBTASK
This is one of the real, measurable gains of splitting.
6. MEASURE DUPLICATION
The most common coordination failure is step repetition.
If two subagents do the same thing, the split is wrong.
The third point is the most common mistake. The subagent does not know what you have discussed so far — and that is not a shortcoming, it is the point. But it does mean the task description has to be complete on its own.
Common misconceptions
- "More agents give better results." At an equal token budget, the measurement says they do not. Most of the improvement comes from the extra compute.
- "Splitting speeds things up." Latency may drop, but by the published multipliers the token cost grows several-fold.
- "The subagent can see what we have done so far." It cannot. It starts in a fresh, isolated window.
- "Coding is good ground for splitting." The primary documentation says that in most coding tasks there is less genuinely parallelisable work than in research.
- "If it does not work, add another agent." The measured share of coordination failures is above thirty per cent — and every further agent adds to that too.
- "The 90.2% is proof." It is an internal evaluation, on the most favourable task type, and the same source writes that 80% of the variance is explained by token consumption.
What to take away
A subagent is not a parallelisation tool, it is a context management tool. That distinction decides when it is worth using.
The practical question is therefore not "how many agents should I split this into", but which subtask is the one that dirties the main context. Exploration, long searches, going through many files — those typically do. Planning, implementation and testing together, on shared ground — typically do not.
And one cheap check: if the subagent hands back an answer as long as the work it did, the split gained you nothing. Condensation is the whole point.
Why reliability degrades with step count — and why self-checking does not help — is worked out step by step in the agent reliability math post, with the tables; memory and forgetting are the subject of the agent memory post, in detail.