Proven Multi-Agent Patterns
Roles and coordination are the machinery. These patterns are the assemblies that repeatedly work. Each one buys a specific kind of independence or parallelism; none of them is "run more agents for speed." If you cannot name the failure mode the pattern prevents, you do not need the pattern yet — start from Agent Roles and Coordination.
1. Builder + reviewer
Prevents: self-confirming review; plausible-but-wrong merges.
Builder prompt (abridged):
Implement docs/specs/<feature>.md on branch feat/<name>.
Stay inside the file paths listed in the spec. Do not review
yourself. Paste typecheck/test output when done. List assumptions.Reviewer prompt (abridged):
Fresh review of git diff main...feat/<name> against
docs/specs/<feature>.md and CLAUDE.md. You did not write this.
Find blockers ranked by blast radius. Do not edit files.
Do not ask why the builder did anything — only whether it
matches the spec.Human arbitrates disagreements by fixing the spec, then re-running the losing side. Full independence rule: Agent Roles.
2. Architect then builder
Prevents: architecture improvisation inside an implementation session (what not to delegate).
Architect session is read-heavy (Claude Code plan mode is the natural fit): no production code until a human records the decision in an ADR or spec section. Builder gets the approved plan as input, not a vague goal. If the builder discovers the plan is wrong, it stops and escalates — it does not silently redesign.
3. Tester-first
Prevents: tests that characterize the agent's bugs; missing named edge cases.
Tester inputs: spec only — deliberately not the implementation. Builder inputs: spec + failing tests. Reviewer greps for deleted/weakened assertions. This is the highest-leverage pattern for money and auth paths; see Verification Strategy and Reviewing AI Tests.
4. Parallel feature slices
Prevents: serial bottleneck on independent work; also prevents merge chaos if mis-sliced.
Preconditions: stable interfaces on main, non-overlapping path ownership, one human integrating. If slices share a hot file, they are not slices — sequence them. Coordination details: Coordination.
5. Mixed-tool workflow
Prevents: using one interaction shape for every job. Tools change; the mapping is by shape, not brand loyalty.
| Job shape | Tool fit | Notes |
|---|---|---|
| Long-horizon multi-file implement | Autonomous agent (e.g. Claude Code, Codex-class) | Needs repo tools + test loop |
| Adversarial / cold review | Fresh agent session or other model | Different context; optionally different model family |
| Line-level interactive edit | In-IDE assistant (e.g. Cursor-class) | Human drives; bad as unsupervised builder |
| Planning dialogue | Chat or plan-mode agent | Read-only until approval |
| Broad research / second opinion | Separate model or research role | Cite sources; spot-check APIs |
Example assembly for a billing feature:
- Planner (chat or plan mode) → options doc → human ADR.
- Tester (autonomous agent, spec-only) → failing tests PR.
- Builder (autonomous agent) → implementation PR.
- Reviewer (fresh session, possibly other model) → findings.
- Interactive assistant → human fixes nits in-IDE.
- Human merges after verification checklists.
Roles still matter more than logos. Five tools sharing one contaminated conversation lose to one tool with clean builder/reviewer separation.
Choosing a pattern
| Situation | Pattern |
|---|---|
| Any non-trivial PR into production | Builder + reviewer |
| New subsystem, unclear shape | Architect then builder |
| Clear acceptance criteria, high cost of bugs | Tester-first |
| Independent modules, time pressure | Parallel slices after interface merge |
| Team already multi-tool | Mixed-tool by job shape |
Stack patterns when needed: architect → tester-first → parallel builders → reviewers is a valid pipeline for a large feature; it is also a lot of process — use the minimum that matches blast radius.
Anti-patterns
| Anti-pattern | Why it fails |
|---|---|
| Same session builds then "reviews" | No independence |
| Three builders, one branch, no ownership | Edit conflicts + blame fog |
| Reviewer applies fixes | Unreviewed changes; role collapse |
| Parallel work before interfaces land | Incompatible assumptions, rewrite tax |
| Pasting builder rationale to reviewer | Context contamination |
Related
- Agent Roles — taxonomy and independence rule behind every pattern.
- Coordination — git, worktrees, and repo-as-bus mechanics.
- Verification Strategy — second-agent attack as the review half of builder+reviewer.
- What Not to Delegate — why architect-then-builder exists.
- Case Study: Multi-Agent Feature — patterns in a realistic delivery.
- Learning Path: Multi-Agent Mastery — structured practice.