Orchestrator-workers: a lead agent and parallel workers

Overview

Orchestrator-workers is an agent pattern in which one lead model, the orchestrator, looks at a task, decides how to split it into sub-tasks, sends each sub-task to a worker, and then combines the workers' results into one answer. Workers are usually separate model calls or agents, each with its own instructions, tools and context window. They often run in parallel.

The key feature is that the split is decided at run time. In a fixed parallel workflow, a programmer decides in advance that there are always three sub-tasks. In orchestrator-workers, the orchestrator reads the request and decides that this question needs two workers and that one needs seven, and what each should do. That makes it suited to broad, unpredictable tasks such as research across many sources or code changes across many files.

An everyday comparison is a newspaper editor on a big story. The editor reads the brief, decides which angles matter, and sends one reporter to the courthouse, another to interview residents and a third to check the figures. The reporters work at the same time and file short reports. The editor then checks them, asks for a follow-up where something is missing, and writes the final piece. The editor is the orchestrator; the reporters are the workers.

What it is

Orchestrator-workers is a pattern used across agent frameworks. It is closely related to sub-agents and is one of the main designs in multi-agent systems.

Part	What it does
Orchestrator	Analyses the task, plans sub-tasks, dispatches them and combines results
Worker	Carries out one sub-task with its own prompt, tools and context
Task brief	The instructions sent to a worker: objective, scope, tools, output format
Dispatcher	The code that starts workers, often in parallel, and collects results
Shared store	Optional memory, files or database where workers save outputs
Synthesiser	The step, often the orchestrator, that merges results into an answer
Verifier	Optional checks on worker outputs or on the final answer
Budgets	Limits on the number of workers, rounds, tokens and time

Workers are usually given a fresh context. They do not see the whole conversation, only their brief. This keeps their context focused and lets the overall system process far more information than one context window holds.

Where it came from

Splitting work between a coordinator and workers is an old idea in computing, from master-worker job scheduling to map-reduce. For language models, it emerged in 2023 and 2024 in multi-agent research and in frameworks that let one agent call others as tools, such as hierarchical crews in CrewAI and manager-led orchestration in Microsoft's Magentic-One.

The name "orchestrator-workers" was popularised by Anthropic's December 2024 guide "Building effective agents", which listed it among common workflow patterns. The guide described it as suited to complex tasks where the sub-tasks cannot be predicted in advance, such as coding changes that touch many files or search across many sources.

In June 2025 Anthropic published an engineering account of its multi-agent research system, in which a lead agent based on Claude Opus 4 directed sub-agents based on Claude Sonnet 4. On Anthropic's internal research evaluation, this design outperformed a single Claude Opus 4 agent by 90.2 per cent. It also used far more tokens: about 15 times as many as a chat interaction, compared with about 4 times for a single agent. The lead agent typically started 3 to 5 sub-agents in parallel, which cut research time by up to 90 per cent on complex queries. The account stressed that the pattern pays off for valuable, broad tasks, not for everything.

How it works

Step 1: Analyse the task

The orchestrator reads the request and decides whether it needs workers at all. A simple question should be answered directly. A broad one, such as "compare the data protection rules for health apps in five countries", is a candidate for delegation.

Step 2: Plan sub-tasks

The orchestrator splits the task into parts that can be done independently. Good splits have little overlap, clear boundaries and roughly balanced effort. It should also scale the number of workers to the task, since spawning many workers for a simple query wastes money.

Step 3: Write clear briefs

Each worker needs a brief with an objective, the scope and boundaries, which tools and sources to use, the output format and a length limit. Vague briefs cause workers to duplicate each other, miss key parts or return results that are hard to combine.

Step 4: Dispatch and run

Code starts the workers, usually in parallel. Each worker runs its own loop, calling tools and reasoning, and returns a compact result: findings, sources and confidence. Long outputs can be written to a shared store, with only a reference returned, to keep the orchestrator's context small.

Step 5: Check and iterate

The orchestrator reviews results. If something is missing, contradictory or weak, it can send follow-up tasks. A round limit stops endless delegation.

Step 6: Synthesise

The orchestrator, or a dedicated synthesiser, combines results into the final answer, resolving conflicts and keeping sources. A verifier can check citations or run tests before the answer is returned.

Key concepts and terms

Term	Meaning
Orchestrator	The lead agent that plans, delegates and combines
Worker	An agent or model call that does one sub-task
Sub-agent	A delegated agent with its own context, often a worker
Dynamic decomposition	Deciding the sub-tasks at run time from the input
Task brief	The instruction package given to a worker
Fan-out	Sending sub-tasks to many workers at once
Fan-in	Collecting and merging worker results
Context isolation	Giving each worker a fresh, focused context
Synthesis	Combining worker results into one answer
Effort scaling	Matching the number of workers to task difficulty
Token budget	A cap on total tokens across all agents

A worked example

This scenario is illustrative. A product team asks a research assistant: "What do the five largest competitors charge for their business plans, and which features do they include?"

The orchestrator decides the task is broad enough for workers. It plans five sub-tasks, one per competitor, plus one to check for recent price changes.
Each worker brief says: find the current business plan price and listed features on official pages; return a table row with price, billing period, five key features and source links; stop after 8 tool calls.
Six workers run in parallel. Five return clean rows. One returns two different prices from two pages.
The orchestrator sends a follow-up to that worker: "Check which page is newer and whether the lower price is a promotion." The worker confirms the lower price is a time-limited offer.
The orchestrator builds the final table, notes the promotion and lists sources.
Total cost: about 7 worker runs and 3 orchestrator calls. Wall-clock time is close to the slowest single worker, not the sum.

A single agent could have done this in sequence, but it would have filled one context window with five sets of web pages and taken roughly five times as long.

Strengths and limitations

Strengths:

Handles broad tasks that exceed one context window.
Parallel workers cut wall-clock time.
Each worker has a focused context and tool set, which improves quality.
Decomposition adapts to each request.
Workers can use cheaper models than the orchestrator.

Limitations:

Much higher total token use and cost than a single agent.
Poor briefs cause duplicate work, gaps and inconsistent outputs.
Coordination errors: the orchestrator may split badly or misread results.
Harder to debug, because behaviour is spread across many runs.
Not suited to tasks that need tight shared context, such as editing one tightly linked piece of code.
Errors in one worker can be passed on confidently in the synthesis.

How it compares with alternatives

Pattern	Who decides the split	Best for
Orchestrator-workers	The lead model, at run time	Broad, unpredictable tasks
Fixed parallel workflow	The programmer, in advance	Known, repeatable sub-tasks
Plan-and-execute	A planner writes steps, often run by tools	Multi-step tasks with a predictable shape
Single agent with the ReAct loop	Nobody; one agent does everything	Narrow tasks that fit one context
Handoff routing	Each agent passes control to the next	Conversations that move between specialists

Practical guidance and best practices

Start with a single agent; move to orchestrator-workers only when tasks are broad and valuable enough to justify the cost.
Teach the orchestrator to scale effort: no workers for simple questions, a few for medium ones, more only for complex ones.
Give every worker a full brief: objective, boundaries, tools, sources, output format and limits.
Make worker outputs structured and short; see structured outputs.
Store long results outside the orchestrator's context and pass references.
Cap workers, rounds and total tokens; see cost and latency budgets.
Trace every worker run so failures can be traced to a brief or a tool; see tracing.
Evaluate the whole system against a single-agent baseline with evals.

Common mistakes

Spawning many workers for simple queries.
Writing one-line briefs such as "research competitor A".
Letting workers return long, unstructured text that floods the orchestrator.
Splitting tasks that depend heavily on each other, so workers make conflicting assumptions.
Never checking worker outputs before synthesis.
Measuring quality but not cost, then being surprised by the bill.

Frequently asked questions

What is the orchestrator-workers pattern?

It is a design where a lead model splits a task into sub-tasks at run time, sends them to worker agents, often in parallel, and combines the results into one answer.

How is it different from a parallel workflow?

In a parallel workflow the sub-tasks are fixed in code. In orchestrator-workers the orchestrator decides the sub-tasks for each request, which suits tasks whose shape cannot be predicted.

Is it worth the extra cost?

For broad, valuable tasks, often yes. Anthropic reported a large quality gain for research tasks with this design, but about 15 times the tokens of a chat interaction. For narrow tasks a single agent is usually better value.

Should workers use the same model as the orchestrator?

Not necessarily. A common design uses a strong model to orchestrate and cheaper models for workers, if they meet the quality bar on your tests.

How do I stop workers duplicating each other?

Give each a clear scope and boundaries in its brief, tell it what the other workers are covering, and ask the orchestrator to check for overlap when planning.

Is this the same as sub-agents?

Closely related. Sub-agents are the mechanism, a delegated agent with its own context; orchestrator-workers is the pattern of a lead agent using several of them and combining their results.

Glossary

Orchestrator: the lead agent.
Worker: an agent that performs one sub-task.
Brief: a worker's instructions.
Fan-out: dispatching many sub-tasks.
Fan-in: collecting results.
Synthesis: combining results into an answer.
Context isolation: separate contexts per worker.
Effort scaling: sizing delegation to the task.
Token budget: a cap on token use.

Summary

In the orchestrator-workers pattern a lead agent decides at run time how to split a task, sends sub-tasks to focused workers, often in parallel, and combines their results. It shines on broad, valuable tasks such as research and multi-file changes, and it costs much more than a single agent. Anthropic named the pattern in 2024 and reported strong research results with it in 2025. Write precise briefs, scale effort to the task, keep outputs compact, cap budgets and compare against a single-agent baseline.

It belongs to Patterns in my stack, under Agentic AI. Others in the same group:

ReAct loop Plan-and-execute Reflection Tree-of-thoughts Multi-agent systems Human-in-the-loop LLM-as-judge Guardrails