Multi-agent patterns that converge (and ones that don't)

Running several agents at once doesn't automatically get you a better answer faster — it gets you several partial answers and a new problem: deciding when you're done. Some multi-agent shapes resolve that cleanly. Others, especially anything built as "agent A reviews agent B reviews agent A," can run indefinitely unless you design the exit explicitly.

The pattern that converges

Anthropic's own research system uses an orchestrator-worker shape: a lead agent breaks a task into independent pieces, spawns subagents to work them in parallel, then collects and synthesizes the results into one output. In their internal evaluation, a multi-agent system with a stronger lead agent and worker subagents outperformed a single agent working alone by 90.2% on research-style tasks, described in their engineering writeup. The structural reason it converges is visible in the figure: fan-out is bounded (a fixed number of subagents), the verify gate is a single checkpoint everything passes through once, and synthesis produces one artifact. There's no path back to an earlier stage.

The pattern that doesn't

The failure shape is symmetric: two agents pointed at each other with no independent stopping rule. Agent A drafts, agent B critiques, A revises based on the critique, B critiques the revision, and so on. Each round looks like progress locally, but nothing in the loop says when to stop — "critique found no issues" is a judgment call an LLM can make inconsistently, and a slightly different phrasing each round can manufacture new nitpicks indefinitely. The same Anthropic writeup describes an early, related failure mode from the other direction: subagents given vague task boundaries would spawn far more workers than a query needed, or keep searching after they already had a sufficient answer — not a two-agent ping-pong, but the same underlying problem of no explicit stop condition. They fixed it with explicit scaling rules and clearer task boundaries, not with a smarter model.

Judge panels and deduplication

A useful middle pattern is the judge panel: run the same task through two or three agents independently, then use a separate, cheaper pass to pick or merge the results rather than having them negotiate directly. This avoids the back-and-forth entirely — there's no loop because the judge only runs once, after all candidates exist. Deduplication matters here too: if two subagents research overlapping ground, synthesis has to notice the overlap rather than presenting the same finding twice as if it were confirmed independently.

Stop conditions that actually stop

A stop condition needs to be checkable by something other than the agents in the loop: a fixed round limit, a budget, or a verify step with a pass/fail the loop can't argue with. "Stop when quality is good enough" is not a stop condition if the same model is both producing and judging quality.

Try it today

1. Draw your current multi-agent setup as a graph. If there's a cycle with no external exit, that's the bug, not a tuning problem.
2. Add a hard round cap to any critique-and-revise loop you're running today.
3. Replace one negotiation-style loop with a judge pattern: run candidates independently, pick with a single separate pass.
4. Check your synthesis step for duplicate findings when subagents' scopes overlap.

Where this breaks

Fan-out costs more tokens up front even when it converges cleanly, so it's wasted on tasks a single agent could do in one pass. A verify gate is only as good as what it checks — a gate that just asks "does this look done" will pass through the same problems a two-agent loop would. And a hard round cap prevents infinite loops but can also cut off a task that was one round away from actually converging; log what the last round produced so you can tell the difference.

Next: agents that browse and pay — the same convergence question shows up again once an agent is allowed to take real-world action instead of just producing text.