Multi-agent systems

The appeal, and the arithmetic against it

Dividing a problem among specialists is such a familiar idea from organising human teams that multi-agent architectures feel obviously correct on first encounter. A researcher agent, a writer agent, a critic agent and an editor agent, each with its own prompt and tools, coordinated by an orchestrator. The arithmetic is less encouraging than the intuition suggests. Each agent is its own model call with its own context, so cost multiplies roughly with the number of agents involved. Each handoff between agents is a lossy serialisation of state into text, so information that was clear and structured inside one agent’s context has to be compressed into a summary the next agent can parse, and detail is lost at every such boundary. And reliability compounds in the wrong direction: five sequential steps each succeeding ninety-five percent of the time independently multiply to roughly seventy-seven percent success end to end, with no mechanism by which a later agent in the chain can notice and correct a misunderstanding an earlier agent already baked in and passed along.

The common topologies, and where each one fits

A sequential pipeline runs agents one after another, each consuming the previous one’s output — suited to a task that genuinely decomposes into distinct, ordered stages, such as draft, then critique, then revise. A parallel fan-out, fan-in dispatches the same or related sub-tasks to several agents simultaneously and then combines their independent results — suited to genuinely independent work, such as several unrelated research queries that do not depend on each other’s findings. A hierarchical orchestrator has one agent retain overall control, deciding which sub-agent to invoke for which piece of a larger task and integrating their results itself, rather than letting sub-agents hand off to one another directly — generally the easiest topology to reason about and to debug, because there is always one place to look for the current state of the whole task. A peer-to-peer or debate arrangement has agents critique or challenge each other’s output directly without a central coordinator — used for tasks where catching a specific type of error benefits from an adversarial rather than a cooperative framing, at the cost of being considerably harder to bound and terminate cleanly.

Context isolation, the strongest real argument for splitting

The most defensible technical reason to use more than one agent is not specialisation of skill but isolation of context. A sub-agent asked to investigate something can spend its entire context window exploring dead ends, reading large amounts of irrelevant material, and iterating on a difficult sub-problem, then return only a few sentences of conclusion to whatever invoked it. The orchestrator never sees any of that exploration, so its own context stays clean and focused on the decisions that actually matter for the overall task, rather than being diluted by the sub-agent’s working process — directly applying the “isolate” move from context engineering.

A worked cost comparison

Consider a task that a single well-equipped agent completes in about ten model calls. Splitting the same task across a four-agent pipeline, where each agent needs roughly three calls of its own to do its narrower piece plus overhead for handoff messages between them, can easily total twenty or more calls for the same underlying work — call it double the cost — while introducing three additional points where information can be lost or distorted in translation between agents, and three additional places where a failure can occur that then has to be traced back through the whole chain rather than through a single agent’s trace.

Before reaching for more agents

Try one agent with better tools first. A striking number of multi-agent designs turn out to be compensating for a tool that returns far too much raw data, a single prompt trying to cover too many distinct cases at once, or a context that was simply never compacted as it grew — all problems that are cheaper to fix directly, and fixing them often removes the original reason a second agent seemed necessary at all.

When splitting is still the right call

Genuinely parallel, independent work — several unrelated searches, several files to examine at once — gains real wall-clock time from splitting, when the branches truly do not depend on one another’s results. Different tools or permission levels is another legitimate reason: an agent permitted to write to a production system should be a structurally different agent from the one reading untrusted web content, with an explicit, inspectable boundary between them. When you do split, make every handoff an explicit, structured format passed between agents rather than a loose paragraph of prose, and trace the entire multi-agent run as a single connected unit — a chain of agents with no end-to-end trace spanning all of them is not meaningfully debuggable at all.