The single agent vs multi-agent systems question comes down to the shape of your task, not the sophistication of your setup. Some work splits cleanly and gets better when you divide it. Other work falls apart the moment two agents hold slightly different ideas of what's going on. Here's how to tell which one you have.
What we mean by single-agent and multi-agent
A single agent is one model running in a loop. It reads the task, calls tools, looks at the results and decides what to do next, all within one continuous context.
A multi-agent system splits that job across several model instances. The most common pattern is orchestrator-worker. A lead agent breaks the task into pieces, hands each piece to a subagent, and combines what comes back.
Both are "agents." The difference is whether the thinking happens in one place or gets spread out.
The case for multi-agent: when parallel work pays off
Anthropic's engineering team published a detailed account of how it built its multi-agent research system. In its internal evaluation, a setup with Claude Opus 4 as the lead and Claude Sonnet 4 subagents beat a single Claude Opus 4 agent by 90.2%.
The reason is worth understanding. Anthropic found that token usage alone explained about 80% of the variance in research quality. Multi-agent systems help partly because they let you spend more tokens on a problem, in parallel, with each subagent working in its own fresh context window.
Anthropic's own guidance on where this works is specific. Multi-agent shines on tasks with heavy parallelization, information that exceeds a single context window, and many complex tools. Their example is a breadth-first research question, such as finding the board members of every company in a large index. Each lookup is independent, so you can fan it out.
If your task looks like that, splitting it is a real advantage.
The case against: when agents need to share a brain
Then there's the counterargument. Cognition, the team behind the Devin coding agent, published a post titled "Don't Build Multi-Agents." Their two principles are short: share context (including full agent traces, not just messages), and remember that actions carry implicit decisions, so conflicting decisions produce bad results.
Their example makes it concrete. Ask an agent to build a Flappy Bird clone and split the work. One subagent builds a background that looks like Super Mario Bros. The other builds a bird that doesn't match. Neither was wrong given what it knew. The final agent is left trying to stitch together two sets of assumptions that never met.
Anthropic says something similar. Domains where all agents need the same context, or where there are many dependencies between agents, are a poor fit. Most coding tasks, they note, have fewer truly parallelizable pieces than research does.
What the failure data says
If you want numbers on how often this goes wrong, a research team analyzed 1,642 annotated execution traces from seven popular multi-agent frameworks, including ChatDev, MetaGPT and AG2. Failure rates ranged from 41% to 86.7% depending on the framework.
They sorted the failures into 14 modes across three groups: system design issues (44.2%), inter-agent misalignment (32.3%), and task verification problems (23.5%). Think agents ignoring their assigned roles, losing conversation history, withholding information, or declaring the job done too early.
One finding is encouraging. Better role definitions and stronger verification steps improved task success by up to 15.6% in their tests. Many of these failures come from how the team of agents was set up, not from the model itself.
A caveat: these frameworks were tested on tasks like coding and math, and the models have moved on since the paper. Treat the percentages as a warning about coordination, not a forecast for your project.
The hidden cost: tokens and money
Anthropic reports that agents use roughly 4x more tokens than a normal chat, and multi-agent systems use roughly 15x more. That is a real bill, and a real latency problem too.
It means multi-agent only makes sense when the task is valuable enough to justify the spend. A customer support triage flow that runs thousands of times a day is a different calculation from a one-off deep research report.
A quick checklist before you split the work
Start with a single agent. Move to multiple agents only if most of these are true:
The subtasks are independent. Each piece can be done without knowing what the others decided.
The work is broad, not deep. You're exploring many directions at once, not building one thing step by step.
One context window can't hold it all. The information volume truly exceeds what a single agent can handle.
The result is worth the cost. You can justify roughly 15x the tokens of a chat.
You can verify the output. There's a clear check that catches a subagent's mistake before it spreads.
If your task is closer to "many steps that build on each other," such as writing code in one codebase or drafting a document with a consistent voice, a single agent with good context management usually wins. Cognition's suggested route for longer jobs is a single-threaded agent plus a model that compresses history into key decisions.
The practical takeaway
The debate is less about which approach is better and more about the shape of the work. Parallel, independent, high-value tasks reward multiple agents. Sequential, tightly connected tasks reward one agent that sees everything.
Before building a team of agents, try the boring version first: one agent, good tools, clear instructions. If it hits a real wall on context size or speed, you'll know exactly what the second agent is for.
