On April 10, 2026, Anthropic published something the developer community had wanted for a long time: an official guide to coordinating multi-agent systems. Not a vague blog post. Not an X thread. Architecture documentation — five concrete patterns, explicit failure modes, and a decision matrix.
Why does it matter? Because the model vendor is saying: “this is how you should build agent systems on our stack.” And for the first time they are transparent about the limits.
Why vendor documentation changes the game
Until now, knowledge about agent systems came from three places: YouTube, Twitter threads, and your own experiments. Each has a structural problem.
YouTube gives you a twenty-minute tutorial that works on a demo but falls apart in production. Twitter gives hot takes without architectural context. Experiments cost tokens and time — and often rediscover issues the vendor already knew.
Now Anthropic says: here are five patterns we see in production. Here is where each one breaks. Here is how to choose. Along the way they confirm that Claude Code — their flagship agentic coding tool at ~USD 2.5B ARR — itself uses an orchestrator–subagent pattern.
That is not altruism. Anthropic benefits when we build effective agent systems: effective systems burn more tokens. But incentives align here: fewer wasted tokens, faster pipelines, fewer production bugs. Transparency on failure modes means Anthropic is playing a game where both sides can win — and for the first time the business assumptions are on the table.
Five patterns — a practitioner’s tour
Anthropic describes five coordination patterns. We will not repeat the full docs — read the original, it is worth every minute. Instead, here is what changes for developers doing agentic coding.
Generator–verifier: the quality loop
The simplest pattern. One agent generates output, another verifies. Feedback returns to the generator until acceptance or an iteration cap.
You see this daily in agentic coding: the tool writes code, you (or a test agent) review, you give feedback, the tool fixes. Anthropic formalises the pattern and adds a key insight: a verifier without explicit criteria is a verifier that approves everything. If your review prompt is “check if it looks OK” — you have theatre, not quality control.
Orchestrator–subagent: Claude Code in practice
Anthropic states plainly that Claude Code uses this pattern. The main agent writes code and edits files. In the background it dispatches subagents to search the codebase, explore side questions, and return condensed results. Each subagent works in its own context window.
If you use Claude Code, Cursor, or similar — you already use this pattern. The question is whether you use it consciously.
Agent teams: long-lived context, independent work
Unlike the orchestrator pattern, teammates persist. They do not vanish after one task — they accumulate context and specialisation. Practical case: a codebase migration where each agent owns one service end-to-end.
For agentic coding: if you have many independent modules, dedicated agents with memory can beat one agent that restarts from zero every time.
Message bus: event-driven at scale
Publish/subscribe with a router. Agents subscribe to topics; the router delivers messages. New agents join without rewiring the old ones.
In engineering practice: a CI/CD pipeline with agents. A test alert → triage agent → route to fix or report agent. Add a new agent without touching the existing graph.
Shared state: a common knowledge store
No central coordinator. Agents read and write a shared store. Everyone sees others’ findings immediately. Anthropic cites research synthesis; for developers the interesting case is a debug session where several agents explore different hypotheses in parallel and share results in real time.
Hardest failure mode: reactive loops — agents reply to each other without converging and burn tokens. Mitigation: make termination conditions a first-class part of the architecture.

Decision matrix — how to pick a pattern
Anthropic gives four qualifying questions:
- How long must an agent keep context? Short, single task → orchestrator–subagent. Long, many steps → agent teams.
- How predictable is the workflow? Known sequence → orchestrator. Emergent → message bus.
- Do agents need to discover each other? No → agent teams. Yes → shared state.
- Is work event-driven or knowledge accumulation? Events → bus. Knowledge → shared state.

Anthropic’s headline recommendation: start with orchestrator–subagent. It covers the broadest problem range with the lowest overhead. Watch where it struggles — only then evolve.
What you will not learn from YouTube
Agentic coding videos share one trait: they show the happy path. Working demos. Wow moments.
Anthropic’s documentation does something else — it names failure modes. For example:
- “A verifier told only to check whether output is good will rubber-stamp the generator’s output.”
- “After several handoffs, critical details are often lost or summarized away.”
- “The system keeps burning tokens on work that isn’t converging.”
That is knowledge you normally pay for in weeks of experiments and token budget. Anthropic gives it away because it wants working systems — and productive token spend, not reactive loops.
Lesson: read the vendor documentation. Not instead of experiments — but before them. You will know what to look for and what to avoid.
What we are testing at REL8 — and why we publish this now
As we write this, our team is actively testing Anthropic’s patterns in production workflows — not as a thought experiment, but in pipelines that generate code, content, and automation every day.
Concretely: we are reshaping our agent architecture. Until now our pipeline (RESEARCH → WRITER → SEO → VISUAL → FRONTEND) behaved like a simple chain. After reading Anthropic’s guide, it is clearly orchestrator–subagent with generator–verifier elements — built intuitively, without explicit pattern names.
We are now experimenting with:
- Explicit verification criteria at each pipeline stage (not “check if OK” — checklists with measurable points)
- Termination conditions for agent loops — token budgets, iteration caps, convergence thresholds
- Different models in different roles — faster model for research, stronger for writing, fast model for verification
We will run the same tasks under different configurations and measure wall time, token cost, and output quality. Documentation is one thing — production numbers are another. We will publish benchmarks when we have them.


What you can implement today
- Read the original. Seriously. Start here: claude.com/blog/multi-agent-coordination-patterns
- Map your current workflow to patterns. If you use Claude Code or Cursor, you are probably already on orchestrator–subagent. Name it. Find where it strains — that is your evolution point.
- Add explicit verification criteria. If one agent “checks” another’s output, give concrete rubrics — not vibes.
- Ship termination conditions. Every agent loop needs iteration limits, token budgets, timeouts. Without them you pay for non-converging reactive loops.
- Experiment with model roles. Not every agent needs the most expensive model. Research: fast model. Writer: strongest. Verifier: small model with a sharp prompt.
What you can gain
Better coordination patterns directly affect cost and delivery speed:
- 30–60% fewer wasted tokens when agents avoid reactive loops and duplicate work.
- 2–5× faster pipelines when subtasks run in parallel (agent teams) instead of strictly sequential flows.
- Fewer bugs in review when generator–verifier uses explicit criteria.
- Architecture scale-out — message bus lets you add agents without rewriting existing ones; shared state avoids a single coordinator bottleneck.
Key idea: vendor documentation is not marketing — it is an architectural shortcut. Instead of rediscovering failure modes over weeks, you get them spelled out upfront. Time saved avoiding known traps can go into experiments that actually move the bar.
We believe Anthropic wants better outcomes for developers — with business assumptions finally stated clearly. The way to verify that is to measure. That is what we are doing.