Multi-agent systems: when it helps
Most multi-agent demos don't beat one well-prompted agent. When coordination is worth the added latency and failure surface, and when it's overhead.
The test for whether you need an agent at all was whether the next step was ever actually in doubt. Multi-agent systems add a second question on top of that one: does splitting the work across agents that talk to each other actually beat one agent doing it all, or does it just add a network of model calls between you and the answer.
Who this is for: an engineer who's building — or has already built — a system with multiple named agents coordinating on a task, and hasn't checked whether a single agent with a bigger prompt would do the same job faster and more reliably.
The default assumption should be one agent
A single agent with a well-structured prompt and the right tools can handle more than most multi-agent architectures give it credit for. The instinct to split a task across a "researcher" agent, a "writer" agent, and a "reviewer" agent often isn't driven by the task actually needing three distinct competencies — it's driven by multi-agent frameworks making that split easy to express, which is a very different reason.
Every hop between two agents costs a full model round trip, and multiplies the failure surface rather than dividing it: a hallucinated tool argument, a retry storm, state leaking across a handoff — each failure mode that a single agent can produce, a multi-agent system can now produce at any of its seams, and a failure at one agent's output becomes corrupted input for the next one. Debugging which of five agents introduced the error is strictly harder than debugging one.
Where it's real: genuine independence
Parallel, independent subtasks with no shared state between them are the strongest case. If agent A summarizing document one and agent B summarizing document two never need to see each other's work until a final merge step, running them concurrently is a real latency win — you're not paying a coordination cost, you're just doing independent work in parallel, which is closer to a map-reduce than to "agents collaborating."
The tell is whether the subtasks could be answered in either order, or no order at all, with identical results. If B's output would change depending on what A decided, they're not independent, and the coordination cost you were trying to avoid by parallelizing just moved into a synchronization problem instead.
Where it's real: specialization that shrinks each prompt
A supervisor-and-specialists pattern earns its complexity when a single agent's prompt would otherwise have to hold too much at once — competing sets of instructions, tools, and context that interfere with each other when they're all live simultaneously. Splitting into a supervisor that routes and several narrow specialists, each with a prompt small enough to be reliably followed, can be more reliable than one enormous prompt trying to do all of it — not because multiple agents are inherently better, but because a smaller, focused prompt is easier to get right than a sprawling one, and that gain has to be weighed against the coordination cost you're now paying at the supervisor boundary.
This only pays off when the specialists are genuinely narrow. Three agents each holding half of what a single focused agent would need is worse than one agent, not better — it has all the coordination cost and none of the focus benefit.
The check before building one
Count the round trips a request actually takes end to end, including every supervisor-to-specialist and specialist-to-supervisor hop, and multiply by your per-call latency and cost. Compare that number to what a single well-prompted agent would take for the same task. If a multi-agent version isn't clearly winning on quality — not on architecture elegance — the coordination overhead is a cost with no offsetting benefit, the same trap a fixed pipeline built as an agent falls into one level up.
The cost adds up the same way anywhere else model calls multiply: a multi-agent system that adds three round trips per request is three times the token cost of the parts that don't need to happen in the single-agent version, before any coordination benefit shows up in the output at all.
If you're weighing whether a task actually needs multiple coordinating agents or one agent with a better prompt, that's usually a conversation worth having before either gets built.