Multi-Agent Systems: Orchestrating Many AIs

A single agent can plan and act. Some problems are better split across several specialised agents — a researcher, a writer, a critic — each with its own tools and instructions, coordinated toward a shared goal. That's multi-agent architecture, and it mirrors how you'd staff a team: specialists who hand work between them, with someone coordinating.

The patterns worth naming are few. Orchestrator and workers: a lead decomposes the task, delegates sub-tasks, and synthesises the results. Pipeline: agents run in sequence, each transforming the last one's output — draft, critique, revise. Debate or critique: one agent produces, another attacks it, and quality improves through adversarial review. Most real systems are a combination of these rather than a pure form.

The design decisions are the ones that make or break any team: unambiguous roles, clean hand-offs with defined shapes, and a coordinator that resolves conflicts and — crucially — knows when the job is finished. That last point causes more trouble than it should. Without an explicit termination condition, agents ping work back and forth politely improving nothing, and you pay for every round.

There's a genuine case for this architecture. Parallelism, when sub-tasks are independent and can run at once. Specialisation, where each agent gets a focused prompt and a narrow toolset rather than one prompt trying to be everything. Context isolation, which is underrated: each agent carries only what it needs, so no single context fills with the accumulated debris of the whole job. And separation of concerns for safety — the agent that browses the untrusted web need not be the agent holding write access to your database, which is a structural defence against the injection problem from Level 4.

Now the honest costs, because they're larger than the demos suggest. Latency adds up, since agents mostly wait for each other. Token spend multiplies, and the orchestration overhead — agents describing work to other agents — can exceed the work itself. Errors compound across handoffs exactly as they do across steps. And debugging is materially harder: when the output is wrong, you're reading a transcript of several models talking to each other to find where it went astray.

So the architect's discipline is restraint. Reach for multiple agents only when a single well-designed agent provably can't do the job, and be suspicious of your own reasoning here, because multi-agent designs are intellectually satisfying in a way that biases the decision. Five agents that each hallucinate produce worse output than one that does, not better — you've added surface area, not judgement.

Before splitting, try the cheaper things first. A longer, better-structured prompt. Better retrieval. A sequential chain that you control in ordinary code, rather than a model deciding the orchestration. Deterministic code is faster, cheaper and debuggable, and a great deal of what gets built as "multi-agent" is a fixed pipeline that never needed a model to route it.

If you do build one, build in the controls from the start: a global step and budget cap across the whole system, not just per agent; a hard termination condition; logging of every inter-agent message; and a single named place where a human can intervene. Otherwise the first runaway run is discovered on the invoice.

The summary an architect should carry: complexity is a cost you pay, not a virtue you accumulate. Start with one agent. Split only when a specific, identified bottleneck demands specialisation — and be able to say what that bottleneck was.