Orchestrator-worker pattern: how to split and gather AI work

How does it differ from chaining or parallelizing?

Anthropic describes this pattern in Building effective agents (December 2024) as one of five workflows, meant for complex tasks where you cannot predict the subtasks needed. Its examples: code changes that touch several files and searches that gather information from several sources.

The key difference from parallelization is flexibility. If you always run the same three reviews in parallel, the subtasks are fixed and you do not need an orchestrator. If their number and type depend on what each person asks for, someone has to decide them on every run: the orchestrator.

To compare it with the other four patterns, read multi-agent patterns. For the general coordination layer, see agent orchestration.

What do the orchestrator and the workers each do?

The orchestrator does four things the workers do not:

1. It understands the full task. It reads the request and decides which parts exist and which are independent.
2. It writes the delegations. Each worker gets an assignment, not the original request in the hope that it will guess.
3. It gathers results. It receives findings from several agents and combines them, removing duplicates.
4. It decides whether that is enough. If information is missing, it launches another round. If there is enough, it stops.

Anthropic’s research system (June 2025) shows it in practice. A lead agent analyzes the query and launches subagents that search in parallel, each with its own context window. The subagents condense what matters and return findings; they do not pass along everything they read. The lead saves its plan to external memory, because once the context goes past 200,000 tokens it gets truncated. At the end, a separate agent finds where each claim comes from so citations can be added.

Workers do not see the whole conversation either. In Claude Code, according to its documentation, a subagent starts with a fresh, isolated context window: it does not see the history, and it works from the delegation message the main agent writes (plus its own system prompt and some project files, such as CLAUDE.md). When it finishes, it returns only a summary. That makes it cheap and focused, but it also means a bad delegation has nothing to recover from.

What should every delegation contain?

Anthropic lists four elements each subagent needs:

• Objective: what it must find out or produce, in one sentence.
• Output format: how to return it (a list, a table, JSON, five points with sources).
• Tools and sources: what to use and what to avoid.
• Task boundaries: what belongs to this worker and what belongs to another.

Without them, the work overlaps. Anthropic reports one case: given the short instruction “research the semiconductor shortage”, one subagent looked at the 2021 automotive chip crisis while two others duplicated work on the 2025 supply chains.

Illustrative example of a complete delegation: “Objective: find the cancellation reasons that appear in the last 200 support messages. Format: a table with reason, number of messages and one short quote per reason. Sources: only the exported support file; do not use pricing data. Boundaries: other workers handle pricing and releases; if something is not in the file, say so instead of assuming it.”

If you cannot write in three lines what each worker is responsible for, you are not ready to delegate.

How many workers should you launch, and what does it cost?

An orchestrator can overspend. Anthropic reports that early versions of its system made mistakes such as spawning 50 subagents for simple queries. The fix was scaling rules inside the prompt:

Cost is the other side. According to Anthropic’s measurements, agents use about 4 times the tokens of a chat and multi-agent systems about 15 times. In return, in its internal research evaluation, a Claude Opus 4 lead with Claude Sonnet 4 subagents outperformed Claude Opus 4 working alone by 90.2%. Those are 2025 models and an in-house evaluation: treat them as an order of magnitude, not a promise. Set the effort before you delegate: how many workers, how many calls per worker and when to stop.

When should you NOT use it?

• When all the agents need the same context. Anthropic says the pattern fits those domains poorly.
• When the task is code with few truly parallel parts. According to the same article, most programming tasks have fewer than a research task.
• When each step needs the complete previous one. A chain is clearer and cheaper there.
• When the value does not justify the cost. A simple question does not need eleven agents.

Anthropic also acknowledges engineering limits. The lead waits for each group of subagents to finish before continuing, which creates a bottleneck. Errors accumulate, because agents keep state. And to avoid losing information by routing everything through the lead, subagents can save their work outside (for example, in files) and return only a lightweight reference.

How does it show up in design?

For a designer, the orchestrator is the invisible part that most affects trust. The person should be able to see which subtasks were created, which is running and which finished, which results came in and which were discarded, and which question the system could not answer. If the split is hidden, a bad result looks like a single AI decision, when it was a set of decisions with intermediate failures. Also decide when the orchestrator stops to ask for a decision, for example before an expensive second round.

Example

Illustrative example: you want to know why subscription cancellations rose last quarter. The orchestrator splits the problem into three delegations: one reviews support cancellation comments, another compares prices and plan changes from the last six weeks, and another reviews the product release notes. Each worker returns five findings with a source and a confidence level. The orchestrator groups them, flags two hypotheses that contradict each other and leaves you one concrete question to validate with database data.

The blog has a real orchestration case with tickets, a two-agent workflow where Claude Opus 4.8 manages OpenCode, in which one agent plans and reviews and the other executes.

Common mistakes

• Delegating with a vague phrase like “research the topic”. The worker guesses and the results cannot be compared.
• Not asking for an output format. Gathering ten free-text answers is work the orchestrator does badly.
• Letting workers overlap. Give them clear boundaries or separate their workspaces.
• Using the same effort level for everything. Simple questions become expensive.
• Using the pattern when the subtasks are already fixed. A plain parallelization is cheaper and easier to debug.
• Trusting the synthesis without checking the sources behind it.

Sources

• Building effective agents (Anthropic Engineering, December 2024): definition of the pattern, when to use it and how it differs from parallelization.
• How we built our multi-agent research system (Anthropic Engineering, June 2025): plan memory, delegation contents, vague-instructions example, scaling rules, the 4x, 15x and 90.2% figures, synchronous execution and cases where it does not fit.
• Subagents in Claude Code (documentation): each subagent’s fresh, isolated context, the delegation message and the summary that comes back.