Opening the post0.0s
7 min read
Anthropic's 2026 trends report lists multi-agent systems as one of eight trends and describes a shift from single assistants to coordinated agent teams running for hours. In the same year, an ICML 2026 paper titled The Illusion of Multi-Agent Advantage shows that automatically generated multi-agent systems consistently underperform a single agent using chain-of-thought with self-consistency, while costing up to ten times more.
Multi-agent is a cost you pay for a specific benefit, and most teams pay it before they have measured whether the benefit exists.
Read the Illusion paper for what it tests, not for the headline. The authors evaluated automatically generated multi-agent systems, the kind produced by searching over agent architectures, against a plain single agent running chain-of-thought with self-consistency. They ran traditional reasoning datasets, an interactive multi-step workflow benchmark (BrowseComp-Plus), and a synthetic diagnostic set built to isolate the situations where multi-agent should have an edge.
The automated systems underperformed the single agent across the board while being up to ten times more expensive. The diagnosis is structural. The paper describes architectural bloat that prioritises superficial complexity which does not translate into functional utility: agents with redundant roles, and agents whose function collapses into repeating what another agent already did.
On the synthetic set, expert-designed multi-agent systems outperformed the generated ones. The paper's result is that the structure has to be justified by the task, and that a search procedure does not justify it.
That matches what production harnesses do. The eleven-system source study found orchestration to be the least developed of its seven subsystems, and where harnesses do parallelise, the named patterns are session-tree version control and recursive composition: isolated workers with explicit boundaries, not free-form swarms. The Anthropic report's own trend list puts multi-agent next to long-running agents and verification as the bottleneck; the report is describing a direction, not certifying that it is cheaper.
Trigger: Two or more agents are given overlapping responsibilities: a planner and a reviewer that both re-plan, or three researchers who all search the same source.
Detection: Compare the agents' outputs pairwise; if they are near-duplicates, you are paying for one answer several times.
Mitigation: Collapse the roles. One agent with self-consistency gets you the redundancy benefit at a fraction of the cost.
Trigger: An agent's specialised role degenerates into passing through or paraphrasing another agent's output, because the task did not need the specialisation.
Detection: Ablate the agent. If the result does not change, the agent was not doing anything.
Mitigation: Remove it. Keep only agents whose ablation measurably hurts.
Trigger: Parallel workers each behave as if they own the whole budget; the aggregate spend is n times what was planned.
Detection: Aggregate cost per accepted outcome, not per agent.
Mitigation: Budget reservations at the coordinator; fan-out limits; cancellation of orphan work on timeout.
Trigger: Two workers change the same file or the same decision; the merge is blind.
Detection: Integration failures that neither worker's own checks caught.
Mitigation: Result contracts per worker, one explicit integration owner, and independent verification of the merged result rather than of each piece.
Trigger: The coordinator summarises the task for a worker and the constraint that mattered does not survive the summary.
Detection: Workers violate constraints the coordinator knew about.
Mitigation: Pass the intent spec, not a summary; enforce constraints in the harness, not in the hand-off prose.
The first two are the paper's findings restated as symptoms. The other three are what teams meet in production the week after the demo worked.
There are real cases, and they share a shape: the work decomposes, the pieces are independent enough to run in isolation, and someone owns the integration.
Independent inspection tasks. Three questions about a codebase that do not depend on each other, such as an audit of dependency licences, a scan for a deprecated API, and a check of test coverage by module. Three isolated workers and three result contracts produce one report, with no shared state and no conflicting edits, and the parallelism buys wall-clock time.
Verification separated from generation. One agent proposes; a different agent, with a different prompt and no access to the first one's reasoning, verifies against the acceptance criteria. This is the one structure with evidence behind it in the harness study's verify-on-stop pattern, and it works because the second agent is adversarial to the first rather than redundant with it.
Context protection for long-running work. When a single session would exceed the window several times over and compaction is losing decisions, isolated workers on bounded sub-tasks with a shared intent spec can preserve more than one agent compacting itself. Measure it; the Illusion paper's context-protection argument did not hold up for its automated designs, and it may not for yours.
What these have in common is that a human designed the structure for a specific reason. That is the expert-designed case the paper says can win.
| Option | Task decomposes into independent pieces(w:1) | Pieces can run in isolated workspaces(w:1) | A clear integration owner exists(w:1) | Each piece has its own verification(w:1) | Wall-clock time matters more than cost(w:1) | Weighted score |
|---|---|---|---|---|---|---|
| Single agent with self-consistency | 2 | 5 | 5 | 3 | 2 | 68% The default. Beat this on a matched comparison before adding agents. |
| Parallel isolated workers, one integrator | 5 | 5 | 4 | 5 | 5 | 96% For independent inspection or generation tasks with result contracts. |
| Coordinator with specialised sub-agents | 4 | 3 | 3 | 3 | 4 | 68% Only where a human can name why each role exists and an ablation confirms it. |
Score your task on the criteria. If the first two rows score low, stop; a single agent will win and cost less. If they score high, the question becomes ownership and verification, and those are engineering decisions you make before adding the second agent, not after.
Do not argue about it. Run the comparison the paper ran, on your tasks.
Hypothesis: On our task class, a coordinated group of agents produces more accepted outcomes per unit of total cost than a single agent with self-consistency under the same aggregate budget.
Include failed work in the cost; the group's cancelled and orphaned attempts are real spend. Review time counts as well, because a result assembled from four workers often takes longer to review than one written by one agent. And accept the outcome: a single agent may legitimately win, and a no-change decision is a valid result of a good experiment.
Headlines about a paper are only as good as its method, so this section covers what the Illusion paper compared and why the comparison is fair.
The baseline is a single agent using chain-of-thought with self-consistency, meaning it samples several reasoning paths and takes a majority or selected answer. That is the cheapest form of redundancy there is, and it is what a multi-agent system has to beat, because if several samples of one agent do as well as several agents, the agents were not adding anything.
The challengers are automatically generated multi-agent systems, the kind produced by searching over architectures rather than by an engineer deciding what roles are needed. The authors evaluate on three kinds of task: traditional reasoning datasets, an interactive multi-step workflow benchmark, BrowseComp-Plus, and a synthetic diagnostic set they built specifically to contain the situations where multi-agent should have an advantage, such as tasks that decompose cleanly.
The finding is that the automated systems consistently underperform the baseline while costing up to ten times as much, and the diagnosis is architectural bloat that prioritises superficial complexity which does not translate into functional utility. The two failure modes they name, role redundancy and functional collapse, are the two you can test for in your own system by ablation.
On the synthetic set, expert-designed multi-agent systems did outperform the automated ones, which is the caveat the headlines drop. The paper is a result about automated design and about defaulting to multi-agent, not a proof that a human cannot design a team that works.
If multi-agent were as valuable as the marketing suggests, the eleven production coding harnesses in the source-code study would be full of it. They are not. Orchestration is the thinnest of the seven subsystems the paper identifies, and where it exists it takes two conservative shapes.
Session-tree version control: a session can be forked like a branch, a sub-task run on the fork with a narrowed scope, and its result folded back. The parent keeps ownership; the child cannot wander. Recursive composition: the harness runs itself as a sub-agent, inheriting the same loop, tools and permissions rather than a different agent with a different prompt. Both are ways of parallelising bounded work under one owner, which is the case the decision framework says can win.
No harness in the study ships a swarm or hands a task to a committee of differently prompted agents and merges what comes back. The people with the most production traffic through coding agents chose isolated workers with explicit contracts, and mostly chose one agent.
When parallel workers are justified, a contract per worker is what keeps them from collapsing into conflicting edits. Here is the shape we use.
{
"worker": "licence-audit",
"scope": {
"read": ["**/package.json", "**/LICENSE*", "**/pyproject.toml"],
"write": [],
"budget": { "tokens": 40000, "wallclock_s": 600 }
},
"result": {
"schema": "audit-findings/v1",
"must_include": ["package", "licence", "path", "evidence"],
"on_timeout": "return_partial_with_flag"
},
"integration": {
"owner": "coordinator",
"merge": "append_only",
"verify": "independent"
}
}Read the fields as answers to the failure modes. scope.write is empty because inspection workers do not edit; the conflicting-edits failure cannot occur. budget is reserved at the coordinator before the worker starts, so oversubscription cannot occur; the sum of the reservations is the aggregate budget. on_timeout says what a partial result looks like, so a timed-out worker returns something with a flag instead of vanishing, and the coordinator cancels nothing it does not own. integration.owner names who merges, merge says how, and verify: independent means the merged result is checked by something that did not produce it.
For generation workers that do write, scope.write is a disjoint set of paths per worker, and the integration step runs the full test suite on the merged tree rather than trusting each worker's own green.
Security is the second reason to be sparing with agents.
Every additional agent is an additional principal that can be persuaded, an additional channel through which a hostile tool result can travel, and an additional place where authority can leak. A systematisation paper this year, on the security of multi-agent LLM systems, frames it as safe agents failing together: components that are each acceptable in isolation compose into a system with failure modes none of them had alone. The mechanism is familiar from the firewall discussion. Agent A reads an injected instruction, cannot act on it, and passes it to agent B as a summary. Agent B trusts A more than it would trust a web page.
The practical rule follows from the framework rather than adding to it. Each worker gets its own scope and its own policy decision on every tool call. A worker's output is data to the coordinator, not instruction, and it does not widen anyone's permissions. And the fewer agents there are, the fewer places that rule has to hold.
Anthropic's report predicts coordinated agent teams, orchestrators with specialised agents working in parallel across separate context windows, and task horizons that stretch from minutes to days. The evidence here contradicts only the idea that it comes free.
The report's readers put human oversight and verification beside the multi-agent prediction, and the two belong together. A team of agents produces more output to verify, from more sources, with more seams. The infrastructure to run teams is arriving, ACP hosting, meta-harness policies, budget reservations, and this site has written about all of it. The infrastructure to know whether the team did better than one agent is the matched comparison in this piece. Run that comparison before scaling the team.