# Task Decomposition Strategies > Task decomposition is the up-front architectural choice between two regimes: fixed decomposition (subtasks known in advance, run as a sequential prompt chain) and dynamic decomposition (a lead LLM determines subtasks at runtime because they depend on what earlier steps discover). Reach for dynamic decomposition only when the subtask list genuinely cannot be predicted in advance - defaulting to it on a fixed-path task adds cost and unpredictability with no accuracy gain. **Domain:** D1 · Agentic Architectures (27% of the exam) **Canonical:** https://claudearchitectcertification.com/concepts/task-decomposition **Last reviewed:** 2026-05-04 ## Quick stats - **Decomposition regimes:** 2 - **Exam domain (CCA-F):** D1 - **Certs testing this:** 3 - **C-compiler parallel agents:** 16 - **C-compiler sessions:** ~2,000 ## What it is Task decomposition is the architectural step of breaking a complex request into ordered, delegable subtasks before an agent (or a chain of prompts) starts executing - the analysis happens up front, not as an emergent side effect of one giant prompt. Anthropic frames this as a choice along a spectrum: some tasks decompose cleanly into a fixed set known in advance (a workflow), while others require a dynamic decomposition that only an LLM orchestrator can determine at runtime, because the right subtasks depend on what earlier steps discover. The architect's job is picking which regime a given problem falls into, then applying the matching pattern, not defaulting to the more complex one. In fixed decomposition, subtasks are pre-defined - but predictability and execution order are two separate questions. Predictable subtasks most often run as prompt chaining (a sequential workflow that trades a bit of latency for higher accuracy on each step, since each stage gets a focused prompt instead of one that has to do everything); the same predictability can just as validly run as parallelization/sectioning, where the pre-defined subtasks execute independently and simultaneously rather than one after another. "Fixed" describes whether the subtask list is knowable in advance, not whether it runs sequentially - that coupling is a common oversimplification. In dynamic decomposition (the orchestrator-workers pattern), a central LLM analyzes the unique task and determines the best subtasks to delegate to specialized worker LLMs at runtime - the subtask list is not known ahead of time, which is what separates it from parallelization or sectioning, where subtasks are pre-defined. ## How it works Start by classifying the regime. If a task can be easily and cleanly decomposed into fixed subtasks, hardcode it as a sequential prompt chain - it is cheaper, more predictable, and easier to debug than a dynamic system. Only escalate to orchestrator-workers when the subtasks genuinely cannot be enumerated in advance. Dynamic decomposition puts the planning inside the loop. A lead LLM reads the query, decides which angles matter, and spins up parallel subagents, each with its own tools and an independent exploration trajectory, which minimizes overlap and path dependency between workers. Anthropic's production multi-agent Research system runs exactly this: the lead agent plans from the user query, decomposes it into parallel subagent tasks, and updates the decomposition based on intermediate findings rather than committing to a static plan. Granularity is a real tradeoff, not a free dial. Coarser subtasks cut coordination overhead but risk one agent doing too much to verify cleanly; finer subtasks improve parallelism and auditability but raise the context-handoff cost between agents. Anthropic's guidance to start with the simplest workflow and escalate only when needed implicitly encodes this tradeoff - default to the coarsest split that stays independently verifiable. Decomposition scales to long-running, human-off-the-loop work too. Anthropic's C-compiler experiment split one large goal (a Linux-capable C compiler) across 16 parallel Claude agents over roughly 2,000 sessions - at that scale, the harness has to structure the decomposition so agents can make progress in parallel without stepping on each other's work, not just split the task once and walk away. A softer framing worth holding loosely. Decomposition is sometimes described as splitting by meaning or intent (semantic decomposition) rather than by string or token boundaries (lexical splitting). That framing captures the underlying orchestrator-workers idea well, but the exact phrase is not independently verified against a single citable Anthropic source, so treat it as a mental model rather than a quoted principle. Decomposition also works as a single-prompt technique, not just a multi-call architecture (CCAOF-D1-O2). Everything above assumes decomposition happens across separate calls or agents - fixed prompt chaining or dynamic orchestrator-workers. At the prompting level, an architect or associate can ask Claude, inside one turn, to explicitly break a complex request into an ordered list of subtasks before acting on them - a numbered plan, or steps enumerated in XML tags - the same instinct as chain-of-thought prompting, applied to structuring the request itself rather than to reasoning about a single answer. This needs no orchestration infrastructure at all: it is a prompt-engineering move (structure the ask so Claude decomposes it explicitly) that sits underneath, and is compatible with, the fixed-vs-dynamic architectural choice - a single well-decomposed prompt can still be one step in a fixed chain, or one call inside a dynamic worker. ## Where you'll see it in production ### Quarterly report generator Fixed decomposition: pull data, compute metrics, format the doc, hardcoded as a prompt chain since the steps never vary. ### Anthropic's multi-agent Research system A lead agent decomposes a user query into parallel subagent tasks per research angle, updating the plan as intermediate findings come in, then condenses each subagent's output before returning it. ## Decision tree 1. **Can every subtask be enumerated in advance, independent of what earlier steps find?** - **Yes:** Fixed decomposition - prompt-chain the subtasks as a sequential workflow. - **No:** Subtasks depend on intermediate discovery - dynamic decomposition is needed. 2. **Do the subtasks need independent, parallel exploration paths rather than a single sequential thread?** - **Yes:** Consider orchestrator-workers - a lead LLM spins up parallel subagents per angle. - **No:** A single-agent sequential loop may be enough - do not add orchestration overhead you do not need. 3. **Is subtask granularity (coarse vs fine) a live design concern for this task?** - **Yes:** Coarser subtasks cut coordination cost but risk one agent doing too much to verify; finer subtasks improve parallelism and auditability but raise context-handoff cost - tune to the task. - **No:** Default to the coarsest split that still keeps each subtask independently verifiable. 4. **Will the work run long enough, or across enough parallel agents, that they could collide on the same resources?** - **Yes:** Structure explicit, non-overlapping ownership boundaries per agent, as in Anthropic's C-compiler harness design. - **No:** Standard orchestrator-workers coordination is sufficient. 5. **Once subtasks are confirmed fixed (predictable in advance), do they have data dependencies on each other's output?** - **Yes:** Run them sequentially as prompt chaining - a later step needs an earlier step's result. - **No:** Run them in parallel as sectioning/parallelization - fixed does not mean sequential; independent fixed subtasks are strictly faster run at once. 6. **Is this a single-turn prompting task rather than a multi-call architecture decision?** - **Yes:** Ask Claude to decompose the request explicitly within the prompt (a numbered plan or XML-tagged steps) before acting - a prompting technique, not an orchestration pattern. - **No:** The fixed-vs-dynamic, sequential-vs-parallel architectural questions above apply. ## Exam-pattern questions ### Q1. A 'generate quarterly report' feature always (1) pulls data, (2) computes metrics, (3) formats a doc, in that exact order every time. An engineer proposes giving an LLM orchestrator full planning authority to decide the steps at runtime. What is the correct architectural call? Reject it - the subtasks are fully known in advance and never vary, so this is fixed decomposition: prompt chaining as a sequential workflow. Named distractor: "give an LLM orchestrator planning authority for consistency" - dynamic decomposition here adds cost and unpredictability with no accuracy benefit, since nothing about the task genuinely varies. ### Q2. A 'research this company's competitive position' feature needs to cover financials, hiring signals, and product launches, but which angles matter varies by company. How should the subtasks be decided? By a lead LLM orchestrator that reads the query and dynamically determines which angles to delegate to parallel subagents - orchestrator-workers, not a fixed pipeline. Named distractor: "hardcode the three angles as a prompt chain" - that fails whenever a company does not fit the assumed three-angle mold. ### Q3. A long-running coding goal is split across many parallel agents, and they keep stepping on the same files, corrupting each other's work. What is missing from the decomposition? Explicit, non-overlapping ownership boundaries per agent. Anthropic's own C-compiler experiment (16 parallel agents, roughly 2,000 sessions) needed the harness to structure work so agents could progress without collision. Named distractor: "just add more agents to cover more ground faster" - that makes the collision problem worse, not better. ### Q4. An orchestrator delegates one subtask per angle, but each worker's output is nearly a full sub-report, and reconciling them takes longer than doing the research directly. What granularity mistake was made? Subtasks were decomposed too coarsely to verify or condense cleanly. Named distractor: "decompose into as few subtasks as possible to save coordination cost" - that heuristic is pointed the wrong way here; finer subtasks would have improved parallelism and made each worker's output condensable before returning to the lead. ### Q5. A junior engineer decomposes a research-agent task into roughly 40 near-identical micro-subtasks, arguing that finer is always safer. What tradeoff are they ignoring? Finer decomposition improves parallelism and auditability but increases context-handoff cost between agents - the coordination overhead can outweigh the benefit. Named distractor: "finer decomposition always improves accuracy" - that ignores the cost side of the tradeoff; the right granularity is task-dependent, not maximal. ### Q6. A 'generate quarterly report' feature always (1) pulls data, (2) computes metrics from that data, (3) formats a doc from the metrics, in that exact order. An engineer argues this fixed decomposition should run all three steps in parallel to save latency. What's wrong? Fixed does not mean parallelizable by default - these three subtasks are fixed AND sequential because each depends on the previous step's output (metrics need the pulled data; the doc needs the computed metrics), so prompt chaining is correct, not sectioning. Named distractor: "fixed decomposition should always run in parallel for speed" - that conflates predictability (known in advance) with independence (no data dependency); only independent fixed subtasks are candidates for parallelization/sectioning. ### Q7. An associate-level user asks Claude, in a single message, to plan and then execute a multi-step data-cleaning task, without building any multi-agent infrastructure. What decomposition technique applies here, and how does it differ from orchestrator-workers? A prompting-level decomposition technique: ask Claude to explicitly enumerate the ordered subtasks (e.g. a numbered plan or XML-tagged steps) within the same prompt before executing them, the CCAOF-D1-O2 skill. This differs from orchestrator-workers, which is an architectural pattern where a lead LLM call dynamically dispatches separate subtasks to other LLM calls or agents - the prompting technique needs no multi-call infrastructure at all. Named distractor: "this requires an orchestrator-workers setup" - that overshoots what the task needs; structuring one prompt to decompose itself is sufficient. ## FAQ ### Q1. Does more decomposition always mean more agents? No. A cleanly decomposable task should stay a fixed workflow (prompt chaining if sequential, or sectioning/parallelization if the fixed subtasks are independent), which is cheaper and easier to debug than a dynamic orchestrator-workers system. ### Q2. Who decides subtask granularity in a dynamic decomposition? The lead or orchestrator LLM, at runtime, based on what the query and intermediate findings reveal - and it can revise the plan as it goes, as in Anthropic's Research system. ### Q3. Does 'fixed decomposition' always mean the subtasks run one after another? No. Fixed just means the subtask list is knowable in advance. Whether they run sequentially (prompt chaining) or in parallel (sectioning) depends on whether one subtask's input depends on another's output, not on fixedness itself. ### Q4. Is single-prompt task decomposition the same as the orchestrator-workers pattern? No. Asking Claude to enumerate steps within one prompt is a prompting technique with no orchestration infrastructure; orchestrator-workers is an architectural pattern where a lead LLM call dynamically delegates subtasks to separate LLM calls or agents at runtime. --- **Source:** https://claudearchitectcertification.com/concepts/task-decomposition **Last reviewed:** 2026-05-04 **Evidence tiers**, 🟢 official Anthropic doc / API contract · 🟡 partial doc / inferred · 🟠 community-derived · 🔴 disputed.