The Orchestrator-Worker Pattern for Coding Agents, Explained

The moment one long session stops being enough

An AI coding agent can only hold so much of a job's history before every new answer gets slower. Picture a single Claude Code session three hours into a job: add a notifications feature across the API, the background worker, the frontend, and the tests. It is still capable, but every answer takes a little longer, because the model has to re-read everything it already decided before it can add one more line. You start repeating yourself: reminding it what the endpoint is called, what it already ruled out, which test it already fixed once this afternoon.

That slowdown is not the model getting worse at coding. It is one agent carrying the entire job, including every wrong turn it took along the way, inside a context that only ever grows. The orchestrator-worker agent pattern is the fix most serious builders converged on: split the job between a lead agent that keeps the plan and workers that each do one piece, starting clean, then hand the result back.

Comparison at a glance

All three put one agent in charge of delegating, but they differ in who can add a worker, how many can run at once, and who gets to say a task is done.

What the orchestrator-worker pattern actually splits

A lead agent, sometimes called the orchestrator, does three things: it reads the job, breaks it into pieces that do not depend on each other mid-flight, and decides which piece goes to which worker. It never writes the final code itself. Its job is the plan and the handoff.

A worker does one piece and nothing else. It gets the task, the specific files it needs, and nothing about the other tasks running alongside it. That narrowness is deliberate: a worker that only knows its own piece can be as sharp on hour four as it was on minute one, because it never carried the first three hours of the job in its own context.

When a worker finishes, it reports back to the lead, not to you. The lead reads the result, folds it into the plan, and either hands out the next piece or flags that something needs a human.

• Lead: reads the job, splits it into pieces, assigns them, reads the results back.
• Worker: gets one task and a fresh context window per task, nothing else.
• Neither role is fixed to one product. A research system, Claude Code's subagents, and a Forkbench squad all split the same two jobs differently.

Why Anthropic built its own research system this way

Anthropic did not choose this shape for style. In its own writeup on how it built its multi-agent research system, it describes a lead agent running Claude Opus 4 that directs subagents running Claude Sonnet 4, each researching its own angle of a question in its own context before reporting a summary back. Measured against a single Opus 4 agent working alone, the orchestrator-worker setup beat it by 90.2% on Anthropic's internal research evals.

The cost is real, and Anthropic is specific about it: agents typically use about 4x more tokens than chat interactions, and multi-agent systems use about 15x more tokens than chats, because every worker reads and writes its own context on top of the lead's. In Anthropic's testing, token usage alone explained about 80% of the variance in how well a run performed. That suggests the real cost of a bad run is a worker re-deriving what the lead already knew, not a worse plan.

That lines up with older research. A paper on how language models use long contexts, tested across GPT-3.5-Turbo, GPT-4, and Claude 1.3 among others, found accuracy highest when the information a model needs sits at the start or end of its context, lower when it is buried in the middle, and dropping further as the context grows, even for models built to handle long inputs. A worker that starts fresh never builds a middle to lose anything in.

Where the orchestrator-worker pattern breaks

Anthropic is just as specific about where this does not work. Its own writeup says plainly that domains needing shared context or with many dependencies between agents are not a good fit for splitting across workers, because a worker that cannot see what another worker just decided will make a conflicting decision with total confidence. Two workers editing related code without seeing each other's changes is the coding version of the same failure.

The second limit is structural. Anthropic names it directly: synchronous execution creates bottlenecks, because the lead has to wait for an entire batch of workers to finish before it can act on any of them. A squad is not faster than one agent if the lead is sitting idle for the slowest worker in the batch, and a worker that hangs with no timeout turns the whole plan into a wait.

The third is spawning more workers than the job needs. Anthropic has said an early version of its system spawned 50 subagents for simple queries. A lead agent told to delegate will delegate, even when the job was never big enough to split.

None of this is an argument against the pattern. Cognition has made the opposite case publicly: default to a single-threaded agent, because actions carry implicit decisions that two agents who cannot see each other's context will make differently. The honest version of the pattern agrees more than it disagrees: split a job only when the pieces are genuinely independent, and leave a tightly coupled change to one agent.

Claude Code subagents vs Agent Teams, explained

Claude Code ships two versions of this inside one vendor's product. A subagent starts with a fresh, isolated context window unless it is explicitly forked, and which model it runs is resolved in order: a per-invocation parameter first, then the subagent's own frontmatter field (sonnet, opus, haiku, fable, a full model id, or inherit), then an environment variable, then whatever model the main conversation uses. Claude Code allows 20 subagents to run at once by default, past which it reports a concurrent-subagent-limit error, and a subagent can call further subagents up to a default nesting depth of 3 layers, both configurable. Every subagent's requests count against the same usage limit as the main conversation, so running more of them spends the same budget faster.

Agent Teams is a separate, experimental feature, off by default, where a lead session and one or more teammate sessions share a task list and message each other directly, each keeping its own context window. It looks more like a squad than a subagent does, because the teammates are closer to peers than to disposable workers. Both features belong to Claude Code alone, and neither is documented to coordinate with a different vendor's agent.

• Subagent model order: a per-invocation parameter, then the frontmatter model field, then an environment variable, then the main session's model.
• Default limits: 20 concurrent subagents, 3 layers of nesting, both configurable.
• Agent Teams: experimental, off by default, teammates share a task list and keep separate context windows.

What has to sit underneath it to survive a crash or a vendor switch

A subagent's fresh context and Agent Teams' shared task list both solve the problem Anthropic documented: a long session degrading under its own weight. Neither answers a different question: what happens to the plan and the work once the session that started everything closes, crashes, or the next task should go to a different vendor's agent entirely.

A Forkbench squad answers that by keeping the plan outside any one agent's memory. The board where a lead agent writes tasks, progress, and blockers is written to disk, so it survives a context compaction, a closed pane, quitting the app, and a reboot. A task on it records no vendor, so a worker built from any agent you can start from a command, Claude Code, Codex, Aider, or anything else, can claim it. Claiming is a lease: close the pane and the claim releases at once, and if a worker is alive but stuck, a 120-second heartbeat is the backstop that eventually frees the task anyway.

The second piece is who gets to say a task is finished. A worker can report its task done, which only moves it to awaiting acceptance. No agent can verify its own work, and nothing lets an agent raise its own rank to approve it either. Only a human accepting the task makes it done, and a disagreement about whether it is actually finished becomes a discussion that has to resolve before the task can close. That gate does not prove the work is correct. It guarantees that someone other than the agent that wrote it looked at it before it counted as done.

This is also where runaway spawning gets checked, in the plainest possible way: a lead can suggest a new kind of helper, but nothing is added until a human says yes. A vendor's own orchestrator-worker setup is real and it works well at the one thing it was built for, running entirely inside one session, for one vendor's agents. The part it was never going to cover is the part that happens after that session is gone.