Prompt chaining is breaking a task into a sequence of separate LLM calls, where each call does one step and passes its output to the next. Your code runs the steps in order and can check the result between them. It trades some speed for accuracy and control, because each call has a smaller job and you can inspect every intermediate result.
Anthropic's post Building effective agents gives the definition most people use: "Prompt chaining decomposes a task into a sequence of steps, where each LLM call processes the output of the previous one. You can add programmatic checks (see "gate" in the diagram below) on any intermediate steps to ensure that the process is still on track."
This page covers when chaining helps, how to design a chain, how it compares with other workflow patterns, and where it fits now that models reason internally. Sources were checked on 27 October 2026.
When should you use prompt chaining?
When a task splits cleanly into fixed steps that you know in advance. Anthropic's post says the pattern "is ideal for situations where the task can be easily and cleanly decomposed into fixed subtasks. The main goal is to trade off latency for higher accuracy, by making each LLM call an easier task."
Its two examples:
- "Generating Marketing copy, then translating it into a different language."
- "Writing an outline of a document, checking that the outline meets certain criteria, then writing the document based on the outline."
Anthropic's current prompting best practices narrow the case further for its latest models: "With adaptive thinking and subagent orchestration, Claude handles most multistep reasoning internally. Explicit prompt chaining (breaking a task into sequential API calls) is still useful when you need to inspect intermediate outputs or enforce a specific pipeline structure."
So the strongest reasons to chain today are control and visibility, not that the model cannot reason through steps on its own.
How does a prompt chain work in practice?
Each step is its own call with its own focused prompt. Code sits between the calls and decides whether to continue. Here is a sketch of an extract, check, then write chain:
# call_llm() stands in for your provider's SDK call.
fields = call_llm(
prompt=EXTRACT_PROMPT, # "Extract vendor, amount, due_date as JSON"
input=invoice_text,
schema=INVOICE_SCHEMA, # structured output keeps the hand-off parseable
)
# Gate: plain code, no model involved
if fields["amount"] <= 0 or not fields["due_date"]:
raise ValueError("Extraction failed, send to manual review")
summary = call_llm(
prompt=SUMMARY_PROMPT, # "Write a two-sentence payment reminder"
input=fields,
)
Three design choices matter most:
- One job per step. If a step's prompt needs "and also", consider splitting it.
- Structured hand-offs. Pass data between steps as JSON that matches a schema, so the next step gets exactly the fields it needs. See structured outputs.
- Gates between steps. A gate can be ordinary code (a range check, a regex, a test run) or another model call that grades the output.
Google's prompting strategies describe the same structure: "make each step a prompt and chain the prompts together in a sequence. In this sequential chain of prompts, the output of one prompt in the sequence becomes the input of the next prompt. The output of the last prompt in the sequence is the final output."
What is a self-correction chain?
It is the most common chain Anthropic describes today: generate a draft, have the model review it against criteria, then have the model refine it based on the review. Anthropic notes: "Each step is a separate API call so you can log, evaluate, or branch at any point."
Step 1 (draft): Write release notes for these merged PRs: <prs>...</prs>
Step 2 (review): Check the draft against these criteria and list every problem:
user-facing language, no internal ticket IDs, breaking changes first.
<draft>...</draft>
Step 3 (refine): Rewrite the draft to fix every problem in the review.
<draft>...</draft> <review>...</review>
Because the review is a separate output, you can log it, count how often each criterion fails, and stop the chain early when the review finds nothing.
How is prompt chaining different from other workflow patterns?
Building effective agents describes prompt chaining as one of several workflows, which it separates from agents. It defines workflows as "systems where LLMs and tools are orchestrated through predefined code paths," and agents as "systems where LLMs dynamically direct their own processes and tool usage." The post was published in December 2024 and now carries a note that much of the tooling landscape has changed, but the pattern definitions are still widely used.
| Pattern | What it does | Good fit |
|---|---|---|
| Prompt chaining | Fixed sequence of calls, each using the last output | Tasks with known, ordered steps |
| Routing | "classifies an input and directs it to a specialized followup task" | Distinct input types that need different prompts |
| Parallelization | Runs subtasks at once (sectioning) or the same task several times (voting) | Independent subtasks, or when you want several attempts |
| Orchestrator-workers | "a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results" | Tasks where you cannot predict the subtasks |
| Evaluator-optimizer | "one LLM call generates a response while another provides evaluation and feedback in a loop" | Clear criteria and measurable gains from refinement |
Google's guide adds a related idea it calls aggregating responses: run different operations on different parts of the data in parallel, then combine the results. For multi-agent designs built on the orchestrator pattern, see multi-agent systems.
When is one prompt better than a chain?
More often than you might expect. Building effective agents recommends "finding the simplest solution possible, and only increasing complexity when needed," and adds that "For many applications, however, optimizing single LLM calls with retrieval and in-context examples is usually enough."
Stay with a single prompt when:
- The steps depend on each other so tightly that splitting loses context.
- Latency matters more than the accuracy gain, since every step is another round trip.
- The model already handles the task reliably in one call on your test set.
Move to a chain when tests show one prompt failing on a specific sub-step, when you need an audit trail of intermediate results, or when a step must pass a hard check before the next one runs. The prompt engineering workflow page covers how to run that comparison.
Do you need a framework to build a prompt chain?
No. Anthropic suggests "that developers start by using LLM APIs directly: many patterns can be implemented in a few lines of code." It warns that frameworks "often create extra layers of abstraction that can obscure the underlying prompts and responses, making them harder to debug," and adds: "If you do use a framework, ensure you understand the underlying code."
A chain of two or three calls is usually a short function. Log every step's input and output from the start; those logs become your test cases. For measuring each step, see LLM evals. Gates between steps are also a natural place for safety checks, which AI guardrails covers.
How do you keep the prompts in a chain organized?
Treat each step's prompt as its own versioned file, because you will tune them separately. Kipt keeps prompts as Markdown in a private GitHub repo you own, with {{name:default}} blanks for the input each step receives, and you can tag the steps of one chain together so they are easy to find with search.
What should you read next?
Structured outputs makes the hand-off between steps reliable. Multi-agent systems covers what happens when the model, not your code, decides the steps. Chain of thought prompting explains reasoning inside a single call, the in-call counterpart to chaining.