⚡The verdict up front
Most production agent systems should be a single agent. One model, one system prompt, a set of well-designed tools, and a loop that runs until the task is done. This architecture is easier to debug, cheaper to run, simpler to evaluate, and — this surprises people — frequently more accurate than a committee of agents arguing with each other.
Multi-agent architecture earns its complexity in three specific situations: when the work decomposes into independent subtasks that can run in parallel and wall-clock time matters, when a single context window is being overloaded by conflicting instructions or too much irrelevant history, and when you need hard isolation between parts of the system — different permissions, different models, different blast radii when something goes wrong.
If none of those three applies to your workload with evidence — not vibes, evidence — a single agent wins and it is not close. The rest of this article explains what multi-agent actually buys, what it charges, and the thresholds we use when we make this call for clients.
| Situation | Single agent | Multi-agent |
|---|---|---|
| Sequential, dependent steps | Clear winner | Adds latency and coordination for no gain |
| Independent subtasks, time-sensitive | Runs them serially — slow but correct | Real parallelism pays |
| One overloaded context window | Instruction following degrades | Focused contexts recover quality |
| Different permission levels per subtask | One agent holds all the keys | Isolation is the point |
| Team is early and still learning the domain | Cheap to iterate and debug | Premature — you will redesign it twice |
| Consistency of output matters most | One voice, one style, one judge | Outputs drift between agents |
🧩What multi-agent architecture actually buys you
Strip away the marketing and a multi-agent system buys exactly three things. Everything else people claim for it — emergent intelligence, better reasoning through debate, agents that check each other — is either unproven in production or achievable more cheaply inside a single agent.
The first purchase is parallelism. A research agent that needs to investigate five suppliers can investigate them simultaneously instead of sequentially. This is real and it is the most defensible reason to go multi-agent: wall-clock time drops roughly with the number of independent workers, and no prompt engineering trick can make one agent do five things at the same time.
The second purchase is context isolation. Each agent carries a small, focused system prompt and sees only the history relevant to its job. Instruction following degrades as context grows and instructions conflict — a specialist that sees only its own task simply has less to get confused by. The third purchase is specialization: different subtasks can use different models, different tools and different permission scopes, so the expensive model only handles the steps that need it.
Parallelism
Independent subtasks execute concurrently. This is a latency optimization, not a quality optimization — the same work, faster wall-clock.
Context isolation
Each agent holds a small focused prompt and a narrow history, which keeps instruction following sharp and token counts per call low.
Specialized prompts and models
A coding subtask can run on a strong reasoning model while a formatting subtask runs on a cheap fast one. One agent forces a single model for everything.
Failure isolation
A worker that crashes or loops burns its own budget and can be retried or replaced without contaminating the rest of the run.
🕸️The coordination tax nobody budgets for
Every boundary between agents is an interface you now own. Two agents that must cooperate need a shared message format, a contract for what a completed subtask looks like, and a decision about who validates the handoff. With three agents you have a handful of boundaries. With eight agents arranged in a hierarchy you have a distributed system, with all the distributed-system problems: partial failures, retries, idempotency, and state that lives in more than one place.
The orchestration layer itself becomes a real piece of engineering. Something has to decide which agent gets which subtask, when to fan out, when to merge results, and what to do when two workers return contradictory answers. In a single-agent system the model does this inside one context, for free, in the same loop. In a multi-agent system you either write that logic yourself or you delegate it to a supervisor agent — which is just another model call that can be wrong, now at the most expensive possible point in the pipeline.
Debugging cost rises faster than agent count. When a single agent misbehaves you read one trace. When a multi-agent system misbehaves you read five traces and then reconstruct the interaction between them, because the bug is usually in the handoff, not inside any single agent. Teams consistently budget for the agents and forget to budget for the seams between them.
The rule of thumb we apply: every agent boundary you add must pay for one interface, one failure mode and one debugging surface. If you cannot name what the boundary buys, it is a cost dressed as architecture.
💥Failure modes that only exist in multi-agent systems
Single agents fail in boring, visible ways: wrong answer, bad tool call, loop that hits a step limit. Multi-agent systems inherit all of those and add a second layer of failures that live in the coordination itself. These are the ones that do not show up in a demo and do show up in month two of production.
Error amplification is the most expensive. If a supervisor decomposes a task incorrectly, every worker executes the wrong decomposition competently, and you pay full price for a confident, well-formatted, wrong result. In a single agent the same mistake is one wrong turn you can see in one trace. In a multi-agent system it is a wrong turn replicated across workers, with each worker output lending false credibility to the others.
The subtle one is validation theater: agent A assumes agent B checked something, agent B assumed agent A did, and nobody did. Handoff points are where assumptions about responsibility go to die, which is why mature multi-agent systems validate explicitly at every boundary rather than trusting the upstream agent.
| Failure mode | What it looks like | Primary mitigation |
|---|---|---|
| Delegation loops | Agents hand the task back and forth; nothing completes | Hard hop limits and a supervisor timeout |
| Error amplification | One bad decomposition executed confidently by all workers | Validate the plan before fan-out, not after |
| Validation theater | Each agent assumes another one checked the output | Explicit acceptance checks at every boundary |
| Contradictory workers | Two agents return conflicting answers; merge picks arbitrarily | Defined conflict-resolution policy, logged |
| Runaway cost | Retry storms and re-delegation multiply token spend | Per-run budget caps enforced in code |
| Irreproducible bugs | Failure depends on timing of parallel agents | Full traces with correlation IDs per run |
💰Cost and latency multiplication, with honest ranges
The token economics of multi-agent are unforgiving and worth stating plainly. A supervisor agent that plans, delegates and synthesizes spends tokens on coordination that produce no user-facing output. Every worker carries its own system prompt overhead. Every handoff serializes context into a message and deserializes it at the other end — which often means re-reading information that a single agent would simply still have in its context.
Across the systems we have built and reviewed, a multi-agent decomposition of a task typically costs somewhere between two and ten times the tokens of a single-agent attempt at the same task, with the multiplier driven by how much coordination and re-reading the architecture forces. Treat that as a labelled market range from observed builds, not a benchmark — your multiplier depends entirely on your orchestration design, and a lean fan-out with minimal synthesis sits at the low end.
Latency moves the other way only when parallelism is real. Independent subtasks run concurrently and wall-clock time drops. But dependent subtasks — where agent B needs the output of agent A — get slower, not faster, because you have added serialization and handoff overhead to a chain that was already sequential. Before choosing multi-agent for speed, draw the dependency graph. If it is a line, parallelism buys you nothing.
| Workload shape | Single agent | Multi-agent | Net effect |
|---|---|---|---|
| 5 independent research subtasks | ~25 min serial | ~6–8 min parallel | Multi-agent wins on latency, costs more tokens |
| 5 dependent steps, each feeding the next | ~20 min, one context | ~25 min plus handoffs | Single agent wins on both cost and latency |
| Mixed: 2 parallel branches, then a merge | Serial throughout | Branches parallel, merge serial | Multi-agent wins if branches are long |
| One hard reasoning task | One focused call | Debate adds tokens, not accuracy | Single agent wins |
📏Decision criteria with honest thresholds
Here is the framework we actually use, stated as thresholds rather than principles. Go multi-agent when at least one of these is measurably true. First: the task decomposes into three or more independent subtasks that each take meaningful time, and users feel the serial latency. Below three subtasks the coordination overhead eats the parallelism gain.
Second: your single agent is demonstrably degrading — you can show in evals that instruction following drops as the task grows, or the context regularly fills past the point where the model stays reliable, and prompt compression has not fixed it. Third: parts of the task need materially different trust levels — for example, one subtask reads the open web while another touches your production database — and you need permission isolation between them. Fourth: different subtasks genuinely need different models, and the cost saving from routing easy subtasks to cheap models exceeds the coordination cost.
Notice what is not on the list: the task feeling complex, the demo looking impressive, or the framework making it easy. Complexity of the problem is not a reason for multiplicity of agents. Most complex tasks are long chains of dependent steps, and long dependent chains are exactly where a single strong agent with good tools performs best.
The honest test: write the task as a dependency graph. Three or more long independent branches justifies multi-agent. A chain with one fan-out does not. If you cannot draw the graph, you are not ready to choose the architecture.
🎯When one well-prompted agent wins outright
A single agent wins whenever the value of the output depends on coherence. Document drafting, code changes that must hold one mental model of a codebase, analysis that builds an argument step by step — all of these benefit from one context that remembers every decision it has made so far. Splitting them across agents forces constant re-explanation, and re-explanation is where nuance dies.
A single agent also wins while you are still learning the problem. Early in a build you do not know where the real boundaries are, and any agent split you design now is a guess. A single agent lets you iterate on the prompt and the tools at full speed; the natural split points reveal themselves in the traces, in the places where the context fills up or the instructions start to conflict.
Finally, a single agent wins on operability. One prompt to version, one eval set to maintain, one trace to read when a customer complains, one place to add a guardrail. Production maturity is mostly about how fast you can diagnose and fix bad behavior, and nothing diagnoses faster than one agent with one log.
🛤️The path that works: evolve from one to many
The teams that succeed with multi-agent almost never start there. They ship a single agent, instrument it properly, and let production data tell them where the boundaries are. The first split usually comes from one of the triggers above: a measurable latency problem from serial execution, a measurable quality drop from context overload, or a security requirement for permission isolation.
When the split comes, split along the measured seam and keep the rest single. A common mature shape is one main agent that owns the conversation and one or two specialist workers for the genuinely parallel or genuinely isolated work — not a committee of eight. Add agents the way you add database indexes: in response to a measured bottleneck, with the trace to justify each one.
If you are weighing this decision for a real system, this is exactly the scoping work we do in our multi-agent engagements: instrument the single-agent baseline, find the seams, and split only where the data says to.
Multi-agent development servicesAI agent development services