Why Multiple Agents? (And Why Not)

Introduction

Welcome to Section 7 — Multi-Agent Systems. It's the most hyped topic in agents and the most over-applied, so we start with the question that should come before any architecture diagram: do you even need more than one agent?

Multiple agents can crush a task a single agent flails at — and just as easily make your system slower, pricier, and more fragile for no benefit. The skill isn't building multi-agent systems; it's knowing when not to.

The 2026 evidence is striking in both directions. Anthropic's multi-agent research system beat a single agent by 90.2% on broad research. And Cognition (the Devin team) published an essay literally titled "Don't Build Multi-Agents," arguing they're "inherently fragile." Both are right — for different tasks. This lesson teaches you to tell which is which.

In this lesson:

Why multiple agents — parallelism, specialization, context isolation (the real wins)
Why not — the 4–15× cost, conflicting decisions, and coordination fragility (the honest counter-case)
The deciding factor (coupling), the single → workflow → multi spectrum, and a hands-on decision guide
The 2026 consensus — and when to climb the ladder

Scope: this is the why / why-not / when. The how — supervisor & hierarchical architectures (L144 — Supervisor / Hierarchical Architectures), handoffs & shared state (L145 — Agent Handoffs & Shared State), the A2A protocol (L146 — The A2A (Agent-to-Agent) Protocol), coordination & cost (L147 — Coordination & Cost), and designing a system (L148 — Designing a Multi-Agent System) — fills the rest of the section.

An infographic titled 'Why Multiple Agents — and Why Not' weighing the case for and against multi-agent systems. Across the top is a spectrum of increasing power and cost: one strong agent, then a workflow, then a multi-agent system, with a note that simpler and cheaper is on the left and more power, cost, and risk is on the right. The left panel, WHY MULTIPLE AGENTS, lists the benefits: parallel breadth, exploring many independent directions at once, where Anthropic's research system beat a single agent by about 90 percent on broad queries; specialization, a lead agent coordinating expert subagents each with its own role, tools, and model; context isolation, each agent getting its own context window so nothing overflows; and modularity for scaling and fault tolerance. The right panel, WHY NOT, lists the costs: token cost, since multi-agent systems use about four to fifteen times the tokens of a chat and up to hundreds of times in the worst case, so the task value must justify it; conflicting decisions, where parallel agents make incompatible choices they cannot reconcile, the Cognition Flappy Bird problem; coordination overhead, because sharing context and state across agents is hard and degrades sequential reasoning; and fragility, since dispersed decision-making creates more failure modes and harder debugging. The three cards give the decision: multi-agent wins when the task is genuinely parallel, spans distinct specialties, overflows one context, and is high-value enough to pay the premium, such as breadth-first research; a single agent wins when the work is sequential or tightly coupled, needs shared context, or is cost-sensitive, which is most tasks including most coding; and the rule is to start with one strong agent and climb the ladder to a workflow and then multi-agent only when the task genuinely demands it. The takeaway: multi-agent systems shine on parallel, high-value work but cost far more and turn fragile when the work is coupled, so start with one strong agent and go multi-agent only when the task truly demands it.

Why Multiple Agents — The Case For

When a task genuinely outgrows one agent, splitting it across several is transformative. The real wins:

Parallelism / breadth. Independent subtasks run at the same time instead of one-after-another. This is multi-agent's killer use case: breadth-first exploration. Anthropic's research system — a lead agent delegating to parallel sub-agents — outperformed a single agent by 90.2% on broad queries like "find every board member across all S&P 500 IT companies." A single agent searching sequentially simply can't keep up.
Specialization. Each agent can have its own role, prompt, tools, and even model — a cheap fast model for retrieval workers, a strong model for the lead/synthesizer. Like a team of experts, each focused, rather than one generalist juggling everything.
Context isolation. Each agent gets its own context window. A research task that would overflow one agent's context fits comfortably when split across ten sub-agents, each holding only its slice. (Remember Section 5 — context is finite.)
Modularity & resilience. Independent agents can be developed, tested, scaled, and replaced separately, and one failing needn't sink the whole task.

Notice the thread: these wins all come from decomposition into independent parts. That word — independent — is also exactly where the case against begins.

The Honest Counter-Case — Why Not

Now the part the hype skips. Multi-agent systems carry real, often-underestimated costs, and for many tasks they make things worse:

Cost — the headline. More agents = many more tokens. Anthropic measured agents at ~4× a chat and multi-agent at ~15×; a UIUC study found 4–220×. One reported deployment paid $47k/month** for a multi-agent system that ran fine as a single agent for **$ 22.7k. "Multi-agent systems require tasks where the value is high enough to pay for the increased performance."
Conflicting decisions. This is Cognition's core argument: "Actions carry implicit decisions, and conflicting decisions carry bad results." When parallel sub-agents work without seeing each other's reasoning, they make incompatible choices. Their example: one sub-agent builds a Super Mario–style background while another builds a clashing bird — and the result can't be reconciled. Parallel work on a shared goal silently diverges.
Coordination overhead. Agents must share context and state, and "context isn't able to be shared thoroughly" across separate agents. This overhead "can actively degrade performance on sequential reasoning tasks."
Fragility & debugging. Dispersed decision-making means more failure modes, non-deterministic interactions, and traces that are far harder to debug than one linear agent.

Cognition's blunt verdict: "running multiple agents in collaboration only results in fragile systems. The decision-making ends up being too dispersed and context isn't able to be shared thoroughly." Strong words — and the right caution.

The Deciding Factor — Coupling

Hold the two cases side by side and the contradiction resolves into one axis: how coupled are the subtasks?

Loosely coupled (independent, read-mostly, recombinable) → multi-agent shines. Each sub-agent explores its slice without needing the others; you just gather the results. Breadth-first research, scanning many sources, surveying options — parallel, and the parts don't conflict.
Tightly coupled (each step depends on the last; shared, evolving state; one coherent artifact) → a single agent wins. Decisions must stay consistent, and the cheapest way to keep them consistent is to keep them in one context, one reasoning thread. Most coding, most sequential reasoning, anything building one artifact lives here — which is why even Anthropic notes multi-agent is a poor fit for most coding.

Put crisply: multi-agent parallelizes exploration; it struggles with coordination. If your subtasks can run in parallel and be merged without fighting, more agents help. If they must agree as they go, more agents just multiply the chances they won't. Ask of any task: would these parts make conflicting decisions if they couldn't see each other? If yes — keep it single.

The Spectrum — Single → Workflow → Multi

"Single vs multi-agent" is a false binary — it's a spectrum of increasing power and cost, and you should climb only as high as the task forces you:

One strong agent + good tools. The default, and the right answer for most tasks. One context, one reasoning thread, cheapest, easiest to debug. For long runs, compress the context (Cognition's recommendation) rather than splitting the agent.
A workflow. Predefined orchestration — the chaining, routing, parallelization, and orchestrator-worker patterns from Section 2 (L116–L120 — Evaluator-Optimizer). Structure and some parallelism without full agent autonomy; deterministic and inspectable. Often this is what people actually need when they think "multi-agent."
A multi-agent system. Autonomous, collaborating agents — a lead coordinating specialists that reason independently. The most powerful and the most expensive and fragile. Reserve it for genuinely parallel, high-value work.

In code, the jump from one to many is the cost cliff:

# One task, two architectures — the cost is the headline difference.

# SINGLE agent: one loop, one shared context, ~N tokens.
answer = agent.run(task, tools=[search, read, calc])         # ≈ 4× a chat

# MULTI-agent: a lead spawns parallel specialists, each its OWN context.
plan    = lead.decompose(task)                               # orchestrator
results = await gather(*[worker.run(sub) for sub in plan])   # specialists, in parallel
answer  = lead.synthesize(results)                           # ≈ 15× a chat (Anthropic)
# Faster & better on BROAD, parallel work — but ~4× the tokens of even one agent…
# …and the parallel workers can make conflicting decisions they can't reconcile.

The discipline: start at rung 1 and only move up when you hit a wall the current rung can't clear — a real parallelism win, a real context overflow, a real need for distinct expertise. Most teams over-shoot to rung 3 when rung 1 or 2 would be cheaper, faster, and more reliable.

When To Use Which

Make it concrete. Run your task through the guide — answer honestly about parallelism, coupling, and value, and watch where it lands (and when it warns you to stop):

Single agent, a workflow, or a full multi-agent system? Answer five questions about your task and the ladder recommends how far up to go — and flags when you're over-building. The honest defaults: parallelizable + multi-domain + overflowing one context pushes you up; tightly-coupled or cost-sensitive work pulls you back to a single agent (where most tasks belong). Two warnings fire when they should: tightly-coupled work is where parallel agents make conflicting decisions they can't reconcile (Cognition's Flappy Bird problem), and multi-agent burns 4–15× the tokens (Anthropic), so the task must be valuable enough to pay for it. The rule the industry converged on in 2026: start with one strong agent; go multi-agent only when the task genuinely demands it.

The pattern the guide encodes is the whole lesson: scores climb with parallelism, distinct specialties, and context overflow — and the warnings fire on tight coupling and cost-sensitivity. If you can't get a confident push past a single agent, that is your answer. The bar for multi-agent is high on purpose.

The 2026 Consensus

After a year of real deployments, the field has largely converged — and it's refreshingly humble:

Start with one strong agent. Adopt multi-agent only when the complexity genuinely justifies the cost.

Even the teams that build the best multi-agent systems say this. Anthropic ships one and warns it's a poor fit for shared-context, coupled, or low-value tasks. Cognition argues for single-threaded agents + context compression as the default. The honest summary of the state of the art:

Single-agent is the strong baseline — and "the practical conditions under which multi-agent beats a strong single-agent baseline are still not well characterized." When in doubt, it's a single agent.
Multi-agent is a specialized tool for parallel, breadth-first, high-value work where subtasks are independent — not a default architecture, and definitely not a flex.

The maturity signal in 2026 isn't "I built a swarm of agents." It's "I used one agent because the task didn't need more" — and knowing exactly when it does. That judgment is what the rest of this section sharpens.

🧪 Try It Yourself

Decide single vs multi for each (check 1–2 in the guide):

"Summarize the latest news on 8 different companies" — each independent. Single or multi, and why?
"Refactor this 5-file module so the pieces stay consistent." Single or multi?
Your manager wants a multi-agent system because it sounds impressive. The task is a simple sequential workflow. What do you say?
A multi-agent research system is 3× slower and 15× the cost but only 5% more accurate than a single agent for your use case. Worth it?
Two parallel sub-agents keep producing incompatible outputs that the lead can't merge. Name the problem and the fix.

→ (1) Multi-agent (or at least parallelized) — 8 independent, loosely-coupled subtasks are the ideal parallel/breadth case; spin up a worker per company and gather. (2) Single agent — the files are tightly coupled (must stay consistent); split it and the sub-agents make conflicting refactoring decisions. Keep one reasoning thread. (3) Push back: a workflow (or single agent) is simpler, cheaper, and more reliable for a sequential task; multi-agent would add 4–15× cost and fragility for no benefit — don't build multi-agent to look impressive. (4) Almost certainly not — multi-agent needs the value to justify the premium; 15× cost for 5% accuracy rarely pays. Optimize the single agent first. (5) Conflicting decisions from un-shared context (Cognition's point) — fix by sharing full context/traces between them, serializing the dependent parts, or collapsing to a single agent.

Mental-Model Corrections

"Multi-agent is the advanced, better architecture." It's a specialized tool, not an upgrade. For most tasks a single strong agent is faster, cheaper, and more reliable.
"More agents = more capable." Often more agents = more cost + more conflicting decisions. Capability comes from the right structure, not the agent count.
"Split the work across agents to go faster." Only if the work is loosely coupled. Tightly-coupled subtasks split into agents make incompatible choices and need expensive coordination — slower and worse.
"Single vs multi is the choice." It's a spectrum: one agent → workflow → multi-agent. Often the real answer is a workflow (Section 2), not autonomous multi-agent.
"The cost is similar." Multi-agent runs 4–15× (up to 220×) the tokens. The task's value must justify the premium.
"If it works in a demo, ship the swarm." Multi-agent is fragile and hard to debug; the demo hides the coordination failures. Prove a single agent can't do it first.

Key Takeaways

Don't reach for multi-agent by default — it's the most over-applied pattern in agents. Start with one strong agent + good tools (compress context for long runs); it's the right answer for most tasks.
Why multiple agents (the wins): parallel breadth (Anthropic's research system +90.2%), specialization (per-role prompts/tools/models), context isolation, and modularity — all from splitting work into independent parts.
Why not (the costs): 4–15× the tokens (up to 220×), conflicting decisions when parallel agents can't see each other (Cognition's Flappy Bird), coordination overhead that degrades sequential work, and fragility.
The deciding factor is coupling: loosely-coupled / parallel / breadth-first → multi-agent shines; tightly-coupled / sequential / one-artifact (most coding) → a single agent wins.
It's a spectrum: one agent → a workflow (Section 2) → a multi-agent system. Climb only as high as the task forces you; the real need is often a workflow, not autonomy.
2026 consensus: start single; go multi-agent only when the work is genuinely parallel, specialized, context-overflowing, loosely-coupled, AND high-value enough to pay the premium.
Next — L144: Supervisor & Hierarchical Architectures — the most common way to structure a multi-agent system once you've decided you need one.