Multi-Agent or One Big Agent? A Practical Way to Choose

Every few months a client sends me an architecture diagram with six agents on it, and I have learned to ask the same first question: which of these agents needs to know what the others decided? The multi-agent vs single agent debate has produced a lot of confident posts on both sides, and the confidence is the problem. Both designs win, under conditions specific enough that you can test for them. Here is how I decide.

Why the Multi-Agent vs Single Agent Debate Got So Loud

Multi-agent designs are appealing because they map onto how we already think about work. You would not ask one person to research six markets, write the memo, and check the math. You would staff it. Give each agent a role, a prompt, and a narrow tool set, and the thing reads like an org chart you can debug.

There is real evidence behind the enthusiasm too, not just vibes. Anthropic's engineering team published that a lead agent running Claude Opus 4 with Claude Sonnet 4 subagents outperformed single-agent Opus 4 by 90.2% on their internal research eval. Their explanation is worth sitting with: research is breadth-first work, a query needing fifty searches means fifty sequential round trips for one agent, and the material blows past any single context window. Subagents solved a capacity problem, each arriving with its own fresh window.

So the case for many agents is strong. It is just narrower than the diagrams suggest.

What Each Extra Agent Actually Costs You

Each additional agent costs you tokens, latency, and a new place for the system to lie to itself. The token part is measurable and alarming once you see it. In that same Anthropic post, the team reported that agents use roughly 4x the tokens of a chat interaction and multi-agent systems roughly 15x, and that token usage alone explained 80% of the performance variance they measured. Read that twice. A large share of the multi-agent advantage was not architectural cleverness. It was buying more thinking.

Latency compounds the same way, because every handoff is another model call and any agent waiting on a sibling is a queue you did not plan for. The failure part is subtler and more expensive. Researchers from Berkeley and collaborators built the first taxonomy of multi-agent failures from 1600+ annotated traces across seven popular frameworks, cataloguing 14 distinct failure modes in three groups: bad specification, inter-agent misalignment, and missing verification. Their opening line is the one I quote in meetings: "Despite enthusiasm for Multi-Agent LLM Systems, their performance gains on popular benchmarks are often minimal."

None of those three families is "the model was not smart enough." You are not debugging intelligence, you are debugging an organization, and that is a large part of why Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027 on cost and unclear value.

When Specialization Genuinely Helps

Specialization helps when the subtasks are independent, read-heavy, and collectively larger than one context window. That is the whole rule, and it explains why Anthropic's research system worked. Five subagents searching five different corners of the web never have to agree with each other about anything. They gather, they report, the lead agent reconciles. Their outputs are additive.

Compare that to a task where the pieces have to cohere. Walden Yan at Cognition uses a Flappy Bird example in his essay arguing against multi-agent designs: one subagent builds the background, another builds the bird, and you get two assets in different visual styles because neither could see what the other assumed. Nobody made an error. They made incompatible decisions, which is worse, because errors show up in logs and assumptions do not.

Yan's two principles are the cleanest heuristic I have found. Share context, including full agent traces rather than individual messages. And remember that actions carry implicit decisions, so conflicting decisions carry bad results. He argues these are so rarely worth violating that you should rule out architectures that break them by default. I think he is right, with one caveat: Anthropic's read-only research swarm does not break them, because gathering facts carries very few implicit decisions.

A Single Agent With Tools, Revisited

A single agent with good tools is still the correct default for most business workflows, and the research has been quietly catching up to that. Tran and Kiela at Stanford ran the comparison the field had mostly been avoiding: they held the reasoning-token budget equal across single-agent and multi-agent systems on multi-hop reasoning, across three model families. The single agent matched or outperformed the multi-agent variants in nearly every condition.

Their theoretical argument is the part I keep thinking about. It leans on the Data Processing Inequality, which here means every handoff between agents can lose information but can never create it. Passing a summary to a colleague is lossy by definition. Unless the receiving agent gains something the sender could not have (a fresh context window, a parallel clock, a tool the first one lacks), the handoff is pure decay.

That reframes the comparison. The multi-agent premium is not paying for coordination, it is paying for capacity. So the first question is not "how do I split this," it is "have I actually run out of room?" Most teams have not. They have run out of prompt discipline, which is a different problem and one I have written about in the context of why big context windows still leave agents forgetting things.

Choosing Multi-Agent vs Single Agent by Failure Mode

Choose by asking which failure you would rather own, because you are going to own one of them. A single agent fails by running out of room. It loses the thread, drops early context, or grinds through fifty tool calls in sequence while your user watches a spinner. A multi-agent system fails by disagreeing with itself, silently, at a seam nobody is watching.

Here is the sequence I run with clients:

• Ship the single agent with tools first, and instrument it. If you cannot see what it did, you cannot tell which failure you have, which is why agent observability comes before architecture.
• Find the real ceiling. Exhaust context management, better retrieval, caching, and a stronger model before you reach for headcount.
• If the ceiling is capacity, split only along seams where the pieces never need to agree. Research, retrieval, and independent checks split cleanly. Shared style, shared interpretation, and sequential reasoning do not.
• Give the supervisor the full trace, not a summary. Lossy handoffs are where the 14 failure modes live.
• Price it honestly. At roughly 15x the tokens, a multi-agent design has to earn its keep against a real number, not a demo.

I am not anti multi-agent. The pattern is legitimate, it is what the major agent frameworks have converged on, and for breadth-first research it is clearly better. What I am against is reaching for it because a diagram looks more impressive with six boxes than one. The diagram is not the system. The handoffs are the system, and every one of them is a place where your agents can quietly decide different things and hand you the wreckage as a finished deliverable.

If you are staring at a workflow and cannot tell which side of that line it falls on, that is usually a scoping problem rather than an architecture problem, and it is what we untangle in a System Review Diagnostic.

Frequently Asked Questions

What Is a Multi-Agent System?

A multi-agent system splits a task across two or more LLM agents that each hold their own context and pass results to one another, usually coordinated by a supervisor or router. The appeal is parallelism and role specialization. The cost is that context now has to cross boundaries between them.

Is a Multi-Agent System Better Than a Single Agent?

Not by default. Controlled comparisons that hold reasoning-token budgets equal find single agents match or beat multi-agent setups on tasks requiring connected reasoning, while multi-agent designs win on breadth-first work that genuinely parallelizes.

When Should You Use a Multi-Agent Architecture?

Use it when subtasks are independent, read-heavy, and collectively larger than one context window, so the extra agents buy parallel capacity rather than coordination overhead. If the subtasks must agree with each other on style, assumptions, or interpretation, keep them in one agent.

Why Do Multi-Agent Systems Fail?

Research cataloguing 1600+ traces found 14 recurring failure modes in three families: bad specification, inter-agent misalignment, and missing verification. Most failures come from the coordination layer rather than from the models being insufficiently capable.

Are Multi-Agent Systems More Expensive to Run?

Substantially. Anthropic reported agents use roughly 4x the tokens of a chat interaction and multi-agent systems roughly 15x, before you count the latency added at every handoff.

How Do You Debug a Multi-Agent System?

You need trace-level observability spanning every agent, because an error introduced by one gets accepted as fact by the next and surfaces far from where it started. Without shared tracing you are reading logs from several conversations and guessing which one lied first.

Does a Supervisor Agent Solve the Coordination Problem?

Partly. A supervisor gives you one place to reconcile results, but only if the workers hand up full traces rather than summaries. Fed compressed output, it reconciles conclusions without the reasoning that produced them.

References

• Anthropic Engineering: How We Built Our Multi-Agent Research System
• Cognition: Don't Build Multi-Agents, by Walden Yan
• arXiv: Why Do Multi-Agent LLM Systems Fail?
• arXiv: Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets
• Gartner: Over 40% of Agentic AI Projects Will Be Canceled by End of 2027