Prompt chaining is the practice of breaking a complex task into a sequence of simpler LLM calls, where the output of each call feeds into the next. It works because language models perform better on narrow, focused tasks than on complex multi-step requests packed into a single prompt. A model asked to "research, outline, draft, critique, and format a 2,000-word blog post" in one shot will produce worse results than a pipeline of five focused calls, each doing one thing well.
The insight is simple: LLMs make fewer errors per step when each step is small. Chaining composes small reliable steps into complex reliable pipelines.
Why Single Prompts Break Down on Complex Tasks
When you ask a model to do too much in one prompt, three things happen:
First, earlier parts of a long output are generated without the model "knowing" how the whole thing will turn out. A model writing an introduction cannot see how its conclusion will read.
Second, the model spreads attention across too many constraints simultaneously. "Be concise, comprehensive, technically accurate, written for beginners, include examples, avoid jargon" — these constraints conflict, and the model makes tradeoffs you did not intend.
Third, errors compound. If the model makes a mistake in step 2 of a 6-step task embedded in one prompt, it often builds on that mistake for steps 3 through 6. In a chain, each step can be validated before proceeding.
Pattern 1: Sequential Chaining
Each step depends on the previous. This is the simplest pattern.
Example: writing a technical blog post
Step 1: Research
You are a research assistant. List 8 concrete, specific facts about how PostgreSQL query planning works, with emphasis on index selection and join strategies. Focus on facts that would be surprising or useful to a mid-level developer.
Step 2: Outline (uses output from Step 1)
Here are 8 facts about PostgreSQL query planning:
[output from step 1]
Create a logical outline for a 1,500-word blog post targeted at mid-level developers. The post should explain query planning in a way that helps them write faster queries. Use these facts as the backbone. Structure: intro (hook + thesis), 4-5 body sections, conclusion with actionable takeaway.
Step 3: Draft (uses output from Step 2)
Write the full draft of this blog post using the following outline:
[output from step 2]
Writing guidelines: concrete examples over abstract explanations, no passive voice, no "leverage" or "utilize," technical but readable by someone who knows SQL but not internals.
Step 4: Critique (uses output from Step 3)
You are a skeptical technical editor. Review this draft and identify:
1. Claims that need more evidence or examples
2. Sections where the explanation jumps too fast
3. Any technical inaccuracies
4. The weakest section (and why)
Draft:
[output from step 3]
Step 5: Revise (uses outputs from Steps 3 and 4)
Revise the following draft to address these specific critiques:
[critiques from step 4]
Original draft:
[output from step 3]
Make only the changes needed to address the critiques. Do not restructure sections that were not criticized.
Each step is narrow. Each produces output that the next step can use directly. The critique step catches errors before they reach the final output.
Pattern 2: Parallel Chaining
Multiple independent prompts run simultaneously, and their outputs are merged.
Example: competitive analysis
Run these three prompts simultaneously (in parallel API calls):
Prompt A: "Analyze Linear's pricing page. What tiers do they offer, what is included in each, and what is the value proposition for each tier?"
Prompt B: "Analyze Jira's pricing page. Same question."
Prompt C: "Analyze Asana's pricing page. Same question."
Then merge step: "Here are pricing analyses for three project management tools: [A], [B], [C]. Write a comparison table and a 200-word summary of how each positions itself by price tier."
Parallel chains are faster (the three analysis calls run concurrently) and produce better results because each analysis prompt can focus entirely on one tool.
Pattern 3: Conditional Chaining
The next prompt is chosen based on the output of the previous one.
Example: customer support routing
Step 1 (classification):
Classify this customer message into one of three categories: BILLING, TECHNICAL, or GENERAL.
Message: "I was charged twice for my subscription this month."
Respond with only the category word.
Output: "BILLING"
Step 2 (conditional on classification):
- If BILLING: use the billing specialist prompt with account information
- If TECHNICAL: use the technical support prompt with system status
- If GENERAL: use the general support prompt
The router step is cheap (a single classification call), and it allows each downstream prompt to be specialized. A billing specialist prompt can include billing system context that would be irrelevant for technical support calls.
Pattern 4: Iterative Refinement
The same prompt (or a critique-and-improve pair) runs repeatedly until a quality threshold is met.
Example: improving a function signature
Iteration 1: "Write a TypeScript function signature for a function that fetches user data with optional filters."
Review step: "Does this function signature handle pagination, error states, and optional fields cleanly? If not, list specific improvements."
Iteration 2: "Improve this function signature based on this feedback: [review output]. New signature:"
Repeat until the review step produces no further improvements, or until a maximum of N iterations.
Iterative chains are powerful for creative and quality tasks where "good enough" is hard to specify in advance but easy to recognize through a critique step.
Real Example: Zlyqor AI Task Suggestions
Zlyqor uses a prompt chain to generate project task suggestions from a brief project description:
- Extract intent: Parse the project description to identify the goal, constraints, and domain.
- Generate phases: Given the goal and constraints, generate 3 to 5 project phases with names and descriptions.
- Generate tasks per phase: For each phase, generate 4 to 8 specific tasks with effort estimates.
- Validate and deduplicate: Check for overlapping tasks across phases and resolve conflicts.
- Format output: Structure the final output as a task list in the format expected by the Zlyqor data model.
A single prompt asking for all of this would produce a much less reliable task breakdown. The chain produces consistent, structured output because each step is focused.
When Chaining Is Worth the Complexity
Chaining adds engineering complexity: you have to manage multiple API calls, handle failures at each step, pass data between steps, and debug a multi-step pipeline. This is only worth it when:
The task has natural subtasks with clear interfaces. If you cannot articulate what each step's input and output look like, the chain is not well-defined and will be hard to debug.
Single-prompt results are inconsistent. If the same single prompt produces wildly different quality outputs on different runs, a chain with validation steps can improve consistency.
Steps can be validated or checked independently. One of the benefits of chaining is catching errors early. If you cannot validate the output of an intermediate step, you lose this benefit.
Some steps can run in parallel. Parallel chaining can be faster than a single long prompt if the steps are independent.
When a Single Prompt Is Fine
For most everyday tasks, a single well-engineered prompt is easier to maintain and fast enough. Use a single prompt when:
- The task has a clear quality bar that a good prompt reliably hits
- The task is short enough that the model can hold the full context
- Engineering time is more constrained than output quality
- You are prototyping and want to move fast
Start simple. Add chaining only when you can measure that it improves results.
Tools for Implementing Chains
LangChain Expression Language (LCEL): Declarative chain composition in Python. Good for complex chains with many steps. The overhead is real; for simple 3-step chains, direct API calls are cleaner.
Vercel AI SDK pipeline (TypeScript): Supports streaming chains where the output of one step flows into the next without waiting for full completion.
Raw API calls: For most production chains, calling the API directly gives you the most control and the least magic. A simple loop with a results array is often all you need.
Keep Reading
- Getting Structured Output From LLMs — Chains are most reliable when each step produces structured output that the next step can parse deterministically
- AI Agents Explained: What They Are and How They Actually Work — Agents extend prompt chaining with tool use and loops; understanding chains is the prerequisite
- Prompt Engineering Complete Guide 2026 — Prompt chaining in context of the full landscape of techniques
Pristren builds AI-powered software for teams. Zlyqor is our all-in-one workspace — chat, projects, time tracking, AI meeting summaries, and invoicing — in one tool. Try it free.
