Multi-agent systems: when several are worth it

Anyone who has once seen an agent start three helpers wants to solve everything that way afterwards. The diagrams are seductive: a planner, a researcher, a writer, a critic. In practice most of these set-ups fail – not on the model but on the handovers and on the bill.

The default is one agent

A single agent with good tools, a rules file and a clear brief solves the great majority of tasks. It has the whole picture in mind, and there is nothing to coordinate.

Several agents cost:

• Quota. Every helper reads its context in afresh. A run with five agents easily uses a multiple.
• Loss at the handovers. The helper knows only what was in the brief. The one commissioning it knows only what is in the summary.
• Debugging. With a wrong result you have to find out which agent took the wrong turn where.

Three reasons that hold up

1. Context. The task requires reading more than fits into one working memory – a large codebase, a hundred documents. Helpers read parts and hand back summaries.

2. Breadth. The task breaks into independent sub-questions that can be answered at the same time: eight competitors, twelve sources, five variants.

3. Independence. You need a verdict that is not influenced by how the work came about. An agent that wrote a text is poor at finding its own mistakes. A second one with a fresh context finds them better.

Not a reason: roles for the sake of roles. A “project manager agent” passing tasks to a “developer agent” adds a handover and nothing else.

The diagnostic question

Before you build a second agent, ask: what does the first one fail on?

Three patterns

Orchestrator and helpers. A main agent breaks the task down, distributes parts to helpers and assembles the results. Suitable for context and breadth. The helpers read and report – the writing stays with the main agent.

Pipeline with checkpoints. Fixed stages in sequence: collect, analyse, draft. Between the stages sits a check that decides whether things go on. Suitable for recurring workflows in which an early error makes everything after it worthless.

Maker and checker. One generates, one checks – with a fresh context and the explicit brief to find mistakes. The checker gets the brief and the result, not the maker’s reasoning. Otherwise it confirms it.

Writing the handover

A helper starts without your conversation, without the background, without what the main agent has already ruled out. The brief to it must therefore stand on its own:

Goal:      What should exist at the end – and what for.
Known:     What has already been checked or ruled out.
Scope:     Which files or sources, and what explicitly not.
Return:    In what form, with what evidence.

And on the way back: what a helper reports is a report, not proof. The main agent checks the load-bearing statements before building on them – just as you open the sources of a piece of research.

Two rules for operation

One writer per resource. Files, records, tickets: two agents never write to the same thing at the same time. Any number may read.

A cap on fan-out. An orchestrator that starts helpers at its own discretion can use up a monthly budget in minutes. Define how many helpers a run may start at most, and measure what a run costs – that is the next station.

The honest trial

Take your test set and run it once with one agent and once with the multi-agent set-up. Compare hit rate, cost and duration. If the set-up is not clearly better, it is merely more expensive.