Several agents together: orchestration patterns

A single agent works well as long as the task fits in one head. When the work needs different skills — write then criticise, explore then decide — a model doing everything tends to be mediocre at each part, and above all not to contradict itself: whoever just wrote a solution is the worst candidate to find its flaw.

There are four signals that more than one agent is warranted, worth recognising before building anything:

1. the task does not fit one context, by number of files or responsibilities;
2. you need different perspectives, not more force on the same one;
3. the work splits into genuinely independent parts;
4. those parts call for different skills.

If none of the four holds, extra agents only add latency and bills.

The four patterns

Sequential. Each agent takes the previous one’s output. It is an assembly line: simple, predictable, and as slow as the sum of its steps. Its flaw is that a mistake in step one is dragged all the way through, gaining credibility at every handover.

Parallel. The same task is split into independent parts, one per agent, and the results are recombined. It is the best ratio of gain to complexity, but only if the parts are genuinely independent: if part B needs to know how A went, parallelism is a lie you pay for in inconsistencies.

Hierarchical. One agent coordinates and delegates, the others execute. It holds up well for projects with distinct roles, and brings the classic problem of any hierarchy: the coordinator has to keep enough context to decide, and that context grows.

Competitive. Several agents solve the same task independently, and a judge picks. It costs three to five times as much and in exchange raises the odds of a good solution noticeably. It makes sense when a mistake costs more than the compute.

Pattern	Complexity	Speed	Cost	When
Sequential	Low	Slow	Medium	Linear flows with clean handovers
Parallel	Medium	High	Medium	Independent parts
Hierarchical	High	Medium	High	Projects with distinct roles
Competitive	Medium	Medium	High	When being wrong costs more than compute

How information gets passed

Three ways, in order of how long they last.

Direct messages: one agent writes to another. Simple, but everything lives in the conversation, and the conversation grows.

Shared state: agents read and write a common structure. Tidier, and it introduces the problem of two writing the same thing at once.

A mailbox on disk: messages become files. It looks crude and is in fact the option that survives failures best: if an agent dies halfway, what it produced is still there, and the work resumes where it stopped instead of from the beginning.

Where it really breaks

The context fills up. This is the constraint that shows up first, every time. A three-agent conversation over twenty steps produces a history no context window holds intact. What works: interim summaries, mailboxes holding the essentials rather than the history, agents that restart each time by reading only the current state.

Costs multiply, they do not add. Three agents at five steps each are fifteen model calls, and every call carries its own context. With paid models the bill surprises you; with local models the wall clock does.

Nobody converges. Two agents correcting each other can argue indefinitely, each politely convinced. Somebody has to close it: an iteration ceiling, or a coordinator that eventually just decides.

Errors propagate backwards. If one agent fails and another depends on it, the second usually does not stop: it works on a missing or invented result. This is the case where the best fallback is going back to a single agent, not pushing harder.

They step on each other. Two agents writing the same file at the same time produce a failure neither can diagnose, because each only sees its own half.

The question to ask first

The temptation, on discovering this world, is to put five agents where one with the right tools would have done. Before orchestrating, ask: is the bottleneck capability or organisation?

If a single agent fails because it cannot reach some data, the answer is one more tool, not one more agent. If it fails because it is not capable, five copies of the same incapacity do not improve the average: they worsen the cost. Multi-agent pays off when the division of labour brings different perspectives, not more hands.

In short

Concept	In one line
When it is warranted	Not enough context, different perspectives, independent parts
Sequential	Simple, but an early mistake reaches the end
Parallel	Best gain-to-complexity ratio, if the parts are independent
Hierarchical	Distinct roles, and a coordinator accumulating context
Competitive	Costs 3-5x, used when being wrong costs more
The real constraint	The context window, before the cost
The typical failure	No convergence: you need a ceiling or a referee
The prior question	Is capability missing, or organisation?