Orchestrator-worker agents: splitting work across agents

The orchestrator-worker pattern splits a task into independent pieces, runs workers on them at the same time, then combines their results. Anthropic reported a 90.2 percent improvement over a single agent on its internal research evaluation, while using about 15 times more tokens than a single chat. The trade makes sense for research questions that benefit from several independent searches. It gets harder when workers must edit the same files or depend on each other's decisions. Decide which tasks can run separately and which need to share files, information, or decisions.

TL;DR An orchestrator assigns independent subtasks to parallel workers and combines their results. Anthropic reported a large research gain in its evaluated setup, with about 15 times the tokens of one chat. Shared writes and dependent decisions need coordination; separate worktrees only prevent file collisions, not conflicting assumptions. Compare the pattern with a simpler baseline on your task before paying for extra workers.

What the orchestrator-worker pattern is

Orchestrator-worker has three roles: a lead that chooses the subtasks, workers that execute them in parallel with separate contexts, and a synthesis step that combines their results. For a research brief, the lead might ask one worker to find primary sources, another to find counterexamples, and a third to check dates and definitions before it writes the answer.

The emphasis here is dynamic task splitting and parallel execution. A supervisor can also delegate to several workers at once; these patterns overlap. If one subtask needs another's result, express that dependency instead of putting both in the same parallel batch.

This is one of the eight agent patterns. Test it when a simpler system cannot cover the work quickly or broadly enough, and when the subtasks can run independently.

How it works

The mechanism has three moving parts, and each one is where the cost and the risk live.

Decomposition. The lead agent turns one task into N subtasks. This is the hardest step to get right, because the quality of the split decides everything downstream. A good split produces subtasks that do not overlap and do not depend on each other's results. A bad split produces workers that duplicate effort or make conflicting assumptions, and synthesis may need to send work back for revision.

Parallel execution. Each worker runs in its own context. The lead receives their outputs rather than every intermediate step. Workers do not see each other's decisions unless the system explicitly shares them, which keeps their tasks separate but can leave conflicting assumptions undiscovered.

Synthesis. The lead reads every worker's output and produces one coherent result. Separate research searches cannot overwrite each other's files, but they can return conflicting claims. The lead must compare sources and resolve those conflicts. On work that writes or decides, conflicting assumptions may surface only at this stage, when they are costly to fix.

The mental model: the orchestrator decides what gets done and how it recombines, the workers decide how each piece gets done. The pattern is only as good as the orchestrator's answer to the first and third questions. Worker reliability still matters, but it cannot repair an unclear assignment by itself.

Figure: LangChain, workflows and agents, recolored to the page.

What it looks like in code

The fan-out is the Send API. The orchestrator returns one Send per unit of work, and LangGraph spins up a worker for each in parallel. Each worker returns a result update. A reducer combines those updates into a list for the synthesizer. Without that reducer, concurrent writes to the same LangGraph state key can fail. The wiring fragment below assumes the three application node functions are defined separately.

import operator
from typing import Annotated, TypedDict
from langgraph.types import Send
from langgraph.graph import StateGraph, START, END
 
class State(TypedDict):
    sections: list[str]
    completed_sections: Annotated[list[str], operator.add]
    final_report: str
 
def assign_workers(state: State):
    # one worker per section, all in parallel
    return [Send("llm_call", {"section": s}) for s in state["sections"]]
 
builder = StateGraph(State)
builder.add_node("orchestrator", orchestrator)
builder.add_node("llm_call", llm_call)        # the worker
builder.add_node("synthesizer", synthesizer)
builder.add_edge(START, "orchestrator")
builder.add_conditional_edges("orchestrator", assign_workers, ["llm_call"])
builder.add_edge("llm_call", "synthesizer")
builder.add_edge("synthesizer", END)
orchestrator_worker = builder.compile()

The orchestrator returns a nonempty sections list. Each llm_call receives its assigned section and returns {"completed_sections": [result]}. The synthesizer reads that accumulated list and returns final_report. Handle an empty plan before dispatch, and include section identifiers if output order matters.

Source: LangGraph, workflows and agents.

The evidence: 90.2 percent and 15x

Anthropic's multi-agent research system is the cleanest public data point. Their orchestrator with parallel workers scored 90.2 percent higher than single-agent Opus 4 on internal research evaluations. In the same post they report the price: the multi-agent system used about 15 times more tokens than a chat interaction. They are explicit that this only makes sense for high-value tasks, and that most coding work has fewer parallelizable subtasks than research does.

Anthropic also examined the association between resource use and benchmark scores. On BrowseComp, Anthropic found that token usage alone explained 80 percent of the performance variance, and token count, tool calls, and model choice together explained 95 percent. That analysis links performance to resource use in the evaluated setup. It does not show that adding tokens alone will improve a different task.

For one coding harness, Anthropic's harness-design post reports an orchestrated version over 20 times more expensive than a single agent on the same task. These are measurements from different workloads and baselines, not a general price range. Measure your own tokens, time, and answer quality against a single-agent run.

When to use it

Consider the parallel variant when these conditions fit the work:

• The subtasks are genuinely independent. No worker needs another worker's output. This is the load-bearing condition, and it is rarer than it looks.
• Workers can operate without colliding. Read-heavy tasks are a natural fit; write-heavy tasks need isolated outputs and a defined integration step.
• Concurrent work provides useful coverage. Separate searches or checks can cover different angles. A final narrative still needs synthesis and review.
• The result is worth the measured cost. Additional workers increase model calls and synthesis work. Compare the useful output with a simpler baseline.

Test the proposed split against a single-agent baseline. If dependencies dominate, a sequential workflow may be simpler. Anthropic's research result is evidence for its evaluated setup, not a performance promise for every task.

When it breaks: shared state, not scale

Shared state creates a failure that can look like success. Every worker may return a plausible result, yet their outputs can conflict when combined. More workers make that harder to inspect unless the task split and merge rules are clear.

The clearest public evidence is a pair of posts published a day apart in June 2025. Cognition argued in Don't build multi-agents that actions carry implicit decisions, and parallel agents making conflicting decisions produce incoherent output. Anthropic published their 90.2 percent result the next day. These reports involve different workloads. Independent research queries make a useful parallel workload; shared code changes require coordination and integration.

Google Research put numbers on that boundary. Across 180 controlled experiments, multi-agent coordination improved parallelizable tasks by up to 81 percent and degraded sequential ones by 39 to 70 percent. Independent agents with no coordination amplified a single mistake 17.2 times through unchecked propagation, against 4.4 times under central coordination. The variable that predicted the outcome was whether the task decomposed into independent subtasks. The findings support testing the task decomposition before adding workers.

The MAST taxonomy, built from over 1,600 annotated traces across seven frameworks, groups failures into system design, inter-agent misalignment, and task verification. Prompt changes may help a particular handoff, but they cannot by themselves remove shared writes or verify a broken merge.

Removing the shared state

Some writing tasks can run in parallel after the shared state is reduced. The important choice is how each worker's output will be combined.

• Disjoint file sets. A 2026 study of 33,596 agent-authored pull requests found the cross-agent conflict rate of 42 percent drops to near zero when agents are handed non-overlapping files. Partition the work so no two workers touch the same thing.
• Git worktrees. Give each worker its own checkout so parallel writes never land on the same file on disk. Isolation by construction.
• Map-reduce with a reducer. LangGraph's Send API lets N workers write into a merge function rather than a shared object, so the combination is explicit and controlled.
• Best-of-N. Generate many candidates independently, then select one. AlphaCode generated up to a million samples per problem and filtered to ten, reaching the top 54.3 percent of Codeforces competitors. CodeT lifted HumanEval pass@1 by 18.8 points by having candidates vote through generated tests.

Two traps that survive the fix

Decoupling is not a free pass, and two failure modes outlive it.

Isolation is not coordination. Worktrees stop two agents overwriting a file. They do not make two agents agree on an interface. CodeCRDT measured 5 to 10 percent of conflict-free merges as structurally valid but logically broken, the code merges clean and still does the wrong thing.

The selector is another failure point. Best-of-N moves the final decision into the test or reviewer that picks a winner. If that check misses a bad candidate, generating more options can make the selected output look more convincing without making it correct.

Cursor reported a concrete example of this bottleneck. Under a lock-based design for parallel coding agents, they found twenty agents slowed to the throughput of two or three, almost all of the time spent waiting on shared state. Adding workers past the point of real independence does not add throughput. It adds a queue.

What to trace

Trace the split, worker outputs, and merge so a bad decomposition is visible:

• Repeated-run success. Run representative tasks more than once and count how often the full result passes. A single successful demo cannot show reliability.
• Cross-worker conflicts. Record overlapping edits, incompatible interfaces, and contradictory assumptions. These show where the proposed split was not independent enough.
• Tokens per run against the single-agent baseline. Watch the multiplier for your own task, not a published example from another workload.
• Synthesis and verifier catch rate. Whether the merge step and whoever checks it actually reject broken candidates. A verifier that never rejects is not verifying, and best-of-N with a blind selector is worse than one good agent.

A staged workflow

Consider a coding task with research, an interface decision, and implementation. Workers can inspect independent source files in parallel. The lead then resolves conflicting findings and chooses one interface. After that decision, workers can edit separate file sets in worktrees, followed by a single integration and test step. A dependency between stages does not prevent parallel work inside a stage.

Before adding workers, define their outputs, the merge, and the check that can reject a bad merge. Compare repeated results, time, and cost with a simpler run. If routing itself becomes hard across distinct domains, hierarchical teams address a different problem. The agent-patterns overview shows the other designs without treating them as required steps.

Sources

• Anthropic: How we built our multi-agent research system
• Anthropic: Harness design for long-running apps
• Cognition: Don't build multi-agents
• Google Research: Towards a science of scaling agent systems
• Berkeley: MAST multi-agent failure taxonomy
• Study: Merge conflicts across 33,596 agent pull requests
• CodeCRDT: Conflict-free parallel agent editing
• DeepMind: AlphaCode and Microsoft: CodeT
• Cursor: Scaling agents