Single agent vs multi-agent: when splitting actually helps

Single agent vs multi-agent is presented as a maturity ladder — you start with one agent, then graduate to a team of specialists. That’s backwards. Splitting is a technique for specific problems, and applied without one it makes a system slower, costlier and considerably harder to debug.

Start with one. Split when you can name the reason.

What a single agent actually handles

One agent with a good tool set and a clear system prompt covers more than the discourse suggests. It reads email, checks a calendar, drafts a reply, files a ticket — sequential steps, one context, one trace.

Its real limits are three:

• Context pressure. Long runs accumulate history until the useful signal is diluted.
• Instruction dilution. A prompt covering many domains gets vague in each.
• No parallelism. Ten independent lookups happen one after another.

Notice that only the third is a hard architectural limit. The first two are addressable with better context management and tighter scoping — which is why so many multi-agent systems are solving a prompt problem with an org chart.

The three conditions that justify a split

Genuine parallelism. Research across twelve sources, where each is independent, is twelve times faster split. This is the strongest case and the easiest to verify: if the subtasks can’t run simultaneously, you’ve bought coordination overhead for nothing.

Real specialisation. A subagent with fifteen tools and one domain outperforms a generalist with two hundred. The specialisation has to be real, though — “planner” and “executor” as separate agents over the same tools is usually one agent with two prompts.

Isolation as a control. A subagent that processes untrusted content and holds no credentials cannot exfiltrate anything, whatever it’s persuaded to do. This turns prompt injection into a containment problem rather than a detection one, and it’s the most underrated reason to split.

If none of these apply, one agent is the better engineering choice.

What the split costs

Every handoff loses information. The subagent gets a summary of the situation, not the situation. Ambiguity that the parent would have resolved from context becomes a wrong assumption downstream, and the parent can’t see it happen.

Latency compounds rather than adds. Each layer means another model call before any work starts, so a three-level hierarchy pays three round trips of pure overhead.

Cost multiplies faster than the work does. Each agent re-establishes its own context, and a naive fan-out to five subagents costs well over five times a single call.

And debugging gets genuinely hard. When the answer is wrong, the fault is in the parent’s decomposition, one subagent’s execution, or the synthesis — and you can’t tell which without traces that span the whole run.

Side by side

Criterion	Single agent	Multi-agent
Latency (sequential work)	Lower	Higher — handoff overhead
Latency (parallel work)	Higher	Much lower
Token cost	Baseline	3–15× typical
Debuggability	One trace	Requires correlated traces
Specialisation	Limited by prompt size	Real
Failure mode	Wrong answer	Wrong answer, unclear origin
Security isolation	None	Available, and valuable

The topologies, briefly

If you do split, the shape matters more than the count.

Supervisor with workers is the default and the right first choice. One agent decomposes, delegates, synthesises. Workers don’t talk to each other, so the coordination surface stays small and the trace stays readable.

Pipeline suits fixed stages — extract, then classify, then route. Predictable and cheap, but it isn’t really multi-agent; it’s a workflow with model calls in it, which is a good thing to notice because workflows are easier to reason about.

Peer-to-peer, where agents negotiate freely, is where systems become unpredictable. Loops emerge, costs run away, and behaviour stops being reproducible. Compelling in demos, rarely worth it in production.

Depth costs more than breadth. Ten workers under one supervisor is manageable; three levels of nesting is where debugging stops working.

How to choose

Stay single when the work is sequential, the domain is one thing, or you’re still learning what the system needs to do. This covers most systems, permanently.

Split when you have independent subtasks that can genuinely run at once, a domain that needs its own large tool set, or untrusted input you want handled by something holding no credentials.

Split later, not first. Build the single agent, find where it strains, then cut along that line. A split chosen up front is a guess about a failure you haven’t observed.

The test before adding an agent: what does this do that the existing agent can’t, and what does the handoff lose? If the first answer is thin or the second is expensive, you’ve found an argument for a better prompt.

See also: the coordination patterns in more depth and why fewer, wider tools beat more agents.