Multi-Agent Systems, and When You Don't Need One

The appeal, and the trap

There is a seductive narrative around multi-agent systems. A team of specialists, a planner who breaks down the work, a researcher who gathers facts, a writer who drafts, a critic who reviews, sounds self-evidently superior to a single generalist trying to do everything. It mirrors how human organisations work, and it makes for great architecture diagrams.

Sometimes it genuinely is better. Just as often, it is a trap. Splitting a problem across agents multiplies the cost (more model calls), the latency (more round trips), and the failure surface (more components that can break or miscommunicate), for a problem that a single, well-prompted agent with good tools could have handled cleanly. The diagram looks impressive; the system is slower, pricier, and harder to debug. Before reaching for a crowd, it is worth being honest about whether the problem actually calls for one.

When multiple agents genuinely help

There are three situations where the split earns its cost.

Distinct skills or permissions. When sub-tasks require genuinely different capabilities, or different access rights, separation is both cleaner and safer. An agent that can read sensitive data and an agent that can post publicly probably should not be the same agent with both powers; splitting them limits the blast radius of any one mistake.

Independent, parallelisable work. When parts of a task do not depend on each other, running them concurrently is simply faster. If you need to research five companies, five workers in parallel beat one agent doing them in sequence. The win here is wall-clock time, and it is real.

Adversarial verification. This is the most underrated benefit. A separate agent whose only job is to attack the first agent's output, to find the flaw, refute the claim, spot the missing case, catches errors that a single pass, however capable, tends to miss. Generation and criticism are different mindsets, and separating them improves quality on hard problems.

When one agent is better

Outside those cases, a single agent usually wins. If the steps are sequential and share a lot of context, handing off between agents mostly adds overhead: each handoff is a chance to lose information, drop nuance, or garble the goal. You pay for serialisation, marshalling state between agents, and you gain little. A single agent with a well-designed loop and the right tools is easier to build, cheaper to run, and dramatically easier to debug, because there is one reasoning trace to follow rather than a tangle of inter-agent messages.

A good rule of thumb: if you cannot clearly articulate why two agents are better than one well-prompted agent for a given boundary, they probably are not.

Coordination is the hard part

The instant you have more than one agent, you have stopped building an application and started building a distributed system, with all the difficulty that implies. Who decides what? How are results passed between agents? What happens when one agent fails, stalls, or produces output another agent disagrees with? These are not prompt problems; they are systems problems, and they are where multi-agent projects most often come apart.

The practical advice is to keep the topology as flat and explicit as you can. A star pattern, one coordinator that delegates to workers and collects their results, is far easier to reason about than a free-for-all where agents converse in an open loop. Open-ended agent conversations are mesmerising in demos and a nightmare in production: they can loop, drift off-task, or amplify each other's mistakes, and they are nearly impossible to debug after the fact. Explicit control flow beats emergent chatter.

Start single, split later

The disciplined path is almost always the same. Build the single-agent version first and get it working. Then, only when you hit a concrete wall, a clear boundary between skills, a genuine opportunity to parallelise, a real need for independent verification, split exactly at that wall, and nowhere else. Let the architecture grow in response to demonstrated need, not in anticipation of imagined elegance.

Multi-agent systems are a powerful tool. They are also one of the easiest ways to turn a tractable problem into an intractable one. Reach for them deliberately, at the boundaries that actually justify them, and you get the upside without buying a distributed-systems headache you did not need.