The coordination patterns behind multi-agent systems that actually work

Production multi-agent wins are not luck. They run on a small set of repeatable patterns, and the public case studies show exactly which ones.

B

Balagei G Nagarajan

3 MIN READ


An orchestrator agent at the center delegating to specialized worker agents arranged in a fan
First, a clear orchestration boundary: one agent owns the plan, the others own narrow slices.
— from “The coordination patterns behind multi-agent systems that actually work”

Key facts.

  • Anthropic's Research uses an orchestrator-worker pattern: a lead agent plans, spins up 3-5 specialized subagents in parallel, each with its own context window and tools, then synthesizes via a separate citation pass (Anthropic Engineering).
  • That multi-agent setup outperformed single-agent Claude Opus 4 by 90.2% on their internal research evaluation (reported).
  • The same post is candid about cost (about 15x the tokens of a chat interaction) and early coordination failures (agents spawning 50 subagents, scouring for nonexistent sources, distracting each other with updates).
  • The pattern is what does the work, not the agent count: Tran and Kiela show that under an equal thinking-token budget a single agent matches or beats multi-agent setups, because every handoff can only lose information (Tran and Kiela, 2026).

What do the working systems do that the broken ones skip?

Coordination is what the eval moved past, not the upgrade; strong models inherit the need for the pattern, paid as 15x token cost and rework. (arXiv:2604.02460)

Three things show up in every public success story. First, a clear orchestration boundary: one agent owns the plan, the others own narrow slices. Second, isolation: each worker gets its own context so a noisy intermediate result does not pollute everyone. Third, a shared store plus a verification pass, so findings are reconciled and checked rather than trusted on faith. Strip any one of these out and the extra agents stop paying for themselves.

Swimlane diagram showing orchestrator, parallel subagents, shared memory, and a verification lane

Pattern vs. anti-pattern

Anti-patternWorking pattern
Peer agents chatting freelyOrchestrator delegates to scoped workers
Shared context everyone writes toIsolated context per worker, shared store for results
Final answer trusted as-isSeparate verification and citation pass
Subagent count unboundedBounded fan-out tuned to task size

VibeModel sits at the pattern level on purpose. The Pattern Intelligence Layer recognizes when an orchestration is drifting from the patterns that work, an unbounded fan-out, an unverified merge, and flags it before it becomes your incident. You copy the patterns; we make sure they keep holding under real traffic.

Frequently asked questions

Do I need frontier models for this to work?
The pattern matters more than the model tier. On WebArena the best agent finishes only 14.4% of real web tasks where humans reach 78.2%, so the coordination structure, not raw capability, is doing the heavy lifting.

Is the token cost worth it?
Sometimes. A 15x token bill is justified for high-value research-style tasks, rarely for simple ones. Match the pattern to the task.


Share this post

Join the discussion

Have a take, a war story, or a question? Sign in with GitHub to comment and react. Comments are powered by GitHub Discussions, ad-free and yours to moderate.

Continue Reading

Find where your agent breaks, before you build it

Faultmap maps where your agent will fail from the goal and your data, then hands you the first test suite it has to pass.