CertSafari
    Anthropic Claude Certified Architect – Foundations (CCAR-F)· Lessons

    Domain 1 · Lesson 6/30

    Prompt Chaining vs Dynamic Decomposition

    Design task decomposition strategies for complex workflows

    11 min read
    3.86% of exam
    5 sources
    Published 4 Oct 2026
    Docs as of 30 Sep 2026

    What you will be able to do

    • Tell apart workflows that follow predefined code paths from agents that decide their own subtasks
    • Explain what a fixed prompt chain buys (accuracy, inspectable intermediate outputs) and what it costs (latency)
    • Explain why open-ended investigations need plans that produce new subtasks from intermediate findings
    • Choose between prompt chaining, pre-defined parallelization and orchestrator-driven decomposition for a given workflow

    Key concept

    Fixed vs. adaptive decomposition — With fixed decomposition, the designer sets the subtasks before any input arrives and code runs them in order. With adaptive decomposition, the model creates and revises subtasks at runtime, based on the input and on what earlier steps found. Choosing between them comes down to how much of the plan you can know in advance.

    1.Two families: predefined paths and model-directed plans

    Every decomposition strategy answers one question: who decides what the subtasks are, and when? Anthropic's *Building effective agents* divides agentic systems along that line. Workflows are "systems where LLMs and tools are orchestrated through predefined code paths." Agents are systems where LLMs "dynamically direct their own processes and tool usage." In a workflow, the designer fixes the steps before any input arrives. An agent picks its next step as it goes.

    Neither one is the default. Anthropic's first recommendation is "finding the simplest solution possible, and only increasing complexity when needed", and that can mean not decomposing at all. When more structure is justified, the trade-off is stated plainly: workflows give predictability and consistency on well-defined tasks, and agents give flexibility when decisions have to be made at runtime. Claude's prompting guidance says the same about delegation. For simple tasks, sequential operations, single-file edits, or work that has to keep context across steps, Claude should "work directly rather than delegating."

    So for this objective, don't ask which pattern is most powerful. Ask how much of the plan can be known before the work starts. If all of it can, use a fixed pipeline. If the next step depends on what the last one found, the decomposition has to adapt.

    Checkpoint 1 of 6· Check yourself

    An architect knows every step of a task before any input arrives and needs consistent output across thousands of runs. Which family of agentic system fits best?

    Sources12

    2.Prompt chaining: a fixed pipeline of easier calls

    Prompt chaining "decomposes a task into a sequence of steps, where each LLM call processes the output of the previous one." You can add programmatic checks, called gates, between steps to confirm the process is still on track. Anthropic calls it ideal when a task "can be easily and cleanly decomposed into fixed subtasks". The examples include writing an outline, checking it against criteria, and then writing the document from it.

    The Anthropic cookbook's chain example turns a quarterly report into a table in four steps. Each step does one simple job on the previous step's output:

    The four-step chain from the cookbook's structured-data example
    StepWhat that call does with the previous output
    Step 1Pulls each numeric value and its metric out of the raw Q3 text
    Step 2Normalizes the values (e.g. 92 points becomes 92%)
    Step 3Sorts the lines in descending order by numerical value
    Step 4Formats the sorted lines as a Markdown table

    Current Claude models handle most multistep reasoning internally, so is chaining still needed? The prompting guide says explicit chaining "is still useful when you need to inspect intermediate outputs or enforce a specific pipeline structure." Its most common form is self-correction: generate a draft, have Claude review it against criteria, then have Claude refine it based on the review. Because "each step is a separate API call", you can log, evaluate or branch between any two steps.

    This makes chaining the natural fit for a predictable multi-aspect review. If the same aspects are checked in the same order on every input, the order is part of the specification, and a fixed chain enforces it.

    Checkpoint 2 of 6· Check yourself

    A team runs every document through draft → review against criteria → refine, and auditors need to see each intermediate output. Why use an explicit chain of API calls instead of one long prompt?

    Checkpoint 3 of 6· Exam question

    A team is building an automated pipeline that takes a raw customer support transcript, produces a structured summary, then translates that summary into three fixed target languages. The steps and their order never change between runs. Which decomposition strategy best fits this workflow?

    Sources12

    3.Dynamic decomposition: subtasks generated from findings

    Some tasks can't be cut into fixed steps, because the right next step depends on what the last one turned up. Anthropic's write-up of its multi-agent Research system says research involves open-ended problems where it is very hard to predict the required steps in advance. "When people conduct research, they tend to continuously update their approach based on discoveries, following leads that emerge during investigation." The model has to keep choosing which directions to pursue based on intermediate findings, and "a linear, one-shot pipeline cannot handle these tasks."

    The matching pattern is orchestrator-workers: a central LLM breaks the task down dynamically, delegates the pieces to workers and combines their results. Anthropic's coding example explains why: the number of files to change, and what each change should be, depend on the task. The cookbook puts the difference this way: "The orchestrator decides at runtime what subtasks to create, making this more adaptive than pre-defined parallel workflows."

    An adaptive investigation plan also changes as the work goes on. In the Research system, the lead agent saves its plan to memory, spawns subagents for specific research tasks, combines what they return, and then "decides whether more research is needed—if so, it can create additional subagents or refine its strategy." Claude Code's dynamic workflows support the same idea in loops whose length nobody knows up front, such as one that will "keep fixing the reported errors until the type check passes or two rounds in a row make no progress."

    Adapting has a cost. Multi-agent systems use about 15× more tokens than chats. Early versions of the Research system also spawned 50 subagents for simple queries. And the cookbook warns: "Orchestrator might not break down tasks optimally (prompt engineering is critical)."

    Checkpoint 4 of 6· Put it in order

    Put the steps of the Research system's adaptive loop in order.

    1. 1.The lead agent creates subagents with specific research tasks
    2. 2.Once there's enough information, a CitationAgent attributes the claims to sources
    3. 3.The lead agent thinks through its approach and saves the plan to memory
    4. 4.The lead agent combines the results and decides whether more research is needed
    5. 5.Each subagent searches independently and returns findings

    Checkpoint 5 of 6· Exam question

    An architect is asked to design an agent that investigates why a production incident occurred, given only a vague alert message and no prior knowledge of which service is at fault. The number of logs, services, and code paths to inspect cannot be known ahead of time. Which decomposition approach is most appropriate?

    Sources345

    4.Choosing: chain, section or orchestrate

    Two questions settle most choices. Are the subtasks known before the input arrives? And does any subtask need another one's output? The answers point to one of three patterns:

    Choosing a decomposition pattern by two questions
    PatternSubtasks known in advance?Do subtasks depend on each other?Typical fit
    Prompt chainingYes, fixedYes, each step processes the previous outputGenerate then translate; outline, check, then write; a predictable multi-aspect review
    Parallelization (sectioning)Yes, fixedNo, independentThe same independent checks on every input, with outputs combined in code
    Orchestrator-workersNo, decided at runtime from the inputThe plan is revised as results come inMulti-file coding changes; gathering information from many sources

    The middle row is the one people miss. If every input gets the same set of independent actions, the subtasks are still predefined. They just don't need to run in order. Adding a runtime orchestrator here gains nothing. It costs extra calls (N+1 in the cookbook's implementation) and adds the risk of a bad breakdown. The cookbook's "don't use" list names this case directly. In the other direction, forcing a fixed chain onto an open-ended investigation fails for the reason given in the previous section.

    Delegating to parallel subagents is a separate choice. The prompting guide says: "Use subagents when tasks can run in parallel, require isolated context, or involve" independent workstreams that don't share state. Anthropic also notes that "most coding tasks involve fewer truly parallelizable tasks than research", so check whether code work can really be split before fanning it out.

    Checkpoint 6 of 6· Match them up

    Match each scenario to the decomposition pattern it calls for.

    Tap a term, then the definition that fits it.

    Sources14

    Exam traps

    Each one states something that sounds right. Open it to see what is actually true.

    1. 1.Claude now reasons through multistep tasks internally, so explicit prompt chaining is obsolete.Why is that wrong?

      Explicit chaining still earns its place when you have to inspect intermediate outputs or enforce a specific pipeline order.

      Covered in Prompt chaining: a fixed pipeline of easier calls

    2. 2.An open-ended investigation can be planned completely up front as a fixed sequence of steps.Why is that wrong?

      The next step in an investigation depends on what earlier steps found, so the plan has to generate and revise subtasks as it goes.

      Covered in Dynamic decomposition: subtasks generated from findings

    3. 3.A dynamic orchestrator is the safer, more flexible choice even when every input gets the same fixed checklist.Why is that wrong?

      When subtasks are predictable, pre-defined parallelization or a chain is simpler and cheaper. An orchestrator only adds calls and the risk of a poor breakdown.

      Covered in Choosing: chain, section or orchestrate

    Sources

    Every claim above is drawn from one of these pages, quoted as it was written on the date shown.

    1. 1.
      “work directly rather than delegating.”
      ↩︎ Two families: predefined paths and model-directed plans
      “is still useful when you need to inspect intermediate outputs or enforce a specific pipeline structure.”
      ↩︎ Prompt chaining: a fixed pipeline of easier calls
      “Use subagents when tasks can run in parallel, require isolated context, or involve”
      ↩︎ Choosing: chain, section or orchestrate
      “is still useful when you need to inspect intermediate outputs or enforce a specific pipeline structure.”
      ↩︎ Exam trap 1
      “Each step is a separate API call so you can log, evaluate, or branch at any point.”
      ↩︎ Checkpoint
    2. 2.
      “Workflows are systems where LLMs and tools are orchestrated through predefined code paths.”
      ↩︎ Two families: predefined paths and model-directed plans
      “we recommend finding the simplest solution possible, and only increasing complexity when needed.”
      ↩︎ Two families: predefined paths and model-directed plans
      “Prompt chaining decomposes a task into a sequence of steps, where each LLM call processes the output of the previous one.”
      ↩︎ Prompt chaining: a fixed pipeline of easier calls
      “This workflow is ideal for situations where the task can be easily and cleanly decomposed into fixed subtasks.”
      ↩︎ Prompt chaining: a fixed pipeline of easier calls
      “workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale”
      ↩︎ Key concept
      “workflows offer predictability and consistency for well-defined tasks”
      ↩︎ Checkpoint
      “The main goal is to trade off latency for higher accuracy, by making each LLM call an easier task.”
      ↩︎ Prediction
    3. 3.
      “keep fixing the reported errors until the type check passes or two rounds in a row make no progress”
      ↩︎ Dynamic decomposition: subtasks generated from findings
    4. 4.
      “When people conduct research, they tend to continuously update their approach based on discoveries, following leads that emerge during investigation.”
      ↩︎ Dynamic decomposition: subtasks generated from findings
      “most coding tasks involve fewer truly parallelizable tasks than research”
      ↩︎ Choosing: chain, section or orchestrate
      “A linear, one-shot pipeline cannot handle these tasks.”
      ↩︎ Exam trap 2
      “The LeadResearcher synthesizes these results and decides whether more research is needed—if so, it can create additional subagents or refine its strategy.”
      ↩︎ Checkpoint
    5. 5.
      “The orchestrator decides at runtime what subtasks to create, making this more adaptive than pre-defined parallel workflows.”
      ↩︎ Dynamic decomposition: subtasks generated from findings
      “Subtasks are predictable and can be pre-defined (use simpler parallelization)”
      ↩︎ Exam trap 3
      “Subtasks are predictable and can be pre-defined (use simpler parallelization)”
      ↩︎ Checkpoint

    Continue to page 2 of 2

    Decomposing Code Reviews and Open-Ended Codebase Tasks

    Spotted a mistake, or was something unclear? Tell us.