When Multi-Agent Makes Things Worse (and When It Doesn't)

Two things are true at the same time this year.

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. And 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.

The tension is the story. Multi-agent is not a capability you switch on. It is a cost you pay for a specific benefit, and most teams pay it before they have measured whether the benefit exists.

What the evidence says

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.

The part people skip: on the synthetic set, expert-designed multi-agent systems outperformed the generated ones. So the paper is not a proof that teams of agents cannot work. It is a proof that the structure has to be earned by the task, and that a search procedure does not earn 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.

Why generated teams collapse

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.

When it does help

There are real cases, and they share a shape: the work genuinely 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, three result contracts, one report. No shared state, 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 genuinely long 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.

The decision framework

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.

The experiment that settles it

Do not argue about it. Run the comparison the paper ran, on your tasks.

Include failed work in the cost. The group's cancelled and orphaned attempts are real spend. Include review time; 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.

Reading the paper's method

Headlines about a paper are only as good as its method, so here is what the Illusion paper actually compared, and why the comparison is fair.

The baseline is deliberately boring: 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 the thing 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.

The caveat the headlines drop: on the synthetic set, expert-designed multi-agent systems did outperform the automated ones. 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. That distinction is the whole decision framework above.

What production harnesses do about orchestration

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.

What is absent is as telling. No harness in the study ships a swarm. None 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.

Result contracts, concretely

When parallel workers do earn their cost, the thing that keeps them from collapsing into conflicting edits is a contract per worker. 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.

The security angle

There is a second reason to be sparing with agents, and it is not cost.

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 certainly does not widen anyone's permissions. And the fewer agents there are, the fewer places that rule has to hold.

Reconciling this with the trends report

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. None of that is contradicted by the evidence here; what is contradicted is 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 the second before scaling the first.

Where this leaves the trend

The Anthropic report is describing where the tooling is going: harnesses that can spawn workers, protocols that can host other agents, long runs that outlast a session. That infrastructure is real, and we have written about it. It does not make multi-agent free, and the best evidence we have this year says that adding agents without a designed reason makes things worse at ten times the price.

Use the infrastructure when the task earns it. Measure it when you do. Keep the single agent as the baseline it has to beat.