Task Decomposition Strategies

What you need to know

Task decomposition is how you break complex work into pieces an agentic system can actually handle. The exam tests choosing between two patterns: fixed sequential pipelines and dynamic adaptive decomposition. Pick the pattern that matches the task. The wrong choice fails in a predictable way. The exam also tests one specific failure mode of shallow, overloaded decomposition: attention dilution, which appears when too many items share a single pass.

Pattern 1: Fixed sequential pipelines (prompt chaining)

A fixed sequential pipeline breaks work into predetermined steps that execute in order. Each step consumes the output of the previous step. The sequence does not change based on intermediate results. Step 1 runs, its output feeds Step 2, and Step 2's output feeds Step 3. If a later step discovers something unexpected, the remaining steps stay as written.

Example: code review

1. Local analysis per file (style, bugs, complexity).
2. Cross-file integration (data flow, API consistency, import chains).
3. A unified report that compiles both layers.

Best for predictable, structured tasks where the steps are known in advance: code reviews, document processing, data extraction, and compliance checks.

Advantages. The path is consistent and reliable. The same input follows the same steps. It is easy to debug, because you know which step produced which output, and easy to monitor, because you can log each step.

Limitation. The pipeline cannot adapt to unexpected findings. If Step 2 discovers something that should change Step 3, the steps stay fixed.

Pattern 2: Dynamic adaptive decomposition

Dynamic adaptive decomposition starts with a high-level goal, investigates, and generates subtasks dynamically. The plan adapts as new information appears. The agent does not commit to a full sequence before it has seen the problem.

Example: adding tests to a legacy codebase

1. Map the codebase structure: directories, modules, and dependencies.
2. Identify high-impact areas: most-used modules, modules with the most bugs, and untested critical paths.
3. Create a prioritised test plan from that map.
4. Start writing tests. Discover that Module A depends on Module B, which has no tests.
5. Reprioritise: test Module B first so Module A's tests can rely on it.
6. Continue adapting as new dependencies and issues emerge.

Best for open-ended investigation where the full scope is unknown at the start: legacy systems, security audits, research, and unfamiliar debugging.

Advantages. The plan is adaptable. It handles unexpected complexity and produces more thorough results when the scope is unknown, because it does not force a predetermined plan onto the problem.

Limitations. Execution is less predictable. Time and resource usage vary with what is discovered, and the run is harder to debug when something goes wrong.

Selecting the right pattern

Match the pattern to the task characteristics.

Attention dilution problem

Attention dilution is what happens when an agent processes too many items in one pass. Early items receive more attention. Later items receive shallower analysis. Evaluation depth is inconsistent: thorough on some items, and missing obvious issues on others.

Symptoms:

• Detailed feedback on the first files, and shallow analysis on later files.
• An identical pattern flagged in one file and approved in another.
• Obvious bugs missed later, while minor style issues are caught earlier.

The cause is attention distributed across all items in the context. When the item count is high, attention per item falls. Early items take a disproportionate share. Later items are skimmed.

Multi-pass architecture

The fix is structural. Split the work into two layers. Batching files into smaller groups is not sufficient on its own.

1. Per-item local analysis passes. Analyse each file, document, or module in its own pass. That pass has the full attention budget on a single item. Local passes solve consistency and depth.
2. Cross-item integration pass. After the local passes, run a separate pass that looks across items for data flow, API consistency, pattern consistency, and cross-file dependencies. The integration pass catches those cross-cutting issues because it is not also trying to review every line.

Smaller batches can even out depth inside a batch. They still miss issues that span batches unless a cross-item integration pass follows.

Practical example: 14-file code review

A code review agent processes 14 files in a single pass:

• Files 1–5: detailed feedback with line references, bug identification, and improvement suggestions.
• Files 6–9: moderate feedback. Some issues are identified, with less thorough analysis.
• Files 10–14: superficial feedback that misses obvious null-pointer bugs and SQL injection vulnerabilities.
• Inconsistent forEach evaluation: the loop is flagged as inefficient in File 3, and identical code in File 11 receives no comment.

That pattern is attention dilution. A better model, a larger context window, or a more detailed prompt does not fix it. Multi-pass architecture does: 14 per-file local analysis passes, each focused on one file, plus a cross-file integration pass that checks data flow and pattern consistency. The local passes catch the null-pointer bugs in files 10–14 because each file has its own pass. The integration pass identifies the inconsistent forEach evaluation because it specifically compares patterns across files.

Exam traps

• Suggesting a more powerful model or a larger context window as the fix

  Attention dilution is an architectural problem, not a model capability problem. Processing too many items in a single pass produces inconsistent depth regardless of model power or context size. The fix is multi-pass architecture.

• Treating better prompts as equivalent to multi-pass architecture

  Better prompts improve average quality. They do not solve the attention allocation problem. Multi-pass architecture gives each item a dedicated pass. A single pass cannot guarantee that.

• Applying fixed pipelines to open-ended investigations

  Open-ended tasks need adaptability. A fixed pipeline cannot respond to unexpected findings. Dynamic adaptive decomposition is the pattern when the full scope is unknown at the start.

• Batching files without a cross-file integration pass

  Batching reduces attention dilution inside each batch and misses issues that cross batches. Without a dedicated cross-file integration pass, data-flow issues and pattern inconsistencies stay undetected.

Practice scenario

A code review agent processes 14 files and produces detailed feedback for the first 5 files but misses obvious bugs in files 10–14. It also flags a forEach loop as inefficient in one file while approving identical code in another. What is the root cause and the most appropriate solution?

Build exercise

Build a Multi-Pass Code Review Pipeline

60 minutes

What you will learn

• Why attention dilution produces inconsistent analysis depth across files in single-pass reviews
• How multi-pass architecture (per-item plus cross-item) solves the structural attention allocation problem
• The difference between fixed sequential pipelines and dynamic adaptive decomposition
• Why batching without a cross-file integration pass still misses cross-cutting issues
• How to identify attention dilution artefacts: the same pattern flagged in one file and approved in another

1. Step 1

   Create a code review agent that accepts a directory containing at least 10 source files

   Build a loader that reads a directory of source files and prepares them for review. Use at least 10 TypeScript or JavaScript files.

   Why: The 10+ file threshold is where attention dilution becomes observable. The exam uses a 14-file example where detailed feedback for early files degrades to superficial analysis for later files. Your setup must replicate this scale.

   You should see: A code review function that reads all files in a directory and prepares them for analysis. It should handle at least 10 TypeScript or JavaScript source files.

   Stuck? Get a nudge

2. Step 2

   Implement a single-pass review that processes all files together and record the results

   Send every file in one prompt. Record issues per file and how detailed the feedback is from the first file to the last.

   Why: The single-pass approach is the baseline that demonstrates attention dilution. The exam expects you to recognise the symptoms: thorough analysis for early files, shallow analysis for later files, and contradictory pattern evaluation.

   You should see: A review result where early files receive detailed feedback with specific line references and bug identification, while later files receive increasingly brief or missing feedback. This is the attention dilution pattern.

   Stuck? Get a nudge

3. Step 3

   Implement per-file local analysis passes

   Review each file in its own pass. Return structured feedback: bug count, severity, and line references.

   Why: Per-file passes give each file the full attention budget. This is the first layer of multi-pass architecture. The exam contrasts this with single-pass to show that structural decomposition solves attention dilution, not better prompts or larger context windows.

   You should see: Consistent analysis depth across all files. The last file receives the same level of detail as the first. Each review includes bug count, severity ratings, and specific line references in a structured format.

   Stuck? Get a nudge

4. Step 4

   Implement a cross-file integration pass

   After the local passes, run a separate pass that checks data flow, API consistency, and pattern consistency across files.

   Why: Per-file passes catch local issues but miss cross-cutting concerns. The exam tests whether you include a cross-file integration pass. Batching without it still misses data flow issues and pattern inconsistencies across files.

   You should see: A separate analysis that takes the per-file summaries and checks for cross-file issues: inconsistent API usage, data flow problems between modules, and patterns used differently across files.

   Stuck? Get a nudge

5. Step 5

   Compare single-pass and multi-pass results

   Document which issues each approach caught. Compare total issues, consistency across files, and cross-file issues.

   Why: This comparison demonstrates the exam argument quantitatively. Attention dilution is not a model capability problem. It is an architectural problem. The same model produces better results with multi-pass architecture, proving the fix is structural.

   You should see: A comparison table showing more total issues found by multi-pass, consistent issue counts across files with no drop-off for later files, and cross-file issues caught only by the integration pass.

   Stuck? Get a nudge

6. Step 6

   Record attention-dilution artefacts

   Find cases where the single-pass review flagged a pattern in one file and approved identical code in another.

   Why: Contradictory pattern evaluation is the clearest symptom of attention dilution. The exam uses the forEach example: flagged as inefficient in File 3, approved without comment in File 11. Documenting these artefacts proves the structural nature of the problem.

   You should see: At least one case where the single-pass review treated identical code patterns differently across files. The multi-pass review should treat the same pattern consistently.

   Stuck? Get a nudge

Sources

• Claude Agent SDK Overview — Anthropic
• Claude Code in Action (Skilljar) — Anthropic, Skilljar
• Anthropic Prompt Engineering Guide — Anthropic