Orchestrator-Workers: Decide the Subtasks at Runtime

#agents #ai #architecture #llm

Short version: In orchestrator-workers, a central agent breaks a task into subtasks at runtime, delegates them to worker agents, and synthesizes the results. Anthropic calls it orchestrator-workers; Google calls it hierarchical task decomposition. The defining trait is that the subtasks are not known in advance.

What is orchestrator-workers?

In the orchestrator-workers workflow, a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results (Anthropic). Google's hierarchical task decomposition organizes agents into a multi-level hierarchy: a root agent receives a complex task, decomposes it into smaller subtasks, and delegates each to a specialized subagent, which can decompose further (Google Cloud).

The one line to remember is Anthropic's: this looks like parallelization, but the subtasks are not pre-defined, they are determined by the orchestrator based on the specific input (Anthropic).

How it actually works

The orchestrator reads the task, decides what subtasks it needs right now, and hands each to a worker. Google's ADK guide shows a report writer that does not research anything itself. It delegates to a research assistant, which in turn manages its own web-search and summarizer tools (Google Developers).

A neat trick makes this composable: you can wrap a whole sub-agent as a tool. In ADK, wrapping an agent in an agent-tool lets the parent call the entire sub-workflow as if it were a single function (Google Developers).

# Google ADK, sketch
research = LlmAgent(name="ResearchAssistant",
                    sub_agents=[web_search_agent, summarizer_agent])
report   = LlmAgent(name="ReportWriter",
                    instruction="Write a report. Use ResearchAssistant to gather info.",
                    tools=[AgentTool(research)])

When to use it

Use orchestrator-workers when you cannot predict the subtasks a task will need. Anthropic's example is coding: the number of files to change and the nature of each change depend on the task, so you cannot hardcode them (Anthropic). Search is similar, where you gather and analyze from sources you do not know ahead of time.

Google positions hierarchical decomposition for ambiguous, open-ended problems that need multi-step reasoning: research, planning, and synthesis. A coordinator decomposes a research project into gathering, analysis, and writing, then delegates each to a specialist (Google Cloud). Decomposing the ambiguity is the whole point.

When not to use it

Do not reach for this when the subtasks are fixed. If you already know the steps, use parallelization or a chain, both of which are cheaper and easier to debug. Do not use it for simple tasks, because the multi-level structure adds real overhead you will not recover. And if a single agent with good tools already handles the task, the hierarchy is premature.

Known problems

The cost is complexity, on two fronts. The multi-level structure adds considerable architectural complexity, which makes the system harder to design, debug, and maintain (Google Cloud). And the layers of delegation and reasoning produce a high number of model calls, which significantly increases both latency and operational cost (Google Cloud).

There is a subtler risk when this pattern is pushed toward autonomous multi-agent territory. When parallel workers share implicit context they do not actually have, they can make conflicting choices that do not compose, which is why some teams keep writes single-threaded even in a hierarchy. The safe version keeps the orchestrator firmly in charge of how the pieces fit back together.

Three things to know before you start

This is dynamic, not parallel. If you can list the subtasks in advance, you do not need an orchestrator, you need a fan-out.
Wrap sub-agents as tools. Treating a sub-workflow as a single callable keeps the parent's reasoning clean and the system composable.
Budget for the model calls. Each layer multiplies calls. Watch cost and latency before you add another level.

FAQ

How is orchestrator-workers different from parallelization?
Parallelization uses fixed, predefined subtasks. Orchestrator-workers decides the subtasks at runtime based on the input. Same shape on a diagram, different flexibility.

Is hierarchical task decomposition the same pattern?
Yes, it is Google's name for it, extended across multiple levels. A root agent decomposes and delegates, and subagents can decompose further.

Why is this pattern so expensive?
Every layer of decomposition and delegation adds model calls, and those calls drive latency and cost. Deep hierarchies multiply the effect.

When does the model decide versus the code?
Here the orchestrator model decides the subtasks. That is what separates it from a coded pipeline, where the control flow is fixed.