Prompt Chaining: Breaking a Task Into Linked Prompts

Prompt chaining is the practice of splitting a large task into a sequence of smaller prompts, where the output of each step is passed as input to the next. Use it when a single prompt keeps dropping requirements, when stages need different instructions, or when you want to inspect and correct intermediate results. Each link does one job with the model's full attention, which makes the whole process more accurate and much easier to debug.

Why one long prompt struggles

A prompt that asks for research, analysis, a draft, a critique and a formatted summary in one reply is asking the model to balance five sets of instructions and produce everything in a single pass. In practice, some part gets thin treatment, and when the result is wrong you cannot tell which stage went astray.

Splitting the work addresses both problems. Anthropic's documentation lists the benefits as accuracy, because each subtask gets full attention; clarity, because simpler subtasks allow simpler instructions; and traceability, because a faulty step can be found and fixed in isolation. OpenAI's guide makes the same recommendation under the heading of splitting complex tasks into simpler subtasks, and Google's prompting guidance describes sequential prompts in which each output feeds the next.

Signs a task should be chained

• The prompt has more than one distinct deliverable.
• You keep adding "and also" and the model keeps forgetting one of them.
• Different stages need different roles, such as writer then critic.
• An early mistake would invalidate everything after it, and you want a chance to catch it.
• The intermediate result is useful in its own right, such as an outline or an extracted data set.
• The source material is long, and only parts of it matter to later steps.

If none of these apply, a single well-structured prompt is simpler and should be the default.

A worked chain

Suppose the job is turning an hour-long customer interview transcript into a one-page brief for a product team.

Step 1: extract

From the transcript in <transcript>, list every problem the
customer describes. For each: a one-line statement of the
problem, and the supporting quote, verbatim. Do not interpret
or group yet. Output inside <problems> tags.

Step 2: analyze

Here are problems extracted from a customer interview:

<problems>
{{step_1_output}}
</problems>

Group them into themes. For each theme: a name, the problems
it contains, and how often the customer returned to it. Flag
any problem where the quote does not clearly support the
statement. Output inside <themes> tags.

Step 3: write

Using only the themes below, write a one-page brief for a
product team: three themes at most, each with one quote, then
open questions. Under 350 words.

<themes>
{{step_2_output}}
</themes>

Each prompt has a single objective and its own constraints. Step 1 forbids interpretation so the evidence stays clean. Step 2 never sees the full transcript, only the extracted problems, which keeps it focused. Step 3 is restricted to what step 2 produced, so it cannot introduce unsupported claims without that being visible.

Designing the handoff

The handoff between steps is where chains succeed or fail.

• Make outputs easy to lift. Ask each step to put its result inside named tags or a defined structure such as JSON. The next step, or your code, can then take exactly that part and nothing else.
• Pass forward only what is needed. Carrying the whole history into every step reintroduces the clutter chaining was meant to remove.
• But pass everything that is needed. A later step knows only what you give it. If the audience or word limit matters at step 3, restate it there; do not assume it carries over from step 1.
• Name the input. "The themes in <themes>" is unambiguous. "The above" is not.
• Keep one objective per step. If a step's instruction contains "and then", consider whether it is two steps.

Common chain shapes

Linear pipeline

Research, outline, draft, edit, format. Each step runs once, in order. This suits most content and analysis work.

Draft, review, revise

One call produces a draft; a second, given reviewer instructions, critiques it against stated criteria; a third revises using the critique. Anthropic's documentation describes this self-correction pattern. It works because critiquing is a different task from writing, and a reviewer prompt can be strict in ways a drafting prompt cannot.

Review the draft in <draft> against these criteria: every claim
traceable to <notes>; no section over 120 words; reading level
suitable for a non-specialist. List each failure with the
offending sentence. Do not rewrite.

Parallel branches, then merge

When subtasks do not depend on each other, such as summarizing five separate documents, run them independently and combine the results in a final step. This is faster than a sequence and keeps each summary uncontaminated by the others.

Gate and route

A first step classifies the input, and its answer decides which prompt runs next. A support message tagged billing goes to one prompt, bug to another. A gate can also be a plain check in code, such as whether the previous output parses as valid JSON, with a retry if it does not.

Chaining by hand in a chat window

You do not need an API to chain. In a chat app:

1. Ask for the first stage only, and say so: "Just the outline for now."
2. Read it. Correct it yourself or ask for changes.
3. Ask for the next stage, pointing at the approved version.

The review in step 2 is the main advantage of doing it by hand. For long work, starting a new conversation for a later stage and pasting in only the approved intermediate result keeps earlier discarded drafts from influencing what follows.

Trade-offs

• More calls. A chain takes longer and costs more than one prompt. The parallel shape recovers some of the time.
• Errors propagate. A mistake in extraction flows through every later step. Put a check, by a person or by a reviewer step, after the stages that everything else depends on.
• Information loss. Summarizing between steps can drop a detail a later step needed. If the final output lacks something, inspect the handoffs before rewriting the last prompt.
• More to maintain. Five prompts are five things to keep current. Do not split further than the task requires.

Some recent models with extended reasoning can handle multi-stage work inside a single call. Explicit chaining remains useful when you need to see or store intermediate results, apply different instructions per stage, or insert checks between stages.

Debugging a chain

Because each step has a visible output, debugging is a matter of walking back from the fault:

1. Find the first step whose output is wrong. Later steps may be behaving correctly on bad input.
2. Fix that step's prompt only.
3. Re-run from that step forward with the same input.

Test each link on its own with a few representative inputs before testing the chain end to end. The rubric in how to test AI prompts applies to individual steps as well as to the final result.

Related reading

Chains often use examples inside individual steps to fix an output format; see few-shot prompting. In an application, each step usually has its own narrow system prompt, covered in how to use system prompts. Several prompts in this library are natural neighbors in a chain: an article outline feeds blog writing, which feeds editing; a technical spec feeds implementation, which feeds code review.