CCAO-F 1.2 — Breaking big requests into steps

From a sprawling ask to a structure

Name the deliverableone sentence: what lands on the desk
List the sub-tasksthe distinct jobs inside it
Mark the checkpointswhere a wrong turn is costly
Sequence or chainnumbered steps, or separate turns

A checkpoint that fails sends you back to the sub-task, not to the start

Decomposition is a small piece of thinking you do before prompting. The middle step — deciding where a human needs to look — is the one the exam cares about.

Why one enormous request under-performs

A request like “review these three vendor proposals against our requirements, score them, model the five-year cost, flag contract risks and write a recommendation for the board” is five jobs wearing one coat. Asked all at once, the output tends to be thin in the middle: the scoring gets two lines, the cost model is asserted rather than shown, and the risks are generic. Nothing has gone wrong mechanically — the model has spread a fixed amount of attention across five tasks, and you gave it no way to know which ones carry the weight.

There is a second, quieter cost. When five jobs arrive as one block of prose, you cannot tell which part is wrong. If the recommendation is off, is that because a proposal was misread, because a score was wrong, or because the cost model used the wrong discount rate? A decomposed request gives you named intermediate outputs, and a wrong one is immediately visible — which is the bridge to the evaluation work in Domain 2.

One block versus five named jobs

Everything at oncetext

Review the three attached vendor
proposals, score them, work out the
five-year cost, flag any contract
risks and recommend one for the
board.

Numbered sub-taskstext

Work through these steps in order,
showing the output of each before
moving on.

1. For each of the three proposals,
   extract: price model, term,
   SLA, exit terms. One table.
2. Score each against our five
   requirements, 1-5, with a
   one-line reason per score.
3. Build the five-year cost for
   each. Show your workings and
   every assumption on its own row.
4. List contract risks, quoting the
   clause each one comes from.
5. Only then, recommend one, with
   the strongest case against it.

Same scope, same conversation. The right-hand version can be read step by step, and a wrong score shows up before it reaches the recommendation.

This version costs nothing extra to run. It uses the ordinary advice to give instructions as sequential steps using a numbered list where the order or the completeness of the steps matters, and it adds one instruction that does most of the work: show the output of each step before moving on. The intermediate tables are now things you can read, correct and reuse.

When to split into separate turns

Sequencing inside one prompt handles most business work. Chaining — deliberately splitting the task across separate prompts, feeding the output of one into the next — is the heavier tool, and Anthropic’s guidance is explicit that it is selective rather than routine: current models handle most multistep reasoning internally, so chaining earns its place when you need something that reasoning alone cannot give you. The documentation names the reasons: you want to inspect intermediate outputs, you need to enforce a specific pipeline, you need branching logic, or you need each step logged for transparency or compliance.

Sequence inside one prompt, or chain across turns?

Does anything need to happen between the steps?

No — just order
Numbered steps, one promptask it to show each step
A person must approve
Chain across turnsstop at the checkpoint
Next step depends on result
Chain, then branchdifferent follow-up per outcome
Each step must be logged
Chain for the audit trailone record per stage

The deciding question is not how big the task is. It is whether a human or a rule has to act on the middle of it.

The commonest and most useful chain is the self-correction pattern the documentation highlights: generate a draft, have Claude review it against stated criteria, then have it refine the draft using that review. Keeping the review as its own turn matters. A model asked to “write it and make sure it is good” tends to produce one confident pass; a model handed a finished draft and a checklist behaves like a reviewer, and finds things.

The draft · review · refine chain

You

Claude

Brief + source documents

Draft v1

Review v1 against these 6 criteria

Findings, per criterion

Revise v1 using findings 2, 3, 5

Draft v2 + change list

Three turns, one document. The review turn is given criteria, not the instruction to be critical — “check it carefully” produces praise.

Worked example · The RFP response that kept coming back generic

Tomás leads bids at a facilities-management firm. He asks Claude to “write our response to this 40-page RFP using our capability documents”. The drafts are fluent, repeat the client’s own language back, and say little specific.

He names the deliverable. Not “a response” but “answers to the 22 numbered questions in Section 4, each under 300 words, each citing which of our capability documents it draws on”.
He lists the sub-tasks. Extract the 22 questions with their scoring weights; map each to the capability documents that cover it; identify questions with no supporting evidence; draft; review against the scoring criteria.
He marks one checkpoint. The gap list — questions where the firm has no evidence — must reach the bid director before anything is drafted, because those are commercial decisions about what to claim.
He sequences the rest. Extraction and mapping run as numbered steps in one prompt, with the RFP at the top of the message and the instruction at the end.
He chains across the checkpoint. The gap list comes back, the director decides three questions will be answered with partner capability and two will be declined, and only then does drafting start in a new turn.
The review is its own turn. He pastes the RFP’s published scoring criteria and asks for findings per question, then revises.

Takeaway: The output was never a wording problem. Five jobs were compressed into one, and the one place a human decision was genuinely required — what to claim where evidence was thin — had been buried inside a draft.

Keeping the pieces connected

Decomposition has one failure mode: the steps drift apart. Step 4 forgets a constraint from step 1, or the second conversation no longer knows what the first decided. Three habits prevent it.

Carry the handoff explicitly. When you start a new turn, paste or restate what the previous step produced — the table, the shortlist, the decision — rather than assuming it is still in view. Label it, so you can refer to it by name.
Keep the standing brief in one place. Audience, format, tone and hard constraints belong in a Project’s instructions, which apply to every conversation in that workspace, so every step of a long chain inherits them.
Re-state the constraint that matters most at the step where it bites. If nothing may be claimed without evidence, say so again in the drafting step, not only in the extraction step.

Placement matters too when a step carries a long document. Anthropic’s long-context guidance is to put the long material at the top of the message and the actual question at the end — in their tests, queries at the end improve response quality by up to thirty percent on complex multi-document inputs. In a chain, that means each turn starts with its inputs and ends with its one instruction.

Worked example · A policy rollout, decomposed

Elena in HR must roll out a revised expenses policy to 900 staff across four countries: a summary of what changed, a one-page staff explainer, a manager FAQ, and translated versions.

Step 1 — diff. Old and new policy documents at the top of the message; the instruction at the end: list every substantive change as a table of clause, old rule, new rule, who it affects. Editorial changes excluded.
Checkpoint. She checks the change table against the new policy herself. Two changes are missing and one is overstated; she corrects the table by hand.
Step 2 — explainer. A fresh turn, starting with her corrected table: “using only this table, write a one-page explainer for staff who have never read the policy”.
Step 3 — FAQ. Another turn: “from the same table, write the fifteen questions managers are most likely to ask, with answers; mark any question the table cannot answer”.
Step 4 — review. She pastes the explainer and asks for a review against four criteria: accuracy against the table, reading level, tone, and anything a member of staff might misread as a benefit reduction.

Takeaway: The corrected change table is the spine of every later step. Because it was a named intermediate output, one hour of checking protected four documents — and a translation budget — from an error that would otherwise have been copied everywhere.

Where a corrected artefact pays for itself

Verified change tablechecked against the policy by a person

Staff explainer
Manager FAQ
Translations
Training slides
Intranet update

One verified intermediate output feeds several deliverables. Get it wrong and every downstream document inherits the error.

Finally, decomposition is not free. Every extra turn costs time and usage, and a chain of six steps where two would do is its own anti-pattern. The test is the one in the decision diagram above: if nothing needs to happen between the steps — no approval, no branch, no record — then the steps belong in one prompt, numbered, with each output shown.

Traps the wrong answers are built from

Tempting but wrong	Do this instead
Sending five jobs as one sentence and blaming the depth of the answer	Name the sub-tasks as numbered steps and ask for each output in turn.
Chaining every task by reflex	Chain only where a person must approve, a branch must be taken, or a step must be logged.
Starting the next turn assuming the last one is still in view	Paste or restate the previous step’s output and label it.
Asking for a draft and a self-check in the same breath	Make the review its own turn, with explicit criteria to review against.
Putting the question before a long document in the same message	Long material first, the single instruction at the end.

You should now be able to

Break a sprawling request into a named deliverable and its distinct sub-tasks.
Decide whether a task needs numbered steps in one prompt or a chain across turns.
Identify the points in a workflow where a human checkpoint is genuinely required.
Run a draft, review and refine chain with explicit review criteria.
Carry handoffs between steps so later steps keep earlier constraints.
Recognise when decomposition is adding cost without adding control.

Breaking big requests into steps