Multi-agent vs single agent: when 3–10× the tokens pays off

A multi-agent system pays off when the task splits into independent parts that can run in parallel, each part needs its own context, and the result is valuable enough to cover 3–10× more tokens than one agent would spend. In every other case one agent with good tools usually wins. Research by Google Research, Google DeepMind and MIT shows how wide the gap is: on a decomposable financial analysis task, multi-agent coordination improved results by 80.8%; on sequential planning it degraded them by up to 70%.

The rule below comes from 2025–2026 research and vendor experience, with a decision checklist at the end.

01 · The 2025 debate: two posts a day apart

In June 2025 two teams published opposite conclusions a day apart.

Cognition, the company behind Devin, went first on 12 June with “Don’t Build Multi-Agents”. Its two principles: share full context, and remember that “actions carry implicit decisions, and conflicting decisions carry bad results”. Two sub-agents that build parts of the same app without seeing each other’s work produce pieces that don’t fit.

On 13 June Anthropic described its Research feature: a lead agent on Claude Opus 4 with Sonnet 4 sub-agents beat single-agent Opus 4 by 90.2% on an internal research eval. The price was tokens. Agents used about 4× more tokens than chat, the multi-agent system about 15× more than chat. On the BrowseComp benchmark token usage alone explained 80% of the variance in performance.

Both were right about their own tasks. Anthropic’s was breadth-first research, where sub-agents read different sources in parallel. Anthropic itself wrote that domains where agents must share context or depend on each other heavily “are not a good fit for multi-agent systems today”, and named most coding tasks as an example.

02 · What the research measured

The debate soon got numbers. Google Research, Google DeepMind and MIT first published their study in December 2025; version 3 (April 2026) covers 260 configurations: six agent benchmarks, five architectures (one agent plus four multi-agent schemes) and three model families. Tools, prompts and the total reasoning-token budget were held constant, so the comparison isolates architecture.

Four findings matter for design decisions:

1. Task structure decides the sign. The effect ranged from +80.8% on decomposable financial analysis to −70.0% on sequential planning. Google’s summary for PlanCraft: every multi-agent variant tested was 39–70% worse.
2. A ceiling. When a single agent already scores above 45%, extra agents give negative returns: coordination costs more than the remaining headroom. On SWE-bench Verified all multi-agent architectures were slightly worse than one agent.
3. Errors multiply. Independent agents without a check amplified errors 17.2× compared with a single agent; a central orchestrator that validates results held it to 4.4×.
4. Coordination costs tokens. Communication overhead ranged from 58% (independent agents) to 515% (hybrid schemes).

A paper by Tran and Kiela (April 2026) narrows the claim further: with the reasoning-token budget held constant, a single agent matched or beat multi-agent systems on multi-hop reasoning, a sequential task. Part of the gains attributed to architecture comes from extra compute. Their framing also predicts where several agents should win: when one agent uses its context poorly, which is exactly the “context pollution” case below.

03 · Where multi-agent systems break

Numbers on success leave open why multi-agent setups fail. The MAST study from UC Berkeley annotated 1,600+ traces from 7 popular open-source frameworks and found failure rates from 41% to 86.7%.

It grouped 14 failure modes into three families: system design, misalignment between agents and task verification. Among the most frequent:

• repeating steps that were already done (15.7% of traces);
• reasoning about one thing while doing another (13.2%);
• not recognising that the task is finished (12.4%);
• ignoring task requirements (11.8%);
• weak or wrong verification (9.1%).

Some of it is fixable by design. In ChatDev, letting the CEO agent have the final say raised task success by 9.4%. The authors add that robust reliability “often requires more than isolated fixes”. Coordination errors appeared even when agents talked in plain natural language inside one framework, so protocols like MCP or A2A don’t remove them.

04 · Where the two camps converged

By 2026 the positions moved closer, and the shared rule is practical.

Cognition updated its view in April 2026. Parallel-writer swarms still don’t work, but one class of patterns does: “multi-agent systems work best today when writes stay single-threaded and the additional agents contribute intelligence rather than actions”. Its examples are a code reviewer with a clean context and an expensive model consulted as a tool by a cheaper one.

Anthropic, in January 2026, named three situations where several agents “consistently outperform” one:

• context pollution, when unrelated material degrades the main agent’s work;
• parallel work, when subtasks really are independent;
• specialisation, when separate tool sets or focus improve the choice of actions.

“Outside these situations, the coordination costs typically exceed the benefits.” Anthropic also warns that teams have spent months on elaborate multi-agent architectures “only to discover that improved prompting on a single agent achieved equivalent results”.

One more detail changes how to split. Anthropic recommends dividing by context boundaries. Splitting by job titles failed in its own test: with agents for planner, implementer, tester and reviewer, the sub-agents spent more tokens on coordination than on the work. An agent that builds a feature should write its tests too, because it already holds the context.

05 · How many agents: scale effort to the task

If the task qualifies, the next question is how many. Anthropic’s research system started with the wrong answer: early versions spawned 50 sub-agents for simple queries and distracted each other with updates. The fix was a scaling rule written into the prompt:

• simple fact-finding: one agent with 3–10 tool calls;
• direct comparisons: 2–4 sub-agents with 10–15 calls each;
• complex research: more than 10 sub-agents with clearly divided responsibilities.

So “ten agents” is the top of the scale, for broad tasks with many independent parts.

06 · Try the cheaper fixes first

Many reasons to add agents have cheaper fixes inside one agent:

• Too many tools. Anthropic suggests a tool search tool once an agent has 15–20+ tools, and reports up to 85% fewer tokens with better tool choice. Vercel cut 80% of the tools from its text-to-SQL agent: success went from 80% to 100% on its five test queries, with 3.5× faster responses.
• Complex logic or overlapping tools. OpenAI’s guide names two reasons to split: a prompt full of if-then-else branches, and tools that overlap. Some teams handle 15+ distinct tools; others struggle with fewer than 10 similar ones. Its advice is to “maximize a single agent’s capabilities first”.
• A cluttered context. A sub-agent that searches or reads logs in its own window and returns a summary isolates context without a full multi-agent design. Claude Code works this way.
• Repeated know-how. Agent Skills (folders with instructions and scripts loaded on demand) specialise one agent instead of building a separate agent per use case.

The production data points the same way. Datadog’s State of AI Engineering 2026 found that 59% of agentic application requests made a single service call and only 18% made three or more: “a significant majority of agents are still monoliths”. Datadog counts service calls, not agents, so this is an indirect signal.

07 · Cost and time

The bill grows with the number of agents. Anthropic’s 2026 guidance: multi-agent implementations “typically use 3-10x more tokens than single-agent approaches for equivalent tasks” and often take longer overall. The main gain is coverage; total run time often grows. Sub-agents that run one after another bring multi-agent token costs without any time savings.

Scale adds its own limits. Cursor tried 20 agents coordinating through a shared file with locks; they ran at the throughput of two or three, waiting on each other, and the team moved to planners and workers. Anthropic’s team of 16 parallel agents built a C compiler over about 2,000 sessions and just under $20,000 in API costs. On the Linux kernel, one huge task, every agent hit the same bug and overwrote the others’ fixes; the team got unstuck by using GCC as an external reference to check against. Cognition notes that such demos share “a simple, verifiable success criterion”, which most real software lacks.

Datadog adds an operational point: the main production failure mode of LLM applications is capacity (rate limits), and it hits hardest on variable loops and “multiple collaborative agents”.

08 · A case: ten specialist agents for document review

StroyIntellekt, where I’m the product owner and lead developer, reviews construction cost documentation. Ten specialist agents (estimator, chief engineer, economist, contracts specialist and others) and an orchestrator check a full project package — estimates, PDF drawings, contracts — and the system returns one verdict, findings and a pack of ten report documents. The task fits the conditions above: review is mostly reading, which LangChain notes is easier to coordinate than writing; specialists need different expertise, and each agent has its own acceptance checklist; the output is a single verdict. Money and arithmetic run in deterministic code, and every number links to its file, sheet and row: agents explain the numbers, code computes them.

The same review can run in four modes: a parallel pipeline with strict JSON-schema outputs, a fast single-agent mode, a tool-calling agent loop, and a crew of agents on the OpenAI Codex SDK that hand work to each other. The figures that moved the product were elsewhere: a reference base of 103,000 federal estimate items and 150+ building codes raised parsing accuracy on our internal reference set from 21% to 86%, and an agent run went from 11 minutes to 67 seconds. In my view, the data and engineering around the agents mattered as much as how many agents there were.

09 · Where these findings stop

• Models age. MAST studied 2025 models (GPT-4o, Claude 3.7 Sonnet) on open-source frameworks; failure rates on 2026 models may differ.
• Some numbers are self-reports. Anthropic’s 90.2% comes from an internal, unpublished eval. Cursor, the C compiler and Cognition’s figures are company reports.
• Sources have interests. Anthropic sells managed multi-agent setups, Cognition sells Devin, LangChain sells LangGraph.
• Single agents get stronger. Context compaction and tool search shrink the “context pollution” case over time.

10 · Checklist: one agent or many

Answer five questions before you add an agent:

1. Does the task split into independent parts? If step two needs the result of step one, keep one agent.
2. Does each part need its own context? If agents would need to share full context, the split adds coordination without benefit.
3. Who writes? Keep one writer for the final result; other agents read, review and advise.
4. Does the value pay for 3–10× tokens and a longer run? A research report may; a routine CRM update usually doesn’t.
5. Have you tried the cheaper fixes? Better prompt, fewer or searchable tools, a sub-agent for reading, skills.

Then compare on your own tasks: run the same eval set on one agent and on the multi-agent version, with the token budget recorded. The guide to agent evals covers how to build that set, and the token price breakdown shows why several times more tokens rarely gets cheaper on its own.

How many agents does your system run today, and which one writes the final result?