Multi-Claude Workflows in Practice

Why two Claudes beat one, sometimes

A model reviewing code it just wrote is biased — the reasoning that produced the bug is still sitting in its context, quietly justifying it. A fresh context window has no such loyalty. That one observation drives most practical multi-Claude workflows: split writing from checking so the checker starts clean.

Pattern 1: writer / reviewer

The simplest split uses two sessions:

1. Session A implements the feature.
2. Session B — a fresh session that never saw A's reasoning — reviews the diff: "Review this rate limiter for edge cases, race conditions, and consistency with our middleware patterns."
3. Session A addresses the findings.

A useful variant: one Claude writes the tests, another writes code to pass them. The test-writer can't unconsciously shape tests around the implementation's weaknesses, because it never saw the implementation.

Scope the reviewer, or it will invent work

A reviewer told to find gaps will find gaps — even in sound work. That's not diligence; it's instruction-following. Unscoped review findings send you chasing hypotheticals and produce defensive, over-engineered code. Scope it explicitly:

"Report gaps against the stated requirements and genuine correctness issues only. Not style preferences."

Pattern 2: git worktrees for parallel sessions

Run two agents in one checkout and they'll trip over each other — one runs the tests while the other has files half-edited. Git worktrees solve this: one repository, multiple working directories, each on its own branch.

git worktree add ../myapp-rate-limiter feature/rate-limiter
git worktree add ../myapp-search-fix   fix/search-crash
# one Claude session per directory — edits can never collide

Each session gets an isolated checkout; merging happens through git, where conflicts are visible and resolvable, instead of through two agents silently overwriting each other. Claude Code's subagents can even request this directly (worktree isolation), and the desktop and web apps manage parallel sessions the same way under the hood.

Pattern 3: agent teams

Worktrees isolate agents; agent teams coordinate them. A team adds three mechanisms on top of parallel sessions: a shared task list agents claim work from, inter-agent messaging for questions and handoffs, and a team lead session that decomposes the work and integrates results.

Teams shine on work that genuinely parallelizes — porting many independent modules, writing lessons for different chapters, migrating many similar files. They struggle exactly where the research-system lesson predicted: tightly coupled changes where every agent needs every other agent's context.

The discipline that makes teams work

Parallel agents fail in predictable ways, and two rules prevent most of it:

Freeze shared contracts first. Before any agent launches, pin down the interfaces they all touch: type definitions, API shapes, registry keys, event names. Paste the frozen contract into every agent's brief. Agents build against contracts; they never invent or edit them mid-flight. Without this, each agent extends the shared types "just a little" and integration becomes archaeology.

Give each agent disjoint file ownership. List the exact files each agent owns. Two agents must never edit the same file. An agent that discovers it needs a file it doesn't own reports the need instead of editing. And the seams — the pages, registries, and wiring that join everyone's work — get integrated by the lead afterwards, not delegated.

This mirrors how human teams scale, because it solves the same problem: coordination cost grows with shared mutable state, so minimize what's shared and freeze what remains.

Pattern 4: adversarial verification before "done"

Before declaring work finished, hand the diff to a subagent that sees only the diff and the acceptance criteria — not the reasoning, not the conversation:

"Review the rate limiter diff against PLAN.md. Check every requirement is implemented, listed edge cases have tests, and nothing out of scope changed. Report gaps, not style preferences."

Because findings return into the implementing session, it fixes and re-reviews without you ferrying text between windows. This is the cheapest quality gate in the whole playbook: one extra call, fresh eyes, criteria-scoped.

A worked example, end to end

Shipping a rate limiter with the full workflow:

1. Contract freeze: the middleware interface and config type are written down first.
2. Worktree A implements against the frozen contract; worktree B simultaneously builds the load-test script (disjoint files, no collisions).
3. Fresh session reviews A's diff for race conditions and edge cases; A fixes two real findings, declines one style nit — correctly, because the review was scoped.
4. Verification subagent checks the final diff against PLAN.md: every requirement present, no scope creep.
5. The lead merges both worktrees and runs the full suite.

Four sessions, zero collisions, and every check ran in a context that couldn't rationalize the code it was checking.