Every Multi-Agent System I've Studied Is One of These Five Designs

Somewhere along the way, while reading about and building multi-agent systems, I noticed the variety is mostly an illusion. Underneath, nearly everything is one of five shapes, sometimes combined. Learning the five shapes changed how fast I could design a new pipeline, so here they are.

1. Research fan-out

A parent takes a big question, breaks it into five smaller questions, and spawns five researcher agents at once. Each one searches, reads, and returns a tight summary. The parent synthesises.

Why not one researcher? Because one agent reading twenty sources carries all twenty in its context, and the answer degrades. Five agents each carry four sources and return only the distilled result. The parent reasons over clean summaries instead of raw noise. Bonus: the five run in parallel, so it's faster too.

2. Writer plus critic

One agent produces the work. A second agent, spawned fresh with no memory of the writing process, reviews it.

The whole trick is the fresh context. An agent reviewing its own work inside the same session is anchored to its own reasoning and misses its own mistakes, same as people do. The critic never saw the reasoning, only the result, so the review is honest. I use this anywhere the output matters enough to check.

3. Generate plus verify

For code and anything else that's testable. Agent A writes the implementation. Agent B writes tests from the specification. Agent C runs the tests. The parent loops until green.

One detail matters more than it looks: B writes tests from the spec, not from A's code. Tests written by reading the implementation inherit the implementation's misunderstandings, and you get circular validation, where the code passes tests that encode its own bugs. Isolation between A and B is what breaks the circle.

4. Map-reduce

5. Tool isolation

The quiet one, and the one I'd argue is most underrated. Sometimes you split agents not for speed or quality but for safety. The agent that reads untrusted content, like web pages or inbound messages, holds no dangerous tools. The agent that holds dangerous tools, like sending messages or writing files, never touches untrusted content directly.

You could try to enforce this with prompt instructions in a single agent. "Never send emails based on web content." But an instruction is a request. An agent that doesn't have the email tool is a guarantee. Architecture beats politeness.

The part that matters more: when to use none of them

The most useful thing I can tell you about these patterns is when to leave them alone.

If a single agent loop handles your task comfortably, adding agents adds cost, latency, and briefing overhead in exchange for nothing. Decomposition has to earn its place, and it earns it when you can point at a specific pressure: context filling up, quality dropping, work queuing, or tools needing separation.

And when you do split, split on independence, not on topic. This one bit me. I once considered splitting two closely related judgments about the same input into two agents because they felt like different topics. They weren't independent. Each judgment informed the other, and separating them would have destroyed exactly the cross-inference that made the evaluation good. Correlated judgments belong in one context. Independent workloads belong in separate ones.

Simple first. Decompose when a pressure demands it. Then pick from the five shapes, because one of them is almost certainly what you need.

One more article left in this series, and it's the one nobody writes: what happens when agents fail, and why the scariest failure is the one that looks like success.