Prompt chaining

What prompt chaining is

Prompt chaining means running a sequence of prompts where the output of one becomes part of the input to the next. It's the most common way to execute a decomposed task: instead of one giant prompt, you have a chain of focused ones.

[Raw input] -> Prompt A (extract) -> Prompt B (analyse) -> Prompt C (write) -> [Final output]

You can chain by hand in a chat (copying results into the next message) or in code, where each call is a function and outputs are passed programmatically.

Why chain instead of one big prompt?

• Focus. Each prompt has one job and only the context it needs, so it tends to do that job better.
• Inspectability. You can see every intermediate result and find exactly where things went wrong.
• Control. You can validate, filter or transform between steps — with code, a human, or another prompt.
• Reuse. A good "extract key facts" link can feed many different downstream prompts.
• Flexibility. Different steps can use different settings or even different models — e.g. a smaller, faster model for simple classification and a more capable one for nuanced writing.

The costs: more calls (more latency and often more tokens), more code to maintain, and hand-offs where information can be lost. Chain when the gains are worth it.

A worked example: research brief

Goal: turn several articles into a balanced one-page brief.

Link 1 — extract claims (run once per article)

From the article in <article>, list the main factual claims.

For each claim return:
- "claim": one sentence
- "quote": the exact supporting sentence from the article
- "source_id": "{{article_id}}"

Only include claims the article actually makes. Return a JSON array.

<article>
{{article_text}}
</article>

Between links — code: merge the arrays, drop any claim whose "quote" isn't actually found in its source article (a cheap check that catches some fabricated quotes).

Link 2 — group and compare

Below are claims extracted from several articles, as JSON in <claims>.

Group them into themes. For each theme, note where sources agree, where they disagree, and which claims are supported by only one source. Keep the source_id for every claim you mention.

<claims>
{{verified_claims_json}}
</claims>

Link 3 — write the brief, using only the grouped output, for a named audience, with a required "Open questions" section for disagreements and single-source claims.

Each link is simpler than the whole task, and the verification step in the middle is something a single prompt couldn't give you.

Designing good links

"Use the previous answer" assumes the model has it in context and knows what to do with it. The improved link names its input explicitly, restates the constraints that matter at this step, and defines the output.

Guidelines:

• Make each link's output a good input. Structured formats (JSON, tagged sections) chain far better than chatty prose.
• Carry forward what later steps need. Source IDs, the audience, key constraints — if step 3 needs it, make sure it survives steps 1 and 2.
• Validate between links. Check structure with code; for risky chains, add a check prompt or a human review.
• Fail early. If link 1 returns invalid output, stop or retry there; don't let bad data flow downstream.

Chaining patterns

• Sequential: A -> B -> C, the classic pipeline.
• Fan-out / fan-in: run the same prompt over many items (each article), then combine results in one prompt.
• Conditional routing: a classification link decides which prompt runs next (billing questions go to one prompt, technical ones to another).
• Generate -> check -> revise: one link drafts, another critiques against criteria, a third revises. (More on this in the next lesson.)