Multi-Agent vs Single Agent: When Orchestration Is Worth the Complexity

The Short Answer

Use a single agent by default. Add orchestration only when the extra agents do read-only work that runs in parallel, such as search, retrieval, or review, and when one run is worth roughly four times the token cost. Keep every write on one agent. Anthropic measures multi-agent systems at about 15x chat token usage against about 4x for a single agent, and two compute-matched 2026 studies found single agents match or beat most multi-agent systems once budgets are equal.

Why Did Cognition and Anthropic Reach Opposite Conclusions?

They did not. In June 2025, one day apart, the two most credible engineering teams working on agents published what read as opposite headlines. Cognition, the team behind Devin, posted "Don't Build Multi-Agents" on June 12. Anthropic posted "How we built our multi-agent research system" on June 13, reporting that its orchestrator-worker Research feature, a Claude Opus 4 lead spawning Claude Sonnet 4 subagents, outperformed single-agent Claude Opus 4 by 90.2% on their internal research eval.

Ten months later the positions were visibly the same. Cognition's follow-up on April 22, 2026, "Multi-Agents: What's Actually Working," says the narrower class that works is the one where writes stay single-threaded and the additional agents contribute intelligence rather than actions. Anthropic had already written the matching carve-out: domains that require all agents to share the same context or that involve many dependencies between agents are not a good fit, and most coding tasks fall into that category because they involve fewer truly parallelizable subtasks than research does.

Neither team was arguing about agent count. Both were describing workload shape. That distinction is the whole decision.

Split on Write Access, Not on Job Titles

Most teams design a multi-agent system by drawing an org chart: a researcher agent, a planner agent, a writer agent, a QA agent. That is a taxonomy of job titles, and it produces systems that fight each other.

The rule that survives production is simpler. If a subtask only reads, fan it out. Search, retrieval, code search, evidence gathering, critique, and review are all safe to parallelize because two agents reading the same repository cannot corrupt each other's work. If a subtask writes to shared state, meaning it edits files, mutates a record, commits, or sends something, keep it on one agent.

Cognition's illustration of breaking that rule is worth keeping in your head. Ask a swarm to clone Flappy Bird and one subagent builds a Super Mario Bros background while another builds a bird that does not match the game's assets or its movement. Neither made a mistake in isolation. Both made unstated decisions the other could not see, and the synthesis step cannot reconcile them. Their two principles cover it: share full agent traces rather than individual messages, and actions carry implicit decisions, so conflicting decisions carry bad results.

Their production data shows the read-only half working as predicted. Devin Review, their code review agent, catches an average of 2 bugs per PR, roughly 58% of them severe, which Cognition defines as logic errors, missing edge cases, and security vulnerabilities. The second agent adds judgment and never touches the branch.

What Orchestration Actually Costs

Anthropic publishes the multiplier directly: agents typically use about 4x more tokens than chat interactions, and multi-agent systems use about 15x more. That puts orchestration at roughly three to four times the cost of a single agent doing the same job.

The same post explains why. On the BrowseComp eval, three factors accounted for 95% of performance variance, and token usage by itself explained 80% of it, with tool call count and model choice as the other two. Anthropic's conclusion is that multi-agent systems need tasks whose value is high enough to pay for the increased performance.

Price it before you build it. A worked example at Anthropic list prices, $5 input and $25 output per million tokens for Claude Opus 5 and $3 and $15 for Claude Sonnet 5: a lead Opus 5 turn at 40K in and 8K out costs $0.40, and five Sonnet 5 subagents at 60K in and 4K out each cost $0.24 apiece, so $1.20. That is $1.60 per query, so $16,000 at 10,000 queries a month. This is arithmetic from published prices, not a benchmark. Do it on your own traffic before anyone writes an orchestrator, because a system that clears the business case at 500 queries a month can fail it at 20,000.

Two levers cut that bill without changing the architecture. Prompt caching bills cache reads at 0.1x base input, so design each subagent role around a stable cached prefix. The Batch API takes 50% off both input and output and stacks with caching.

Do the Benchmarks Support Multi-Agent?

Mostly not, once you control for compute. This is the part that gets left out of vendor comparisons.

Tran and Kiela's April 2026 paper, "Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets," held the reasoning-token budget fixed across Qwen3, DeepSeek-R1-Distill-Llama, and Gemini 2.5. Single agents matched or beat multi-agent systems, and the authors conclude that many reported multi-agent advantages are better explained by unaccounted computation and context effects than by architectural benefit.

BenchAgent, the harness behind "Do More Agents Help?" in June 2026, went further by normalizing the benchmark loader, tool access, answer contract, usage accounting, and trajectory logging across ten reasoning, coding, and tool-use benchmarks on GPT-4.1. At most one of six tested multi-agent systems matched the single-agent anchor on benchmark-balanced average accuracy. The other five trailed it by 2.56 to 11.29 points while sitting at worse accuracy-cost trade-offs.

Reliability is worse than the headline numbers suggest. The UC Berkeley-led paper "Why Do Multi-Agent LLM Systems Fail?" built MAST, the first multi-agent failure taxonomy, from 150 annotated traces with inter-annotator agreement of kappa 0.88, then applied its 14 failure modes, grouped into 3 categories, to more than 1,600 traces across seven frameworks. ChatDev managed 33.33% correctness on ProgramDev in their runs, and the authors report that the obvious structural fixes were still not enough to make performance reliable. The failures are coordination design, not model quality, which is the part no model upgrade will fix for you.

None of this means orchestration never wins. Anthropic's 90.2% result is real, and Microsoft Research's Magentic-One ablations show the coordination layer earning its place: without the Orchestrator's full ledgers, performance drops by 31%. It means the win is workload-specific and has to be demonstrated on your workload, at matched cost.

The Decision Table

OpenAI's guidance points the same direction: maximize a single agent's capabilities first, because more agents add complexity and overhead and a single agent with tools is often sufficient. On the tool row specifically, they are explicit that the problem is overlap and not count. Some implementations manage more than 15 well-defined, distinct tools while others struggle with fewer than 10 overlapping ones.

The one architectural argument for subagents that survives compute-matched testing is context isolation. Chroma's context rot study held task complexity constant across 18 models and varied input length, and performance degraded as inputs grew even on simple tasks. When the tempting fix is to stuff more into the prompt, a subagent with its own clean window is a real performance lever rather than a tidiness preference.

If You Do Build It, Build the Manager Shape

Use a central orchestrator that delegates through tool calls and synthesizes results. Cognition calls the unstructured-swarm approach, arbitrary networks of agents negotiating with each other, mostly a distraction, and names the working shape map-reduce-and-manage: a manager splits work, children execute, the manager synthesizes and reports back. OpenAI's manager pattern is the same shape.

Size the fan-out in the orchestrator prompt rather than hoping the model is frugal. Anthropic ships explicit rules: simple fact-finding gets 1 agent with 3 to 10 tool calls, direct comparisons get 2 to 4 subagents with 10 to 15 calls each, and complex research gets more than 10 subagents with clearly divided responsibilities. Without those rules their early versions spawned 50 subagents for simple queries.

Give every subagent four things in its brief: an objective, an output format, a tool and source list, and an explicit boundary. Anthropic's own failure case was a lead agent saying "research the semiconductor shortage," after which one subagent investigated the 2021 automotive chip crisis and two duplicated each other on 2025 supply chains. If you cannot write that brief in a paragraph, the task is not ready to delegate.

Budget for operations before the second agent exists. Agents are stateful and errors compound, and identical prompts produce different runs, which makes debugging harder than in any request-response service you have run. Build per-agent trace capture and resume-from-failure rather than restart, because a crash 40 minutes into a run should not burn the tokens twice. Ship releases by shifting traffic gradually with both versions live, the way Anthropic's rainbow deployments do, so a deploy does not kill in-flight agents. Then set a hard per-run token ceiling and a kill switch on subagent count, because the first production incident in a multi-agent system is almost never a wrong answer. It is a bill.

The Security Cost Nobody Prices In

Adding a second agent creates a risk class with no single-agent analogue: one agent treating another agent's output as trusted input. Every message between agents is untrusted text, and most orchestrators are written as though it is not.

This is demonstrated, not theoretical. Palo Alto Networks Unit 42 published proofs of concept for agent session smuggling, where a malicious remote agent misuses an ongoing session to inject instructions between a legitimate client request and the server's response. One extracted chat history, system instructions, available tools, and tool schemas from a financial assistant. The other caused that assistant to buy 10 shares without user consent, with the intermediate turns invisible in the interface. Unit 42 is explicit that this is not a vulnerability in the A2A protocol. It exploits implicit trust between agents, which any stateful protocol carries.

Decomposition can also defeat your own guardrails. Anthropic's report on a Chinese state-sponsored group that manipulated Claude Code into an espionage campaign against roughly thirty organizations describes the technique plainly: the attackers broke the work into small, seemingly innocent tasks that Claude would run without the full context of their purpose. Any safety check that evaluates one agent's slice rather than the whole plan has that hole.

Test accordingly. A NIST agent-hijacking evaluation found that attacks developed for a specific model raised success from 11% to 81%, and that repeating each attack 25 times instead of once raised average success from 57% to 80%. Single-attempt security testing understates risk for any non-deterministic agent, and an orchestrator gives you more injection surfaces to understate.

Grade It on pass^k, Not pass@1

Every architecture comparison should be compute-matched and repeated. The tau-bench authors introduced pass^k, the fraction of tasks where all k trials succeed, and found state-of-the-art function-calling agents succeeding on under 50% of tasks and dropping below 25% at pass^8 in retail.

Run each eval task 8 times and report the fraction where all 8 pass. An orchestrator multiplies the number of stochastic steps, so it multiplies that decay. If your A/B shows multi-agent winning, check whether it simply spent more tokens before you credit the architecture.

What This Looks Like in Our Work

We reach for orchestration when the workload justifies it and stay on one agent when it does not. Agent orchestration over existing data cut onboarding effort by 90%, and a call center QA system reached 100% automated coverage where manual review had only ever reached under 5%. Our delivery model is a proof of concept in days, production in 4 to 8 weeks, and 90 days of monitoring, and the architecture decision gets made against a measured cost per run rather than a diagram.

The Short Version

Agent count is the wrong variable. Ask which subtasks write to shared state, keep those on one agent, and fan out the reads. Price the run at roughly 4x single-agent tokens and confirm the business value clears it. Compare architectures only at matched compute, grade on pass^k, and treat every inter-agent message as untrusted input. Most teams that think they need a second agent need a sharper tool description and a cleaner task boundary instead.

Get a Free Technical Assessment

If you are deciding between a single agent and an orchestrated system, we offer a free technical assessment: a 30-minute call about your use case, followed by a written roadmap within 48 hours covering architecture, cost per run, evaluation, and timeline. There is no obligation, and the roadmap is yours to keep. Book at sasid.ai.