Single agent vs. multi-agent: when splitting actually helps

“Should this be multi-agent?” is the new “should this be microservices?” — same energy, same failure mode: teams pay a distributed-system tax for an org-chart diagram that demos well. And the same truth underneath: the split is genuinely powerful when specific forces demand it. Here are the forces.

The three forces that justify a split

1. Context. One agent’s window fills with tool schemas, results, and history until the actual task drowns. When a separable chunk of work would flood the main context — a broad codebase search, a long document review — a sub-agent burns its own window and returns only conclusions. This is the strongest and most common reason, and note its shape: it argues for task-scoped workers, not a standing cast of characters.

2. Focus. A system prompt trying to be researcher, writer, and critic at once does all three worse — instruction-following measurably degrades as roles pile up. If you keep catching your agent applying the wrong role’s rules, the roles want separate prompts.

3. Ownership & trust. The reviewer agent shouldn’t share context with the agent it reviews; the agent reading untrusted email shouldn’t hold send-capable tools. When two responsibilities must not contaminate each other — for correctness or for security — the boundary is architectural, not aesthetic.

No force present? A single agent with good tools, structured outputs, and a clean prompt wins on every axis: latency, cost, debuggability.

What the split costs (the part the diagrams omit)

Cost	Why it bites
Token overhead	Every hop re-sends context; orchestration can double spend before adding value
Latency stacking	Sequential agents add whole model-call round-trips per hop
Error compounding	95% reliability per agent ≈ 77% across five sequential hand-offs
Lossy hand-offs	Each agent sees a summary of a summary; nuance dies in transit
Debug surface	”Which agent went wrong, with which context?” — N trajectories to read, not one

The staged path (how mature systems actually get there)

1. One agent, better tools. Most “we need multi-agent” pain is actually tool pain — noisy outputs, missing capabilities.
2. One agent + task-scoped sub-agents for context-heavy chunks (search, review, summarize). Workers are spawned, return conclusions, and die — no standing roster.
3. Fixed pipeline of roles when focus forces it: planner → workers → synthesizer, like our orchestration tutorial — with an agent allowlist and a dispatch cap.
4. Dynamic delegation (agents choosing agents, A2A across org boundaries) only when ownership boundaries are real — different teams, different vendors, different trust zones.

Each stage adds machinery only after the previous one demonstrably ran out. Skipping stages is how you get five agents doing one agent’s job at three times the cost.

The tell-tale smells

You split too early: agents mostly relay each other’s outputs unchanged; one agent could hold all the context comfortably; your “planner” produces the same plan every run (that’s a workflow). You split too late: the context window is chronically near capacity; the prompt is a committee memo of conflicting roles; you can’t grant a tool because some of the agent’s job shouldn’t have it.