Catalog / Single agent

Prompt chaining

One model is called several times in a fixed order. Each call does one small job on the previous output, and code checks the result between calls.

Reference task used across all patterns: "My order arrived damaged. Can I get a refund?"

Topology

ActorLead agentGate

Run

09 steps

Ready to run

Play runs the whole scenario. Step advances one event at a time so you can read what happens.

Metrics

Wall-clock time0.0 s
Tokens processed0
Estimated cost$0.000
Unchecked handoffs
0
Illustrative values. They show proportions between patterns, not benchmarks.

All steps

Normal run

  1. Request arrives. The three boxes are the same model with three different prompts. The order of the calls is fixed in code.
  2. Link 1: extract. The first prompt asks for one thing only: the facts of the case as JSON. A narrow prompt is easier to get right than a broad one.
  3. Hand over. The output of one call is the input of the next. Nothing else carries over between links.
  4. Check in code. Between links sits a gate that is not a model. Does the JSON parse? Is the order id present, and does order 4417 exist?
  5. Pass. Only a verified artifact moves on. A failed check would have retried link 1 instead.
  6. Link 2: decide. The second prompt applies the policy to clean facts. Delivered 12 Sep, damage confirmed, inside the 30-day window.
  7. Hand over. The decision travels on as data.
  8. Link 3: write. The third prompt only words the reply. It cannot change the decision, because it is never asked to make one.
  9. Respond. Refund approved. Three short calls took longer than one, in exchange for three outputs that could each be checked.

Outcome: correct answer. The chain traded latency for accuracy. Each call had an easier task than the whole, and the check between calls kept a bad output from becoming the next input.

Failure mode

  1. Request arrives. Same chain, but this build has no check between the links.
  2. A truncated output. The first call hits its output limit and the JSON is cut off mid-object. The order id field is missing.
  3. Unchecked handoff. Nothing parses the output before passing it on, so the broken artifact goes straight to the next prompt.
  4. The gap gets filled. The second prompt expects an order id and finds none, so it supplies a plausible one, 4471. Models complete patterns; they do not raise exceptions.
  5. Hand over. The invented id now looks like any other field.
  6. Link 3: write. The reply is fluent and confident, as always.
  7. Incorrect response. Refund approved, for order 4471, which belongs to someone else.

Failure: no gate between the links. A chain amplifies whatever it is fed. Mitigation: check every intermediate output in code, for schema, required fields and existence, and retry or stop the link instead of passing a bad artifact on.

Execution trace

Model workingSending a message

Reference

Problem
One prompt asked to do everything does each part worse, and its single output cannot be checked halfway.
Analogy
A recipe. Each step uses what the previous one produced, and a cook tastes the sauce before it goes on the plate.
Use when
The task decomposes cleanly into fixed subtasks, and you will accept more latency in exchange for accuracy and checkable intermediate results.
Avoid when
The subtasks are not known in advance, or each call needs context that the previous output does not carry.
Typical failure
An unchecked intermediate output is treated as fact by the next call, which fills any gaps by guessing.
Also known as
Prompt chaining (Anthropic)Chains (LangChain)SequentialAgent (Google ADK, related)
Related patterns
Sources

Space play or pause   → next step   ← previous step  R reset   F failure mode