Home › Study guides › CCAO-F › Domain 1 › Lesson 1.2

CCAO-F · Domain 1 · 14% of the exam · Lesson 1.2 · 18 min read

Breaking a complex request into steps you can check

Why one big prompt hides its mistakes, how to split complex work into stages you can check, and when a task is simple enough to ask for in one go.

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

1.2.1 Why one big request hides its mistakes

It's the last week of the quarter. You're a project manager at a small IT-services firm, and on Thursday you present the quarterly business review to your largest client, a group of eleven dental practices. You have three inputs: the monthly status reports for July, August and September, the project budget spreadsheet, and the results of the client's satisfaction survey. You upload all three and ask Claude for "an outline for the quarterly review, with the three key messages".

The outline that comes back looks ready to present. It has clear sections and a confident first message: "Spending is 12% over budget; we recommend a scope review." The survey section even links the two, noting that satisfaction held up "despite cost pressure". You're about to forward it to your account director when something nags at you. In August the client signed two change requests that raised the budget.

The spreadsheet has two budget columns: "Baseline", the figure in the original contract, and "Budget v2", the approved figure after the change requests. Claude compared spending with Baseline. Against the approved budget you are 2% under, not 12% over. Everything later in the outline was built on that one choice: the headline, the recommendation, even the tone of the survey section. And nothing in the finished outline showed you the choice.

That is the general problem with one big request. To answer it, Claude makes many small decisions you never see: which column counts, which months belong to the quarter, what counts as a complaint. Each part of the job also gets less focus: Anthropic's prompt engineering blog notes that a focused task with clear boundaries consistently produces better results than one prompt that tries to do several things at once. And a wrong decision early on doesn't look wrong at the end. It looks polished.

The fix is task decomposition: splitting a complex job into stages, each with an output you can check before the next stage depends on it. The Claude Help Center gives the same advice in one line: break complex requests into substeps.

1.2.2 Split the work where you can check it

So where do you cut? It's tempting to split by topic, but topic is not the test. A stage earns its place when it produces something you can check on its own, AND something later depends on it. The first condition gives you something to inspect. The second tells you the inspection matters, because an error there would travel.

Think of a building inspector. They check the foundations before the walls go up, because once the walls are standing, a crack underneath is both hidden and expensive to reach. A checkpoint in a decomposed task works the same way: a planned stop where you inspect one stage's output before any later stage is built on it.

Here is the quarterly review split that way. Step 1 describes each input and flags gaps. Step 2 calculates the budget variance and shows the working. Step 3 summarises the survey themes with a count for each. Step 4 reconciles all three, checking that they tell one consistent story, and proposes the three key messages. Step 5 drafts the outline from the messages you approved.

The checkpoints sit after steps 1, 2 and 4. Step 1 is where the Baseline mistake would surface, as a stated choice you can correct in one sentence. Step 2 produces the figure the client will quote back to you, and step 4 decides the story of the review. Step 3's counts get checked with step 4, since they are its evidence, and step 5 is the final draft, which you would read anyway.

1.2.3 Three ways to split a job

The quarterly review is not one straight line, and most real jobs aren't. Stages connect in three basic ways, and each suits a different kind of work.

A sequential chain passes each stage's result to the next. Use it when later work depends on earlier results. Data work usually follows one order: inspect the inputs, agree the definitions and clean up problems such as duplicates or missing values, calculate, interpret, and only then draft. In the review, describing the inputs, calculating, reconciling and drafting form a chain.

Independent parts are pieces that don't need each other, done separately and combined later. The budget variance and the survey themes need nothing from each other, so you can run each on its own, even in its own chat, and bring only the checked results into step 4. Keeping them apart also stops one from colouring the other, which is how "despite cost pressure" crept into the survey section.

Plan first means asking Claude to propose the stages, or an outline of the work, and correcting that plan before any of the work starts. Use it when the job is new or you're unsure how to split it. Asked for a plan, Claude might merge the budget and the survey into one "analyse the data" step and never mention the two budget columns. You split the step and add the check. Anthropic's AI Fluency course plans projects the same way: work out the major tasks together with Claude, then decide which parts need human strengths.

1.2.4 What to check before you move on

A checkpoint only works if you know what you're looking for. A glance that says "looks fine" is the same trust you would have given the finished outline, and a confident answer is not evidence. Check the four things a later stage will lean on.

Memorise the four. You don't need to redo Claude's work to check them: two budget lines added by hand, or three comments matched to a theme, are usually enough to catch a misread.

Once a stage is checked, pass forward only the checked version. In a chat, Claude can still see its own earlier answers, so don't leave it to work out which version counts. Start the next step by stating the confirmed results. In the hand-off below, look at the first line, which marks the results as checked, and the last, which stops Claude from running ahead to the outline.

Confirmed results for this step. I have checked them; use these and not any earlier figures in this chat.
- Budget: Budget v2 ($96,000) is the approved budget. Spent to date is $94,100, which is 2% under.
- Survey: 38 responses, collected 1 to 15 September. Themes: fast responses (21 comments), slow ticket updates (9), unclear invoices (6).
- Status reports: the booking-system migration finished three weeks late, in September.
Step 4: propose three key messages for the review, each with the evidence behind it. Mark any message that relies on something not listed above. Do not draft the outline yet.

The checkpoint after step 4 is different. There you ask not only whether the messages are right, but whether they are what you want to tell the client. Whether to open with the late migration or with the budget news is a judgement about the client relationship, and it belongs to you and your account director. Claude can propose the messages and the evidence for each; the people accountable for the review approve them before the outline is built on them.

1.2.5 One prompt, several turns, or no split at all

Once you have the stages, you still choose how to run them. A numbered list of steps in one prompt looks like working in stages. It isn't, and the difference is the checkpoint.

Numbered steps in one prompt tell Claude the order of the work, and Anthropic's prompting guide recommends them when the order or completeness of the steps matters. But Claude runs every step in one response, so you see step 1 only after step 5 has been built on it. Separate turns, often called prompt chaining, give each stage its own message, and you read and correct each result before sending the next. The same guide says chaining is still useful when you need to inspect intermediate outputs. Anthropic's prompt engineering blog names the trade: more time for more accuracy, because each step is easier.

In the app, you run a chain by hand: send one stage, read the answer, then send the next. Here is step 1 of the review. Look at the budget-column line, which turns the hidden choice from the opening into a question you can answer, and at the first and last lines, which keep Claude from running ahead.

I'm preparing a quarterly business review for a client, and I'll give you the work in stages. Do only step 1 now, then stop and wait for me.
Step 1: describe each of the three attached files: what it covers, the period, and the columns or sections that matter.
For the budget spreadsheet, say which column you would treat as the approved budget and why. If more than one column could be it, say so and ask me.
List any gaps: missing months, missing figures, or anything that doesn't match between the files.
Do not calculate anything or suggest key messages yet.

A third tool works inside a single step: ask Claude to think the problem through, or show its working, before it answers. It helps with a step that needs judgement, such as weighing the three inputs in step 4. In the apps, the thinking setting does similar work: it gives Claude time to break the problem down and plan before it responds, and you can open a summary of its reasoning. That summary helps you follow how Claude got there, but it is not a checkpoint: by the time you read it, the answer is already built on it.

Some tasks need none of this. Anthropic's prompting guide notes that Claude handles most multistep reasoning on its own, and that a general instruction to think thoroughly often works better than a step-by-step plan a person writes for it. So you split a job to create places where YOU can check it, not to tell Claude how to think. You wouldn't book a building inspection to hang a picture.

Memorise the middle two rows: numbered steps give you order, separate turns give you checkpoints.

1.2.6 The exam traps

The traps in this objective come in two kinds: too little structure on a complex job, and too much on a simple one.

• ✗ Sending a multi-input job as one big request and checking only the final draft. ✓ Split it into stages and check each output before the next depends on it. A finished draft can't show you which column Claude used.
• ✗ Fixing a wrong result by polishing the final draft or asking Claude to confirm it. ✓ Find the stage where it went wrong and correct it there. Everything after that stage was built on the error.
• ✗ Writing the stages as a numbered list and treating that as checking. ✓ Use separate turns where you need to inspect a result. A numbered list sets the order but gives you no stop to check.
• ✗ Letting Claude's unchecked output flow into the next stage. ✓ Check it, then state the confirmed result at the start of the next step so Claude builds on that version.
• ✗ Letting Claude pick the findings or messages that go to the client. ✓ Claude proposes; the person who owns the decision approves it before later stages depend on it.
• ✗ Splitting every request into stages "to be safe". ✓ Match the structure to the task. A single-step job you can check in one read needs one good brief.

1.2.7 Put it together: run a complex request in stages

You now have every piece. You split a complex job into stages you can check, arranged as a chain, as independent parts or from a reviewed plan. At each checkpoint you confirm inputs, definitions, numbers and evidence, pass forward only what you checked, and leave decisions with their owners. Here is how to feel the difference.

The rest of Domain 1 works inside these stages. Iteration (1.3) is what you do when one stage's output is close but not right. Prompting by task type (1.4) matters because the stages of one job are often different kinds of work: step 2 of the review is analysis, step 5 is drafting. And when a staged job like this repeats every quarter for a whole team, Domain 4 looks at redesigning the team's workflow around it (4.4).

Key takeaways

• ✓ One big request hides Claude's early choices, so a wrong assumption reaches the final draft looking polished.
• ✓ Task decomposition splits a job into stages whose outputs you can check before the next stage depends on them.
• ✓ Use a sequential chain when each stage feeds the next, independent parts when strands can be done separately, and plan first when you're unsure of the steps.
• ✓ At each checkpoint, confirm inputs, definitions, numbers and evidence, then pass forward only the checked result.
• ✓ Claude proposes and drafts; the person who owns a decision approves it before later stages build on it.
• ✓ Numbered steps in one prompt set the order, separate turns let you check between steps, and a simple task needs only one clear brief.

Check your understanding

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

Sources

• Prompting best practices
• Prompt engineering best practices
• Effective prompting techniques (AI Fluency)
• Project planning and delegation (AI Fluency)
• My prompt isn't giving me a helpful answer
• Change the model, effort and thinking settings
• The CCAO-F exam guide, summarised