Dynamic Decomposition: Orchestrator-Workers and Subagents

1.Orchestrator-workers: when you can't predict the subtasks

Fixed workflows break down when you can't list the subtasks before you see the input. In the orchestrator-workers workflow, a central LLM dynamically breaks the task down, delegates the pieces to worker LLMs, and synthesises their results. On a diagram it looks like parallelization. The difference is flexibility: the orchestrator chooses the subtasks for each specific input. Coding is Anthropic's example. How many files need to change, and what each change is, depends on the task. Searches that gather and analyse information from many sources also fit.

Anthropic's cookbook runs the pattern in two phases. In the analysis and planning phase, the orchestrator receives the task and context, works out which approaches would be valuable, and writes structured subtask descriptions in XML. In the execution phase, each worker receives the original task, its own subtask description, and any extra context. Giving workers the original task as well as their own instructions is a deliberate design choice. The cookbook's demo asks for copy for an eco-friendly water bottle. The orchestrator decides on three approaches (technical-specifications, lifestyle-emotional and benefit-practical), and none of them was hard-coded.

This flexibility has a price. The pattern makes N+1 LLM calls: one orchestrator plus N workers. The cookbook says not to use it for simple single-output tasks, for latency-critical applications, or when the subtasks are always the same, since simple parallelization handles that case. Its main failure mode is that the orchestrator might break the task down badly, so prompt engineering for the orchestrator is critical. One way to manage cost is to use Claude Opus for the orchestrator and Claude Haiku for the workers.

Managed Agents provides this structure as a platform feature. Each delegated agent gets its own session thread, and threads persist, so the coordinator can send a follow-up to an agent it called earlier.

Sources123

2.Isolated subagent context: decomposing to keep context clean

Splitting work across agents doesn't only parallelise it. It also gives each piece a context of its own. Context windows are finite, and response quality can drop as context grows. When information from one subtask piles up and isn't relevant to the next, Anthropic calls it context pollution. Picture a support agent that looks up order history while it diagnoses a technical fault. If every lookup adds thousands of tokens, the agent reasons worse about the fault.

The fix is to give the noisy subtask to an agent with a fresh context and have it return only what matters.

class OrderLookupAgent:
    def lookup_order(self, order_id: str) -> dict:
        # Separate agent with its own context
        messages = [
            {"role": "user", "content": f"Get essential details for order {order_id}"}
        ]
        response = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            messages=messages,
            tools=[get_order_details_tool]
        )
        # Returns only essential information
        return extract_summary(response)

The lookup agent reads the full order history. The main agent gets only the 50–100 tokens it needs. Isolation works best under three conditions: the subtask generates a lot of context (more than 1000 tokens) that is mostly irrelevant to the main task, the subtask is well-defined with clear criteria for what to extract, and the operation is a lookup or retrieval that needs filtering before use.

The Agent SDK builds this in. Each subagent runs in its own conversation, and its intermediate tool calls and results stay inside it. A research subagent can explore dozens of files, and the parent receives a concise summary. Anthropic's research system describes the same thing as compression: subagents explore different aspects of a question in parallel, each in its own context window, then condense the most important tokens for the lead agent. Each subagent also gets its own tools, prompts and exploration path, which reduces path dependency.

Sources456

3.Is the multi-agent split worth its cost?

The basic multi-agent research loop is short. A lead agent splits a question into independent facets, runs subagents on them concurrently, and synthesises their results. Complete the sample below.

async def research_topic(query: str) -> dict:
    # Lead agent breaks query into research facets
    facets = await lead_agent.decompose_query(query)

    # Spawn subagents to research each facet in parallel
    tasks = [
        research_subagent(facet)
        for facet in facets
    ]
    results = await asyncio. ? (*tasks)

    # Lead agent synthesizes findings
    return await lead_agent.synthesize(results)

This split can pay off a lot. With Claude Opus 4 leading and Claude Sonnet 4 subagents, Anthropic's multi-agent system beat single-agent Claude Opus 4 by 90.2% on an internal research eval. When asked to find the board members of every Information Technology company in the S&P 500, the multi-agent system found the answers by splitting the job into subtasks, while the single agent's slow sequential searches failed. Token usage alone explained 80% of the performance variance on BrowseComp. Splitting the work is largely a way to spend more tokens on the problem.

The cost is real too. Multi-agent implementations typically use 3–10x more tokens than single-agent approaches for the same task. Another measurement puts multi-agent systems at about 15× the tokens of chat. The task has to be valuable enough to pay for that. Anthropic has also seen teams spend months building elaborate multi-agent architectures, only to find that better prompting on a single agent got the same results.

Some problems split badly. Domains where every agent needs the same context, or where agents depend heavily on each other, are a poor fit today. Most coding tasks have fewer truly parallelisable pieces than research. That doesn't contradict orchestrator-workers listing coding as a use case: one orchestrator directing file-level workers is a different thing from a team of agents coordinating in real time. Managed Agents says multiagent coordination is best suited to complex tasks that need work across many surfaces, or where several well-scoped tasks contribute to an overall goal.

Sources165

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Running subagents in parallel means a multi-agent system finishes faster than a single agent.Why is that wrong?

   Parallelism shortens the time compared with doing the same work in sequence. But multi-agent systems often take longer overall than single-agent ones because they do so much more total computation. The benefit is thoroughness.

   Covered in Is the multi-agent split worth its cost?

2. 2.Any complex task gets better when you split it across several agents.Why is that wrong?

   Tasks where all agents need the same context, or with many dependencies between agents, are a poor fit. Coding usually has fewer truly parallelisable pieces than research.

   Covered in Is the multi-agent split worth its cost?