Task Decomposition Strategies

Official Exam Guide Objectives

Task 1.6: Design task decomposition strategies for complex workflows.

Knowledge of

• When to use fixed sequential pipelines (prompt chaining) versus dynamic adaptive decomposition based on intermediate findings
• Prompt chaining patterns that break reviews into sequential steps (e.g., analyze each file individually, then run a cross-file integration pass)
• The value of adaptive investigation plans that generate subtasks based on what is discovered at each step

Skills in

• Selecting task decomposition patterns appropriate to the workflow: prompt chaining for predictable multi-aspect reviews, dynamic decomposition for open-ended investigation tasks
• Splitting large code reviews into per-file local analysis passes plus a separate cross-file integration pass to avoid attention dilution
• Decomposing open-ended tasks (e.g., "add comprehensive tests to a legacy codebase") by first mapping structure, identifying high-impact areas, then creating a prioritized plan that adapts as dependencies are discovered

What You Need to Know

Decomposition is the act of cutting a large problem into units an agentic system can hold one at a time. Two patterns are examinable, they fail in different and recognisable ways when misapplied, and choosing between them is the skill being tested. Alongside them sits a single named failure mode — attention dilution — which appears whenever the cutting was too coarse.

Pattern 1: Fixed Sequential Pipelines (Prompt Chaining)

A fixed sequential pipeline settles the steps before any of them run, then feeds each one's output into the next as input.

How it works: The route is decided at design time. Step 1 completes and hands its output to Step 2, which hands its output to Step 3, and so on to the end. Nothing that turns up along the way alters the sequence.

Example — Code review pipeline:

1. Analyse every file on its own — style, bugs, complexity — one pass per file.
2. With all of those complete, make a second sweep across the whole set for data flow, API consistency and import chains.
3. Merge both layers of findings into a single review report.

Best for: Work whose shape you already know — the steps are enumerable before you begin. Reviewing code, processing documents, extracting fields and running compliance checks all belong in this category.

Advantages: The same input takes the same route every time, which makes behaviour reproducible. Debugging is straightforward because each step's output is attributable to that step, and monitoring is a matter of logging at fixed points.

Limitations: Nothing discovered mid-run can change the plan. Where Step 2 turns up something that ought to redirect Step 3, the pipeline proceeds regardless — the steps were fixed before that information existed.

Pattern 2: Dynamic Adaptive Decomposition

Dynamic adaptive decomposition derives its subtasks from what the run turns up, so the plan is written as the problem is understood rather than before.

How it works: The agent begins with an objective rather than a route. It investigates, forms a plan from what it finds, and then revises that plan as execution surfaces information the original plan could not have accounted for.

Example — Adding tests to a legacy codebase:

1. Survey the repository — directories, modules, what depends on what.
2. Work out where coverage would pay best: the modules everything calls, the ones with the worst bug history, the critical paths nobody tests.
3. Turn that into a prioritised plan.
4. Begin writing. Module A turns out to rest on Module B, and Module B is untested.
5. Reorder: cover Module B first, so Module A's tests have something dependable underneath them.
6. Keep revising as further dependencies surface.

Best for: Investigation where the scope is genuinely unknown at the outset. Exploring an inherited system, auditing for security holes, running an open research question, or debugging code nobody on the team wrote — all of these qualify.

Advantages: The plan tracks the problem instead of a guess about the problem. Unexpected complexity gets handled rather than ignored, and the results go deeper on open-ended work because nothing is forced into a shape decided in advance.

Limitations: You cannot say beforehand how long it will run or what it will cost, because both depend on what it finds. Reproducing a run is harder, and so is debugging one, since two executions over the same input may legitimately diverge.

Selecting the Right Pattern

The exam tests your ability to match the pattern to the task:

The Attention Dilution Problem

Attention dilution is what happens when one pass is asked to handle too many items at once. The output is not uniformly poor — it is uneven, thorough in places and superficial in others, which is what makes it hard to spot.

The telltale symptoms:

• The opening files receive close, specific commentary and the closing ones receive summaries.
• The same construct draws a complaint in one file and passes without remark in another.
• Serious defects slip through in places where trivial style points were still being raised.

Why it happens: Attention is finite and spread across everything in context. Add more items and the share available to each one falls; the items encountered early absorb a disproportionate amount and the rest are progressively skimmed.

The fix: Multi-pass architecture. Split the work into two layers:

1. Per-item local analysis passes: each file, document or module is analysed in a pass of its own, where the full attention budget is available to that single item.
2. Cross-item integration pass: once every local pass has finished, a separate pass looks across the whole set for what only shows up in relationships — data flow, inconsistent use of a pattern, dependencies that cross file boundaries.

Each layer succeeds because it is asked one kind of question. The local passes are consistent because no item competes with any other; the integration pass finds cross-cutting problems because comparison is the only thing it is doing.

Practical Example: The 14-File Code Review

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

• Files 1-5 come back with line-level references, named bugs and concrete suggestions.
• Files 6-9 come back thinner — some real issues, less depth behind each.
• Files 10-14 come back with generalities, missing null pointer dereferences and SQL injection holes outright.
• A forEach loop draws an efficiency complaint in File 3; the same loop in File 11 draws nothing.

The gradient is the diagnosis: quality declines with position rather than with the difficulty of the code, and the same construct is judged differently depending on where it appeared. Neither a stronger model, nor a larger context window, nor a more detailed prompt addresses that, because none of them changes how many items are competing in one pass.

Restructuring does. Fourteen per-file passes give each file the whole budget, which is what recovers the null pointer bugs in Files 10-14. A cross-file integration pass afterwards is the only place the inconsistent forEach judgement becomes visible, because catching it requires holding File 3 and File 11 side by side — which is exactly the comparison the single pass was too crowded to make.

Deep Dive

Prompt chaining, formally: gates and the latency-for-accuracy trade

Anthropic's own name for "fixed sequential pipelines" is prompt chaining: "Prompt chaining decomposes a task into a sequence of steps, where each LLM call processes the output of the previous one." Crucially, chains are not just sequences — they can carry programmatic checkpoints: "you can add programmatic checks (see 'gate' in the diagram below) on any intermediate steps" to catch a malformed intermediate output before it propagates. The whole point is a deliberate trade: "the main goal is to trade off latency for higher accuracy, by making each LLM call an easier task." That framing explains why the per-file-then-integration pipeline in this lesson works: each pass is a simpler, more accurate LLM call than one giant multi-file review.

Sourceanthropic.com › building-effective-agentsfetched 2026-07-30

The other three workflow patterns you'll see named on the exam

Prompt chaining and dynamic decomposition are not Anthropic's only two named workflow patterns — three more appear in the same taxonomy, and a question could reference any of them by name:

• Routing — "classifies an input and directs it to a specialized followup task," useful for "complex tasks where there are distinct categories that are better handled separately," including routing cheap/common cases to a smaller model and hard cases to a larger one.
• Parallelization — two sub-variants: sectioning ("breaking a task into independent subtasks run in parallel," e.g. one instance handling the user query while another screens it for guardrail violations) and voting ("running the same task multiple times to get diverse outputs," e.g. several independent reviews flagging code vulnerabilities).
• Evaluator-optimizer — "one LLM call generates a response while another provides evaluation and feedback in a loop," which fits best "when we have clear evaluation criteria, and when iterative refinement provides measurable value" (e.g. literary translation, where a critic LLM catches nuance the translator missed).

Sourceanthropic.com › building-effective-agentsfetched 2026-07-30

Dynamic decomposition's formal name is orchestrator-workers

The lesson's "dynamic adaptive decomposition" maps directly onto what Anthropic calls orchestrator-workers: "a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results." The defining property, again, is that subtasks are not fixed in advance: "the key difference from parallelization is its flexibility—subtasks aren't pre-defined, but determined by the orchestrator." This is precisely the legacy-codebase-testing scenario: the orchestrator can't know before it starts how many modules will need tests or in what order, so the plan has to be generated dynamically as dependencies surface.

Sourceanthropic.com › building-effective-agentsfetched 2026-07-30

Adaptive decomposition needs ground truth, and a stopping condition

Dynamic decomposition only adapts correctly if it has real feedback to adapt to: "it's crucial for the agents to gain 'ground truth' from the environment at each step" — tool results, test runs, actual file contents — rather than reasoning purely from its own prior assumptions. And because an adaptive plan has no fixed endpoint by design, control still needs a backstop: "it's also common to include stopping conditions (such as a maximum number of iterations) to maintain control," precisely because "the autonomous nature of agents means higher costs, and the potential for compounding errors." This mirrors the iteration-cap guidance from Task 1.1 — a safety bound, not the mechanism that decides the task is actually done.

Sourceanthropic.com › building-effective-agentsfetched 2026-07-30

Simplicity first: don't reach for decomposition you don't need

Anthropic's blanket advice against over-engineering applies directly to decomposition strategy selection: "we recommend finding the simplest solution possible, and only increasing complexity when needed" — and "for many applications, optimizing single LLM calls with retrieval and in-context examples is usually enough." A predictable, structured task that only looks like it needs dynamic decomposition (because it's multi-step) may be fully served by a fixed prompt chain; reach for orchestrator-workers only once the scope is genuinely unknown at the start.

Sourceanthropic.com › building-effective-agentsfetched 2026-07-30

Quick Reference

Exam Traps

Practice Scenario

Build Exercise

Build a Multi-Pass Code Review Pipeline

Difficulty: Advanced (3/4)

60 minutes

1. Create a code review agent that accepts a directory path containing at least 10 source 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.

2. Implement a single-pass review that processes all files at once and record the results

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.

3. Implement per-file local analysis passes that produce structured feedback for each file individually (bug count, severity, specific 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.

4. Implement a cross-file integration pass that checks for data flow issues, API consistency, and pattern usage consistency across all 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.

5. Compare results: document which issues the single-pass review caught versus the multi-pass approach, paying special attention to consistency of analysis depth across all files

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 (no drop-off for later files), and cross-file issues caught only by the integration pass.

6. Record any cases where the single-pass review flagged a pattern in one file but approved identical code in another — these are attention dilution artefacts

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.

Sources

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

Appendix A — Build Exercise Step Hints

Progressive hints revealed by the "Stuck? Get a nudge" control on each step.

Step 1. Create a code review agent that accepts a directory path containing at least 10 source 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.

import fs from "fs";
import path from "path";

function loadCodebase(dirPath: string): Map<string, string> {
  const files = fs.readdirSync(dirPath)
    .filter(f => f.endsWith(".ts") || f.endsWith(".js"));
  const codebase = new Map<string, string>();
  for (const file of files) {
    codebase.set(file, fs.readFileSync(path.join(dirPath, file), "utf-8"));
  }
  console.log(`Loaded ${codebase.size} files for review`);
  return codebase;
}

from pathlib import Path


def load_codebase(dir_path: str) -> dict[str, str]:
    files = [p for p in Path(dir_path).iterdir() if p.suffix in {".ts", ".js"}]
    codebase = {p.name: p.read_text(encoding="utf-8") for p in files}
    print(f"Loaded {len(codebase)} files for review")
    return codebase

Step 2. Implement a single-pass review that processes all files at once and record the results

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.

async function singlePassReview(codebase: Map<string, string>): Promise<ReviewResult[]> {
  const allCode = Array.from(codebase.entries())
    .map(([name, content]) => `=== ${name} ===\n${content}`)
    .join("\n\n");
  const response = await client.messages.create({
    model: "claude-sonnet-5",
    max_tokens: 4096,
    messages: [{
      role: "user",
      content: `Review all files for bugs, style issues, and security vulnerabilities. Provide specific line references for each issue.\n\n${allCode}`
    }]
  });
  const text = response.content.find(b => b.type === "text");
  return parseReviewResults(text?.text ?? "");
}

def single_pass_review(codebase: dict[str, str]) -> list[dict]:
    all_code = "\n\n".join(
        f"=== {name} ===\n{content}" for name, content in codebase.items()
    )
    response = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=4096,
        messages=[
            {
                "role": "user",
                "content": (
                    "Review all files for bugs, style issues, and security "
                    "vulnerabilities. Provide specific line references for each "
                    f"issue.\n\n{all_code}"
                ),
            }
        ],
    )
    text = next((b.text for b in response.content if b.type == "text"), "")
    return parse_review_results(text)

Step 3. Implement per-file local analysis passes that produce structured feedback for each file individually (bug count, severity, specific 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.

interface FileReview {
  fileName: string;
  issues: { line: number; severity: string; description: string }[];
  bugCount: number;
}

async function perFileReview(codebase: Map<string, string>): Promise<FileReview[]> {
  const reviews: FileReview[] = [];
  for (const [name, content] of codebase) {
    const response = await client.messages.create({
      model: "claude-sonnet-5",
      max_tokens: 2048,
      messages: [{
        role: "user",
        content: `Review this file for bugs, style issues, and security vulnerabilities. Return JSON with issues array (line, severity, description).\n\n=== ${name} ===\n${content}`
      }]
    });
    const text = response.content.find(b => b.type === "text");
    reviews.push(JSON.parse(text?.text ?? "{}"));
  }
  return reviews;
}

import json

# FileReview shape: {"fileName": str,
#                    "issues": [{"line": int, "severity": str, "description": str}],
#                    "bugCount": int}


def per_file_review(codebase: dict[str, str]) -> list[dict]:
    reviews = []
    for name, content in codebase.items():
        response = client.messages.create(
            model="claude-sonnet-5",
            max_tokens=2048,
            messages=[
                {
                    "role": "user",
                    "content": (
                        "Review this file for bugs, style issues, and security "
                        "vulnerabilities. Return JSON with issues array (line, "
                        f"severity, description).\n\n=== {name} ===\n{content}"
                    ),
                }
            ],
        )
        text = next((b.text for b in response.content if b.type == "text"), "{}")
        reviews.append(json.loads(text))
    return reviews

Step 4. Implement a cross-file integration pass that checks for data flow issues, API consistency, and pattern usage consistency across all 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.

async function crossFilePass(codebase: Map<string, string>, perFileResults: FileReview[]): Promise<CrossFileIssue[]> {
  const summary = perFileResults.map(r =>
    `${r.fileName}: ${r.bugCount} issues - ${r.issues.map(i => i.description).join("; ")}`
  ).join("\n");
  const imports = extractImportGraph(codebase);
  const response = await client.messages.create({
    model: "claude-sonnet-5",
    max_tokens: 2048,
    messages: [{
      role: "user",
      content: `Cross-file integration review. Check for:\n1. Data flow issues between modules\n2. Inconsistent API usage across files\n3. Same pattern handled differently in different files\n\nPer-file summaries:\n${summary}\n\nImport graph:\n${JSON.stringify(imports)}`
    }]
  });
  const text = response.content.find(b => b.type === "text");
  return JSON.parse(text?.text ?? "[]");
}

def cross_file_pass(codebase: dict[str, str], per_file_results: list[dict]) -> list[dict]:
    summary = "\n".join(
        f"{r['fileName']}: {r['bugCount']} issues - "
        + "; ".join(i["description"] for i in r["issues"])
        for r in per_file_results
    )
    imports = extract_import_graph(codebase)
    response = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=2048,
        messages=[
            {
                "role": "user",
                "content": (
                    "Cross-file integration review. Check for:\n"
                    "1. Data flow issues between modules\n"
                    "2. Inconsistent API usage across files\n"
                    "3. Same pattern handled differently in different files\n\n"
                    f"Per-file summaries:\n{summary}\n\n"
                    f"Import graph:\n{json.dumps(imports)}"
                ),
            }
        ],
    )
    text = next((b.text for b in response.content if b.type == "text"), "[]")
    return json.loads(text)

Step 5. Compare results: document which issues the single-pass review caught versus the multi-pass approach, paying special attention to consistency of analysis depth across all files

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 (no drop-off for later files), and cross-file issues caught only by the integration pass.

function compareResults(singlePass: ReviewResult[], multiPass: FileReview[]) {
  console.log("=== Consistency Comparison ===");
  for (const review of multiPass) {
    const sp = singlePass.find(r => r.fileName === review.fileName);
    console.log(`${review.fileName}: single-pass=${sp?.issues.length ?? 0}, multi-pass=${review.bugCount}`);
  }
  const spCounts = singlePass.map(r => r.issues.length);
  const mpCounts = multiPass.map(r => r.bugCount);
  // Spread is the tell: single-pass depth varies far more across files.
  console.log(`Single-pass std dev: ${stdDev(spCounts).toFixed(2)}`);
  console.log(`Multi-pass std dev: ${stdDev(mpCounts).toFixed(2)}`);
}

import statistics


def compare_results(single_pass: list[dict], multi_pass: list[dict]) -> None:
    print("=== Consistency Comparison ===")
    for review in multi_pass:
        sp = next(
            (r for r in single_pass if r["fileName"] == review["fileName"]), None
        )
        sp_count = len(sp["issues"]) if sp else 0
        print(
            f"{review['fileName']}: single-pass={sp_count}, "
            f"multi-pass={review['bugCount']}"
        )

    sp_counts = [len(r["issues"]) for r in single_pass]
    mp_counts = [r["bugCount"] for r in multi_pass]
    # Spread is the tell: single-pass depth varies far more across files.
    print(f"Single-pass std dev: {statistics.pstdev(sp_counts):.2f}")
    print(f"Multi-pass std dev: {statistics.pstdev(mp_counts):.2f}")

Step 6. Record any cases where the single-pass review flagged a pattern in one file but approved identical code in another — these are attention dilution artefacts

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.

function findContradictions(results: ReviewResult[], codebase: Map<string, string>): string[] {
  const contradictions: string[] = [];
  const patternFiles = findDuplicatePatterns(codebase);
  for (const [pattern, files] of patternFiles) {
    const flagged = files.filter(f =>
      results.find(r => r.fileName === f)?.issues.some(i => i.description.includes(pattern))
    );
    const notFlagged = files.filter(f => !flagged.includes(f));
    // Both sets non-empty means the same code was judged two ways in one pass.
    if (flagged.length > 0 && notFlagged.length > 0) {
      contradictions.push(
        `Pattern "${pattern}" flagged in [${flagged.join(", ")}] but approved in [${notFlagged.join(", ")}]`
      );
    }
  }
  return contradictions;
}

def find_contradictions(results: list[dict], codebase: dict[str, str]) -> list[str]:
    contradictions = []
    for pattern, files in find_duplicate_patterns(codebase).items():
        flagged = [
            f
            for f in files
            if any(
                pattern in i["description"]
                for r in results
                if r["fileName"] == f
                for i in r["issues"]
            )
        ]
        not_flagged = [f for f in files if f not in flagged]
        # Both sets non-empty means the same code was judged two ways in one pass.
        if flagged and not_flagged:
            contradictions.append(
                f'Pattern "{pattern}" flagged in [{", ".join(flagged)}] '
                f'but approved in [{", ".join(not_flagged)}]'
            )
    return contradictions

Appendix B — Interactive Study Prompts

Two prompts to paste into Claude. B1 drills the judgement the exam actually measures; B3 reviews the code you wrote for the Build Exercise above. The exam simulator between them is the interactive quiz on this page.

B1. Concept Check — Discrimination Drill

B2. Exam Simulator

B3. Build Coach — Code Review

The Build Exercise and its hint ladder are already on this page. This prompt is for the one thing the page cannot do: review the code you actually wrote.