Start with the real problem
A prompt chain passes the result of one AI step into the next step, like runners passing a baton in a relay race.
Breaking work into stages helps only if the handoff between stages is explicit. Prompt chaining defines what each call produces and what the next call is allowed to trust.
prompt A → validated output A → prompt B → validated final output
What you will learn
- Define a prompt chain.
- Design stable handoff formats.
- Trace errors back to the stage that created them.
- Decide when a single call is preferable.
How this connects to current AI systems
Chains can be built with any major model API or framework that coordinates the steps; reliable chains add schemas, tracing, retries, and failure states.
1. Why This Module Exists
Module 11 introduced breaking a task into smaller steps. This module formalizes exactly how those steps connect: the actual mechanics of taking one prompt’s output and feeding it into the next prompt’s input — a real, working pipeline, not just a conceptual breakdown.
2. The Idea, in Plain Language
Prompt chaining means using the output of one prompt as part of the input to the next prompt — a sequence of connected AI calls instead of one single request.
Prompt A
↓
Output A
↓
Prompt B (uses Output A as part of its input)
↓
Output B
↓
Final Result
You already saw this in Module 11’s support-transcript example — the extracted core issue became part of the input to the follow-up-email prompt. Prompt chaining is the general name for that pattern.
3. A Concrete Chain, Step by Step
Step 1 (Prompt A): "Extract all product names mentioned in this
customer review: [review text]"
→ Output A: "Wireless Earbuds Pro, Charging Case"
Step 2 (Prompt B): "For each of these products, note whether the
review's sentiment about it seems positive or
negative: Wireless Earbuds Pro, Charging Case.
Review: [same review text]"
→ Output B: "Wireless Earbuds Pro: positive.
Charging Case: negative."
Step 3 (Prompt C): "Turn this into a short structured summary for
the product team: Wireless Earbuds Pro:
positive. Charging Case: negative."
→ Final Result: a clean summary
Each step is focused and simple on its own — the complexity lives in how they’re connected, not in any single prompt trying to do everything.
4. Why Chaining Is Useful
- Each step can use a different technique — Step 1 might be a simple zero-shot extraction, Step 2 might benefit from few-shot examples of sentiment labeling, Step 3 might need explicit output formatting (Module 8)
- Each step is independently testable and debuggable — exactly Module 11’s point, now made concrete with real data flowing between steps
- Intermediate outputs can be inspected, logged, or validated before moving to the next step — really useful for catching errors early, before they compound
5. Why a Single Prompt Is Sometimes Better
Chaining isn’t free — every additional step in the chain adds response time (you have to wait for each step to finish before starting the next) and cost (Module 25). For a task simple enough to reliably handle in one prompt, chaining just adds overhead without benefit.
"Translate this sentence into French."
No reasonable chain improves this — one focused prompt is already the right level of complexity.
💡 The pattern to notice: chain when steps are really sequential and each benefits from being handled separately — not just because a task sounds complicated.
6. A Real Example From a Developer’s Perspective
Chaining is common in document-processing pipelines, where each stage depends on the previous one’s output:
Step 1: Extract raw text and structure from an uploaded PDF invoice.
Step 2: From that extracted text, identify the vendor name, invoice
number, line items, and total amount.
Step 3: Validate the extracted total against the sum of the line
items — flag a mismatch if they don't agree.
Step 4: Format the validated data into the exact JSON schema the
accounting system expects (Module 8).
Each step depends directly on the previous one’s output, and each benefits from being separately tested — Step 3 in particular acts as a really useful validation checkpoint that wouldn’t exist at all in one giant, undecomposed prompt.
7. A Simple Agentic AI Example
An agent’s entire operation is often best understood as a chain — each step’s output (a decision, a tool result) becomes part of the input for the next step:
Step 1: Agent reasons about what the user needs.
Step 2: Agent calls a tool based on that reasoning.
Step 3: Tool result is fed back into the agent's next reasoning step.
Step 4: Agent decides whether more tool calls are needed, or whether
it's ready to respond to the user.
This loop — reason, act, observe the result, reason again — is a direct, real-world instance of prompt chaining, just with tool calls and their results acting as some of the links in the chain instead of purely text. Module 18-19 cover this pattern (often called ReAct) in full depth.
8. How Is This Used in AI?
🤖 How Is This Used in AI?
Prompt chaining is the connective tissue behind most real, multi-step AI systems: document processing pipelines, RAG systems (retrieve, then generate — Module 17), and agents (reason, act, observe, repeat — Module 19) are all, structurally, chains of connected prompts and results.
9. When Should You Use It?
- The task decomposes (Module 11) into really sequential sub-tasks, where each step’s input depends on the previous step’s output
- You want to validate or inspect intermediate results before proceeding
- Different sub-tasks really benefit from different prompting approaches
10. When Should You NOT Use It?
- The task is simple enough for one well-designed prompt (Module 2) to handle reliably
- Latency is tightly constrained, and waiting for multiple sequential calls isn’t acceptable for your use case
11. Common Mistakes
Incorrect idea
Not passing enough context between steps.
Why it is incorrect
If a later step needs information from an earlier step, that information has to actually be included explicitly in the later prompt — it doesn’t carry over automatically just because it happened earlier in your code.
Incorrect idea
Chaining steps that don’t actually depend on each other.
Why it is incorrect
If two “steps” don’t actually need each other’s output, they’re not really a chain — running them independently (and possibly in parallel) may be faster and simpler.
Incorrect idea
Not handling a failure partway through the chain.
Why it is incorrect
If Step 2 fails or returns something unusable, the chain needs a real plan for what happens next — retry, fall back, or surface an error — not silently pass broken data to Step 3.
12. Limitations
- Chaining adds real response time (each step waits for the previous one) and cost (Module 25) proportional to the number of steps
- An error in an early step can still propagate through later steps if not explicitly validated along the way — chaining makes catching errors possible, not automatic
- Deciding exactly where to split a chain is a judgment call, similar to Module 11’s decomposition — there’s no single formula for the “correct” number of steps
Analogy: The Relay Race Baton Pass Think of prompt chaining like running a track-and-field relay race:
- The Setup: You have three runners in your team: Runner A (The Extractor), Runner B (The Analyst), and Runner C (The Formatter).
- The Baton Pass (Chaining):
- Runner A runs their 100 meters (extracts raw text), then hands the physical wooden baton (Output A) to Runner B.
- Runner B receives the baton, runs their 100 meters (computes sentiment classifications), and hands the updated baton (Output B) to Runner C.
- Runner C completes the race (formats the results into a clean JSON summary).
- The Failure Mode (Dropping the Baton): If Runner A drops the baton on the track (returns a blank string or a format error), Runner B cannot start running. A chain is only as strong as its handoffs, meaning you must validate the output of each link before initiating the next.
📊 Visual Flowchart: The Prompt Chaining Data Pipeline
Here is how outputs flow sequentially to construct the final result:
graph TD
classDef step fill:#3498db,stroke:#333,stroke-width:1px,color:#fff;
classDef check fill:#f1c40f,stroke:#333,stroke-width:1px,color:#fff;
classDef final fill:#2ecc71,stroke:#333,stroke-width:1px,color:#fff;
Input["1. Raw Product Review"] --> Prompt1["2. Prompt A: Extract names"]:::step
Prompt1 --> OutputA["3. Output A: 'Wireless Earbuds'"]
OutputA --> ValidateA{"4. Is output empty?"}:::check
ValidateA -->|No| Prompt2["5. Prompt B: Classify sentiment"]:::step
ValidateA -->|Yes| ErrorHandler["Trigger error fallback / alert"]
Prompt2 --> OutputB["6. Output B: 'Earbuds: positive'"]
OutputB --> Prompt3["7. Prompt C: Format summary"]:::step
Prompt3 --> FinalResult["8. Clean final summary output"]:::final
13. Quick Reference — The Whole Idea in One Diagram
Prompt A -> Output A -> Prompt B (uses Output A) -> Output B -> ...
↓
Benefits: focused steps, different techniques per step,
inspectable intermediate results
↓
Costs: more response time, more cost, more to manage and debug
14. Prompts in Code — Calling an LLM
Here’s how prompt chaining actually looks when calling an LLM through code — passing real output from one call into the next.
Example 1 — Simple
Two calls, with the second one manually using the first one’s printed output.
import anthropic
client = anthropic.Anthropic()
review = "The Wireless Earbuds Pro sound amazing, but the charging " \\
"case stopped working after a week."
step1 = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=50,
messages=[{"role": "user", "content":
f"Extract all product names mentioned in this review: {review}"}]
)
products = step1.content[0].text
print("Products found:", products)
step2 = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=100,
messages=[{"role": "user", "content":
f"For each of these products, note whether the review's "
f"sentiment seems positive or negative: {products}. "
f"Review: {review}"}]
)
print("Sentiment breakdown:", step2.content[0].text)
Example 2 — Intermediate
The chain is wrapped in a function, with each step’s output explicitly passed as a named variable into the next.
import anthropic
client = anthropic.Anthropic()
def extract_products(review: str) -> str:
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=50,
messages=[{"role": "user", "content":
f"Extract all product names mentioned in this review: {review}"}]
)
return response.content[0].text
def analyze_sentiment_per_product(review: str, products: str) -> str:
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=100,
messages=[{"role": "user", "content":
f"For each of these products, note whether the "
f"review's sentiment seems positive or negative: "
f"{products}. Review: {review}"}]
)
return response.content[0].text
review = "The Wireless Earbuds Pro sound amazing, but the charging " \\
"case stopped working after a week."
products = extract_products(review)
sentiment = analyze_sentiment_per_product(review, products)
print(sentiment)
Example 3 — Production Grade
A full chain with error handling at each step — if a step fails or returns something unusable, the chain stops and surfaces a clear error instead of silently passing broken data forward (Module 13’s Common Mistakes point).
import anthropic
client = anthropic.Anthropic()
class ChainError(Exception):
pass
def extract_products(review: str) -> str:
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=50,
messages=[{"role": "user", "content":
f"Extract all product names mentioned in this review: {review}"}]
)
result = response.content[0].text.strip()
if not result:
raise ChainError("Step 1 (extract_products) returned empty output")
return result
def analyze_sentiment_per_product(review: str, products: str) -> str:
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=100,
messages=[{"role": "user", "content":
f"For each of these products, note whether the "
f"review's sentiment seems positive or negative: "
f"{products}. Review: {review}"}]
)
result = response.content[0].text.strip()
if not result:
raise ChainError("Step 2 (analyze_sentiment) returned empty output")
return result
def process_review(review: str) -> dict:
try:
products = extract_products(review)
sentiment = analyze_sentiment_per_product(review, products)
return {"success": True, "products": products, "sentiment": sentiment}
except ChainError as e:
return {"success": False, "error": str(e)}
result = process_review(
"The Wireless Earbuds Pro sound amazing, but the charging case "
"stopped working after a week."
)
print(result)
The explicit ChainError and the check for empty output at each step
directly reflect Module 13’s warning about silently passing broken
data forward — here, a failure at any step stops the chain cleanly and
reports exactly where it happened.
When to use it—and when not to
Use it when:
- each stage has a different responsibility.
- intermediate outputs need inspection or reuse.
Do not rely on it when:
- one call meets the same quality target.
- unvalidated free text is passed into high-impact actions.
15. Interview Questions
Q: What is prompt chaining, and how does it relate to task decomposition?
Ans: Prompt chaining is the mechanism that connects decomposed steps (Module 11) together — it means using the output of one prompt as part of the input to the next prompt, forming a sequence of connected calls rather than one single request. Task decomposition identifies what the separate steps should be; prompt chaining is how those steps actually pass information between each other in a working pipeline.
Q: What are the real costs of using a prompt chain instead of a single prompt?
Ans: Each additional step in a chain adds response time, since each call typically has to complete before the next one can begin, and adds cost proportional to the number of steps, since each step is a separate call to the model. For a task simple enough to be handled reliably in one well-designed prompt, this added response time and cost isn’t justified — chaining earns its overhead specifically when steps are really sequential and benefit from being handled separately.
Q: Why is it important to explicitly handle failures at each step in a prompt chain, rather than assuming every step will succeed?
Ans: If an early step in the chain fails or returns unusable output — empty text, malformed data — and that broken output is silently passed into the next step, the failure can propagate and produce a confusing, hard-to-diagnose failure much further down the chain. Explicitly checking each step’s output and failing clearly and immediately when something goes wrong makes the actual point of failure easy to identify, rather than having to untangle a later symptom to find an upstream cause.
Q: How does prompt chaining relate to how AI agents operate?
Ans: An agent’s operation is often structurally a chain: it reasons about what to do, takes an action (like a tool call), receives a result, and feeds that result back into its next reasoning step — repeating this loop until the task is complete. This reason-act-observe cycle is a direct, practical instance of prompt chaining, just with tool calls and their results serving as some of the links in the chain instead of purely text-based outputs.
16. What You Should Remember
- Prompt chaining connects a decomposed task’s steps (Module 11) by passing one prompt’s output into the next prompt’s input.
- It enables per-step technique choice, independent testing, and inspectable intermediate results — but adds real response time and cost proportional to the number of steps.
- A chain needs an explicit plan for what happens when a step fails — silently passing broken data forward is a real, common mistake.
17. Quick Practice
Take the “review to structured summary” chain from Section 3. Add a 4th step to the chain that would be really useful — what would it do, and what would it need from the previous step’s output?
18. Next Step
Next: Module 14 — Iterative Prompting — treating prompt design as a repeated process of testing and refining, not something you get perfect on the first try.
- Author
- TechByteByByte Editorial Team
- Reviewed by
- TechByteByByte Admin
- Published
- Last reviewed