Key facts.
- Tran and Kiela found single-agent systems match or beat multi-agent ones under equal token budgets, grounded in the Data Processing Inequality, so adding components and handoffs does not reliably buy value but does add cost and failure surface. source
- On SWE-bench Pro, a benchmark of long-horizon software engineering tasks, the strongest frontier models resolve only about 23%, showing that broad, multi-step ambition is where even top models fail most, and failures drive cost. source
- Independent analysis reaching the same conclusion finds the claimed multi-agent advantage often overstated and context-dependent rather than general, reinforcing that more breadth is not a reliable path to more value. source
Why does breadth multiply cost instead of adding to it?
Each added capability lowers success and raises per-outcome cost faster than breadth helps; single agents matched multi-agent ones under equal budgets, and a stronger model won't rescue breadth: SWE-bench Pro's best ~23%. (arXiv:2604.02460)
Because cost per successful outcome depends on the success rate, and the success rate falls with breadth. A narrow agent does one thing, so it has one set of failure modes and a high success rate, which keeps its per-outcome cost low. A broad agent does many things, and each capability brings its own failure modes, its own tool calls, and its own chances to retry. The success rate is roughly the product of the per-step success rates, so adding capabilities drives it down multiplicatively, and the per-outcome cost up by the same factor. The SWE-bench Pro result is this effect at the frontier: long, multi-step tasks resolve at around 23% even for the best models, so a broad agent attempting them pays for the roughly three-in-four runs that fail.
The Tran and Kiela finding closes the loop on the common escape hatch, which is to add more agents to handle the breadth. Under equal budget, that did not help, because every handoff loses information and adds a place to fail. So the broad agent cannot buy its way out of the cost with more architecture. The only reliable fix is less scope, which raises the success rate and lowers the per-outcome cost at the same time.
What does the disproportionate cost look like in practice?
A narrow agent with a 90% success rate pays for roughly one retry per ten outcomes. A broad agent whose breadth drops it to a 30% success rate pays for more than two failed runs per successful one, so its per-outcome cost is several times higher even before the extra tool calls and longer context that breadth brings. The broad agent often looks more capable in a demo, because it can attempt anything, but attempting is not completing, and the cost model counts completions. The narrow agent that does one thing reliably wins on the only number that decides whether the project survives.
| Property | Narrow agent | Broad agent |
|---|---|---|
| Failure modes | Few | Many, multiplicative |
| Success rate | High | Low, product of steps |
| Cost per outcome | Low | Disproportionately high |
| Demo impression | Modest | Impressive, misleading |
The Pattern Intelligence Layer is where scope discipline shows up in the numbers. Success rate and cost per outcome are tracked at the pattern level for each capability, so the cost of breadth is visible before it is committed, and the scope that keeps the economics positive is the one you ship. Reliability at the pattern level is what makes the narrow, scoped agent the affordable one, which is usually the one that lasts.
Frequently asked questions
Isn't a do-everything agent more efficient?
No. Breadth lowers the success rate multiplicatively, and a lower success rate raises cost per outcome faster than the breadth helps. Narrow and reliable is cheaper.
Can we add more agents to handle the breadth?
Tran and Kiela show that did not beat a single agent under equal budget, because every handoff loses information and adds failure surface. More architecture is not the fix.
Why does the broad agent demo so well?
Because it can attempt anything. But the cost model counts completions, not attempts, and on hard multi-step work even top models complete little, as SWE-bench Pro shows.