3 multi-agent patterns—and when each one fails

The three patterns at a glance

Before you add a second agent, be honest that a single well-scoped agent is usually cheaper, simpler, and safer to supervise. Reach for these patterns only when one agent is genuinely overloaded and the work breaks into stages you could brief separately. When it does, three shapes cover almost everything—and each one has a first failure that shows up before any other.

The rest of this note takes each pattern in turn: what it is for, how to tell it is actually working, the failure that appears first, and the trade-off you accept by choosing it.

Pattern 1 · Supervisor and specialists

A supervisor pattern puts one coordinator—you, or a lead agent—in charge of breaking a goal into bounded assignments, handing each to a specialist, and assembling the pieces. It suits mixed work with distinct skills: one agent that is good at gathering research, another at drafting, a third at formatting. The value is narrow roles you can inspect one at a time instead of one agent quietly doing everything.

How to judge it: can you trace the assembled output back to each specialist’s contribution? If you cannot tell which agent produced which part, the split is not earning its cost—you have added coordination without adding clarity.

The first failure is a coordinator drowning in outputs it cannot reconcile. The research specialist returns a wall of unlabeled notes; the drafting specialist invents a structure that does not match; the coordinator stitches them into something that looks finished but is unsourced. The fix is the same as briefing a new contractor: write down exactly what each specialist must return and in what shape, so the coordinator is combining clean parts, not guessing.

The trade-off: flexibility costs money and overhead. Each extra agent is a real expense (a second agent is $10 after the first at $22), and a dynamic coordinator is only worth it when assignments genuinely vary. For a job that is the same shape every week, the coordinator is pure overhead—a simpler pipeline will beat it.

Pattern 2 · Pipeline

A pipeline hands one defined artifact from stage to stage: research notes become an outline, the outline becomes a draft, the draft becomes a fact-checked version. It suits repeatable work with clear boundaries and a fixed format at each handoff. Because every boundary produces a real artifact you can open, you can fix or swap one stage without rebuilding the whole chain.

How to judge it: open the artifact between any two stages and ask whether it stands on its own. If stage three only makes sense after re-reading stage one, your boundaries are blurry and the stages are not really separate.

The first failure is error propagation. A miscounted figure in the notes becomes a confident sentence in the outline and a quoted claim in the draft—each stage trusting the last, so a small early mistake arrives at the end looking authoritative. Pipelines are also brittle: change the format of one artifact and every later stage breaks at once. Put a checkpoint—a person or a reviewer agent—at the boundary most likely to carry an error forward, usually the first one.

The trade-off: pipelines are predictable but rigid. They reward stable, repeatable jobs and punish exploratory ones, where you do not yet know the stages. If the work changes shape often, the fixed handoffs become friction instead of structure.

Pattern 3 · Producer and reviewer

Here one agent produces the work and a second checks it against an explicit rubric, with the authority to send it back. It fits content, classification, and structured reports—anything with a standard you can write down. Separating “make it” from “check it” catches errors the producer is blind to, and it forces you to state the rubric, which is valuable on its own.

How to judge it: the reviewer must actually reject something sometimes. A reviewer that approves every draft is decoration, not a control. Read the rejection reasons, not just the count—they tell you where the real quality line sits.

The first failure is false agreement. If the reviewer shares the producer’s assumptions—same framing, same instructions—it nods through the exact mistakes it was meant to catch, and two agents agree confidently on a wrong answer. The other failure is a reviewer with no real authority: it flags problems that get ignored downstream. Give the reviewer a concrete rubric and a genuine veto, or the pattern is theatre.

The trade-off: quality bought with cost, latency, and the risk of an endless loop where producer and reviewer volley a draft back and forth. Cap the revision rounds, and when they hit the cap, route the draft to a person instead of letting the two agents argue forever.

Keep one accountable owner

Whatever the pattern, more agents diffuse responsibility, and diffusion is dangerous. When three agents pass work along, “the system decided” becomes an excuse and a bad result ships because every stage assumed another one caught it. Name one person who owns the workflow: someone who can pause the whole thing, change the rules, and decide whether the final output is good enough to leave the building.

How to judge it: for any output the workflow produces, can you point to one owner, and can that owner stop the system in one place? If not, you have automated the blame along with the work.

The trade-off is deliberate. A single owner is a bottleneck by design—that is the point for anything consequential. Keep the reversible, low-stakes stages fully automatic, and keep the irreversible ones (sending, paying, publishing, deleting) behind that person. Today you do this by keeping each stage’s artifact visible in the dashboard so the owner can inspect any handoff; a single orchestration view that shows agents passing work to each other automatically is Coming soon. Until then, the cheapest and safest orchestration is often the one you already have: one well-scoped agent, with a person at the boundary that still matters.