A single agent keeps the whole task in one context. A multi-agent system divides it among specialists — gaining parallel work and focus, and paying in tokens, coordination and new ways to fail.
Both camps publish strong evidence. Anthropic’s multi-agent research system beat its single agent by 90%; Cognition argues that most teams should not build multi-agent systems at all. Both are right, about different tasks. This guide sets out the evidence, the signals that justify a split, the failure modes it adds, and a test for choosing.
Updated · 7 sources
One model, one set of instructions and tools, working through the task in one continuous context.
Several agents with their own instructions, tools and context, coordinated by a lead or by hand-offs.
A single-agent system gives one model all the instructions and tools and lets it work through the task in one loop. A multi-agent system splits the task across several specialised agents — a lead that delegates to workers, or peers that hand off to each other. In multi-agent vs single agent, the trade is simple: splitting buys parallel work and focus on tasks that divide cleanly, and costs tokens, coordination and new failure modes on tasks that do not.
The numbers diverge because the tasks do. Research that fans out into independent questions rewards a team; work where each step depends on the last punishes one.
Anthropic found that token usage alone explained 80% of the variance in its browsing benchmark: much of a multi-agent gain is simply more total reasoning spent in parallel. That is worth paying for when the task is valuable and divides cleanly — and wasted when it does not.
The choice is rarely binary. OpenAI advises getting the most out of a single agent first; Microsoft calls a single agent with tools “often the right default for enterprise use cases”. Move right only when the step to the left has failed.
Two properties of the task decide most cases: do its parts depend on each other, and does it fit in one context window? Anthropic’s research system and Cognition’s warning sit in the two top corners of the same map.
Each signal below comes from a platform vendor’s own guidance. Read the second list just as carefully: it explains most failed multi-agent projects.
The Flappy Bird lesson. Cognition’s illustration: split a Flappy Bird clone between two sub-agents. One misreads its brief and builds a Super Mario-style background; the other builds a bird that matches neither the game nor the background. Neither saw the other’s choices, and the agent merging them is left with parts that do not fit.
Task: find every contract that auto-renews within 90 days and summarise its notice terms. Each contract can be read on its own — the parts are independent — and together they far exceed one context window.
Lists the 40 contracts and splits them into four batches.
Four workers each read ten contracts in parallel, in their own context.
Each returns only what matters: party, renewal date, notice period, a citation.
Merges 40 findings, removes duplicates, ranks by renewal date.
A final pass confirms every claim against its cited clause.
A study of more than 1,600 traces across seven frameworks sorted 14 failure modes into three groups. Some, like repeated steps, can hit one agent too; most live in the roles and hand-offs between agents.
Roles and tasks specified badly: agents ignore their role, repeat steps, lose history or never stop.
Agents talk past each other: withheld information, ignored input, a reset conversation, reasoning that drifts from action.
Nobody checks properly: work ends early, or a weak check passes a wrong result.
Seen in production. Anthropic reports early versions of its system spawning 50 sub-agents for simple queries, sub-agents duplicating each other’s work, and endless searches for sources that did not exist — addressed mainly by rewriting the agents’ prompts, starting with the lead agent’s.
Botminds offers each step on the line as its own building block, so a design can start with one agent and add agents only where the evidence says to.
What shape is the work?
Every message between members is carried and remembered by the bus.
A message redelivered after a crash carries the same id; the keyed join recognises it.
A combining member fires once per key, never on a partial set.
A run is not finished while any of its messages is not; failures get a named cause.
In multi-agent vs single agent, a single agent works through a task in one loop with all the tools; a multi-agent system splits the task across specialised agents coordinated by a lead or by hand-offs. Splitting helps when parts are independent and costs more tokens and coordination.
Only on tasks that divide cleanly. Anthropic measured a 90.2% gain on breadth-first research, while controlled tests across 260 configurations found losses of up to 70% on sequential planning. Start with one agent and split when evidence says so.
When independent parts can run in parallel, when the material exceeds one context window, when overlapping tools confuse one agent, or when parts of the task need different security permissions.
Mostly in coordination: unclear roles and stopping rules, agents withholding or ignoring each other’s information, and weak verification. A 2025 study of 1,600+ traces found 14 such failure modes in three groups.
It depends on how distinct they are. OpenAI reports some agents handle more than 15 well-described, distinct tools, while others struggle with fewer than 10 overlapping ones. Improve names and descriptions before splitting.
Yes. Anthropic reports multi-agent systems use about 15 times the tokens of a chat interaction, against about four times for a single agent. Use them where the value of the task justifies the spend.
A lead agent plans the task, starts worker agents on independent parts, and combines what they return. Workers act as filters, passing back condensed findings rather than raw material, so the lead’s context stays small.
An agent team coordinates several agents inside one run, usually one conversation. A mesh carries work between agents, workflows and services durably across documents and machines, with fan-out, joins and failure handling. See the agent mesh.
Bring one process and its documents. We’ll show you the agents, the controls and the record, running on your data.