Multi-Agent Systems in 2026: +90% on Research, -70% on Planning, 15x Tokens

Every few weeks someone shows me an architecture diagram with seven agents on it, each with a job title, and asks which framework to build it in. My first question is always the same: what did one agent score on this task, and what did it cost? Usually nobody has measured. This post is about multi-agent systems in 2026: what the published evidence says about when several LLM agents beat one, why the same split that helps research can wreck planning and coding, what the token bill looks like, how these systems fail (the MAST taxonomy), and how to evaluate the decision instead of guessing.

What is a multi-agent system, and how is it different from subagents?

A multi-agent system is any setup where more than one LLM context does part of the work and something combines the results. That covers three shapes that behave very differently in production:

• Orchestrator-worker. A lead agent plans, spawns workers with narrow briefs, and merges what comes back. Anthropic describes this as one of its core workflow patterns in Building effective agents, and it is what Claude's subagents implement.
• Handoffs. A triage agent passes the whole conversation to a specialist, who then owns it. The OpenAI Agents SDK separates this from the "agents as tools" pattern, where a manager keeps control and calls specialists like functions.
• Peer or decentralised teams. Agents message each other directly, debate, or vote. This is the shape most demo diagrams show and the one with the weakest evidence.

"Subagent" is the vendor word for the first shape. In the Claude Agent SDK, a subagent starts with a fresh context, gets only the prompt string the parent writes for it, and returns only its final message. That isolation is the whole point, and also the whole risk, as the rest of this post shows. If you want the basics of the single-agent loop first, my explainer on what AI agents are covers workflows versus agents.

When do multiple agents beat one? The evidence so far

The strongest positive result is still Anthropic's own. In June 2025 it published how it built its multi-agent research system: a Claude Opus 4 lead agent directing Claude Sonnet 4 subagents beat single-agent Opus 4 by 90.2 percent on an internal research evaluation. Parallelism (the lead spawning 3 to 5 subagents at once, each running several tools in parallel) cut research time by up to 90 percent on complex queries.

The interesting part is the explanation. On BrowseComp, three factors explained 95 percent of the variance in performance, and token usage alone explained 80 percent. In other words, a big chunk of the multi-agent win is that it lets you spend more tokens on a problem than one context window can hold, in parallel. That is a real advantage for breadth-first search across many sources. It is not magic coordination.

The most careful independent study I know of is Google's Towards a Science of Scaling Agent Systems (Kim et al., first posted December 2025, revised April 2026). It ran 260 configurations across six benchmarks, five architectures and three model families, with tools, prompts and compute held constant. The results cut both ways:

Benchmark or study	Best multi-agent result vs single agent	Worst result	Source
Anthropic internal research eval	+90.2% (Opus 4 lead, Sonnet 4 workers)	not reported	Anthropic, Jun 2025
Finance-Agent (decomposable)	+80.8% (centralised)	+57%	Kim et al. v3
BrowseComp-Plus	+9.2% (decentralised)	about -35% (independent)	Kim et al. v3
Workbench	+5.6% (decentralised)	about -11%	Kim et al. v3
Terminal-Bench	+1.7% (independent)	-19.2% (centralised)	Kim et al. v3
SWE-bench Verified	-2.1% (hybrid)	-14.9% (independent)	Kim et al. v3
PlanCraft (sequential)	-39.1% (hybrid)	-70.0% (independent)	Kim et al. v3

The mean change across all benchmarks was -0.3 percent, with a confidence interval wide enough to drive a bus through. The paper's own summary is that architecture-task alignment decides the outcome. Two findings matter most for anyone designing a system. First, a capability ceiling: once a single agent already scores above roughly 45 percent on a task, adding agents tended to make results worse. Second, the coding benchmarks, which are what most of my readers actually build, were flat to negative.

Why multi-agent systems fail: context, decisions and the MAST taxonomy

Cognition's Don't Build Multi-Agents (Walden Yan, June 2025) gave the clearest explanation of the losses, a day before Anthropic published its win. Its two principles are short: share full agent traces, not just messages, and remember that actions carry implicit decisions, so conflicting decisions produce bad results. The example is a Flappy Bird clone split into "background" and "bird" subtasks. One worker builds a Mario-style background, the other a bird that looks nothing like Flappy Bird, and the merging agent inherits two incompatible sets of choices that neither worker knew the other had made.

The academic version is MAST, from Why Do Multi-Agent LLM Systems Fail? (Cemri et al., latest revision October 2025). The authors built a taxonomy from 150 traces with an inter-annotator agreement of kappa 0.88, then annotated more than 1,600 traces across seven frameworks including MetaGPT, ChatDev, Magentic-One and OpenManus. They found 14 failure modes in three groups. The most common, from the paper's breakdown:

• System design: step repetition (15.7 percent), unaware of termination conditions (12.4 percent), disobeying the task specification (11.8 percent).
• Inter-agent misalignment: reasoning-action mismatch (13.2 percent), task derailment (7.4 percent), failing to ask for clarification (6.8 percent).
• Task verification: incorrect verification (9.1 percent), no or incomplete verification (8.2 percent), premature termination (6.2 percent).

Read that list as an operator and it looks familiar. Loops that never terminate, workers that wander off the brief, and a "verifier" that rubber-stamps the output are the same failures I catalogued for single agents in AI agent failures in production; multiple agents just give them more places to happen. The paper's interventions are telling too. Better role specifications improved ChatDev by 9.4 percent, and adding a high-level verification step improved it by 15.6 percent. Those are design fixes, not more agents.

Google's study puts a number on the propagation problem. Independent agents with no central check amplified trace-level errors 17.2 times relative to a single agent; a centralised orchestrator contained that to 4.4 times. If you do build multi-agent, have something verify before merging.

What multi-agent systems cost: the token and latency multipliers

The bill is the part architecture diagrams leave out. Anthropic's own numbers: agents use about 4 times the tokens of a chat interaction, and its multi-agent system used about 15 times. Its stated condition for using the pattern is that the task's value has to be high enough to pay for that.

Kim et al. measured coordination overhead directly: 58 percent extra for independent agents, 263 percent for decentralised, 285 percent for centralised and 515 percent for hybrid, which they summarise as 1.6 to 6.2 times the single-agent token budget. Hybrid configurations also needed 44.3 turns against 7.2 for one agent. More turns means more latency, more places for a tool call to fail, and more log volume for whoever is on call. None of this is exotic. It is the same capacity and cost discipline we apply to any distributed system, and it belongs in the FinOps conversation about token spend before launch, not after the first invoice.

Cognition changed its mind, a bit: the single-writer rule

In April 2026 Cognition published Multi-Agents: What's Actually Working, and it is the most practical piece in this debate. Walden Yan keeps the original objection to parallel writers and describes three patterns that did work in Devin, all sharing one rule: one agent writes, the others contribute intelligence without taking actions.

1. A review loop with clean context. Devin Review sees the diff, not the coder's history, and catches an average of 2 bugs per PR, about 58 percent of them severe.
2. A "smart friend". A smaller primary model escalates hard problems to a bigger one through a tool call. This worked between frontier models and struggled when the primary was weak.
3. Manager delegation. A manager Devin splits large tasks across child Devins and coordinates them, which the post calls map-reduce-and-manage.

This lines up with Anthropic's guidance. Research is read-heavy and parallel, so workers can explore independently and the lead writes the report. Coding is write-heavy and sequential, so writers in parallel collide. The pattern that survives both camps is read in parallel, write in one place.

How to decide: a test before you split

My rule of thumb from all of this, as a checklist:

• Is the work decomposable into independent reads? Searching many sources, scanning many files, reviewing many services: yes. A plan where step 4 depends on step 3: no.
• Does one agent already score above about 45 percent? If so, the Google data says extra agents are more likely to hurt than help. Improve the prompt, tools or context first.
• Is the context the bottleneck? If a single agent fails because its window fills with exploration, a read-only subagent that returns a summary is the cheapest fix. Good context engineering often removes the need entirely.
• Can you afford 2 to 15 times the tokens? Price it per task, not per month.
• Who verifies? If no step checks the merged result, you are building the MAST verification failures on purpose.

Then measure it. The simplest honest evaluation is an A/B run of the same prompts with delegation switched off and on, scored by the same grader. Anthropic started its research evals with about 20 real queries and an LLM judge scoring 0.0 to 1.0, which is a sensible size for a first pass. Here is a minimal harness using the Claude Agent SDK (the step-by-step guide covers the setup):

# ab_multi_agent.py: same prompts, delegation off vs on. Records cost, turns, result.
# pip install "claude-agent-sdk==0.2.176"   (bundles Claude Code CLI 2.1.316)
import asyncio, json
from claude_agent_sdk import query, ClaudeAgentOptions, AgentDefinition, ResultMessage

PROMPTS = [line.strip() for line in open("eval_prompts.txt") if line.strip()]  # ~20 real tasks

WORKER = AgentDefinition(
    description="Read-only researcher. Use to investigate one sub-question in parallel.",
    prompt="Investigate only the question you are given. Return findings with file paths.",
    tools=["Read", "Grep", "Glob"],  # workers read, they never write
    model="sonnet",
)

def options(multi: bool) -> ClaudeAgentOptions:
    return ClaudeAgentOptions(
        allowed_tools=["Read", "Grep", "Glob"] + (["Agent"] if multi else []),
        disallowed_tools=[] if multi else ["Agent"],   # bare name removes the tool entirely
        agents={"researcher": WORKER} if multi else None,
        permission_mode="dontAsk",                     # anything not allowed is denied
        max_budget_usd=3.0,                            # hard stop per task
        env={"CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH": "1"},
    )

async def run(prompt: str, multi: bool) -> dict:
    row = {"prompt": prompt, "multi": multi}
    try:
        async for m in query(prompt=prompt, options=options(multi)):
            if isinstance(m, ResultMessage):
                row.update(subtype=m.subtype, cost=m.total_cost_usd, turns=m.num_turns, result=m.result)
    except Exception as e:          # budget or turn limits raise after the result is yielded
        row["error"] = str(e)
    return row

async def main():
    rows = [await run(p, multi) for p in PROMPTS for multi in (False, True)]
    with open("ab_results.jsonl", "w") as f:
        f.writelines(json.dumps(r) + "\n" for r in rows)  # grade results with your judge next

asyncio.run(main())

Grade the two result sets blind, with the same rubric, and compare quality per dollar, not quality alone. If the multi-agent arm does not win clearly on your own tasks, you have your answer, and it cost you an afternoon instead of a quarter. My agent observability post covers how to keep the traces from these runs so you can see where each arm went wrong.

FAQ

Are multi-agent systems better than a single agent?

Only on some tasks. Anthropic reported a 90.2 percent gain on breadth-first research, and Google measured +80.8 percent on decomposable financial reasoning, but the same study found -39 to -70 percent on sequential planning and flat or negative results on SWE-bench Verified. The average across six benchmarks was roughly zero.

How many more tokens does a multi-agent system use?

Anthropic measured about 15 times the tokens of a chat interaction for its multi-agent research system, against about 4 times for a single agent. Google's controlled study measured 1.6 to 6.2 times the single-agent token budget depending on architecture, with hybrid designs the most expensive.

What is the MAST taxonomy?

MAST is the Multi-Agent System Failure Taxonomy from Cemri et al. (arXiv 2503.13657). It defines 14 failure modes in three categories, system design, inter-agent misalignment and task verification, derived from more than 1,600 annotated traces across seven frameworks. Step repetition and reasoning-action mismatch are among the most frequent.

Should I use subagents or a full multi-agent framework?

Start with subagents for read-only work such as search, review or log analysis, where isolation keeps the main context clean and one agent still does all the writing. That matches the single-writer pattern both Anthropic and Cognition converged on. A peer-to-peer framework is the last thing to reach for, not the first. My framework comparison covers the options if you do.

What I would do this quarter

If I were starting an agent project this quarter, I would build one agent first and give it good tools, then run twenty real tasks through it and write down the score and the cost per task. Only if it plateaus, and only for steps that are genuinely parallel reads, would I add read-only subagents with a spend cap, a depth limit of one and a verification step before anything is merged or written. I would keep every write in a single agent. And I would rerun the same A/B harness whenever the model changes, because the 45 percent threshold moves every time the single agent gets better.

Related: AI Agent Frameworks Compared (2026): LangGraph, CrewAI, ADK and 7 More, Agent-to-Agent Protocols in 2026: A2A Reached 1.0, Three ACPs Died or Merged, and MCP Learned to Do Most of the Same Job and AI Agent Failures in Production: 5 Incidents, 14 Failure Modes (2026).