Orchestrator-worker AI: How a big model plans while cheap models do the legwork

The orchestrator-worker pattern is a way of building AI systems in which one capable model acts as the planner and many smaller models act as workers. The planner reads the task, breaks it into pieces and hands them out. The workers do the pieces, often at the same time, and report back.

Anthropic’s engineers described it in late 2024 as a workflow where a central model “dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results.” The idea is now showing up in pricing and product design.

A newsroom desk as a mental picture

Picture an editor who gets a request for a report on a new law. The editor does not read every document. Instead, they decide what is needed, send ten reporters to check different sources, and then merge the notes into one story.

The editor is the orchestrator. The reporters are the workers. The editor is expensive and slow, so their time goes to judgment. The reporters are cheaper and faster, so they take the volume.

An AI system works the same way. A large model, such as a top-tier reasoning model, writes the plan. Smaller models, which cost less per request and answer faster, run the checks, summaries and edits.

Splitting, running, and merging

The loop has three steps. First, the orchestrator reads the request and decides which subtasks exist. Second, it launches workers, each with its own instructions. Third, it collects their results and decides whether the job is done or needs another round.

The key point is that the orchestrator chooses the subtasks based on the specific input. In the same Anthropic guide, this is what separates the pattern from plain parallelization, where the split is fixed in advance. The guide gives two examples: coding products that change several files at once, and search tasks that gather information from many sources.

Each worker gets only what it needs. Its context, meaning the text it can see at one time, stays small and focused. That keeps individual calls cheap and lets many run side by side.

From a 2024 guide to research systems

Anthropic’s engineering team published “Building effective agents” on December 19, 2024, with the orchestrator-workers workflow as one of its named patterns. The guide also describes a related pattern, parallelization, with two variants: sectioning (independent subtasks run together) and voting (the same task run several times to compare answers).

On June 13, 2025, Anthropic described a production example in “How we built our multi-agent research system.” A lead agent, running Claude Opus 4, analyzed a query and launched subagents running Claude Sonnet 4 to search in parallel. A separate citation agent then attached sources to claims.

Anthropic reported that this setup beat a single Claude Opus 4 agent by 90.2% on its internal research evaluation. It also said parallel tool calling cut research time by up to 90% for complex queries. These are the company’s own results on its own test, so they show the direction rather than a universal gain.

Where the pattern shows up now

The pattern is visible in the way vendors price and recommend models. In its announcement of November 2, 2026, Amazon Web Services said Claude Haiku 5.5 is available in the Kiro IDE and CLI for the AWS GovCloud (US) Regions. Our report on the release noted that Haiku 5.5 runs at a 0.06x credit multiplier, while requests above 100K tokens are billed at 0.3x.

AWS suggests using Haiku 5.5 as a parallel reviewer and leaving the tougher planning and coding to Opus 5.5 and Sonnet 5.5. That is the orchestrator-worker split written into a product menu: two larger models plan and build, and a cheap one checks the output many times over.

The multiplier matters because a worker pool multiplies calls. If each call is cheap, a team can run many reviewers without the bill rising as fast as it would with a large model for every step. AWS did not say in the page what a credit costs in dollars, so the actual saving cannot be calculated from the announcement alone.

What the pattern costs and where it fails

More agents do not mean less spending overall. Anthropic’s research write-up said that agents typically use about 4 times the tokens of a chat, and multi-agent systems about 15 times. In its words, such systems need tasks valuable enough to justify the extra spend.

Token use also drives quality. On the BrowseComp benchmark, Anthropic found that token usage alone explained 80% of the variance in performance, and that token usage, number of tool calls and model choice together explained 95%. In plain terms, part of the gain comes from simply spending more compute.

The pattern fits some jobs better than others. Anthropic said it works for broad, parallelizable tasks, such as research across many sources. It is a poorer fit when agents depend on one another or must share a lot of context. The company noted that most coding tasks have fewer parallelizable parts than research, and that agents still struggle to coordinate in real time.

There are practical risks too:

• Vague instructions: Anthropic reported that unclear briefs led workers to duplicate each other’s effort.
• Errors that compound: a wrong early step can spread through later steps, so the system needs checkpoints.
• Waiting: in its setup the lead waited for each batch of workers and could not steer them mid-task.

What to watch next

Three signals are worth following. The first is pricing: whether other vendors publish clear multipliers for small models and explain how long-context tiers, like the 100K-token step in Kiro, change the math. The second is asynchronous orchestration, where the planner keeps working while workers run, which Anthropic expects to improve as models do.

The third is evidence. Most published results come from the vendors that sell the models. Independent tests that compare one strong model against a planner with many cheap workers, on the same budget, would show how much of the gain comes from the design and how much from extra tokens.