CCAR-F 1.6 — Task decomposition strategies

Two patterns

	Prompt chaining (fixed pipeline)	Dynamic, adaptive decomposition
Shape	Known steps in a known order	Plan generated from what is discovered
Best for	Predictable multi-aspect work, e.g. a structured review	Open-ended tasks, e.g. “add tests to a legacy codebase”
Strength	Predictable, easy to test and debug	Handles what you could not anticipate
Risk	Rigid when the input surprises you	Less predictable cost and duration

Anthropic's “Building effective agents” names prompt chaining as the workflow pattern for tasks that decompose cleanly into fixed subtasks, trading latency for accuracy by making each step simpler. Reach for dynamic decomposition only when the steps genuinely cannot be known in advance.

The same post adds two details worth knowing. A chain can include programmatic “gates” between steps — checks in code that stop the chain if an intermediate result is off track. And there is a middle ground between a fixed chain and a fully dynamic agent: when the parts are independent, you can run them side by side (the post calls this sectioning), or let an orchestrator decide the subtasks from the input (orchestrator–workers, covered in 1.2). The post's overall advice is to start with the simplest pattern that works and add autonomy only when it pays for itself.

Pick the pattern from the task

Could you list the steps before seeing the input?

Yes, in a fixed order
Prompt chaineach step feeds the next; gates between
Yes, and parts are independent
Parallel sectionsrun side by side, then merge
No — findings change the plan
Dynamic planmap, prioritise, adapt as you go

The deciding question is whether a later step depends on what an earlier step finds.

Worked example · An insurer's claim-intake chain

An insurer processes thousands of home-contents claims a week. Every claim needs the same things: extract the key fields, check them against the policy, then draft a summary for an adjuster.

Step 1 — extract. One call pulls policy number, incident date, items and amounts into a fixed JSON shape.
Gate. Code checks that the policy number exists and the incident date falls inside the cover period. If not, the claim is routed to a human and the chain stops.
Step 2 — check. A second call compares each item to the policy's exclusions and limits, with the policy text supplied.
Step 3 — summarise. A third call writes the adjuster's summary from the checked data, not from the raw claim.

Takeaway: Nothing here depends on discovery, so a fixed chain wins: each step is simple, each is testable on its own, and the gate catches bad input before it costs two more calls.

Large reviews: split the attention

Give a model thirty files at once and ask for a review, and it will skim — the guide calls this attention dilution. The fix is a chain: analyse each file on its own for local issues, then run a separate cross-file integration pass looking at how the pieces interact.

Anthropic's context-engineering write-up explains why this happens: as the number of tokens in context grows, the model's ability to recall and use any one part of it falls — attention is a budget that more material spreads thinner. A bigger context window gives you room for forty files; it does not give each file forty times the attention.

Per-file pass: for each changed file, review only that file for local bugs, style and security issues.
Integration pass: with the per-file findings and the interfaces between files, look for cross-file problems — broken contracts, inconsistent data flow, missing updates.
Merge and de-duplicate findings.

One pass versus two layers

All 40 files in one pass

Attention spread across every file at once
Comments get shallower the further down the diff
Cross-file issues found only by luck

Per-file passes + integration pass

Each file gets a focused review of its own
Integration pass reads interfaces and findings, not everything
Findings merged and de-duplicated at the end

The per-file passes find local bugs; only the integration pass is positioned to see that a rename in one file was missed in two others.

The per-file passes are independent of each other, so they can run in parallel; the integration pass depends on all of them, so it runs last. Claude Code's own guidance for very large jobs follows the same idea: generate the list of files first, run one focused invocation per file, test the prompt on two or three files before running it on all of them.

Open-ended tasks: map, prioritise, adapt

“Add comprehensive tests to this legacy codebase” has no knowable step list. The guide's approach is to map the structure first, identify high-impact areas, and create a prioritised plan — then adapt the plan as dependencies are discovered. The plan is a working document, not a contract.

The adaptive loop

Map the codebasemodules, entry points, existing tests
Prioritisehighest risk and most used first
Do the next itemwrite tests for one area
Update the planrecord what was learned

new dependency or surprise → re-plan · plan complete → stop

Each pass of the loop can change the plan. That is the difference from a chain, whose steps are fixed before the first one runs.

Keeping the plan outside the model's head helps on long jobs. Anthropic describes agents keeping structured notes — a progress file or to-do list — that persist while the conversation is summarised or restarted. For this task, that note is the living plan: what is covered, what is next, and what was discovered.

Worked example · Adding tests to a bank's legacy payments module

A bank's internal IT team asks an agent to add tests to a 15-year-old payments service with almost none.

Map. The agent lists modules, finds the three entry points that handle money movement, and notes that only the date utilities have tests.
Prioritise. The plan puts the transfer-validation module first (most business risk), then fee calculation, then reporting.
Discover. Writing tests for transfer validation, the agent finds it calls a currency-rounding helper with no tests and two callers that disagree on rounding.
Adapt. The plan is updated: characterise the rounding helper first, flag the disagreement for a human, then resume transfer validation.
Continue. Fee calculation turns out to share the same helper, so its plan shrinks. The plan file reflects each change.

Takeaway: A fixed pipeline written on day one would have tested transfer validation against a helper nobody understood. The dynamic plan changed order because of what it found.

Traps the wrong answers are built from

Tempting but wrong	Do this instead
Reviewing many files in a single pass	Per-file local passes plus a separate integration pass.
A rigid pipeline for open-ended investigation	Map first, then plan and adapt as you learn.
Dynamic agents for predictable work	Use a fixed chain — cheaper, faster and easier to test.
Relying on a larger context window to fix shallow reviews	Reduce what each pass must attend to.
Treating the first plan as fixed	Update it when a dependency or surprise changes priorities.

You should now be able to

Choose prompt chaining for predictable multi-aspect work and dynamic decomposition for open-ended tasks.
Split large reviews into per-file passes and a cross-file integration pass.
Decompose open-ended work by mapping structure, prioritising, and adapting the plan.
Add programmatic gates between chain steps to stop bad intermediate results.

Task decomposition strategies