Task decomposition: CCAR-F task statement 1.6

Task statement 1.6 sits in Agentic Architecture & Orchestration, 27% of the CCAR-F exam. It tests one choice: when to break work into a fixed sequence of steps decided in advance, and when to let the plan grow from what each step finds.

What the official guide covers

The Claude Certified Architect Foundations exam guide (version 1.0, effective July 2026) lists this under task statement 1.6, "Design task decomposition strategies for complex workflows":

Two ways to decompose a task

Prompt chaining splits the work into steps you define before it starts. Each step is a separate call to Claude with a narrow job, and the output of one step becomes input to the next. Your code controls the order. Anthropic's "Building effective agents" describes it as suited to tasks that break cleanly into fixed subtasks, trading some latency for accuracy because each call is simpler. You can add checks between steps (Anthropic calls them gates) to stop the chain if a step's output is wrong.

Dynamic decomposition decides the subtasks while the work is running. Claude, often as an orchestrator, looks at the input and at each result, then decides what to do next. The subtasks are not known in advance. This is the orchestrator-workers pattern: the orchestrator splits the task based on the specific input and assigns the parts to workers.

Splitting a large code review

Reviewing many files in one request spreads Claude's attention across all of them. Some files get detailed feedback, others get little, and the same pattern can be flagged in one file and passed in another. The fix the guide names is a chain of focused passes:

1. Per-file pass. Review each file on its own for local problems: logic errors, naming, error handling.
2. Integration pass. Review how the files work together: data passed between modules, changed interfaces, calls that no longer match.

import anthropic

client = anthropic.Anthropic()

def ask(prompt):
    response = client.messages.create(
        model=MODEL, max_tokens=2000,
        messages=[{"role": "user", "content": prompt}],
    )
    return "".join(b.text for b in response.content if b.type == "text")

def review_pull_request(changed_files):          # {path: diff text}
    # Step 1: one focused review per file
    local = {}
    for path, diff in changed_files.items():
        local[path] = ask(
            f"Review only this file for local issues.\n<file path='{path}'>\n{diff}\n</file>"
        )

    # Step 2: one cross-file pass over interfaces and data flow
    summaries = "\n".join(f"<file path='{p}'>{r}</file>" for p, r in local.items())
    interfaces = "\n".join(extract_signatures(d) for d in changed_files.values())  # your helper
    integration = ask(
        "These files changed together. Check data flow and interfaces between them. "
        "Report only cross-file issues.\n"
        f"<per_file_reviews>\n{summaries}\n</per_file_reviews>\n"
        f"<changed_interfaces>\n{interfaces}\n</changed_interfaces>"
    )
    return local, integration

Each per-file call has one job and one file, so every file gets the same depth. The integration call sees the per-file findings and the changed interfaces, not every line of every file. Because each step is a separate call, you can log, test and re-run any step on its own. The per-file calls are independent, so you can also run them at the same time.

Breaking down an open-ended task

"Add comprehensive tests to this legacy codebase" has no fixed list of steps. A plan written before anyone has read the code will be wrong. The guide's approach is:

1. Map the structure. List modules, entry points and how they depend on each other.
2. Find the high-impact areas. Code that is used a lot, changes often, handles money or data, or has no tests.
3. Make a prioritised plan. Start with the highest-impact area.
4. Adapt as you go. When writing tests for one module shows it depends on another untested module, add that to the plan and move it up if needed.

This is dynamic decomposition. Each step can create new subtasks. Claude can do this inside one agentic loop, or as an orchestrator that hands each area to a subagent (see 1.2 Coordinator and subagent patterns).

The workflow shapes behind decomposition

Prompt chaining and orchestrator-workers are two of five patterns in Anthropic's "Building effective agents". Exam options often describe one of the others without naming it:

The patterns combine. The code review above is a chain whose first step runs in parallel. When several outputs build on one shared step, such as one extraction feeding a staff notice, an FAQ and a board brief, check that step before you fan out; an error there is copied into every output.

Chaining also fixes a common prompt failure. When one long prompt asks Claude to write something and obey many rules at once, some rules get missed. Split it: one call writes the draft, a second call takes the draft and checks it against the rules one by one. Each call then has a single job.

Start with the simplest pattern that works

Anthropic's advice is to start with a single well-built call, move to a workflow when one call is not enough, and use an agent only when the steps cannot be written in advance. Five factors, checked in order, show where a task belongs: can you list the steps, what a wrong answer costs, whether someone must audit each step afterwards, how long the user can wait, and how many tokens each request can spend. Agents score worst on the last four, so they need a real reason.

A finance team built an open agent to handle expense claims because the work "felt varied". Six months later they read the logs: every run had followed one of three paths. A router with three chains would have done the same work, cost less, and given auditors a named step for every approval.

Choosing a pattern

Rules that decide exam answers

• Predictable means chain. If the steps are the same every time, a fixed chain beats an open agent. It is more consistent and easier to test.
• Open-ended means adapt. If nobody can list the steps before the work starts, choose the option that maps first and lets the plan change.
• Many files means split passes. Uneven or contradictory review feedback across many files points to attention spread too thin. Per-file passes plus an integration pass is the fix; a bigger context window is not.
• Do not drop the integration pass. Per-file reviews alone miss problems between files. Keep a separate cross-file step.
• Prioritise by impact. For large open tasks, the right answer starts with the high-impact areas, not with alphabetical order or the easiest files.
• Start simple. If the runs of an existing agent always follow a few known paths, the better design is a router with fixed chains. If the work splits into independent sections, a parallel workflow beats an open agent.

Where it appears in the exam

Domain 1 is a primary domain in three of the six exam scenarios: Customer Support Resolution Agent, Multi-Agent Research System and Developer Productivity with Claude. Exploring an unfamiliar codebase and planning work on legacy systems fits the Developer Productivity scenario. Splitting research topics fits the Multi-Agent Research System scenario. Large code reviews also appear under task statement 4.6 on multi-pass review.

Two sample questions

These are original Timo practice questions. They are not official exam questions.

Question 1

A finance team uses a Claude agent to check supplier invoices. Every invoice must pass the same four checks in the same order: supplier is approved, purchase order matches, tax is correct, totals add up. The agent sometimes skips the tax check when the other checks look fine. What design should the architect choose?

A. Keep the open agent and add "never skip a check" to the system prompt.B. Use a prompt chain with one call per check and a gate between steps.C. Let a coordinator decide for each invoice which checks are worth running.D. Run the agent twice on each invoice and compare the two answers.

Answer: B. The steps are fixed and known, so a chain makes each check its own call and guarantees all four run. A keeps the order up to Claude, so a check can still be skipped. C makes skipping a design feature. D doubles the cost and both runs can skip the same check.

Question 2

A developer asks an agent to "add comprehensive tests" to a legacy billing service. The agent writes a plan listing all 30 modules in alphabetical order and starts at the top. After two days it has tested simple helper modules, and it finds late that the payment module depends on two untested modules. How should the task be decomposed?

A. Split the 30 modules evenly across three subagents and run them in parallel.B. Keep the alphabetical plan but add a time limit for each module.C. Map the modules and their dependencies first, start with the highest-impact areas, and update the plan as dependencies appear.D. Ask the agent to write tests for all 30 modules in one large request.

Answer: C. Open-ended tasks need a map first, a plan ordered by impact and a plan that changes as dependencies are found. A spreads the same unprioritised work across more agents. B keeps the wrong order. D overloads one request and gives no way to adapt.

Build exercise

1. Take a pull request that touches at least eight files. Review it once in a single request and save the output.
2. Run the two-step chain above on the same pull request. Compare depth per file and look for contradictions between files in each version.
3. Plant a bug that only shows across two files, such as a renamed field. Check that the integration pass finds it and the per-file passes do not.
4. Point an agent at an unfamiliar repository with the goal "add tests where they matter most". Ask it to write its structure map and priority list to a file first, then watch whether it updates the list as it works.

Practise this topic

• Claude Certified Architect practice exam: free, 20 questions, no sign-up
• Claude Certified Architect hub
• CCAR-F study guide: all topics
• Same topic in another exam: CCDV-F Agent Patterns and Frameworks
• Previous topic: 1.5 Agent SDK hooks
• Next topic: 1.7 Session state, resumption and forking

Sources

• Claude Certified Architect Foundations Exam Guide, version 1.0, effective July 2026 (Anthropic), task statement 1.6
• Anthropic: Building effective agents
• Anthropic documentation: Prompting best practices
• Anthropic: How we built our multi-agent research system