Task Decomposition Strategies
Decomposition is choosing the shape of the work before doing it, like a fixed assembly line when the steps are known, or an exploring investigator when steps are not known.
The architect's job is matching the pattern to the workflow and splitting work so each agent call has a narrow, fully-attended objective.
1. Core Idea
Design task decomposition strategies for complex workflows. 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.
Main idea that anchor the whole topic:
- When to use fixed sequential pipelines (prompt chaining) vs. dynamic adaptive decomposition based on intermediate findings.
- 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).
- The value of adaptive investigation plans that generate subtasks based on what is discovered at each step (the orchestrator-workers analogue).
Three abilities:
- Select the pattern to the workflow — chaining for predictable multi-aspect reviews; dynamic decomposition for open-ended investigation.
- Split large code reviews into per-file local passes plus a separate cross-file integration pass to avoid attention dilution.
- 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 |
Heuristic:
Prompt chaining is predictable but not adaptive. Dynamic decomposition is adaptive but less predictable.
3. Prompt Chaining / Fixed Sequential Pipelines
3.1 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 ("hooks") 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/hook is a plain code block, 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.
3.2 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.
3.3 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(draft) then feeds step 2 (translate) |
| 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 |
3.4 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
4.1 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 analogue to Adaptive Decomposition. 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.
4.2 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.
4.3 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 |
4.4 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. Examples
5.1 The Legacy-Codebase Testing
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.
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.
5.2 Attention Dilution + Integration Split
A PR modifies 14 files, and a single-pass review of all files together produces inconsistent depth, 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 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
| Rejected option | Why it fails |
|---|---|
| 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 |
| 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 |
| Run 3 full-PR passes and only flag issues found in ≥2 runs | Consensus voting suppresses real bugs that are only caught intermittently |
Trap:
"Bigger model / bigger context window" is NEVER the fix for attention dilution.
The fix is structural multi-pass decomposition: local passes + integration pass.
6. Prompt Chaining Vs Dynamic Decomposition
| 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)
7. 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 |
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.