Single-agent or multi-agent? A decision guide

Not automatically, and assuming they are is the most common reason teams over-build. A multi-agent system genuinely helps when a task decomposes into specialised, loosely coupled roles that each need different tools, context or permissions — but most tasks are not like that, and for them a single well-equipped agent is simpler, cheaper and far easier to debug. The capability gain from multiple agents is real but conditional: it comes from clean separation, not from the mere fact of having more agents, and a poorly decomposed multi-agent system is usually worse than a single agent at the same task. There is also a marketing pull, because multi-agent sounds more advanced, which leads people to claim the benefit before they have earned it. The honest default is one capable agent, with the burden of proof on adding more. If you cannot point to roles that are genuinely separable, extra agents add coordination cost and new failure modes without buying you capability.

Four things, and they are easy to underestimate from a demo. First, coordination overhead: someone has to route work, merge results and resolve conflicts between agents, and that orchestration logic is itself a source of bugs. Second, token and latency cost: inter-agent messages multiply the number of model calls, so a multi-agent run can cost several times its single-agent equivalent and respond more slowly. Third, harder debugging: a failure now spans hand-offs between agents, so you cannot understand a run without tracing across all of them, which is essential and non-trivial. Fourth, amplified security risk: agents tend to treat each other's output as automatically trusted, so a single error or injection in one agent can propagate as trusted context across the whole system instead of being contained. None of these means never use multi-agent; they mean the design has to earn its cost by genuinely needing the separation, because you pay all four whether or not the task required them.

Ask whether you can name distinct roles that rarely need to share state and could almost be separate services. If the answer is yes — for example a research role and an unrelated formatting role that hand off once and then go their own way — multi-agent may genuinely fit, because the seams between the roles are clean and the coordination is light. If the answer is no, and the so-called roles constantly pass context back and forth, then you do not have multiple agents; you have one task wearing several hats, and splitting it just adds message-passing overhead and failure points around what is really a single reasoning loop. The state-sharing question is the key signal: tightly coupled roles that need each other's working context belong in one agent, while independent roles with a thin, well-defined interface are candidates for separation. When in doubt, treat the doubt itself as the answer and stay single-agent, because it is far easier to split a single agent later than to merge a tangled multi-agent system.

Often the opposite, unless the decomposition is genuinely clean, because each agent and each hand-off is another place the system can fail. Reliability intuition from human teams does not transfer directly: people share rich context and catch each other's mistakes, whereas agents pass narrow messages and tend to accept what they receive as correct, so an error introduced early can ride through the whole pipeline unquestioned. More agents also mean more non-determinism compounding across steps, which makes the end-to-end behaviour harder to predict and harder to keep stable across changes. Where multi-agent does help reliability is when a role is genuinely independent and can be evaluated and hardened on its own, with explicit validation at the boundary so the next agent does not blindly trust the last. The reliable pattern is not more agents but clearer control flow: a coordinator with explicit steps, trust boundaries between agents, and tracing across hand-offs. If you add agents without those, you usually trade a simple, debuggable system for a complex, fragile one.