Domain 1 · Task 1.6
Task Decomposition Strategies
Design task decomposition strategies for complex workflows.
Decomposition is choosing *how* to break a complex task into steps. The core distinction is between fixed sequential pipelines (prompt chaining) and dynamic adaptive decomposition that generates subtasks from intermediate findings. Matching the pattern to the workflow — rather than defaulting to one — is what the exam tests here.
Key concept
Predictable structure → chain. Scope revealed during the work → decompose dynamically. Match the decomposition pattern to whether you know the shape of the work in advance.
What you need to know
Prompt chaining: fixed, predictable structure
Prompt chaining breaks a task into a *known* sequence of steps decided up front. It fits predictable, multi-aspect work: a templated code review (analyze each file, then a cross-file integration pass), or a batch of file migrations. Each step is knowable before you start, so a fixed pipeline is the right, simplest choice.
Dynamic decomposition: scope emerges from discovery
Dynamic decomposition generates subtasks from what gets discovered at each step. It fits open-ended work where you cannot enumerate the steps in advance — for example "add comprehensive tests to an unfamiliar legacy codebase." You decompose by mapping the structure, identifying high-impact areas, then producing a prioritized plan that adapts as dependencies surface. The plan changes as you learn.
Choosing between them
Run the decision through two questions — is the structure known up front, and does each step depend on prior *discovery*?
| Prompt chaining (fixed) | Dynamic decomposition | |
|---|---|---|
| Structure known up front? | Yes | No |
| Each step depends on prior *discovery*? | No | Yes |
| Examples | Code review template, file migrations | "Add tests to legacy code," open investigation |
If the structure is knowable and steps don't hinge on what you find, chain. If scope is only revealed while working, decompose dynamically.
Split large reviews to avoid attention dilution
A single pass over many files gives inconsistent depth — attention gets diluted across the whole set. The fix is decomposition, not a bigger context window or a bigger model: split a large code review into per-file local passes plus a separate cross-file integration pass. Each local pass reasons deeply about one file; the integration pass catches what only shows up across files.
Exam traps
| The trap | The reality |
|---|---|
| A single pass over all 14 files just needs a larger context window to review them consistently. | Attention dilution is a decomposition problem. Split into per-file passes plus a cross-file integration pass. |
| A fixed pipeline is the safe default for any complex task, including open-ended ones. | Open-ended work like adding tests to unfamiliar code needs dynamic decomposition — subtasks emerge from discovery, so a fixed plan can't cover them. |
| Dynamic decomposition is always better because it adapts. | For predictable, repeatable structure (templated reviews, migrations) a fixed chain is simpler and more reliable. Match the pattern to the workflow. |
| "Use a bigger model" fixes inconsistent review depth across many files. | That's the wrong lever. Restructure the work into per-file plus integration passes. |
Practice scenario
Real questions from the bank that test this topic — the correct answer is highlighted.
A coordinator agent is given: "Analyze the security posture of our payment service repository and produce a remediation plan." The repository is ~50K lines across 200+ files. Your team is divided on decomposition strategy.
Which approach is most likely to succeed?
Why: Task decomposition for unfamiliar codebases should be adaptive, not upfront. You don't yet know what security issues exist or where they live. Upfront category-based decomposition (A) wastes subagent runs on areas with no findings and may miss issues that don't fit your predefined categories. Fixed parallel OWASP fan-out (C) has the same problem and duplicates exploration work. Chunking by file count (D) destroys cross-file context — auth flows, data flows, and trust boundaries span files. The coordinator should send out one exploratory subagent to map the territory, then decompose based on actual findings.
A developer asks the agent to add comprehensive tests to a legacy module. The agent must understand the module structure, identify high-impact untested areas, and prioritize work. The legacy module has ~45 files and limited existing tests.
Why: Map structure first, identify high-impact areas, adaptive plan (Task 1.6). Reading all files upfront blows context; Grep alone misses the impact dimension; parallel subagents need scoped subtasks first.
Build exercise
Decompose two workflows two different ways
~50 min- 1Take a repo of ~14 changed files and first review them in a single pass, noting the depth given to each file.
Why: You need the naive baseline to observe attention dilution.
- 2Re-implement the review as a prompt chain: one focused pass per file, then a separate cross-file integration pass.
You should see: Per-file depth becomes consistent, and the integration pass surfaces cross-file issues the single pass missed.
- 3Now take an unfamiliar legacy module with no tests and try to write a fixed up-front plan for adding tests.
Why: You'll find you can't enumerate the steps without first exploring the code.
- 4Switch to dynamic decomposition: map the structure, identify high-impact areas, and build a prioritized plan that updates as dependencies surface.
You should see: The plan evolves as you discover coupling and dependencies — subtasks are generated from findings.
- 5Write a one-line rule for each workflow explaining why it got chaining vs dynamic decomposition.
Why: Articulating the choice cements the "known structure vs discovered scope" discrimination.
Sources
Drill Agentic Architecture & Orchestration
Practice only this domain’s questions, untimed, with instant explanations.