- In short
- Dynamic task decomposition is a strategy where the subtasks are not fixed in advance. Claude generates the next step based on what it discovers at the current one. It suits open-ended investigation with unknown scope, trading the predictability of a fixed pipeline for the ability to adapt to the problem.
What dynamic task decomposition means
Dynamic task decomposition is the adaptive counterpart to a fixed pipeline. Instead of laying out every step in advance, you let Claude decide the next subtask based on what it has just learned. The plan is not handed down before the work begins; it emerges as discoveries accumulate. One step reveals a fact, that fact suggests where to look next, and the agent generates a subtask to look there.
This is the behaviour Anthropic describes when it distinguishes agents from workflows: agents "dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks." The orchestrator-workers pattern from Anthropic's Building effective agents is the textbook implementation, a central model breaks the problem into subtasks it could not have enumerated beforehand and dispatches them to workers, then folds the results back in.
- Dynamic adaptive decomposition
- A decomposition strategy in which subtasks are produced at runtime from intermediate discoveries rather than fixed in advance. The model generates the next step in light of the current step's results, allowing the plan to adapt to the specific problem at the cost of predictability.
How adapting at runtime changes the shape of the work
In a fixed pipeline the path is a straight line you drew before running anything. In dynamic decomposition the path is a tree that grows as the agent explores. After each step the agent asks, in effect, "given what I now know, what is the most useful next thing to do?" and answers it with a freshly generated subtask. That feedback loop is what lets the approach handle problems whose structure you could not see from the outside.
The trade-off is symmetric with prompt chaining. You gain the ability to follow the problem wherever it leads; you lose the guarantee that two runs take the same route. Because the agent invents steps as it goes, you cannot fully predict the number of calls, the order, or the cost in advance. That unpredictability is acceptable, even desirable, for investigation, but it is exactly what makes dynamic decomposition the wrong choice for a well-structured, repeatable job where a fixed sequential pipeline would be more reliable.
Why this maps onto subagents
Dynamic decomposition pairs naturally with delegation. When an agent generates a subtask it could not have predicted, a clean way to run it is to hand it to a subagent that works in its own context window and returns only a summary. Anthropic's Claude Code subagents exist for exactly this: a side investigation that would otherwise flood the main conversation with logs and file contents is delegated, runs independently, and reports back a distilled result. The coordinator keeps a clean working context while the messy exploration happens elsewhere, the same idea applied to real code in decomposition for legacy codebase tasks.
How orchestrator-workers wires the subtasks
Anthropic's cookbook turns the orchestrator-workers idea into a concrete shape worth knowing. The orchestrator's first job is not to do the work but to produce structured subtask descriptions: in the cookbook example these are emitted in a tagged, XML-style format, so downstream code can parse them and dispatch each one cleanly. The orchestrator is effectively planning in a machine-readable form rather than free prose, and that is what lets a program fan the generated subtasks out to workers.
Each worker then receives a tightly scoped brief: the original task for context, the specific subtask type and description the orchestrator generated for it, and only the additional context that slice needs. Workers do not get the orchestrator's whole running picture, and that is deliberate. Keeping the planning state with the coordinator and handing each worker just its slice is what stops the pattern from drowning every worker in irrelevant detail, and it is why dynamic decomposition can scale to subtasks the orchestrator could never have enumerated up front.
The cost of adaptability, and how to bound it
Dynamic decomposition buys flexibility with predictability, and a competent architect plans for the bill. Because the agent invents steps from discoveries, two runs of the same task can take different paths, make a different number of calls, and cost different amounts. That variability is acceptable for investigation, but it is not free, and left unbounded it can become a runaway loop that keeps generating subtasks without ever converging. The remedy is not to abandon adaptivity but to put guardrails around it.
The most important guardrail is an explicit stopping condition. A dynamic agent needs a clear notion of "done", the question is answered, a budget of steps is exhausted, or confidence has plateaued, so that it stops generating subtasks once further exploration stops paying off. Anthropic is blunt about the trade: agentic systems spend more latency and cost in exchange for better performance on hard tasks, so you reach for them only when that trade is worth it, and you scope the autonomy so the agent cannot wander indefinitely. A second guardrail is delegation boundaries, handing exploratory subtasks to subagents with limited tools and their own context keeps a single runaway probe from polluting the main thread or touching things it should not.
Testing changes shape too. You cannot assert that a dynamic agent always takes the same steps, because by design it does not. Instead you test the properties of its behaviour: that it converges, that it respects its step budget, that it reaches a correct conclusion on known cases. That is a genuinely different engineering posture from a fixed pipeline, where every step can be pinned, and it is part of what the exam means when it calls dynamic decomposition "less predictable." The unpredictability is manageable, but only if you design for it on purpose instead of being surprised by it.
In its orchestrator-workers form, this shape becomes concrete. A coordinator holds the goal and the running picture of what has been learned; as each discovery lands, the coordinator decides the next subtask and dispatches it to a worker, then folds the worker's result back into its picture. The coordinator is the only component that needs the whole story, which keeps each worker focused and disposable. That separation, one planner adapting the path, many workers executing bounded subtasks, is what makes dynamic decomposition scale without the central context drowning in detail.
When to choose it
Dynamic adaptive decomposition earns its keep on open-ended investigation tasks: situations where you genuinely cannot list the steps until you start looking. Diagnosing a failure whose cause is unknown, exploring an unfamiliar service to understand how it behaves, or planning changes to a system whose structure has to be discovered first are all natural fits. The advantage is that the approach adapts to the problem; the limitation is that it is less predictable and harder to cost in advance.
The exam trap to internalise is the inverse of the prompt-chaining trap. There, the mistake was using a fixed pipeline for open-ended work. Here, the mistake is reaching for dynamic decomposition on a well-structured task where a fixed pipeline would be more reliable and cheaper. Flexibility you never use is not free. You pay for it in variability and cost. Matching the strategy to the task is the skill that choosing a decomposition strategy formalises. In short, choose dynamic decomposition when the shape of the answer is itself unknown, and accept the bounded variability that comes with letting the agent discover that shape as it works.
Worked example
A payments service starts returning intermittent 500 errors in production. Nobody knows the cause, and the failure does not reproduce locally.
There is no predetermined pipeline that can solve this, because the location of the bug is the very thing you are trying to find. The architect uses dynamic adaptive decomposition.
The agent's first probe is broad: read the recent error logs and identify which endpoint and which time window the failures cluster around. That discovery, failures spike on the refund endpoint during high load, directly determines the next subtask, which the agent generates on the spot: inspect the refund handler's behaviour under concurrency.
That step reveals a shared in-memory cache being mutated without a lock. The finding again shapes the next subtask: the agent now generates a focused check of every code path that writes to that cache. None of these steps existed in a plan beforehand; each was produced from the previous discovery. To keep the main context clean, the heavy log-trawling step is delegated to a subagent that reads thousands of lines and returns just the relevant cluster.
The architect also bounded the run so adaptivity did not become a runaway. The agent was given a step budget and an explicit stopping condition, produce a root-cause hypothesis with supporting evidence, so once it found the unlocked cache mutation and confirmed the offending write paths, it stopped generating new probes rather than wandering off into unrelated modules. That budget is what keeps a dynamic investigation from costing an unbounded amount on a problem that turns out to be deep, and it is the kind of guardrail that makes the unpredictability of the approach acceptable in production.
Contrast this with a fixed pipeline. A predetermined "parse logs, check config, restart service" chain would have run to completion and reported nothing useful, because it could not branch toward the concurrency bug it was never told to look for. Each step of the real investigation existed only because the previous step created it: the log cluster justified inspecting the refund handler, and the handler's behaviour justified auditing the cache writers. Adapting to the discovery was the solution, and that adaptability, disciplined by a stopping condition, is precisely what dynamic decomposition provides and a fixed pipeline cannot.
Common misconceptions
Misconception
Dynamic decomposition is just prompt chaining with more steps added at the end.
What's actually true
Misconception
Dynamic adaptive decomposition is the safest default, so use it for every task.
What's actually true
How this shows up on the exam
Task statement 1.6 wants you to pick the decomposition strategy that fits a described task, and dynamic adaptive decomposition is the answer whenever the scenario emphasises unknown scope, open-ended investigation, or the need to adapt to findings. Watch for language like "the cause is unknown," "explore," "the structure is not documented," or "the agent should follow what it discovers." Those are the signals that a fixed pipeline will fail and an adaptive approach is required. Equally, recognise the reverse: if the task is a stable, repeatable process, dynamic decomposition is a distractor that trades reliability for flexibility you do not need. Holding both the fit (investigation) and the cost (unpredictability) in mind is what makes the choice clear.
An architect is asked to build an agent that investigates customer-reported data discrepancies whose root cause varies case by case and is never known in advance. Which decomposition strategy fits, and why?
People also ask
What is dynamic task decomposition?
How is dynamic decomposition different from prompt chaining?
When should you use dynamic adaptive decomposition?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Environment inspection
Why watch: An agent probing its environment before acting and generating next steps from what it finds is dynamic adaptive decomposition.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.