Most multi-agent systems should be one agent

Multi-agent architectures are the default diagram in every AI strategy deck: a planner, a set of specialists, a critic, a synthesiser. The diagrams are appealing because they map onto how an organisation is structured. That is exactly the reason to distrust them, because dividing a task across agents imports every coordination problem that makes organisations slow, and adds a few that are specific to non-deterministic components.

What the split actually costs

• Context is lost at every boundary. Each handoff is a lossy summary, and the receiving agent cannot know what was dropped.
• Errors compound rather than cancel. Three agents at ninety percent reliability in sequence is not a ninety percent system.
• Debugging becomes correlation. A wrong output now requires reconstructing which agent introduced the error, across separate traces.
• Latency and cost multiply, because coordination messages are themselves inference calls.
• Failure modes emerge that no single component exhibits: two agents deferring to each other, a critic that rejects indefinitely, a planner re-planning on every tool error.

Every agent boundary is a place where context goes to die. Add one only when a single agent has genuinely run out of room.

When orchestration genuinely earns its cost

There are real cases. They share a property: the split is imposed by something structural rather than chosen for elegance.

• Hard permission boundaries. An agent with production write access should not be the same agent processing untrusted inbound text. The split is a security control and worth its cost.
• Genuinely parallel work. Independent subtasks with no shared state, where the parallelism buys wall-clock time that matters.
• Divergent tool or model requirements. A step needing a specialised model, a different latency profile, or a separate deployment lifecycle.
• Independent scaling. One stage runs thousands of times per stage of another, and coupling them wastes capacity.

The honest default

Start with one agent, a well-designed tool set, and a clear context strategy. Most tasks that appear to need a team of agents actually need better tools and a tighter prompt. Split only when you can name the specific constraint the split relieves, and when you have instrumented enough to prove the single-agent version hit it.

The organisational version of this argument is the more important one. A multi-agent system is harder to own, harder to evaluate, and harder to explain to the people who have to trust it. Complexity that cannot be explained to its owner does not survive the first incident, and surviving incidents is the entire test of whether a system stays in production.

A test before you split

Before committing to an orchestrated architecture, run the candidate task as a single agent with a generous context window and all the tools it needs. Characterise what it gets wrong. If the failures are about missing capability, splitting will not fix them. If the failures are about attention degrading over a very long context, about a result one step needing to gate another, or about a genuine security boundary, the split is warranted. Make this a test, not a presumption.

The field has a naming problem here too. Calling a system multi-agent when it is one agent with two sequential tool-use steps is a presentation choice, not an architecture. The costs of true orchestration, shared state, separate deployments, cross-agent tracing, appear late and matter enormously. Know which one you are building before you name it.