"Multi-agent" is the term of the moment. Every framework release, every conference talk, every roadmap slide leans on it — agents that plan, agents that delegate, agents that check each other's work. The implicit pitch is that more agents means more capability, the same story that made microservices sound inevitable a decade ago.
Talk to teams that have actually shipped multi-agent systems to production, though, and the story sounds different. The demo works beautifully. Then, somewhere between the retriever agent and the summarizer agent and the critic agent, an error surfaces that takes two days to trace back to its source. Nobody's worried about the token bill. The real line item is the engineer-week spent making four agents cooperate reliably.
This post is about that gap. The real cost of multi-agent systems isn't inference — it's coordination. And the analogy most teams reach for to justify the architecture, agents as microservices, actively misleads them about the risk they're taking on.
The "More Agents = More Capability" Assumption
Somewhere along the way, agent count became a proxy for sophistication. A pipeline with one agent looks like a prototype. A pipeline with five specialized agents — a planner, a researcher, a coder, a reviewer, a summarizer — looks like a serious system.
Nobody asks the obvious question first: could one well-scoped agent, given the right tools and a clear enough brief, do 80% of this job on its own?
That question gets skipped because splitting responsibilities feels like good engineering. It mirrors the separation-of-concerns instinct every experienced developer already has. Single responsibility principle, applied to prompts. It looks disciplined.
Agent count is a proxy for failure surface area, not for capability. Every additional agent is another place the pipeline can break, and another handoff that has to be debugged when it does.
The instinct isn't wrong in every case — it's wrong as a default. Splitting a task across agents should be a decision you justify, not a decision you reach for because it looks architecturally mature.
The Microservices Analogy Doesn't Hold
The comparison to microservices is seductive because it's familiar. Small, focused services. Clear boundaries. Composition over monoliths. Most engineers already have a mental model for why that architecture works, and it's tempting to reuse it wholesale for agents.
The analogy breaks down at the one place that actually matters: the contract between components.
A call from one microservice to another is typed, versioned, and — mostly — deterministic. You define a schema. The response either matches it or the call fails loudly: a timeout, a 500, a validation error your code can catch and handle. The contract is enforced by infrastructure you didn't have to think about twice.
A handoff from one agent to another is natural language, or something semi-structured that an LLM produced and another LLM has to interpret. There's no compiler sitting between them. There's no schema validator rejecting a malformed response — unless you build one yourself, and most teams don't, because it doesn't feel like the interesting part of the system.
That last difference is the one that matters most in production. Microservices fail loud. A downstream service either gets a response it can parse or it gets an explicit error — something a monitoring system can page on. Agents fail quiet. An agent that receives a subtly wrong input from the step before it doesn't know the input was wrong. It does its best with what it got, and its best often looks completely plausible. Nothing throws. Nothing pages anyone. The bad output just ships.
A system that fails loudly is easier to operate than a system that fails politely.
The Reliability Math Nobody Runs
Here's the calculation most teams skip before wiring four or five agents into a pipeline.
Say each agent, evaluated on its own, is 95% reliable — a number that sounds genuinely good in isolation. Chain four of them together, where each step depends on the previous one succeeding, and the end-to-end reliability isn't 95%. It's roughly 0.95⁴, which is about 81%. Add a fifth agent and it drops under 77%. A sixth, and you're near 70%.
| Agents in the chain | Per-agent reliability | End-to-end reliability |
|---|---|---|
| 1 | 95% | 95% |
| 2 | 95% | ~90% |
| 3 | 95% | ~86% |
| 4 | 95% | ~81% |
| 6 | 95% | ~74% |
Teams evaluate each agent individually — "looks 95% reliable!" — and never multiply the chain out. The math isn't exotic. It's the same reasoning you'd apply to any series of dependent steps. It just rarely gets applied here, because each agent is built and tested in isolation, and nobody owns the end-to-end number.
It's also worse than the table suggests, because the failure mode isn't always a clean independent miss. When agent two receives a slightly wrong input from agent one, it doesn't necessarily fail — it often succeeds at the wrong task, confidently. The error doesn't just propagate. It compounds, dressed up as a normal-looking result at every step along the way. Multiplicative reliability is the optimistic case.
Where Multi-Agent Genuinely Earns Its Keep
None of this means multi-agent architectures are always wrong. There are real cases where splitting work across agents is the right call:
- Genuinely parallel, independent subtasks. Querying three unrelated data sources concurrently doesn't create a dependency chain — each branch can fail on its own without dragging the others down with it.
- Structurally adversarial roles. A generator-and-critic pair, where the critic's entire job is to catch what the generator missed, is a different shape than a linear pipeline. The critic isn't just another hop that can misfire; it exists specifically to reduce the first agent's error rate.
- Work too large for one context window, split along real boundaries. We've written before about a workflow that runs spec, plan, implement, and QA as separate fresh-context steps. It looks like a multi-agent system, but the handoffs between steps are structured documents — a spec file, a plan file — not free-form natural-language messages one agent interprets from another. That distinction is what keeps it reliable.
The common thread in all three: the split exists because it produces a real capability or reliability gain, not because it looked like the more sophisticated architecture.
What Changes When You Default to Single-Agent
Flip the default and the design conversation changes shape. Instead of "which agents do we need for this," the first question becomes: does this subtask genuinely need a different context window, a different toolset, or an adversarial check that the same agent can't credibly give itself? If the answer is no, it's one agent, not two.
That question kills a lot of pipelines before they're built — and that's the point. A single agent with a well-scoped prompt and the right tools is easier to evaluate, easier to trace when it fails, and has exactly one reliability number to worry about instead of a chain of them.
When a split really is justified, the design job shifts from "how many agents" to "what's the contract between them." That's where the microservices instinct is worth borrowing after all — not the part about splitting responsibilities, but the part about enforcing a schema at the boundary. A structured handoff — a typed object, a fixed-format document, a checklist — turns a silent misread into a validation error you can actually catch.
Actionable Takeaways
- Default to a single agent. Justify every additional one. Treat each extra agent in a pipeline as a cost — in reliability and in debugging time — that has to be paid for with a real capability gain, not assumed as an upgrade.
- Measure per-hop reliability before you scale out. Before committing to a multi-agent pipeline, estimate each step's success rate individually and multiply them out. If the end-to-end number surprises you, that's the number you should have been designing against from the start.
- Design structured handoffs, not free-form chat between agents. When a split is genuinely justified, pass a typed object, a fixed-format document, or a checklist between agents — not a paragraph one agent has to interpret from another.
- Instrument before you add complexity. Add tracing and observability to see where failures actually occur before adding more agents meant to fix a problem you haven't actually diagnosed yet.
What's Coming Next
The industry narrative around multi-agent systems treats agent count as a maturity signal. It's closer to the opposite: every additional agent is a liability that has to earn its place through a real, specific capability the single-agent version couldn't provide.
The teams getting real value from multi-agent architectures right now aren't the ones with the most agents. They're the ones who can tell you, for each one, exactly why it's there — and what the end-to-end reliability number looks like with it in the chain.
Before your next multi-agent design review, ask the question that usually gets skipped: what's the one-agent version of this, and what specifically would it fail to do?
