Prompt chaining means splitting one large task into a sequence of smaller prompts, where the output of each step becomes the input of the next. It works because each prompt has one job, so the model is less likely to drop instructions, and you can inspect, test or correct the result between steps. The cost is more calls, more tokens and more latency, so chaining is worth it only when the task has distinct stages or a single prompt keeps getting parts of it wrong.
This guide covers when to chain and when not to, then builds a complete four-step chain for a realistic job (turning raw incident notes into a postmortem), with the prompts, the hand-off format between steps, and the errors you are likely to hit.
How a prompt chain works
A prompt chain is a pipeline: step 1 receives the original input, step 2 receives step 1’s output (plus anything else it needs), and so on until the final step produces the deliverable. Each step is a separate model call, either typed by hand in a chat or made by code through an API.
Between steps you can add what Anthropic’s engineering team calls a gate: a programmatic check that the intermediate output is on track before the next step runs. In Building effective agents, Anthropic describes prompt chaining as a fit for tasks that split cleanly into fixed subtasks, trading latency for higher accuracy by making each call easier. Its examples include writing marketing copy and then translating it, and drafting an outline, checking it against criteria, and then writing the document.
The idea predates current models. A 2021 paper, AI Chains, proposed chaining LLM steps and reported that in a 20-person user study, chaining improved output quality and made the process feel more transparent and controllable. Participants also debugged results by testing individual steps, which is still the most practical benefit.
When to chain and when one prompt is enough
Chaining is not automatically better than one well-written prompt, and current models handle a lot of multi-step reasoning internally. Anthropic’s current prompting best practices say explicit chaining remains useful mainly when you need to inspect intermediate outputs or enforce a specific pipeline structure. Use this table to decide.
| Signal | One prompt | Chain |
|---|---|---|
| Task size | One clear job, such as summarizing an email in two sentences | Several stages with different goals (extract, analyze, write, review) |
| Instruction following | The model does everything you asked | The model keeps skipping or blending parts of a long instruction list |
| Need to inspect | You only care about the final result | You need to log, review or approve an intermediate result |
| Different settings per stage | Same model, same format throughout | Extraction needs strict JSON; writing needs prose; review needs a different model or temperature |
| Branching | Same path for every input | The next step depends on what an earlier step found |
| Cost and latency | Tight budget, interactive use | Accuracy matters more than speed |
Anthropic’s agent article makes the same point from the other side: start with the simplest thing that works and add complexity only when it clearly improves results. If one prompt with good examples and clear structure solves the task, keep it.
Worked example: from incident notes to a postmortem
The scenario below is illustrative. After an outage, you have a messy pile of material: a Slack channel export, alert timestamps and a few engineer notes. You want a blameless postmortem with a timeline, root cause, impact and action items. Asking for all of that in one prompt often produces a confident document where the timeline is out of order, the root cause is a guess, and action items are generic. Four steps fix that.
Step 1: extract facts into structured data
You are extracting facts from incident notes. Do not analyze or interpret.
<notes>
{{RAW_SLACK_EXPORT_AND_NOTES}}
</notes>
Return JSON only, in this shape:
{
"events": [
{"time_utc": "YYYY-MM-DD HH:MM", "actor": "person, system or unknown",
"event": "what happened, in one sentence", "source_quote": "exact text"}
],
"systems_mentioned": ["..."],
"customer_impact_statements": [{"statement": "...", "source_quote": "..."}],
"open_questions": ["facts that are unclear or contradictory in the notes"]
}
Rules:
- Convert all times to UTC. If a time has no timezone, keep it as written
and add the event to open_questions.
- Use "unknown" rather than guessing an actor.
- Every event needs a source_quote copied word for word from the notes.Why this step exists: extraction and interpretation are different jobs. Keeping them apart stops the model from inventing a cause while building the timeline. The source_quote field makes every event traceable, and open_questions gives the model somewhere to put uncertainty instead of resolving it with a guess. If you have trouble getting valid JSON back, the approach in embedding a JSON schema directly in the prompt helps.
Gate 1: check the extraction in code
Before moving on, run cheap checks that do not need a model: does the output parse as JSON, are events sorted by time, does each source_quote appear verbatim in the original notes (a plain string search), and is the events list non-empty? If a check fails, re-run step 1 with the error message appended, or stop and ask a human. This gate is where chaining pays for itself: a bad timeline gets caught here instead of being dressed up in polished prose three steps later.
Step 2: analyze cause and impact
Below is a verified timeline of an incident, as JSON.
<timeline>
{{STEP_1_OUTPUT}}
</timeline>
Using only this timeline:
1. Identify the triggering event and the chain of contributing factors.
Reference events by their time_utc.
2. Separate what the timeline shows from what it only suggests.
Label each factor "Shown" or "Hypothesis".
3. Summarize customer impact using only customer_impact_statements.
4. List any open_questions that block a confident root cause.
Think through the sequence before writing your conclusions.
Return your answer under the headings: Trigger, Contributing factors,
Impact, Blocking questions.Why this step exists: root-cause analysis needs reasoning, and it gets better input (a clean, ordered timeline) than the raw notes. Asking the model to think through the sequence first is a light form of chain-of-thought prompting inside one link of the chain. The “Shown” versus “Hypothesis” labels keep speculation visible.
Gate 2: human checkpoint
For a postmortem, the root cause is the part most worth a human look. Show the step 2 output to the incident owner and let them edit it, or answer the blocking questions, before writing the document. In a script this can be as simple as writing the output to a file and waiting for confirmation.
Step 3: write the postmortem
Write a blameless incident postmortem from the inputs below.
<timeline>{{STEP_1_OUTPUT}}</timeline>
<analysis>{{STEP_2_OUTPUT_AFTER_HUMAN_EDITS}}</analysis>
Sections: Summary (3 sentences), Impact, Timeline (table, UTC),
Root cause, Contributing factors, What went well, Action items.
Rules:
- Describe systems and decisions, not individuals' mistakes.
- Keep any "Hypothesis" labels from the analysis.
- Each action item must name the contributing factor it addresses
and be specific enough to become a ticket.
- Do not add facts that are not in the timeline or analysis.Why this step exists: writing is now a formatting and tone job with verified inputs. The model is no longer extracting, reasoning and writing at once, so each rule has a better chance of being followed.
Step 4: review against criteria
Review the postmortem below against the source timeline.
<timeline>{{STEP_1_OUTPUT}}</timeline>
<postmortem>{{STEP_3_OUTPUT}}</postmortem>
Check:
1. Every time and event in the postmortem matches the timeline.
2. No sentence assigns blame to a named person.
3. Every action item maps to a contributing factor.
4. Hypotheses are not presented as confirmed.
Return a list of problems with the exact sentence and a suggested fix.
If there are no problems, return "No issues found." Do not rewrite
the document.Draft, review, refine is the chain pattern Anthropic’s best-practices page calls the most common. Running the review as its own call means the reviewer reads the document fresh, against explicit criteria, instead of grading its own work in the same breath. If problems come back, send the list and the draft to step 3 again for one revision.
Designing the hand-offs between steps
Most chain failures happen at the boundaries, not inside the prompts. These rules keep hand-offs reliable:
- Use structured output where a machine reads it. JSON or clearly tagged sections between steps; prose only at the end, where a human reads it.
- Pass forward only what the next step needs. Step 3 above does not get the raw Slack export. Less context means less to misread and fewer tokens.
- Wrap each input in labeled tags.
<timeline>and<analysis>tell the model what each block is and where it ends. - Restate the overall goal briefly in each step. A step written in isolation can optimize for the wrong thing. One line such as “this will become a blameless postmortem” keeps it aligned.
- Give each step a success criterion you can check. “Valid JSON, sorted, every quote found in the source” is checkable. “Good timeline” is not.
Common errors and how to fix them
| Symptom | Likely cause | Fix |
|---|---|---|
| The final output contains a fact nobody wrote | An early step guessed, and later steps treated it as true | Require source quotes in the extraction step and verify them in a gate |
| Step 2 fails to parse step 1’s output | Model added commentary around the JSON, or the schema drifted | Ask for JSON only, validate it, retry once with the parser error included |
| The chain is slow and expensive with no quality gain | Steps that do not depend on each other are run in sequence, or the task never needed a chain | Run independent steps in parallel, or merge steps back into one prompt |
| The final document ignores a constraint from step 1 | The constraint was not passed forward | Carry key constraints explicitly into every step that needs them |
| Review step approves everything | Criteria are vague, or the review asks the model to rewrite instead of critique | Use a numbered checklist and ask for problems only |
| Results vary between runs | Prompts changed without tracking, or a step is underspecified | Version each step’s prompt and test the chain on fixed inputs |
The last row matters more as a chain grows: a change to step 1 can break step 3. Treat each step’s prompt as code, as described in prompt versioning, and keep a few saved inputs to re-run through the whole chain after each change.
Sequential, parallel and branching chains
The postmortem example is a sequential chain, but the same building blocks combine in other shapes. Anthropic’s agent article describes them as separate workflow patterns:
- Sequential (prompt chaining): each step depends on the previous one, as above.
- Routing: a first call classifies the input, and the next step depends on the class. For example, a support message goes to a billing prompt or a technical prompt.
- Parallelization: independent subtasks run at the same time and code combines the results. Anthropic splits this into sectioning (different subtasks in parallel) and voting (the same task several times to compare outputs).
In the postmortem chain, you could run a separate “what went well” extraction in parallel with step 2, since it does not depend on the root-cause analysis. When the next step depends on what the model finds, rather than on a fixed sequence you defined, you are moving from a chain toward an agent; see ReAct prompting for that pattern.
Prompt chaining vs. chain-of-thought vs. least-to-most
These names sound alike but describe different things. Chain-of-thought asks a model to show intermediate reasoning inside one response. Prompt chaining splits the work across several calls that you control. Least-to-most prompting sits between them: the model first breaks a problem into subproblems, then solves them in order, often feeding earlier answers into later ones. You can combine all three, as step 2 above does by asking for reasoning within one link.
Running a chain by hand or in code
You do not need code to benefit from chaining. In a chat interface, send step 1, check the result yourself (that is your gate), then paste it into step 2. Starting a new conversation for each step keeps earlier messages from leaking into later ones.
Once a chain proves useful, scripting it is straightforward: each step is one API call, with a function that validates the output before the next call. Anthropic recommends starting with direct API calls rather than a framework, since frameworks can hide the prompts and responses you need to see when debugging. Log every intermediate output; when the final result is wrong, those logs tell you which step to fix.
