Multi-agent systems

Why one agent stops scaling

The first agent anyone builds is a single loop with every tool attached to it. That design works, right up to the point where it does not, and the way it stops working is predictable enough to be worth naming before reaching for a fix.

Three pressures push in the same direction. Tool choice degrades with tool count - a model picking from six well-described tools is reliable, and the same model picking from thirty is guessing between near-neighbours. Context fills with irrelevance - a run that researches, then writes, then verifies carries the research transcript through the writing and the writing through the verification, and none of it can be dropped safely because it is all one conversation. Instructions collide - the prompt that makes a good researcher (explore widely, follow leads) is close to the opposite of the one that makes a good verifier (assume nothing, check each claim).

Splitting the work addresses all three at once, which is why the pattern spread. Each agent gets a handful of tools, a clean context, and one set of instructions that does not have to compromise with another. The catch is that you have not removed the difficulty - you have moved it into the space between the agents, and that space is now yours to design.

Multi-agent systems trade a hard prompting problem for a hard interface problem.- worth knowing which of the two your team is better at

Three shapes that work

Almost every production system is one of three arrangements, or a small combination of them.

The ordering above is deliberate. A pipeline is not a lesser version of a supervisor; it is the correct answer whenever the sequence of stages is actually known in advance, which is most of the time. Teams routinely build a supervisor for work that never deviates from the same three steps, then spend weeks debugging a coordinator that had nothing to decide.

The handoff is the design

Everything hard about multi-agent systems lives at the boundaries. Two agents that each work perfectly can produce a system that does not, because what passes between them is under-specified.

The failure has a recognisable shape: the researcher hands over a prose summary, the writer interprets it slightly differently than intended, and the resulting brief is subtly about the wrong thing. Nothing errored. Both agents did their jobs. The information was lossy in transit, which is the multi-agent version of the compounding-error problem described in Why agents fail - except the error now crosses a boundary where nobody is watching.

What makes a handoff sound:

• A defined artifact, not a conversation. A structured object with named fields - sources, claims, open questions - rather than a paragraph the next agent has to parse and re-understand.
• Validate at the boundary. The receiving side checks the shape before starting work. A missing field caught here costs one retry; caught three agents later it costs the run.
• Pass references, not payloads. A file path or an id beats the full document. The next agent reads what it needs, and the handoff does not consume the context you just saved by splitting.
• Say what was not done. The most valuable field in any handoff is the list of things the previous agent could not resolve. Without it, uncertainty silently becomes fact at the boundary.

What coordination costs

Multi-agent systems are sold on capability and paid for in overhead. The bill arrives in four places, and it is worth being able to predict it before committing.

• Tokens. Every agent needs its own instructions and enough context to act. Three agents with 2,000 tokens of setup each cost 6,000 tokens before any work happens, on every run.
• Latency. Sequential stages add up. A pipeline is at least as slow as the sum of its parts, and usually slower once validation and retries are counted. Parallel stages help, but only for work that genuinely does not depend on itself.
• Debuggability. One transcript becomes four. Tracing why the output is wrong now means finding which boundary lost the information, which is a materially harder question than reading a single log.
• Evaluation. Each agent needs its own success criteria, and the system needs one on top. This is where the effort in How to evaluate an agent multiplies - per-agent pass rates that all look healthy can still produce a system that fails, and only an end-to-end check will show it.

None of that is an argument against the pattern. It is an argument for knowing the price, because the common mistake is not choosing multi-agent - it is choosing it before the single-agent version has actually failed.

When one agent is still right

The industry moved toward multi-agent architectures quickly enough that a single agent can feel like an admission of defeat. It usually is not. Stay with one when:

• The tool count is manageable. Under roughly a dozen well-differentiated tools, a capable model chooses correctly and there is nothing to fix.
• The work is genuinely one job. If every step needs the full context of every other step, splitting means either duplicating that context or losing it. Both are worse than not splitting.
• Latency matters. Interactive work rarely survives the round-trips.
• You have not measured the failure yet. If nobody can point at which tool is being mis-selected or which instructions conflict, splitting is a guess with a coordination bill attached.

A useful test: describe the boundary you intend to introduce, and name the artifact that will cross it. If that artifact is hard to define, the split is in the wrong place - and a badly placed boundary costs more than the problem it was meant to solve.

Making it work in practice

For teams past the decision and into the build, the moves that reliably help:

• Start with the pipeline. Fixed order, defined artifacts. Add dynamic routing only when a real case demands it, and let that case justify itself.
• Give every agent its own budget. Iterations, spend and wall clock per agent, plus a ceiling for the whole run. Without the outer limit, one stalled specialist consumes the entire budget quietly.
• Keep the goal at every stage. Each agent should see the original objective, not only the handoff it received. It is the cheapest guard against a system that drifts a little at each boundary and arrives somewhere nobody asked for.
• Trace the run as one thing. A single correlation id across every agent, tool call and handoff. Without it, debugging means reading four logs and guessing at the order.
• Verify at boundaries, not only at the end. A cheap mechanical check between stages catches the bad artifact while one agent is responsible for it.

The pattern that holds all of this together is unglamorous: the agents are the easy part, and the contract between them is the system. Teams that treat handoffs as an interface design problem tend to ship. Teams that treat them as messages between colleagues tend to debug for a long time.