Why a Multi-Agent Team Beats One Generalist Agent

Once you have more than one agent, they need a way to talk to each other. Before that question is worth answering, though, there is a prior one: why have more than one at all?

The honest answer is that it depends, and the evidence cuts both ways. This first part of the series lays out what is actually known — where a team measurably beats one generalist, what it costs, and where the people who build agents for a living say not to bother.

Does a team actually do better?

There is one good public number. Anthropic built a multi-agent research system — a lead agent spawning subagents that search in parallel — and measured it against a single agent on their internal research eval. The result: a lead Claude Opus 4 with Sonnet 4 subagents outperformed single-agent Opus 4 by 90.2%.

The same write-up is candid about the bill. Multi-agent systems use "about 15x more tokens than chats," and token usage alone explains 80% of the variance in performance on their eval. Their conclusion is a constraint, not a sales pitch: multi-agent architectures need "tasks where the value of the task is high enough to pay for the increased performance."

We have our own number, on a harder benchmark. We built the same idea for software engineering — a coordinator, a researcher, an implementer and a reviewer, each in its own sandbox, working an issue the way a team works a ticket — and measured it on SWE-bench Verified: 72.2% of tasks resolved, ahead of single-agent baselines using comparable models. Same models, different organisation. That is the claim worth sitting with — the gain came from how the work was divided, not from a better model underneath. We wrote up what the benchmark measures and how the team was set up in a separate post.

Both results point the same way, and both come with the same asterisk: a team is not free and it is not automatically better. It wins when the work genuinely splits — and the four reasons it wins are all measurable.

Isolation, because the failure mode is not hypothetical

Simon Willison named the pattern that matters here the lethal trifecta: an agent with access to private data, exposure to untrusted content, and the ability to communicate externally. Any two are survivable. All three together mean "an attacker can easily trick it into accessing your private data and sending it to that attacker."

His mitigation is blunt, because guardrails do not reliably hold: avoid the combination entirely. That is difficult advice to follow with one generalist agent, because a generalist accumulates all three by definition — the tools that read your data, the inputs that come from outside, and the ability to send. It is straightforward advice to follow with a team. The agent that reads the scraped page holds no credentials. The agent that holds credentials never sees untrusted input. The split is the control.

Different tools, because tool choice degrades with tool count

Tools attach per agent. That is partly the security boundary above, and partly a quality one: a model choosing between five relevant tools picks better than the same model choosing between fifty, most of which have nothing to do with the task. Scoping tools to the agent that needs them keeps every decision small.

Different models, because most steps do not need your best one

A coordinator that restates a topic, tracks who has answered and merges results is doing clerical work. A specialist doing deep analysis is not. When agents are separate resources, the model is a per-agent choice.

The routing literature suggests how much that is worth. RouteLLM, from UC Berkeley, Anyscale and Canva, reports cost reductions of over 85% on MT-Bench while retaining 95% of GPT-4's performance, by sending the easy queries to a cheaper model. A team of agents is that idea expressed structurally: the routing decision is made once, at design time, by giving each role the model its job actually needs.

Scoped context, because long context degrades before it fills

The last reason is the one that shows up in output quality. A single prompt covering six jobs carries rules that apply to only some of them, and the model has to decide every turn which are in force. Each agent in a team gets one job described with no competing instructions.

Context length matters as much as prompt length. Chroma's context rot study evaluated 18 frontier models — GPT-4.1, Claude 4, Gemini 2.5, Qwen3 among them — and found that all of them degrade as input grows, non-uniformly and well before the window is full. A 200K-token window does not mean 200K tokens of reliable attention. Splitting the work splits the context, and each agent's window holds only its own conversation.

When one agent is the right answer

The strongest argument against all of this comes from people who ship agents daily. Cognition's Don't Build Multi-Agents, by Walden Yan, argues that parallel subagents produce fragile systems, for two reasons worth quoting: share context and full agent traces, not just individual messages; and actions carry implicit decisions, so conflicting decisions carry bad results. Their example is a Flappy Bird clone where one subagent builds a Super Mario background while another builds a bird in a different style, and the agent above them cannot reconcile what it is handed.

That critique is correct, and it draws the line precisely. Splitting one coherent piece of work across agents that cannot see each other's decisions produces incoherent output. Nothing about a team fixes that. So the question to ask before splitting is not "would this be faster in parallel" but "are these genuinely separate jobs?"

Three specialists reviewing the same proposal from three professional perspectives are separate jobs — the disagreement is the deliverable. Three specialists writing three parts of the same file are not.

The shapes people build

Most multi-agent systems in the wild are one of a few shapes:

• Supervisor, or coordinator: one agent decides who does what and owns the final answer. The panel in this series is one of these.
• Swarm: many interchangeable agents work the same problem until something useful emerges from the aggregate. Same messaging underneath, no hierarchy on top.
• Handoff: control passes from one agent to the next, each owning a stage — triage to specialist to reviewer.
• Planner with subagents, the shape LangChain packages as DeepAgents: a lead agent plans, spawns subagents with isolated context for independent subtasks, and uses a shared filesystem for memory and hand-back.

They differ in who decides and where state lives. They do not differ in what they need underneath: a way for one agent to address another, and somewhere for the answer to land.

The example: a coordinator and a panel

The demo this series builds is an opinion panel. You bring a topic — a product idea, a feature, a launch post — and you get back a structured read on what four different people think of it.

This shape has a few names. An agent swarm usually means many interchangeable agents working the same problem until something emerges from the aggregate; what we are building is the other end of that spectrum — a small multi-agent system of deliberately different specialists, coordinated by one agent that knows who to ask and what to do with the answers. The messaging underneath is the same either way, and everything in this series applies to both.

Agent	Handle	Role
Iris Vale	@coordinator	Runs the panel. Never gives an opinion of her own.
Tomas Alvarez	@tomas	Non-technical founder of a 12-person logistics startup. Measures everything against runway.
Ben Carter	@ben	Backend engineer, on call every fourth week. Reads claims looking for what breaks at 3am.
Viktor Hale	@viktor	Head of operations at a regional insurer. Assumes the demo is the best case.

The three panelists are deliberately different from each other. A topic that lands with the founder and alarms the operations lead is a useful finding; you only get it if neither of them ever hears what the other said. So the coordinator's job has a hard constraint built into it: put the same question to each specialist, in isolation, and merge the answers only at the end.

That constraint is what makes this a good demonstration. It needs one agent to hold several conversations at once, keep them separate, and know which one it owes the final answer to. The rest of the series follows from that.

Next in this series

The panel above needs its four agents to exchange messages without any of them sitting and waiting. Part two covers how that works: inboxes, turns, and the two settings that decide where an agent's output goes.