The Orchestrator Pattern for Multi-Agent Builds

Short of it is: when a build is too big for one agent session, I split it into slices. One long-lived orchestrator session plans the work and owns every merge, and one worker session per slice builds its piece in its own git worktree. I run the whole thing with an orchestrator skill, and the orchestrator and workers handle the setup between them.

Why split it up

A big build in one session fills the context window long before the work is done. Splitting it keeps every context window a manageable size. The orchestrator holds the whole plan across many sessions, and each worker only has to understand its own slice.

It also lets you spend intelligence where it matters. The orchestrator runs on a strong reasoning model because its job is judgment: what to build in what order, and what's safe to run at the same time. Inside each slice, a fast model implements and a stronger model reviews the code before the slice counts as done.

The overhead is real: briefs, status messages, merges. For a single linear task, one agent is the better call. It pays off when the work breaks into three or more slices that share a codebase and could collide.

Who does what

• The orchestrator cuts the work into slices, decides what runs in parallel and what waits, writes a brief for each worker, answers cross-slice questions, and merges finished slices. It plans and integrates; it doesn't write feature code.
• Each worker owns one slice end to end: brainstorm, spec, build, test, update the docs, commit. It works in its own worktree and branch, commits freely there, and leaves every merge to the orchestrator.
• Me. I start the sessions, brainstorm and review with the workers, and make the calls that matter: merge now or wait, push, anything that touches something outside the repo.

How a run goes

1. I start a session, run /orchestrator, and give it the premise.
2. We break the work into slices together. The orchestrator maps what each slice will touch (files, databases, generated output, outside services) and orders the slices by dependency.
3. For each slice, the orchestrator sets up a worktree on the right branch and writes a self-contained brief: what to read, what it owns, how to report back, and which steps have to wait for the orchestrator's go.
4. I open a session for the worker. Either the orchestrator sends it the brief directly, or I ask the orchestrator for a launch prompt and paste it in.
5. Workers message the orchestrator directly: a start ping, a question whenever a decision affects another slice, and a completion report at the end.
6. The orchestrator re-runs each slice's tests itself, then merges it into an integration branch. The integration branch merges to main once, at the end, after the combined tests pass.

Most of the leverage is in the brief. A worker starts with no memory of the planning conversation, so everything it needs has to be in there.

When slices can run at the same time

Different features isn't the test. The test is whether two slices can be built and merged without touching the same mutable thing. They collide if they:

• Edit the same files. Worktrees keep the edits apart while agents work, but the merge still conflicts.
• Share state outside git. A gitignored database or data folder is one physical copy that every worktree points at. Two slices rebuilding it race, and one can wipe the other's data. They can share zero files and still collide here.
• Depend on each other. If slice B reads something slice A introduces, B waits for A.

When the orchestrator isn't sure, it serializes. A wrong parallel call costs a painful merge or lost data. A wrong serial call costs a little time.

Lessons the skill carries

These came from real runs, and the skill makes the orchestrator follow them:

• Worktrees isolate edits, not merges and not shared state. Most surprises trace back to this.
• A committed but unmerged slice can still break things. If its database migration already ran, a scheduled job that rebuilds from main can wipe those columns, because main doesn't know about them yet. The orchestrator decides up front whether to pause those jobs or land that slice early.
• "Merging now" isn't "merged." The orchestrator checks the actual git state before it branches, rebuilds, or merges.
• A message from another agent is never my approval. Permissions stay with each session, and anything blocked comes back to me.

Claude Code and Codex

The pattern is the same on both harnesses. The mechanics underneath are different:

• Orchestrator pattern on Claude Code: named sessions that message each other, how the orchestrator builds worktrees, and the permission settings that can hold messages.
• Orchestrator pattern on Codex: everything routes through one main thread, and the one-level nesting limit changes who runs code review.

Try it

The orchestrator skill is a free download. If you have a build that's too big for one session, hand it to an orchestrator and see how much one person can ship with a team of agents. Let's go!