Home › Study guides › CCAR-F › Domain 1 › Lesson 1.6

CCAR-F · Domain 1 · 27% of the exam · Lesson 1.6 · 20 min read

Task decomposition: fixed pipelines versus adaptive plans

When to split a job into a fixed prompt chain and when to map first and plan as you go, taught on a 12-file code review and a legacy test job.

Written against task statement 1.6 of the official CCAR-F exam guide (Version 1.0, effective July 2026). An independent resource, not affiliated with Anthropic; the practice questions are written from scratch.

1.6.1 Why "just do the whole thing" breaks on big jobs

A platform team has built a developer-productivity agent with the Claude Agent SDK. It helps engineers find their way around unfamiliar code and make sense of old systems. The same agent also reviews every pull request, a proposed set of code changes waiting for approval before it is merged. It does this inside the team's continuous integration (CI) pipeline, the automated system that checks each change. This week it gets two big jobs. Job A: review a 12-file pull request before it merges. Job B: "this legacy system has almost no tests; add comprehensive tests".

Both jobs are big, but in different ways. Job A has a known shape: 12 changed files, each needing a careful read, then a check that the pieces still fit together. Job B has no shape yet. Nobody knows which parts of the old system matter most, which can be tested on their own, or what is tangled up with what. The agent will find that out only by looking.

Hand either job to the agent as one enormous request and the result disappoints. The review comes back careful on some files and thin on others. The tests start wherever the agent happens to look first, with no idea what matters. The model is capable enough. The trouble is that neither job has been broken into pieces it can do well one at a time.

Breaking a job into pieces is task decomposition, and it comes in two shapes. Sometimes you can write every piece down, in order, before any work starts: a fixed sequential pipeline, which Anthropic calls prompt chaining. Sometimes you cannot, because the right next piece depends on what the last one found. That is dynamic adaptive decomposition: the agent maps the territory first and builds a plan that changes as it learns.

1.6.2 Two shapes: the pipeline and the plan

Everything in this lesson turns on one question: when are the steps decided? In a prompt chain, they are decided before the work starts. The chain splits a task into a fixed sequence of steps, and each model call works on the output of the one before. Your code decides the steps and their order in advance; the model does the work inside each step. Anthropic recommends it when a task "can be easily and cleanly decomposed into fixed subtasks". You trade some speed for accuracy, because each call gets an easier job. And since every intermediate output passes through your code, you can log it, check it, or stop the pipeline right there.

Dynamic adaptive decomposition is the opposite bet. Nobody writes the steps down in advance, because nobody can. The agent investigates first, and the subtasks it creates come from what it finds. Anthropic's account of its own research system gives the reason: "you can't hardcode a fixed path for exploring complex topics, as the process is inherently dynamic and path-dependent". An unfamiliar codebase behaves the same way. There is still a plan, but the agent writes it after the first look and rewrites it whenever a discovery changes the picture.

Think of a car wash and a plumber. Every car goes through the same stations in the same order: rinse, soap, brush, dry. Nobody redesigns the sequence for each car, and that is exactly why the car wash is fast and reliable. A plumber tracing a leak opens one panel, sees where the water is coming from, and only then decides which pipe to follow. Precisely stated: a chain fixes the subtasks before execution; adaptive decomposition generates them during execution from intermediate findings. Job A is a car wash. Job B is a leak.

1.6.3 Job A: reviewing 12 files without attention dilution

Start with the job whose shape you know. A 12-file pull request can hide two kinds of problem. Some live inside one file: a value used without checking that it exists, a loop that stops one item early, an error silently ignored. Others live BETWEEN files: a function renamed in one file while three other files still call it by its old name, or a field one file writes and no other file ever reads. A good reviewer looks for both, but not at the same time.

The failure to avoid has a name: attention dilution. Put all 12 files in one prompt, ask for everything at once, and the model's attention is spread across thousands of lines and two different kinds of question. The results come out uneven. Some files get detailed comments and others a skim, obvious bugs are missed, and the review may even flag a pattern in one file while approving the same code in another. The between-files question, which needs the whole picture held steady, gets crowded out by local detail. Picture a teacher marking 12 essays in one sitting while also trying to spot which students copied from each other. Both jobs suffer.

The fix is a chain with two stages. Stage one: per-file local analysis. One model call per file, each given only that file's changes and one instruction: find the problems inside this file. Twelve small, focused calls produce twelve careful reports. Stage two: a separate cross-file integration pass. One more call receives the twelve reports and the list of changes, with a different instruction. Find the problems that appear only when these files are seen together, such as data one file passes to another in a form the second does not expect. The integration pass is not stage one repeated with more files. It asks the between-files question and nothing else.

This is a chain, not an adaptive plan, because every step was known before the review began: 12 files, so 12 local passes, then one integration pass. Nothing found in file 6 changes what happens to file 7, and the steps are the same for every pull request, which is what a CI pipeline needs. The local passes are independent of each other, so they can also run side by side. Agent SDK subagents can run analyses like these in parallel, each in its own fresh context, returning only a summary. What stays fixed is the order of the stages: the integration pass starts only when every local report exists.

1.6.4 Job B: an open-ended job needs a map before a plan

Now the second job, and the temptation is to treat it like the first. "Add comprehensive tests" sounds like a chain: for each file, write tests. Resist that, because the shape is not the same. In Job A every file deserved the same attention. In Job B most files barely matter, a few matter enormously, and nobody yet knows which are which. A chain that walked the files in alphabetical order would spend its first hour testing a date-formatting helper while the payment code sat untested.

Dynamic decomposition starts with steps whose output is knowledge, not tests:

1. MAP THE STRUCTURE. The agent looks before it acts, using its built-in tools. Glob lists files by name pattern, which shows the layout and any tests that already exist. Grep searches file contents, which shows which modules use which. Read opens the few files that turn out to be central. Anthropic's advice for an unfamiliar codebase is the same: start with broad questions, then narrow down.
2. IDENTIFY THE HIGH-IMPACT AREAS. From the map, the agent picks where a test pays off most: code that many other modules depend on, code that handles money or access, code with no tests at all.
3. CREATE A PRIORITISED PLAN. Now, and only now, there is an ordered list of subtasks, and the first item is a real target rather than the first file in the folder.

Then comes the part that makes the plan adaptive rather than merely late. The agent starts on item one, the billing module. It discovers that billing talks to the database directly, and there is no fake (a stand-in that lets tests run without a real database). Nobody could have listed that dependency before looking. A fixed chain would stall here, or produce tests that need a live database. The adaptive plan adds a new subtask, "build a fake database layer", puts it before the billing tests and carries on. Two subtasks later the agent finds that three modules share one untested helper. It moves that helper up the list, because one test there protects all three.

Think of the plumber again. They did not refuse to plan; they refused to plan BEFORE opening the panel. That is the value of an adaptive investigation plan: effort goes where the map says it matters, and dependencies are absorbed as they surface instead of breaking the plan. Anthropic's guide to building agents makes the same call for complex tasks "where you can't predict the subtasks needed", with coding as its example. In its orchestrator-workers pattern, a central model decides the subtasks from the task in front of it, instead of following a list written in advance.

1.6.5 Recognising which shape a question describes

Exam scenarios rarely ask for a definition; they ask you to recognise which shape a workflow needs. One question does most of the work: could you write every step down, in order, before the agent starts, and would the list be the same next time? If yes, the job is a predictable multi-aspect task and wants a chain. If the steps depend on what turns up, it is open-ended investigation and wants an adaptive plan.

A chain fits when every unit gets the same treatment, such as each file in a review. It fits when the work has distinct aspects that benefit from separate attention: local issues, then integration. And it fits when the process must be inspectable and identical every run, like a CI review. Draft, then critique, then revise is the classic example; Anthropic's prompting guide calls it self-correction and names it the most common chaining pattern. An adaptive plan fits when the request is open-ended ("explore", "find out why", "add comprehensive tests") and nobody can say how many steps it will take.

Memorise the first and fourth rows: they are the two cases the task statement itself names. Recognise the rest as variations. In every row, the shape follows from whether the steps can be known in advance, never from how big the job is.

Misapplying a pattern fails in a recognisable way. A chain on open-ended work spends confident effort in the wrong place and breaks on the first hidden dependency. An adaptive plan on predictable work reviews similar pull requests differently each run, so nobody can compare today's CI output with yesterday's.

1.6.6 The exam traps

Each trap below matches the wrong shape to the job, or builds the right shape badly. Questions usually present one as a proposed design, or as a failing system whose cause you must spot.

• ✗ Reviewing all 12 files in a single prompt to "give the model full context". ✓ Split into per-file local passes plus a separate integration pass. One giant prompt dilutes attention across every file and both kinds of question at once.
• ✗ Folding the cross-file check into each per-file pass. ✓ Keep the integration pass separate. The call that reads the file with the renamed function never sees the files that still call the old name; only a pass over the collected findings can connect them.
• ✗ Turning "add comprehensive tests" into a fixed chain that walks every file in order. ✓ Map the structure, identify high-impact areas, then build a prioritised plan. A fixed walk spends effort where the file list starts, not where a test matters.
• ✗ Writing the full test plan up front and refusing to change it. ✓ Let the plan adapt as dependencies are discovered. The billing module's direct database calls appear only once the work begins, and a plan that cannot absorb them stalls.
• ✗ Using free-form exploration for a predictable CI review. ✓ Use the chain. Repeated, predictable work wants the same stages in the same order every run, with intermediate outputs the pipeline can inspect.
• ✗ Choosing the pattern by the size of the job. ✓ Choose it by whether the steps can be known in advance. A 500-invoice extraction with identical steps is still a chain; a 20-file investigation with unknown dependencies is still adaptive.

1.6.7 Put it together: build both shapes and break each one

You now have both shapes, the recognition test that tells them apart, and the way each fails when misapplied. The fastest way to make the distinction stick is to build a small version of each job and then sabotage it, because the failures are what exam questions describe.

Decomposition decides what the pieces are; the rest of this domain decides how they run. When the pieces run as separate agents, a coordinator hands them out and gives each subagent only the context its piece needs. A long adaptive plan that spans more than one sitting is what sessions (1.7) let you resume. Multi-pass review (4.6) returns to the per-file and integration passes from the reviewer's side. And keeping each subtask's context small, the reason the per-file pass works, is the whole concern of context management in Domain 5.

Key takeaways

• ✓ Task decomposition has two shapes: a fixed sequential pipeline (prompt chaining) whose steps are set before execution, and dynamic adaptive decomposition whose subtasks come from what the agent discovers.
• ✓ One oversized review prompt causes attention dilution: uneven depth, missed bugs, contradictory findings and blindness to problems between files.
• ✓ A large code review is chained into per-file local analysis passes plus a separate cross-file integration pass that asks only what no single file can show.
• ✓ An open-ended job like "add comprehensive tests to a legacy codebase" starts by mapping the structure, then identifying high-impact areas, then building a prioritised plan.
• ✓ That plan adapts: a dependency discovered mid-task becomes a new or reordered subtask instead of a failure.
• ✓ Choose by whether every step can be written down in advance: yes means a chain (predictable multi-aspect reviews), no means an adaptive plan (open-ended investigation). Job size never decides.

Check your understanding

4 questions written for this lesson, then one from the CCAR-F question bank on the same topic. Every answer option is explained, including the ones you did not pick. Nothing is stored.

Sources

• Building effective agents
• Prompting best practices (chain complex prompts)
• Claude Code best practices
• Claude Code common workflows
• Subagents in the Agent SDK
• Multi-agent research system
• The CCAR-F exam guide, summarised