Prompt chaining when models reason for themselves: when do you still need it?
TL;DR
New models handle most multi-step work in one call; chaining is still worth it when you need to see and control each step. The most useful pattern is draft, review against specific criteria, refine, one goal per step.
Modern models have thinking and can orchestrate subagents themselves, so they handle most multi-step work within a single call. Do you still need prompt chaining (splitting work into a sequence of API calls)? According to Anthropic's latest prompting guidance: yes, when you want to inspect intermediate outputs or enforce a fixed pipeline. The most common pattern is self-correction: draft → review against criteria → refine.
When to chain, and when not to
| Chain when | One call is enough when |
|---|---|
| You need to log, measure or branch at each step | Nobody needs to see intermediate results |
| Steps need different models, temperatures or tools | One model and config handle it all |
| The process is mandatory (compliance, moderation) | The work is exploratory and flexible |
| One step often fails and needs its own retry | Latency is the top priority |
The three-step self-correction pattern
# Step 1: draft
draft = call("Write an email announcing the Pro plan price increase. Context: <context>…</context>")
# Step 2: review against criteria (separate call, fresh context)
review = call(f"""Evaluate the email in <draft> against these criteria:
1. States the new price and effective date clearly
2. Explains the reason without over-apologising
3. Offers an option for customers who don't want to continue
List each issue; don't rewrite the email.
<draft>{draft}</draft>""")
# Step 3: refine based on the review
final = call(f"Revise <draft> per <review>. Return only the email.\n<draft>{draft}</draft>\n<review>{review}</review>")Because each step is a separate call, you can log, score or stop at any point, for example not sending the email if the review finds a serious problem.
Design principles for chains
- One goal per step: the review step only lists issues, it doesn't rewrite; mixing the two makes both worse.
- Hand off with XML tags: wrap the previous output in clearly named tags (
<draft>,<review>) so the next step knows what's data. - Specific review criteria: "check quality" is too vague; list 3–5 measurable criteria.
- Pick models per step: drafting and reviewing can use different models to balance cost.
- Parallelise where possible: independent steps (say, a legal review and a tone review) run in parallel and are merged.
Risks and caveats
- Latency and cost add up: three calls mean three waits and three bills; chain only when the control is worth more than the cost.
- "Lenient" reviews: a model reviewing its own output tends to be satisfied; clear criteria and an instruction to list issues reduce this.
- Over-editing: the refine step can lose good parts of the draft; ask it to fix only the issues listed.
- Error propagation: if step one is wrong, later steps just polish wrong content; check early.
How to apply it
- Dev: Start with one call; split into a chain only when you can name the step that needs separate checking.
- Tech Lead: Log each step's output so you can evaluate each stage and find the weakest one instead of guessing.
- PM: For customer-facing content, a draft–review–refine chain with a human approval stop is a safe, explainable process.
Sources & references
- Prompting best practices: Chain complex prompts — Claude Docs