Task Decomposition Strategies
Decomposition is choosing the shape of the work before doing it: a fixed assembly line when the steps are known, or an exploring investigator when they are not. The architect's job is matching the pattern to the workflow — and splitting work so each LLM call has a narrow, fully-attended objective.
1. Core exam idea
Design task decomposition strategies for complex workflows. The skill being tested is pattern selection: knowing when a complex task should be broken into a fixed sequential pipeline (prompt chaining) versus a dynamic adaptive decomposition that generates subtasks from intermediate findings — and knowing how to split work to avoid attention dilution.
Two failure modes anchor the whole topic: - Using a rigid pipeline for an open-ended problem (the plan cannot adapt to what is discovered). - Throwing a large, multi-aspect task into one pass (attention dilutes; depth and consistency collapse).
The official knowledge bullets reduce to three ideas: 1. When to use fixed sequential pipelines (prompt chaining) vs. dynamic adaptive decomposition based on intermediate findings. 2. Prompt chaining patterns that break work into sequential steps with optional programmatic gates between steps (e.g., analyze each file individually, then a cross-file integration pass). 3. The value of adaptive investigation plans that generate subtasks based on what is discovered at each step (the orchestrator-workers analogue).
The official skill bullets reduce to three abilities: 1. Select the pattern to the workflow — chaining for predictable multi-aspect reviews; dynamic decomposition for open-ended investigation. 2. Split large code reviews into per-file local passes plus a separate cross-file integration pass to avoid attention dilution. 3. Decompose open-ended tasks (e.g., "add comprehensive tests to a legacy codebase") by first mapping structure, identifying high-impact areas, then producing a prioritized plan that adapts as dependencies are discovered.
2. The two core patterns at a glance
| Pattern | One-line definition | Mental model |
|---|---|---|
| Prompt chaining (fixed sequential pipeline) | A known, fixed sequence of LLM calls, each consuming the previous step's output, with optional programmatic gates between steps. | Assembly line |
| Dynamic adaptive decomposition | A broad goal, investigated step by step, where new subtasks are generated from what is discovered. | Investigator following leads |
Exam phrase to memorize:
Prompt chaining is predictable but not adaptive. Dynamic decomposition is adaptive but less predictable.
3. Prompt chaining / fixed sequential pipelines
Definition
Prompt chaining decomposes a task into a fixed sequence of LLM calls. Each step consumes the previous step's output. Anthropic describes prompt chaining as a workflow where each LLM call processes the output of the previous one, with optional programmatic gates ("checks") between steps that validate intermediate output before continuing.
Input
↓
Step 1: Extract facts
↓
Gate: Are required fields present? ← programmatic check
↓
Step 2: Classify facts
↓
Gate: Is classification valid? ← programmatic check
↓
Step 3: Generate final answer
The gate is plain code, not a model call. It can stop a bad intermediate output before it propagates, retry a step, or route to a fallback. This is what makes a chain reliable rather than just sequential.
When to use it
Use prompt chaining when the task is: - predictable, - structured, - decomposable into known steps, - easy to validate between steps, - better solved by making each individual LLM call simpler.
Anthropic states prompt chaining is ideal when a task can be cleanly decomposed into fixed subtasks, trading some latency for higher accuracy by making each call easier and more focused.
Exam examples
| Scenario | Why prompt chaining fits |
|---|---|
| Extract fields from invoices → validate schema → summarize | Steps are fixed |
| Generate outline → validate outline → write article | Known sequence |
| Translate marketing copy after drafting it | Output of step 1 feeds step 2 |
| Compliance checklist review | Requirements are predefined |
| Code review pipeline: per-file pass → integration pass → final report | Known analysis stages |
| Extract contract parties → identify governing law → validate fields → risk summary | Always the same steps |
Strengths and weaknesses
| Strengths | Weaknesses |
|---|---|
| Easy to monitor and debug | Cannot adapt well to unexpected discoveries |
| Each step has a narrow objective | Brittle if the task path changes |
| Programmatic gates stop bad intermediate output | May over-process simple inputs |
| Predictable cost and latency | Bad fit when the scope is unknown |
| Strong for compliance / structured processing | Rigid by design |
Exam trap:
"Always verify identity, then issue refund" written only in the prompt
is NOT a programmatic gate. The model can still skip the step.
A real gate is code that blocks the refund call until verified == true.
4. Dynamic adaptive decomposition
Definition
Dynamic adaptive decomposition means the agent starts with a broad goal, investigates, then creates or changes subtasks based on what it discovers. The plan is provisional and evolves.
Initial goal
↓
Inspect environment (map structure)
↓
Create provisional plan
↓
Execute first subtasks
↓
Discover new dependencies / blockers / risks
↓
Revise plan (reprioritize)
↓
Continue until goal is satisfied
Anthropic's orchestrator-workers pattern is the closest official analogue: a central LLM dynamically breaks down tasks, delegates to worker LLMs, and synthesizes their results. It is explicitly suited to complex tasks where the subtasks cannot be predicted in advance — the orchestrator decides the subtasks at runtime, which distinguishes it from fixed parallel sectioning.
When to use it
Use dynamic decomposition when: - the full scope is unknown, - the correct path depends on discoveries, - subtasks cannot be listed ahead of time, - the system must adapt to blockers, - investigation itself changes the plan.
Exam examples
| Scenario | Why dynamic decomposition fits |
|---|---|
| Explore an unfamiliar legacy codebase | Dependencies emerge during inspection |
| Debug an unknown production issue | Root cause is not known upfront |
| Security audit of a large system | New attack surfaces / assets appear during the scan |
| Add tests to an untested codebase | Test priorities depend on the dependency graph |
| Research a broad topic with unknown sources | Search findings determine next searches |
| Complex multi-file code change | Files to modify depend on initial findings |
Strengths and weaknesses
| Strengths | Weaknesses |
|---|---|
| Adapts to unexpected information | Harder to estimate cost and latency |
| Handles open-ended problems | Harder to debug |
| Reprioritizes based on findings | Needs stronger observability |
| Strong for exploration and diagnosis | Needs explicit stopping criteria |
| More likely to drift without constraints |
5. The legacy-codebase testing example (canonical Task 1.6 walkthrough)
The official skill bullet calls out "add comprehensive tests to a legacy codebase" as the model open-ended task. The wrong move is a fixed checklist or one giant prompt. The correct decomposition is adaptive:
1. MAP structure → enumerate modules, dependencies, current coverage.
2. IDENTIFY high-impact → find the modules most used / most risky / least tested.
3. PRIORITIZED PLAN → order targets by impact; create a provisional task list.
4. EXECUTE + DISCOVER → start testing; discover that several high-impact modules
depend on an untested shared utility layer.
5. ADAPT → revise the plan: test the utility layer first because
dependents cannot be tested reliably without it.
6. REPEAT until coverage goal is met.
The decisive feature is step 5: the plan changes because of a dependency discovered during execution. That dependency could not have been listed up front, which is exactly why a fixed pipeline would fail here.
Exam trap:
"Add comprehensive tests to a legacy codebase" looks structured, but the
PRIORITIES depend on the dependency graph you don't know yet.
That makes it dynamic, not a fixed pipeline.
6. Attention dilution and the per-file + integration split (Sample Q12)
This is the single most testable skill in Task 1.6. The exam's Sample Question 12 frames it directly: a PR modifies 14 files, and a single-pass review of all files together produces inconsistent depth (detailed for some, superficial for others), misses obvious bugs, and gives contradictory feedback (flagging a pattern in one file while approving identical code in another).
The root cause is attention dilution: when many files are processed in one pass, attention spreads thin and quality degrades unevenly across the input.
The correct fix (Sample Q12 answer A) is a two-phase decomposition:
Phase 1 — Local passes (one per file)
file_1 → analyze for local issues
file_2 → analyze for local issues
...
file_14 → analyze for local issues
↓ (consistent depth on each file — no dilution)
Phase 2 — Cross-file integration pass
examine data flow / contracts / shared state ACROSS files
↓
Final consolidated report
Why the other Q12 options are wrong (high-yield distractors):
| Rejected option | Why it fails |
|---|---|
| B. Require developers to split large PRs into 3–4 files before review | Shifts the burden to humans without improving the system; the architecture still dilutes attention on whatever it gets |
| C. Switch to a larger context window so all 14 files fit in one pass | Larger context windows do not fix attention quality. The model can hold the files but still attends unevenly |
| D. Run 3 full-PR passes and only flag issues found in ≥2 runs | Consensus voting suppresses real bugs that are only caught intermittently |
Note the structure: the per-file phase is a parallelizable/independent decomposition (each file is local), while the integration phase is the synthesis step that catches cross-file relationships no local pass can see. A batching scheme that splits files into groups but omits the integration pass will still miss cross-file data-flow bugs (see §8 Q9).
Exam trap:
"Bigger model / bigger context window" is NEVER the fix for attention dilution.
The fix is structural multi-pass decomposition: local passes + integration pass.
7. Prompt chaining vs dynamic decomposition (high-yield comparison)
| Dimension | Prompt chaining | Dynamic adaptive decomposition |
|---|---|---|
| Plan known upfront? | Yes | No |
| Execution order | Fixed | Evolves |
| Best for | Structured, predictable multi-aspect workflows | Open-ended investigation |
| Debuggability | High | Lower |
| Cost predictability | High | Lower |
| Adaptability | Low | High |
| Failure mode | Too rigid | Scope drift / runaway exploration |
| Control mechanism | Fixed steps + programmatic gates | Planner + task graph + review checkpoints |
| Official analogue | Prompt chaining workflow | Orchestrator-workers |
| Exam keywords | "known steps," "structured," "checklist," "pipeline," "always the same" | "unknown root cause," "legacy," "explore," "discover," "adapt," "emerges" |
Decision shortcut:
Can you list every step before starting AND will those steps not change?
YES → prompt chaining (fixed pipeline + gates)
NO → dynamic adaptive decomposition (orchestrator-workers)
8. Related decomposition shapes (know the difference)
The exam mixes these in distractors. Keep them distinct from the two core patterns:
| Pattern | What it does | When it fits |
|---|---|---|
| Routing | Classifies input into known categories, then sends each to a specialized workflow | Distinct, predefined request types (refund / billing / login / technical) |
| Parallel sectioning | Splits work into independent subtasks run in parallel, then synthesizes | 20 independent interviews → summarize each → find common themes; per-file review passes |
| Evaluator-optimizer | Generates a draft, then evaluates it against clear criteria and refines | A migration plan checked against rollback feasibility, downtime, cost, security |
| Orchestrator-workers | Central LLM dynamically breaks down tasks and delegates | Subtasks unknown until investigation (= dynamic decomposition) |
The key distinction: routing and parallel sectioning use a fixed/known structure, whereas orchestrator-workers decides the subtasks at runtime. Routing classifies into known buckets; dynamic decomposition discovers the buckets.
9. Programmatic gates between steps
A programmatic gate is code that runs between chain steps to validate, block, or route — not a model instruction. It is what turns a fragile sequence into a reliable pipeline, and it is the deterministic enforcement point for high-stakes ordering.
| Need | Mechanism |
|---|---|
| Validate required fields exist before continuing | Schema/validation gate between steps |
| Block a refund until identity is verified | Prerequisite gate (PreToolUse hook / app-side state check) |
| Require manager approval above a threshold | Gate + approval workflow |
| Retry a step whose output failed validation | Validation-retry loop around that step |
| Normalize tool output before the next step reads it | Post-processing transform |
Exam trap:
A prompt that SAYS "verify first" is probabilistic guidance.
A programmatic gate that BLOCKS the next call until a condition is true
is deterministic enforcement. High-stakes ordering needs the gate.
10. Common exam anti-patterns
| Anti-pattern | Why it is wrong | Correct move |
|---|---|---|
| Fixed pipeline for an open-ended audit / legacy exploration | Scope evolves; plan cannot adapt | Dynamic adaptive decomposition |
| Dynamic agent for a fixed 5-field extraction | Unnecessary overhead and unpredictability for known steps | Prompt chaining |
| Single-pass review of many files at once | Attention dilution: inconsistent depth, missed bugs, contradictions | Per-file passes + cross-file integration pass |
| Bigger model / larger context window to "fix" dilution | Larger context does not improve attention quality | Structural multi-pass decomposition |
| Batch files into groups but skip the integration pass | Cross-file data-flow bugs go uncaught | Add a dedicated cross-file integration pass |
| Voting/consensus across full-PR passes | Suppresses intermittently-detected real bugs | Decompose by file, not by repeated full passes |
| Make developers pre-split PRs instead of fixing the reviewer | Shifts burden without fixing the system | Fix the decomposition in the review architecture |
| "Verify first" only in the prompt | Probabilistic; model can skip it | Programmatic prerequisite gate |
| One giant prompt for "add tests to legacy code" | Ignores unknown dependency graph | Map → identify high-impact → adaptive prioritized plan |
Scenario-Based Questions
Q1. Fixed sequence
A legal-processing agent must extract contract parties, identify governing law, validate required fields, then produce a risk summary. The steps are always the same. Which decomposition strategy fits best?
A. Dynamic adaptive decomposition B. Prompt chaining C. Voting D. Autonomous open-ended agent
Answer
B. The steps are fixed and known in advance, so a sequential prompt chain — with gates that validate fields before the summary — is the simplest, most reliable fit.
Q2. Unknown scope
A developer asks Claude to add tests to a legacy codebase. Claude first maps the codebase, then discovers that several high-impact modules depend on an untested utility layer, so it revises the plan to test the utility layer first. What pattern is this?
A. Prompt chaining B. Dynamic adaptive decomposition C. Routing D. Single-pass prompting
Answer
B. The plan changes based on a dependency discovered during execution — subtasks are generated from intermediate findings, which is the definition of dynamic adaptive decomposition.
Q3. Attention dilution (Sample Q12)
A PR modifies 14 files. A single-pass review gives detailed feedback for some files, superficial comments for others, misses obvious bugs, and flags a pattern in one file while approving identical code in another. How should the review be restructured?
A. Require developers to split large PRs into 3–4 files before review B. Switch to a higher-tier model with a larger context window C. Run three full-PR passes and only flag issues found in at least two runs D. Split into per-file local passes, then a separate cross-file integration pass
Answer
D. The symptoms are classic attention dilution. Per-file passes ensure consistent depth, and a separate integration pass catches cross-file issues. A larger context window does not fix attention quality, consensus voting suppresses intermittently-detected bugs, and pre-splitting shifts the burden without fixing the system.
Q4. Known categories
A support system receives refund, billing, login, and technical-support requests. Each category needs different tools and policies. Which pattern fits?
A. Routing B. Dynamic decomposition C. Evaluator-optimizer only D. Voting
Answer
A. The input can be classified into known categories and sent to specialized workflows — routing, not runtime subtask discovery.
Q5. Independent subtasks
A system must summarize 20 independent customer interviews and then identify common themes. Which architecture fits?
A. Single giant prompt B. Parallel sectioning followed by synthesis C. Sequential chain only D. Fork session
Answer
B. Each interview is independent, so summarize them in parallel sections, then run a synthesis step to integrate themes — avoiding the attention dilution of one giant prompt.
Q6. Evaluator fit
A migration plan must be checked against rollback feasibility, downtime, cost, and security risk. Which pattern is useful after generating the first draft?
A. Evaluator-optimizer B. Routing only C. Single-pass prompt only D. Prompt caching only
Answer
A. Clear, enumerable criteria make evaluator feedback actionable: generate a draft, evaluate against the criteria, then optimize.
Q7. Wrong use of dynamic decomposition
An invoice-processing system always extracts the same five fields and validates them against a schema. A team proposes a fully dynamic agent that decides the process each time. What is wrong?
A. Dynamic agents cannot extract fields B. The task is structured, so a fixed prompt chain is simpler and more reliable C. The task requires voting D. The model needs more tools
Answer
B. The steps are fixed and known, so dynamic decomposition adds needless cost and unpredictability. A prompt chain with a validation gate is the right fit.
Q8. Wrong use of fixed pipeline
A security audit starts with unknown assets and discovers new services as it scans. A team proposes a fixed five-step checklist that cannot change. What is wrong?
A. Security audits never need agents B. The task scope evolves, so dynamic adaptive decomposition is a better fit C. Checklists are always invalid D. The answer should be generated directly
Answer
B. Because new attack surfaces emerge during the scan, the plan must adapt — a fixed checklist cannot incorporate assets it did not know about.
Q9. Batching without integration
A code-review system splits 40 files into 4 batches of 10, reviews each batch, and concatenates the results. It still misses cross-file data-flow bugs. What is missing?
A. A larger model
B. A cross-file integration pass
C. More natural-language instructions
D. tool_choice: any
Answer
B. Batching reduces local attention load but never examines relationships across batches. A dedicated cross-file integration pass is required to catch cross-file data flow.
Q10. Programmatic gates
A prompt chain says "verify identity, then issue refund." In production, the model occasionally skips verification. What should be added?
A. Stronger examples B. A programmatic prerequisite gate before refund execution C. More dynamic decomposition D. Voting
Answer
B. Prompt text is probabilistic guidance the model can skip. A programmatic gate deterministically blocks the refund call until verified == true, which is what high-stakes ordering requires.
Q11. Pattern selection from keywords
A task description reads: "Investigate why intermittent timeouts started last week; root cause is unknown." Which decomposition pattern is most appropriate?
A. Prompt chaining with fixed steps B. Dynamic adaptive decomposition C. Routing into predefined categories D. Parallel sectioning with synthesis
Answer
B. "Root cause is unknown" signals an open-ended investigation where subtasks emerge as evidence accumulates — the orchestrator-workers / dynamic pattern.
Q12. Latency vs accuracy trade-off
An architect decomposes a complex generation task into a chain of three simpler LLM calls with validation gates, instead of one large prompt. What is the primary trade-off being made?
A. Lower accuracy in exchange for lower cost B. Higher latency in exchange for higher accuracy and easier validation C. Less observability in exchange for faster responses D. More adaptability in exchange for less predictability
Answer
B. Prompt chaining trades extra latency (more sequential calls) for higher accuracy, because each call is simpler and intermediate gates can validate output before it propagates.
Q13. Orchestrator-workers vs parallel sectioning
A coordinator must analyze a large system where the relevant subtasks cannot be listed in advance and depend on what each step uncovers. Which best describes the correct pattern, and why is it not fixed parallel sectioning?
A. Parallel sectioning, because all subtasks run at once B. Orchestrator-workers, because the subtasks are decided dynamically at runtime rather than fixed up front C. Routing, because the coordinator classifies the system D. Prompt chaining, because there is a coordinator
Answer
B. Parallel sectioning assumes a known, fixed set of independent subtasks; orchestrator-workers lets a central LLM dynamically break down the task and delegate as it discovers what is needed.
Q14. Open-ended task decomposition order
For "add comprehensive tests to a legacy codebase," which sequence reflects the recommended adaptive decomposition?
A. Write tests file-by-file in alphabetical order until coverage is complete B. Map structure → identify high-impact areas → prioritized plan that adapts as dependencies are discovered C. Run a single large prompt asking for tests across the whole repo D. Route each file to a fixed five-step testing checklist
Answer
B. The official approach maps the structure first, identifies high-impact areas, then builds a prioritized plan that reprioritizes as dependencies (e.g., a shared untested utility layer) are discovered.
Q15. Predictable multi-aspect review
A team runs the same review every release: a style pass, a security pass, and a performance pass, always in that order, on a single known artifact. Which decomposition is most appropriate?
A. Dynamic adaptive decomposition, because reviews are complex B. Prompt chaining, because the aspects and order are predictable and fixed C. Voting across three identical full passes D. Orchestrator-workers, because there are multiple passes
Answer
B. A predictable, multi-aspect review with a fixed set and order of passes is the textbook case for prompt chaining, optionally with gates between passes.
Memory hooks
- Fixed steps that won't change → prompt chaining. Unknown/evolving scope → dynamic decomposition.
- Prompt chaining = assembly line; dynamic decomposition = investigator following leads (orchestrator-workers).
- Prompt chaining is predictable but not adaptive; dynamic decomposition is adaptive but less predictable.
- Programmatic gates between steps = code that validates/blocks/routes — not a prompt instruction.
- Sample Q12: 14-file review going inconsistent = attention dilution → per-file local passes plus a separate cross-file integration pass.
- A bigger model or larger context window NEVER fixes attention dilution — only structural multi-pass decomposition does.
- Batching files without an integration pass still misses cross-file data-flow bugs.
- Consensus voting across full passes suppresses intermittently-caught real bugs.
- "Add tests to a legacy codebase" = map structure → identify high-impact areas → prioritized plan that adapts as dependencies are discovered.
- The adaptive signal is "the plan changed because of something discovered mid-execution."
- Routing classifies into known buckets; orchestrator-workers discovers the subtasks at runtime.
- "Verify first" in a prompt is probabilistic; a prerequisite gate is deterministic — high-stakes ordering needs the gate.
- Exam keywords for dynamic: unknown root cause, legacy, explore, discover, adapt, emerges. For chaining: known steps, structured, checklist, pipeline, always the same.