Domain 1 · Statement 1.6 6 of 7

Design task decomposition strategies for complex workflows

What you need to know

Prompt chaining (fixed sequential steps) fits predictable multi-aspect work; dynamic decomposition fits open-ended investigation.
Split large reviews into per-file local passes plus a separate cross-file integration pass to defeat attention dilution.
A larger context window does not fix attention dilution — uneven depth and contradictory findings are an attention problem, not a capacity problem.
Adaptive plans generate subtasks from what each step discovers, so newly found dependencies reshape the remaining work.
For open-ended tasks: map structure, identify high-impact areas, then build a prioritized plan that adapts.
Hybrids are legitimate — use a dynamic phase to produce the item list, then a fixed chain over those items.

Decomposition is the choice of shape for a multi-step job. The exam contrasts two shapes and expects you to match them to workload characteristics.

Fixed sequential pipelines (prompt chaining)

When the aspects to cover are known in advance, break the work into an ordered chain of focused steps, each with a narrow prompt and a clean context.¹⁴ The canonical case is code review: analyze each file individually for local issues, then run a separate cross-file integration pass examining data flow and contracts between them.

The reason this works is attention dilution. A single pass over fourteen files produces uneven results: detailed feedback on some files, superficial comments on others, obvious bugs missed. Worst is the self-contradiction — a pattern flagged in one file and approved in another within the same review. Splitting into per-file passes gives every file the same depth; the integration pass then catches exactly what per-file analysis structurally cannot see.

Two tempting non-fixes: a larger context window does not solve attention quality, it only makes the dilution possible at greater scale;¹⁶ and requiring humans to split large pull requests shifts the burden without improving the system. Voting across repeated full-PR passes is worse still — it suppresses real bugs that are only caught intermittently.

Dynamic adaptive decomposition

When you cannot know the subtasks until you have looked, the plan must be generated as you go. "Add comprehensive tests to this legacy codebase" has no fixed step list: the right work depends on what the structure turns out to be. The pattern runs in three phases: map first (module layout, entry points, existing coverage), identify high-impact areas (complexity, change frequency, blast radius), then produce a prioritized plan that adapts as dependencies are discovered.¹⁵ Finding that a module cannot be tested without a seam changes the plan, and the plan should absorb that.

Choosing between them

The discriminator is whether the aspects to examine are enumerable up front:

Discriminator	Pattern	Worked example
The aspects are known before you start	Prompt chaining — a fixed sequence of focused steps, plus an integration pass if cross-item interactions matter	Review a diff for security, performance and style; one pass per file across N files
The subtasks only appear once you have looked	Dynamic decomposition — each step's findings generate the next subtasks	Understand an unfamiliar system; find the root cause of an intermittent failure; plan a migration
A discovery phase can produce the item list	Hybrid — dynamic mapping first, then a fixed chain over what it found	Review a 40-file PR: work out which files interact, then chain per item and add an integration pass

Hybrids are normal and often correct, so do not treat the third row as a compromise.

Prompt chaining vs dynamic decomposition

Let the learner pick a decomposition pattern from one property: whether the subtasks are enumerable before work begins.

Per-file passes plus a cross-file integration pass

Show that equal-depth per-file analysis and a dedicated cross-file pass together cover what a single combined pass cannot.

one transition at a time

Worked examples

Restructuring a 14-file review into focused passes

Scenario 5 · Claude Code for Continuous Integration

A pull request touches 14 files in the stock-tracking module. The single-pass review gives detailed feedback on some files and superficial comments on others, misses obvious bugs, and contradicts itself — flagging a pattern as problematic in one file while approving identical code elsewhere in the same PR.

Restructure as prompt chaining: one focused pass per file for local issues (correctness, error handling, naming, tests), then one integration pass that receives only the per-file summaries and the diff's cross-file surface, and looks specifically at data flow, contract changes and consistency of patterns across files. Every file now gets equal depth, and the contradictions disappear because consistency is explicitly the integration pass's job.

Rejected alternatives: making developers split the PR (moves the burden), a bigger context window (does not improve attention quality), and majority voting over three full-PR passes (suppresses intermittently-detected real bugs).

typescript

// Phase 1 — one focused pass per file. Equal depth, independent contexts.
const perFile = await Promise.all(
  changedFiles.map((file) =>
    runReviewPass({
      prompt: 'Review ONLY this file for local issues: correctness, error handling, ' +
              'naming, missing tests. Do not comment on other files.',
      context: { path: file.path, diff: file.diff, fullText: file.after },
    }),
  ),
);

// Phase 2 — integration pass sees the summaries, not 14 full files.
const integration = await runReviewPass({
  prompt: 'You receive per-file review summaries and the cross-file surface of this PR. ' +
          'Examine data flow between files, contract and signature changes, and ' +
          'consistency: flag any pattern judged differently across files.',
  context: { summaries: perFile, changedSignatures, callGraphDelta },
});

return mergeFindings(perFile, integration);

Prompt chaining: per-file passes then a cross-file integration pass

Adaptive decomposition for "add comprehensive tests to a legacy codebase"

Scenario 4 · Developer Productivity with Claude

There is no correct fixed step list here, because the right subtasks depend on facts not yet known. The agent maps structure first (modules, entry points, existing test coverage, build and test tooling), then identifies high-impact areas (complexity, change frequency, code paths handling money or auth), then emits a prioritized plan.

The plan then adapts. Discovering that the payments module constructs its own HTTP client inline means a seam must be introduced before it can be tested, which inserts a refactor subtask ahead of the test-writing subtask and may reorder everything downstream of it. A fixed pipeline written before the mapping phase would have had no place to put that.

markdown

## Phase 1 — Map (before planning anything)
- Enumerate modules, entry points and public interfaces
- Measure existing coverage; identify the test runner and fixtures already in use

## Phase 2 — Identify high-impact areas
- Rank by: cyclomatic complexity x change frequency x blast radius
- Flag money, auth and data-mutation paths as highest priority regardless of rank

## Phase 3 — Prioritized, adaptive plan
For each target, in priority order:
1. Attempt a characterization test against the current behavior.
2. If the code is untestable as written, INSERT a seam-extraction subtask before it
   and re-evaluate the remaining priority order — a new dependency may promote or
   demote later targets.
3. Record what was learned so later targets reuse the discovered fixtures.

Re-plan whenever a step reveals a dependency the plan did not account for.

Adaptive investigation plan that regenerates subtasks

Picking the pattern from the workload

Scenario 4 · Developer Productivity with Claude

Two requests, two shapes.

"Review this diff for security, performance and style issues" — the three aspects are known before you start. Chain three focused passes, one per aspect, and merge. Fixed pipeline.

"Why does the checkout flow intermittently double-charge?" — you cannot enumerate the steps: the second step depends on what the logs say, the third on whether the retry path or the idempotency key is implicated. Dynamic decomposition, where each finding generates the next subtask.

The hybrid case is the most common in practice: "review this 40-file PR" needs a dynamic phase to determine which files interact (producing the item list) followed by a fixed per-item chain and an integration pass. Choosing purely on "big task ⇒ pipeline" is the mistake — choose on whether the subtasks are knowable in advance.

Anti-patterns

Reviewing many files in one combined pass instead of per-file passes plus an integration pass because attention dilutes and you get uneven depth, missed bugs and self-contradictory findings.
Moving to a larger context window to fix uneven review quality instead of restructuring the decomposition because context capacity and attention quality are different problems.
Running several independent full passes and reporting only findings that appear in a majority because it suppresses real bugs that are detected intermittently.
Imposing a fixed step-by-step pipeline on an open-ended investigation instead of generating subtasks from intermediate findings because discovered dependencies have nowhere to go and the plan cannot absorb them.

How it is examined

Symptoms of attention dilution — "detailed for some files, superficial for others", "contradictory feedback within one PR" — point at per-file passes plus an integration pass, not at model or context-window upgrades.
Options that push work back to humans ("require developers to split the PR") or add consensus voting are standard distractors on decomposition items.
For "add comprehensive X to a legacy codebase" stems, look for map → prioritize → adapt; any option offering a complete fixed step list up front is claiming knowledge nobody has yet.

References — 3 sources

Building effective AI agents Anthropic Engineering, 19 Dec 2024 The source of the vocabulary, with all five named patterns and the workflow-versus-agent distinction that the two-row table here is a projection of.
Orchestrate subagents at scale with dynamic workflows Anthropic What the three phases look like when someone has to run them on a codebase-wide audit or a 500-file migration.
Effective context engineering for AI agents Anthropic Engineering, 29 Sep 2025 Names and explains context rot — recall degrades as the window fills — which is the evidence that a bigger window buys capacity, not attention.

All sources verified · Aug 21, 2026

Live product docs — where they differ from the exam guide, answer from the guide. All references

Exam guide, verbatim — what is measured

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