CertSafari
    CLAUDE-CERTIFIED-ASSOCIATE-FOUNDATIONS-CCAO-F-VAR5 · Lessons

    Domain 1 · Lesson 2/30

    Prompt Chaining: Ordering Stages, Handoffs and Review Points

    Apply task decomposition techniques to structure complex requests

    9 min read
    3.5% of exam
    4 sources
    Published 28 Sep 2026
    Docs as of 26 Sep 2026

    What you will be able to do

    • Order the stages of a multi-step business task so each builds on a checked result
    • Brief each stage with the context it needs, including decisions from earlier stages
    • Place review points where errors enter, before they spread
    • Choose between sequential, parallel and dynamically planned decomposition

    1.Ordering stages so each builds on the last

    Some tasks are too big or too varied for numbered steps in one prompt. The next level is to run the steps as separate stages, each with its own request. Anthropic calls this prompt chaining: a task broken into a sequence of steps, where each call works on the output of the one before. The payoff is that each request becomes an easier task, at the cost of extra time.

    Chaining fits best when the task splits cleanly into fixed subtasks you can name before you start. One of Anthropic's own examples is a familiar business document. Write an outline, check that it meets certain criteria, then write the document from the outline. Notice where the criteria come in: they exist before the check, so someone decided them before any drafting began.

    That gives a general ordering rule for business tasks: 1. Decide what 'good' means. 2. Gather and structure the raw material. 3. Apply judgement to the structured material. 4. Produce the audience-facing output.

    A vendor-selection memo, for example, runs like this: agree the evaluation criteria → extract the relevant facts from each proposal → score each proposal against the criteria → draft the recommendation. Put drafting first and you get a persuasive memo that rests on nothing. Put the criteria last and every earlier stage worked without a target. Within each stage, the prompting guidance still applies: when order or completeness matters, write the steps out explicitly.

    Sources12

    2.Handoffs: what each stage needs to be told

    A stage works from what its request contains, so each stage's request should stand on its own. Claude's prompting guidance puts it this way: think of Claude as a brilliant new employee who lacks context on your norms and workflows. Treat every stage as a fresh briefing to that employee. The decisions made earlier, such as the agreed criteria, the audience and what was ruled out, need to be in the request.

    Anthropic's orchestrator example shows the pattern to copy. Its worker calls receive both the original task and their own specific instructions, which gives them better context. The business equivalent: when you start a scoring stage, paste in three things. First, the overall goal. Second, the criteria agreed earlier, in their actual wording rather than 'the criteria we discussed'. Third, the material to be scored.

    When a request mixes several kinds of content, such as instructions, earlier outputs and source material, label them. XML tags help Claude parse complex prompts unambiguously when a prompt mixes instructions, context, examples and inputs. A scoring stage might wrap the agreed criteria in <criteria> and each proposal in its own <document> tag, so the criteria are never mistaken for material to be scored.

    Before you send any stage, apply the guidance's golden rule: could a colleague with minimal context follow this request? If they would need to ask 'which criteria?', so would Claude.

    An analyst breaks a market review into six stages and feeds each result straight into the next, reviewing nothing until the final report is written. What is the greatest risk?

    Sources13

    3.Review points: check where errors enter

    Chaining has a weakness that comes with its strength. Each stage works from the previous stage's output, so it inherits whatever that output got wrong, and it cannot recover detail an earlier stage dropped. Anthropic's answer is to add checks on intermediate steps to confirm the process is still on track.

    Anthropic's basic-workflows cookbook shows why. It chains four steps over a short quarterly summary: extract the numbers, normalise them, sort them and format a table. Here is the input:

    The input text fed into the four-step chain in Anthropic's basic-workflows cookbooktext
    Q3 Performance Summary:
    Our customer satisfaction score rose to 92 points this quarter.
    Revenue grew by 45% compared to last year.
    Market share is now at 23% in our primary market.
    Customer churn decreased to 5% from 8%.
    New user acquisition cost is $43 per user.
    Product adoption rate increased to 78%.
    Employee satisfaction is at 87 points.
    Operating margin improved to 34%.
    Three values traced through the chain, as printed in the cookbook's output
    MetricInput textAfter Step 1After Step 2 and in the final table
    Customer satisfactionrose to 92 points92: customer satisfaction points92%
    Employee satisfactionat 87 points87: employee satisfaction points87%
    User acquisition cost$43 per user$43: user acquisition cost43.0

    Scores measured in points came out as percentages. A dollar cost lost its currency, and the final table then ranked it among the percentages. Steps 3 and 4 had no way to notice, because they only saw step 2's output. Someone comparing step 2 with the original input would have spotted the problem in seconds. Someone looking only at the polished final table sees a tidy, plausible ranking.

    Two lessons follow. First, put your review right after the stage that condenses, converts or scores, before the output is polished enough to look trustworthy, not only at the end. Summaries and extractions deserve special care, because every later stage that works only from them is limited to what they kept. Second, make each stage's output checkable. Be specific about the format and constraints you expect, so a reviewer can hold the output up against the source.

    A support team wants to build a comprehensive FAQ from a large set of historical customer tickets. Which decomposition technique is most suitable?

    Sources12

    4.Sequential, side by side, or planned as you go

    Not every decomposition is a chain. When the pieces don't depend on each other, they can be handled side by side and combined afterwards, for example assessing several regional reports separately. Anthropic calls this sectioning: breaking a task into independent subtasks run in parallel. Sometimes you cannot know the subtasks until you have looked at the input. Then a planning step can decide them. In the orchestrator pattern, a central model breaks the task down, delegates the pieces and combines the results. The subtasks are worked out from the specific input rather than fixed in advance.

    Choosing a decomposition shape
    ShapeHow the work is splitFits when
    Prompt chainingA sequence of steps; each call processes the output of the previous oneThe task can be cleanly decomposed into fixed subtasks
    Parallelization (sectioning)Independent subtasks run in parallel, outputs aggregatedSubtasks don't depend on each other, or each consideration needs focused attention
    Orchestrator-workersA central LLM breaks the task down, delegates to workers and synthesizes their resultsYou can't predict the subtasks needed in advance

    The guidance for current models sets the same limit that applies to decomposition in general. Send work to separate agents only when it is large, genuinely independent and parallelizable. Independence is the test. If one piece needs another's result, it belongs in a sequence, not in parallel.

    Sources42

    Exam traps

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

    1. 1.A later stage can rely on 'the criteria we agreed earlier' without restating them in its request.Why is that wrong?

      Each stage should receive the original task together with the specific instructions and context it needs. Paste the agreed criteria in word for word.

      Covered in Handoffs: what each stage needs to be told

    2. 2.The best single place to review a multi-stage task is the finished final output.Why is that wrong?

      Later stages inherit earlier errors, and polish can hide them. Checks belong on the intermediate steps where errors enter, so the process can be corrected while it is still on track.

      Covered in Review points: check where errors enter

    3. 3.A dynamic, orchestrated breakdown is the best choice whenever a task has several parts.Why is that wrong?

      If you can predict and name the subtasks in advance, a simpler fixed decomposition is the better fit. Dynamic planning is for tasks whose subtasks depend on the input.

      Covered in Sequential, side by side, or planned as you go

    Sources

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

    1. 1.
      “Provide instructions as sequential steps using numbered lists or bullet points when the order or completeness of steps matters.”
      ↩︎ Ordering stages so each builds on the last
      “Think of Claude as a brilliant but new employee who lacks context on your norms and workflows.”
      ↩︎ Handoffs: what each stage needs to be told
      “XML tags help Claude parse complex prompts unambiguously, especially when your prompt mixes instructions, context, examples, and variable inputs.”
      ↩︎ Handoffs: what each stage needs to be told
      “Golden rule: Show your prompt to a colleague with minimal context on the task and ask them to follow it.”
      ↩︎ Handoffs: what each stage needs to be told
      “Be specific about the desired output format and constraints.”
      ↩︎ Review points: check where errors enter
    2. 2.
      “Prompt chaining decomposes a task into a sequence of steps, where each LLM call processes the output of the previous one.”
      ↩︎ Ordering stages so each builds on the last
      “The main goal is to trade off latency for higher accuracy, by making each LLM call an easier task.”
      ↩︎ Ordering stages so each builds on the last
      “Writing an outline of a document, checking that the outline meets certain criteria, then writing the document based on the outline.”
      ↩︎ Ordering stages so each builds on the last
      “on any intermediate steps to ensure that the process is still on track.”
      ↩︎ Review points: check where errors enter
      “Sectioning: Breaking a task into independent subtasks run in parallel.”
      ↩︎ Sequential, side by side, or planned as you go
      “subtasks aren't pre-defined, but determined by the orchestrator based on the specific input.”
      ↩︎ Sequential, side by side, or planned as you go
      “on any intermediate steps to ensure that the process is still on track.”
      ↩︎ Exam trap 2
    3. 3.
      “Workers receive both the original task AND their specific instructions for better context”
      ↩︎ Handoffs: what each stage needs to be told
      “Workers receive both the original task AND their specific instructions for better context”
      ↩︎ Exam trap 1
      “Subtasks are predictable and can be pre-defined (use simpler parallelization)”
      ↩︎ Exam trap 3
    4. 4.
      “Delegate to a subagent only for large tasks that are genuinely independent and parallelizable”
      ↩︎ Sequential, side by side, or planned as you go