Lesson 3.2: Breaking a task into steps with prompt chaining
Learn to split a big request into a chain of small prompts, pass results between them, place human checkpoints and judge when a chain beats one prompt.
By the end of this lesson you will be able to split a large request into a sequence of smaller prompts, choose a pattern that suits the task, hand results from one step to the next without losing or distorting them, decide where a person should check the work, and judge with a little arithmetic whether a chain will save time over one big prompt. You will build a five-step chain for turning a long report into a board brief, and see why checking between steps lifts reliability from about 66 per cent to about 89 per cent in a four-step example. You should have read Lessons 2.2 and 3.1, since chaining builds on the extract-then-answer idea and on making reasoning visible. No technical background is needed, and every chain in this lesson can be run by hand in an ordinary chat window.
A single prompt that asks for everything at once is tempting. "Read this 20-page report, find the key risks, compare them with last quarter, write a one-page board brief in our house style and suggest three questions the board might ask." It feels efficient. In practice it hands the model five jobs at once, hides where anything went wrong, and gives you one large output to accept or reject. A person asked the same would not do it all in one breath. They would read, make notes, draft, review and polish. Prompt chaining applies that way of working to a model.
What a chain is
A prompt chain is a sequence of prompts in which the output of one becomes part of the input of the next. Each prompt has one clear job. You or a program can run the chain, and a person can step in between any two links.
The benefits are practical.
Each step is simpler, so the model does it better. A request to "extract every figure with its source" is far easier to do well than "write the brief".
You can inspect the middle. If the final brief is wrong, you can see which step went off, instead of guessing.
You can fix one link without redoing everything. A weak summary does not force you to repeat the extraction.
You can use different settings or tools for different steps, such as a careful prompt for facts and a creative one for headlines.
You can reuse links. A good "extract figures" step serves many chains.
The costs are equally real. A chain needs more calls and more of your attention, handing results between steps can lose or distort information, and a poorly designed chain can compound errors. We will deal with each.
Predict first: a four-step chain has steps that are each right 90 per cent of the time. What is the chance that the whole chain is right, if an error at any step spoils the result? Decide before reading on.
The chance is 0.9 × 0.9 × 0.9 × 0.9 = 0.656, about 66 per cent. Many people guess something near 90. Errors multiply along a chain, because the next step builds on the previous output, mistakes included. This is the central design problem of chaining, and the central remedy is to check between steps.
Reliability, with and without checkpoints
Suppose that after each step you, or a simple automatic check, catch 70 per cent of the errors and fix them. The chance that a step ends up right is then 0.9 + 0.1 × 0.7 = 0.97. Over four steps the chain is right with probability 0.97 to the power 4, which is about 88.5 per cent, compared with 65.6 per cent with no checks. The checks cost some minutes of review, and they lift the chain by more than 20 points.
Patterns that work
Most useful chains follow a handful of shapes. Learn them, and you will recognise where they fit.
Pattern · Steps · Good forExtract, analyse, draft · Pull out the facts, interpret them, write the result · Reports, briefs, research notes
Draft, critique, revise · Write a first version, review it against criteria, improve it · Emails, proposals, anything with a quality bar
Plan, then execute · Outline the approach, you approve it, then carry it out · Long documents, projects, analyses
Generate, then choose · Produce several options, then score and select one · Headlines, ideas, subject lines
Classify, then route · Decide what kind of request it is, then use the matching prompt · Support triage, mixed inboxes
Check against source · Produce an answer, then verify each claim against the supplied text · Anything where accuracy matters
Many real chains combine these: extract the facts, plan the structure, draft, critique and revise. Lesson 3.4 treats the critique and revision pattern in depth.
Passing results between steps
The handoff between steps is where chains quietly fail. What leaves one step is what the next step has to work with, so design it carefully.
Label and fence the output. When you paste a result into the next prompt, put it in delimiters and name it: "Extracted facts:" with the text inside triple quotes. This keeps instructions and data apart, as Lesson 1.3 taught.
Pass only what the next step needs. A long, chatty intermediate result clutters the next prompt. Ask the earlier step for a compact format: a table, a numbered list, a few labelled lines. Short, structured outputs are also easier for you to check.
Keep the source in view. If step 3 needs to verify something, give it the original text as well as the summary, since a summary has already lost details. A good rule: the closer the step is to a factual claim, the more of the original it should see.
Carry the constraints forward. The audience, the word limit and the style sheet should reach every step that shapes the output. A step that does not know the reader will make choices that the final step has to undo.
Number and name the steps. In your notes, write what each step takes in and puts out. A chain you cannot describe in a line per step is probably too tangled.
Where people should check
A checkpoint is a place where a person looks at the intermediate result before it goes on. You cannot review everything, so place checkpoints where they pay most.
After extraction. Facts and figures pulled from a source are the foundation of everything after. A wrong number here propagates silently. Ask for quotations so the check is quick.
Before anything irreversible, such as sending, publishing or filing.
After a step that involves judgement, such as prioritising risks or classifying complaints.
Where the stakes are highest, which is usually the final output.
Skip checkpoints on mechanical steps that are easy to verify at the end, such as formatting a table. The aim is the cheapest review that catches the errors that matter.
When to chain, and when not to
· One prompt · A chainTask · Simple, one clear job · Several distinct jobs, or a long input
Output risk · Low, easy to check · Facts or judgement that need review
Reuse · One-off · You will repeat it
Effort · Least · More setup, easier to debug
Control · Take it or leave it · Edit at every stage
Chaining is worth it when the task is complex, the stakes are real or you will repeat it. For a quick email, one good prompt beats a chain. A simple check of whether it pays is to compare the expected time. Suppose a single prompt takes about 5 minutes to run and read, and succeeds without rework 55 per cent of the time, and when it fails you spend 20 minutes reworking. Its expected time is 5 + 0.45 × 20 = 14 minutes. A four-step chain takes about 2 minutes a step, 8 minutes in all, and with checkpoints succeeds 88 per cent of the time, so its expected time is 8 + 0.12 × 20 = 10.4 minutes. The chain saves 3.6 minutes per task, and more than that on a task you repeat.
A worked chain: from long report to board brief
A finance manager must turn a 20-page quarterly risk report into a one-page brief for the board, in a house style, with three likely questions. Here is a five-step chain, with the checkpoints marked.
Step 1: extract facts. Attach or paste the report. Prompt: "List every figure in the report that concerns credit losses, with its section heading and the exact sentence it appears in. Output a table with the columns Figure, Section and Sentence. Do not interpret." Checkpoint: the manager checks five figures against the report, using the quoted sentences.
Step 2: identify what changed. Prompt: "Using only the table above and the table below of last quarter's figures, list the five largest changes, with the size of each. Show the calculation." Checkpoint: the manager recomputes two changes.
Step 3: outline the brief. Prompt: "Propose an outline for a one-page board brief with a headline, three sections and a closing line on decisions needed. Do not write it yet." Checkpoint: the manager adjusts the outline, since the structure drives everything after.
Step 4: draft. Prompt: "Write the brief following the outline, using only the facts in the changes list. Follow the style sheet below. Under 300 words. If a point needs a figure not in the list, write 'figure needed'." The style sheet and the audience go into this prompt, as the previous steps did not need them.
Step 5: critique and revise. Prompt: "Review the draft against this checklist: every figure appears in the changes list, no jargon, the headline states the main message, under 300 words. List any failures, then give a corrected version." Checkpoint: the manager reads the final text and verifies the three figures that matter most.
Each prompt is short and does one job. The chain takes perhaps twenty minutes, most of it spent on the checks, and it yields a brief whose every figure can be traced to a quoted sentence. The one-prompt alternative would be quicker to run and much slower to trust.
Another chain: handling a complaint. A support lead wants consistent replies. Step 1 classifies the complaint (billing, fraud, service, other) and extracts the key facts. Step 2, which depends on the class, looks up the matching section of the policy supplied as a document and quotes the rule that applies. Step 3 drafts a reply in the house voice using only the facts and the quoted rule. Step 4 checks the draft for promises not found in the policy. A person approves before sending. The class in step 1 acts as a router: it decides which policy section and which template the later steps use, so one chain serves several kinds of complaint.
A small fan-out: headlines. A communications officer needs a headline for an announcement. Step 1 asks for ten headlines in different styles. Step 2 gives the ten, plus the criteria of clarity, accuracy and tone, and asks the model to score each out of 10 with a reason and to name the top three. The officer picks one. This "generate then choose" pattern widens the options before narrowing, which a single request for "the best headline" cannot do.
Doing it in practice
You can run chains by hand in any chat tool. Keep each step in the same conversation if later steps need earlier ones, and start a new conversation, with only the necessary results pasted in, when a step should not be influenced by the whole history. Save each prompt as a template with blanks, as Lesson 1.3 showed, and note the order of the steps. A short document that lists the chain, with the prompt for each step, the checkpoint and the expected output, is both your instruction manual and a way to hand the process to a colleague.
Some tools provide features that run several steps for you, and builders can automate chains in software, a topic covered in Module 5. The thinking is the same whether a person or a program carries the baton: one job per step, a clear handoff and a check where it counts.
Debugging a chain
When the final output is wrong, the great advantage of a chain is that you can find out where. Work backwards from the error, one link at a time, and ask at each step the same two questions: was the input to this step correct, and did the step do its job on that input?
Suppose the board brief states that credit losses rose 18 per cent, but the report says 12. Look at the draft step: did it use the figure from the changes list? Yes, the list says 18. Look at the changes step: did it compute from the extracted table? The table lists the two quarterly figures, and the calculation 18 per cent is wrong against them. The fault is in step 2, where the model mixed up two rows. Now you know exactly where to fix the prompt, perhaps by asking the model to show the two numbers it is comparing before it calculates, and you do not have to touch steps 1, 3, 4 or 5.
Three failure types come up again and again.
A bad input from an earlier step, so a later step faithfully builds on a mistake. The fix is a checkpoint upstream.
A step that does too much, such as "extract and interpret". Split it into two.
Lost information in the handoff, when a summary drops a detail the next step needed. The fix is to pass the source along, or to ask the earlier step for a fuller output.
Keep a short log of each time a chain fails, noting the step, the cause and the change you made. After a few runs you will see which links are fragile and deserve a stronger prompt or an earlier check.
Writing a good handoff prompt
The prompt that begins a new link has a recognisable shape. It names the job, labels what it received, repeats the constraints that still apply and says what to output. Here is the draft step from the board brief chain in full.
text
You are drafting a one-page board brief for non-executive directors.
Facts you may use (the only facts you may use):
"""
[PASTE THE CHANGES LIST FROM STEP 2]
"""
Outline to follow:
"""
[PASTE THE APPROVED OUTLINE FROM STEP 3]
"""
Style: plain English, short sentences, no jargon, no exclamation marks.
Length: under 300 words.
Rule: if a point needs a figure that is not in the facts above, write
"figure needed" instead of estimating.
Output only the brief.
Notice what it does. It states the audience in one line, so the model does not have to guess. It fences each input and names it. It restricts the facts to the list, so the draft cannot quietly pull in numbers from memory. It carries the style and length through, and it gives a safe exit for a missing figure. A handoff prompt written this way is long enough to be clear and short enough to read at a glance, and it is the unit you will reuse most often.
Common mistakes
A chain where one good prompt would do. Use a chain for complex, repeated or high-stakes tasks.
No checkpoints. Errors multiply along the chain, so review after extraction and judgement steps.
Verbose intermediate results. Ask each step for a compact, structured output.
Losing the source. Give later steps the original text when they must verify facts.
Forgetting the audience and style in the early steps. Carry the constraints through.
Not recording the chain. Write down each step's input, output and check.
Reviewing only the final output. By then the error is buried. Check the middle.
Treating every step as equally risky. Put your checking effort where mistakes are costly.
Key takeaways
A prompt chain is a sequence of prompts where each output feeds the next, with one clear job per step.
Chains make steps simpler, let you inspect and fix the middle, and allow reuse. They cost more calls and attention, and errors can compound.
If each of four steps is right 90 per cent of the time, the chain is right only about 66 per cent of the time. Checking and fixing 70 per cent of errors between steps lifts it to about 89 per cent.
Common patterns are extract-analyse-draft, draft-critique-revise, plan-then-execute, generate-then-choose, classify-and-route and check-against-source.
Design the handoffs: label and fence outputs, pass only what is needed, keep the source in view, carry constraints forward.
Put human checkpoints after extraction, after judgement steps and before anything irreversible. Chain when the task is complex, repeated or high-stakes.
Check yourself
1. Why does a chain of reliable steps become less reliable overall?
Errors at any step carry forward and the probabilities multiply, for example 0.9 to the power 4 is about 66 per cent.
2. Name three patterns for chains.
Extract-analyse-draft, draft-critique-revise, plan-then-execute, generate-then-choose, classify-and-route, check-against-source.
3. Where should you place your checkpoints in a report-to-brief chain?
After extraction of figures, after steps involving judgement, and on the final output before it is sent.
4. If a step is right 95 per cent of the time and checks catch 60 per cent of errors, what is the chance a step ends up right?
0.95 + 0.05 × 0.6 = 0.98.
5. A single prompt takes 4 minutes and succeeds 60 per cent of the time, with 15 minutes of rework on failure. What is its expected time?
4 + 0.4 × 15 = 10 minutes.
Try this
You need an assistant and about fifty minutes.
1. Choose a real task with several jobs: a long document to summarise for someone else, a mixed set of customer messages to answer, or a proposal to draft from notes.
2. Write down the chain: the steps, what each takes in and gives out, and where you will check. Aim for four to six steps.
3. Run the whole task first as a single prompt. Save the output and note the time and the mistakes.
4. Run the chain, with your checkpoints. At each checkpoint, record what you found and fixed.
5. Compare the two final outputs against this rubric, one point per yes.
Check · Single prompt · ChainEvery figure traceable to the source? · ·
Right length, tone and structure? · ·
Free of invented facts? · ·
Time spent in total (minutes) · ·
6. Use the checkpoint simulator with your own step accuracy to see how much checking would help a chain as long as yours.
7. Save the chain as a short document with the prompt for each step, so that a colleague could run it.
A good result is a saved chain, a visible quality gain on the rubric, and a clear note on which checkpoint caught the most. In the next lesson we look at the layer that sits above all your prompts: standing instructions, system prompts and reusable templates.
Tags: Prompt Engineering Prompt chaining Workflows Task decomposition Intermediate