Module 5 of 11 · Advanced · 10 min read

Prompt chaining and decomposition

Split hard tasks into steps with clean hand-offs, and know when one prompt is enough.

Key takeaways

1Chains trade a little latency for a lot of control and debuggability.
2Decompose by the natural stages of the work, not arbitrarily.
3Pass structured, checked outputs between steps so errors don't snowball.
4Strong models handle more in one prompt; chain when tests show you need to.

01Why split a task

A single prompt that researches, outlines, drafts, fact-checks and formats asks the model to juggle five jobs at once. Splitting the work into a chain of focused prompts gives each step full attention, lets you inspect intermediate results, and lets you fix one step without rewriting everything.

Chains also let you mix tools: a fast, cheap model for routing, a strong model for drafting, code for calculations, and a human check before anything is sent.

02Common chain shapes

Most real workflows combine two or three of these.

Pipeline: step A's output feeds step B, then C. Example: extract facts, draft, edit.
Router: a first prompt classifies the input and sends it to a specialised prompt.
Map-reduce: process many chunks or items independently, then combine the results.
Gate: a check step decides whether to continue, retry or stop.
Least-to-most: ask the model to break a problem into simpler sub-problems, then solve them in order, feeding each answer into the next (Zhou et al., 2022).

03Designing clean hand-offs

The weak point of any chain is the hand-off. If step one returns a loose paragraph, step two has to guess what matters. Make intermediate outputs structured (lists, JSON, tagged sections) and check them before passing them on. Include only what the next step needs; dumping everything forward bloats context and invites confusion.

Tip

Name each step's output, such as <facts>, <outline> and <draft>. Then the next prompt can refer to them precisely: 'Write the draft using only <facts>, following <outline>.'

04Worked example: a research brief chain

Four prompts, each small enough to test on its own.

Example

Step 1 (extract): From the sources in <sources>, list every factual claim relevant to {{question}} as JSON: [{claim, source_id, quote}]. Skip opinions. Step 2 (outline): Using only <facts>, propose an outline for a two-page brief for {{audience}}. Each section lists the fact IDs it will use. Step 3 (draft): Write the brief following <outline>. Cite fact IDs in brackets after each claim. Do not add facts. Step 4 (check): Compare <draft> with <facts>. List any sentence that makes a claim not supported by a cited fact. Return PASS if there are none.

05Pitfalls

Every step should earn its place by making the result measurably better or easier to check.

Error propagation: a mistake in step one becomes a confident claim in step four. Validate early steps.
Over-chaining: ten steps where three would do adds cost, latency and more places to break.
Lost intent: later steps forget the original goal. Restate the goal briefly in each prompt.
Context starvation: passing too little forward, so later steps lack information they need.

06When one prompt is enough

Strong current models can often do a multi-part task well in a single, well-structured prompt, especially reasoning models that plan internally. Start with one prompt and a clear structure. Split into a chain when testing shows a specific step is failing, when you need to inspect or approve intermediate results, or when different steps need different tools or models.