Contents8 sections
- Multi-agent vs single agent: the architectures compared
- Performance: where multi-agent helps and where it hurts
- Cost: can the task pay for roughly 15x the tokens?
- Error compounding: mistakes grow at every handoff
- When to use multi-agent: a decision checklist
- Multi-agent drawbacks and benefits at a glance
- Frequently asked questions
- Sources and references
Short answer to the multi-agent vs single agent question: split your AI agent into a team only when the work breaks into independent subtasks and the result is worth a much larger token bill. For sequential work, where each step depends on the last, or for tasks where every decision needs the same shared context, a single agent usually performs better and is far easier to debug. This guide reflects research and engineering write-ups available as of November 2026, mainly a controlled study from Google Research and MIT plus production lessons published by Anthropic and Cognition.
The debate is loud because both camps are partly right. "Don't build multi-agents" and "use a team of specialist agents" each describe real outcomes on different kinds of tasks. The useful move is to look at the shape of your own workload before you pick an architecture.
Multi-agent vs single agent: the architectures compared
A single agent runs planning, tool calls and reasoning in one loop with one continuous history. A multi-agent system divides the work among several agents and then combines what they produce. The MIT Media Lab summary of the research groups multi-agent designs by how results are combined:
Single agent
- How it works
- One agent, one unified interaction history
- Strength
- No context loss, simplest to debug
- Watch out for
- Context window limits, no parallelism
Independent
- How it works
- Agents work in parallel without talking; outputs merged at the end
- Strength
- Fast, broad exploration
- Watch out for
- No cross-checking, so mistakes pass straight through
Centralized
- How it works
- An orchestrator delegates, reviews and synthesizes worker output
- Strength
- Catches inconsistent results before merging
- Watch out for
- Quality depends on how well the orchestrator briefs workers
Decentralized
- How it works
- Peers debate and vote on a final answer
- Strength
- Diverse perspectives
- Watch out for
- Message volume grows quickly
Hybrid
- How it works
- Orchestrator plus peer-to-peer exchange
- Strength
- Flexible
- Watch out for
- Most complex and easiest to overbuild
Anthropic's Building effective agents gives the same starting advice: find the simplest solution that works and add complexity only when it demonstrably improves outcomes. For many applications, a single LLM call with retrieval and good examples is enough.
Performance: where multi-agent helps and where it hurts

Google Research first described the study in a January 2026 blog post covering 180 configurations across four benchmarks. The expanded version summarized by MIT covers 260 configurations and six benchmarks: web research, financial analysis, planning, workplace tool use, software engineering and terminal tasks. Prompts, tools and per-system compute ceilings were held constant while only the architecture and model changed, which is what makes the comparison useful.
Parallel work: about 81% better on financial analysis
On Finance Agent, centralized coordination lifted mean performance from 34.9% to 63.1%, an 80.8% relative gain. Traces showed workers researching complementary sources, such as regulatory news and company filings, before the orchestrator combined them. Anthropic saw something similar in its own Research feature: a Claude Opus 4 lead agent with Claude Sonnet 4 subagents beat single-agent Opus 4 by 90.2% on an internal research eval. Its example task, finding all board members of companies in the S&P 500 Information Technology sector, is exactly the breadth-first kind of question that splits cleanly.
Sequential work: 39-70% worse on planning
On PlanCraft, a planning benchmark where each step depends on the previous one, every multi-agent variant underperformed the single agent, with relative declines of 39-70%. The traces show short, sequential workflows being needlessly delegated into separate research, inventory and execution steps, so a fixed budget went to agent chatter instead of the task. SWE-bench Verified also showed small-to-moderate declines across variants.
Stronger models shrink the case for splitting
The strongest statistical signal was the single-agent baseline. The researchers fitted a rule with a capability-saturation threshold near 45% single-agent success: above it, adding agents is predicted to give zero or negative gains. That rule matched the direction of the observed gain in 94% of 16 model-benchmark configurations on SWE-bench Verified and Terminal-Bench. The authors stress it is an empirical selection rule, not a universal cutoff, since those benchmarks used only 20 task instances per configuration. The practical takeaway is to re-test your agent team whenever you upgrade the model.
Cost: can the task pay for roughly 15x the tokens?
Much of the multi-agent advantage comes from simply spending more tokens. In Anthropic's BrowseComp analysis, three factors explained 95% of performance variance, and token usage alone explained 80%; the other two were the number of tool calls and model choice. Separate context windows let subagents process more material in parallel than one agent could hold.
The bill follows. Anthropic reports agents typically use about 4x more tokens than chat interactions and multi-agent systems about 15x more, and concludes that multi-agent systems need tasks valuable enough to pay for the extra performance.
- Usually worth it: research that would take a person hours or days, high-stakes due diligence, and jobs where the material overflows a single context window.
- Usually not worth it: quick fact lookups, fixed-format conversions, short sequential tasks and latency-sensitive customer chats.
- Include in the math: model pricing, subagent count, tool calls per agent and the cost of retries after failures.
Effort budgets matter. Anthropic's early agents spawned 50 subagents for simple queries, so the team wrote scaling rules into the prompt: one agent with 3-10 tool calls for simple fact-finding, 2-4 subagents for direct comparisons, and more than 10 only for complex research with clearly divided responsibilities.
Error compounding: mistakes grow at every handoff
Agents keep state across many steps, so a small early mistake can send the whole run down a different path. Anthropic describes errors as compounding and built checkpoints and resume logic rather than restarting failed runs from scratch. A multi-agent design adds another failure point on top: the handoff between agents.
Unreviewed merging is the riskiest pattern
The study measured a trace-level error-amplification factor of 17.2 for independent agents versus 4.4 for centralized systems. The researchers are careful to say this does not mean final answers were 17.2x or 4.4x more likely to be wrong; the metric captures extra work caused by coordination failures. The direction still matters: an orchestrator can intercept inconsistent worker outputs before aggregation, which is why verification at handoffs deserves engineering time.
Lost context produces conflicting decisions
Cognition's Don't Build Multi-Agents uses a Flappy Bird clone split into a background subagent and a bird subagent. One misreads its subtask, or both build pieces in clashing styles because neither can see the other's choices. Its two principles: share full agent traces rather than single messages, and remember that actions carry implicit decisions, so conflicting decisions lead to bad results.
Debugging and deployment get harder
Agents are non-deterministic even with identical prompts. Anthropic added full production tracing to explain reports of agents "not finding obvious information" and uses rainbow deployments so running agents are not broken mid-task by new code. Each extra agent adds another place where a bad decision can hide.
When to use multi-agent: a decision checklist
- 1
Measure a single-agent baseline
Run around 20 real queries and record success rate, tokens per task and latency. Anthropic recommends starting evals this small. Without a baseline you cannot tell whether a team helped.
- 2
Check whether the work truly parallelizes
Ask whether subtasks can finish without seeing each other's results. Independent sources or separate evaluation criteria are good candidates; step-by-step plans are not.
- 3
Compare cost and value per task
Put the extra token cost next to the gain in accuracy or time saved for one completed task. A small accuracy bump for several times the cost is a reason to stay single.
- 4
If you split, start centralized
Give each worker an objective, an output format, tool guidance and clear boundaries, and have the orchestrator review results before merging. Independent merging amplified errors most.
- 5
Verify and log every handoff
Have subagents write outputs to files or other storage and pass back references, which reduces the "game of telephone". Add format checks, source checks and full traces.
- 6
Re-test after model upgrades
A stronger model may make the single agent good enough. Periodically compare results with fewer agents.
A common middle ground is one main agent plus read-only helper subagents. Cognition notes that, as of June 2025, Claude Code's subagents answered well-defined questions rather than writing code in parallel, which kept exploratory work out of the main agent's context.
Agent architecture advice shifts with every major model release. You can follow AI news flowing through Telegram channels on the theddari AI Telegram trends page and see which topics developer blogs are covering on the blog trends dashboard.
Multi-agent drawbacks and benefits at a glance
Task shape
- Single agent wins
- Sequential, step-dependent work
- Multi-agent wins
- Many independent subtasks
Context
- Single agent wins
- Every decision needs shared context
- Multi-agent wins
- Material exceeds one context window
Cost
- Single agent wins
- Low task value or tight latency
- Multi-agent wins
- High task value that justifies about 15x tokens
Baseline
- Single agent wins
- Single agent already succeeds often
- Multi-agent wins
- Single agent fails frequently
Error control
- Single agent wins
- Runs must be easy to trace and reproduce
- Multi-agent wins
- An orchestrator can review worker output
The better question is not how many agents to run but whether the task splits cleanly and whether the gain beats the added cost and error risk. Build a single-agent baseline, add centralized subagents only where the work is parallel, and keep them only if your own measurements show they earn their place.



