Multi-agent systems get a lot of attention because they're architecturally interesting, but that's not the same as them being the right default. The right question isn't "should we use multiple agents?" It's "have we proven a single agent isn't enough?" Skipping that step is one of the more common ways teams add real cost and complexity for no measurable benefit.

What each architecture actually is

Single agent

One agent, with access to whatever tools it needs, handles the full task itself. Simpler to build, test, and debug, and often entirely sufficient for tasks that don't genuinely require deep, simultaneous expertise across very different domains.

Multi-agent

Multiple specialized agents, each with a narrow domain and its own tools, are coordinated by an orchestrator that decomposes a task, routes work to the right specialist, and synthesizes their outputs. This handles genuinely cross-domain tasks better, at the cost of real added complexity: more moving parts, more latency, and a harder debugging surface.

Why "just use multiple agents" is a trap

A single agent trying to hold deep expertise in several unrelated domains in one prompt tends to perform shallowly across all of them, which sounds like an argument for multi-agent by default. But the complexity cost is real: more agents mean more places for something to go wrong, more latency from coordinated calls, and a harder system to evaluate and debug. Building multi-agent complexity before proving it's needed is a common way engagements go over budget and timeline for a capability the use case didn't actually require.

How to actually decide

  1. Build the single-agent version first, if there's any doubt. Test it against real examples of your actual task. If it performs well, you're done, and you've saved real engineering time and ongoing complexity.
  2. Look for the specific failure pattern that justifies multi-agent. Shallow reasoning across multiple genuinely distinct domains in the same task is the signal, not "this task feels complicated." A task that's just long, not domain-diverse, doesn't need multiple agents; it needs a well-designed single agent with good tool access.
  3. If you do go multi-agent, keep the boundaries genuinely distinct. Each specialist agent should own a clearly separable domain (telemetry interpretation, historical pattern matching, inventory lookup), not an arbitrary split of one task into pieces that still overlap heavily.
  4. Measure the actual improvement, not just architectural elegance. Compare the single-agent and multi-agent versions against the same evaluation set before committing, so the decision is based on real accuracy data, not intuition.
A real example
In a manufacturing fault-triage system we built, we started with a single agent given access to four different systems (telemetry, maintenance history, cross-line patterns, and parts inventory). Evaluated against a labeled set of past fault investigations, it worked for simple cases but performed poorly on genuine cross-system investigations. Only after that evaluation data showed the shallow-reasoning failure pattern did we move to an orchestrator plus four specialist agents, which meaningfully improved accuracy on the cases that needed cross-domain reasoning.

The coordination cost is real, budget for it

A multi-agent system needs explicit orchestration logic (how tasks get decomposed and routed), a way to handle cases where specialist outputs conflict, and typically more testing surface than a single agent, because you're validating both individual agent behavior and the coordination logic between them. That's a real, ongoing engineering cost, not a one-time architectural decision you make and forget.

How we approach this

We default to the simplest architecture that can plausibly work, and only add multi-agent complexity when evaluation data shows a single agent genuinely isn't sufficient. It's never a starting assumption.