Prompt Chaining: How to Build Multi-Step AI Workflows

The problem with one long prompt

The instinctive way to get a big piece of work out of a model is to describe the whole thing in one prompt. Research the topic, outline it, write it, and make it sound good. It seems efficient and it reliably underperforms.

The failure is not a lack of capability. It is that a single prompt asks the model to hold every instruction in working attention at once while producing a long output. Instructions given early compete with instructions given late, and something gets dropped. Usually it is the constraint you cared about most, because constraints are short and the content instructions are long.

There is a second, subtler failure. A single pass gives you no checkpoint. If the model misunderstood the topic in the first paragraph, everything after it is built on that misunderstanding, and you find out at the end when the whole output is wrong. You cannot correct a step you never saw.

What a chain actually is

A prompt chain is an ordered list of prompts where step two receives step one's output. That is the entire idea; its power is in what it enables rather than its complexity.

Each step gets a single, focused instruction, which is the condition under which models perform best. Each step's output is visible, so an error surfaces immediately instead of propagating silently. And each step can be edited independently — if the outlines are consistently weak, you fix the outline prompt without touching the three that work.

In PromptVibe the mechanism is a placeholder: write [PREVIOUS] anywhere in a step and it is replaced at run time with the previous step's output. Ordinary fill-in fields work alongside it — [TOPIC] for a text field, [TONE|formal,casual] for a dropdown, [BRAND:Acme] for a pre-filled default — so a chain becomes a reusable form rather than a one-off.

The canonical example: research, outline, draft, edit

The four-step content chain is worth walking through because the reasoning generalises to almost any chain.

Step one asks only for research: the eight most important points a reader needs about the topic, one sentence of substance each, no introduction and no conclusion. Forbidding the framing matters — left to itself the model writes an essay, and you wanted raw material.

Step two takes those notes and produces an outline: a headline, five sections, and two bullets under each saying what that section must cover. The model is now working from concrete points rather than from its general impression of the topic, which is what makes the outline specific rather than generic.

Step three writes the full piece from the outline, with the tone and length stated here rather than earlier. Step four edits: cut filler and hedging, make every claim specific, vary sentence length, remove anything that adds no information. Separating writing from editing is the single biggest quality gain in the chain, because a model asked to write well and edit ruthlessly in one pass does neither — the same reason human writers separate drafting from revising.

Chains that are worth building

Chaining pays off when a task genuinely has stages with different objectives. If your task is one stage, a chain adds cost and latency for nothing.

• Content: research → outline → draft → edit. The default, and the one most people feel the benefit from immediately.
• Outreach: understand the prospect → choose the single strongest angle → write the email → generate subject lines. Forcing the angle to be chosen explicitly is what stops every email sounding the same.
• Code: plan → implement → review → tests. The review step reads the implementation as a critic rather than an author, which catches things the writing pass will not.
• Analysis: extract the facts → identify the patterns → form conclusions → write the summary. Separating extraction from interpretation is what keeps conclusions traceable to evidence.
• Translation and localisation: translate → check for meaning drift against the original → adapt idioms for the target audience. The middle step is where literal translations get caught.

When not to chain

Chaining has real costs — more model calls, more latency, more places to go wrong — and it is worth being honest about when a single prompt is better.

• Single-stage tasks. Rewriting a paragraph, answering a question, classifying something: one prompt, done.
• Tasks where the stages are not really separable. If step two needs information that only exists inside step one's reasoning rather than its output, splitting them loses that information.
• Very short outputs. The overhead exceeds the benefit when the whole deliverable is three sentences.
• Exploratory work. When you do not yet know what you want, a conversation beats a fixed pipeline — chains are for tasks you understand well enough to have decided the stages.

Designing a chain that holds up

Most chains that disappoint fail for the same handful of reasons. These rules cover them.

• Give each step one job. If a step's instruction contains "and then", it is probably two steps.
• Constrain the intermediate outputs. A research step that returns an essay makes the outline step harder. Say "just the list, no preamble" and mean it.
• Put the format instruction at the end of long steps. It is the last thing the model reads before answering, and that measurably reduces drift.
• Keep the chain short. Three to five steps covers most real workflows. Beyond that, errors compound faster than quality accumulates.
• Do not repeat context the previous step already carried forward. Restating the topic in every step wastes input and can conflict with what actually came through.
• Design step one to work standalone. It receives nothing, so it must be a complete instruction in its own right.

Where chains fail, and what to do about it

Two failure modes account for most disappointing chain runs, and both are fixable once you can name them.

The first is compounding drift. A small misinterpretation in step one is treated as fact by step two and elaborated by step three. By the end you have a polished document about slightly the wrong thing. The fix is to read the first step's output before letting the chain continue — which is why a runner that shows each step as it completes is more useful than one that only returns the final result.

The second is context loss. Step three receives step two's output, not step one's. If a crucial constraint was stated in step one and step two did not carry it forward, it is simply gone. The fix is to restate genuinely load-bearing constraints in the step that needs them, rather than assuming they survive the relay.

Chaining and agents are not the same thing

These get conflated, and the distinction is practical rather than academic.

A chain is a fixed sequence you designed. Step two always follows step one, and it always does the same job. It is predictable, debuggable and cheap to reason about, because the control flow is yours.

An agent decides its own next action, possibly loops, and may call tools. It handles open-ended tasks a fixed sequence cannot, at the cost of predictability and expense — the same task can take two calls or twenty, and diagnosing a bad run means reconstructing the decisions it made.

For a workflow you repeat, a chain is almost always the better tool: you already know the steps, so paying an agent to rediscover them each time buys nothing. Reach for agent-style loops when the path genuinely cannot be known in advance. The related idea of loop engineering — giving a model a repeatable cycle of act, self-evaluate and refine with an explicit stopping condition — sits between the two.

Making a chain reusable

The compounding value of a chain is not the first run, it is the fiftieth. That only happens if the chain is parameterised rather than hardcoded.

The move is replacing the specifics with fields. A chain written for "a blog post about prompt engineering for marketers" is used once. The same chain with [TOPIC] and [AUDIENCE] as fields is a content pipeline you fill in each week. Add a [TONE|practical,conversational,authoritative] dropdown and the same pipeline serves three different publications.

This is also what makes chains shareable inside a team. A well-built chain encodes a process — how your organisation researches, what your outlines must contain, what your editing standard is — in a form someone else can run without absorbing the reasoning behind it first.

A worked chain you can copy

Here is a four-step chain for turning a customer conversation into a product decision brief. It shows the pattern of constrained intermediate outputs feeding forward.

• Step 1 — Extract: "From the customer conversation below, list only the concrete problems the customer described, in their own words where possible. One line each. Do not include solutions, opinions, or your interpretation. Conversation: [CONVERSATION]"
• Step 2 — Classify: "Group the problems below into themes. For each theme give a name, the problems it contains, and a one-sentence statement of the underlying need. Do not propose solutions yet. Problems: [PREVIOUS]"
• Step 3 — Assess: "For each theme below, state what building a solution would require, what evidence we would need before committing, and the strongest argument for doing nothing. Be even-handed — the do-nothing case must be genuinely argued. Themes: [PREVIOUS]"
• Step 4 — Brief: "Write a one-page decision brief for [AUDIENCE] from the assessment below. Structure: the situation, the options, a recommendation, and what would change your mind. Under 500 words. Assessment: [PREVIOUS]"

Using different models for different steps

Once a workflow is split into steps, an option appears that a single prompt never offered: each step can run on a different model.

This matters because steps have genuinely different demands. Extraction and classification are mechanical and high-volume — a small, cheap, fast model handles them well. Judgement, synthesis and final drafting benefit from a stronger model. Running the whole chain on your most capable model means paying premium rates for the step that only had to reformat a list.

The practical pattern is a cheap model for the mechanical steps at either end and a capable one in the middle where the thinking happens. On a chain you run daily, the saving is real; more importantly, the cheap steps are also faster, so the whole chain feels more responsive.

The honest caveat: mixing models adds a variable. If chain quality drops after you switch a step, you now have two candidate causes. Change the model on one step at a time, the same way you would change a prompt.

What to do when a step fails

Chains fail in the middle, and a chain with no answer for that is a chain that wastes the work already done. Three failure modes account for nearly all of it.

• The step returns nothing usable — empty, truncated, or an error from the provider. Retry once; providers have transient failures and a second attempt usually succeeds. If it fails twice, stop rather than passing an empty string forward, because an empty [PREVIOUS] turns the next step into a prompt with a hole in it.
• The step returns the wrong shape — prose where you asked for a list. Usually a prompt problem rather than a model problem: the instruction was not specific enough about format, or it was buried mid-prompt. Restate the format at the end of that step.
• The step returns something plausible but wrong. The hardest case, because nothing errors. This is what makes visible intermediate output non-negotiable: a runner that shows each step as it completes lets you stop the chain at step two instead of reading a polished, wrong document at step four.

The step most people leave out

Almost every chain people build goes straight from input to production: research, then write. The step that most reliably improves the result is the one nobody adds, because it feels like it does not do anything — a step that criticises the previous output before the next step consumes it.

The reason it works is that generation and evaluation are different tasks, and a model asked to do both at once does neither well. This is the same reason the draft-then-edit split improves writing, and it generalises: outline, then critique the outline, then write. Plan, then find the holes in the plan, then implement.

A critique step is cheap to write and easy to get wrong. The failure is asking for feedback in general terms, which produces polite, generic notes that the next step cannot act on. A useful critique step names what to look for and forbids praise.

Something like: "Below is an outline. List only its weaknesses: sections that overlap, claims that will need evidence we do not have, and anything a sceptical reader would object to. Do not summarise the outline back to me and do not say what is good about it. If a section is weak, say what specifically is missing from it."

Then the writing step receives both the outline and the critique, with an instruction to address every point raised. The output is measurably more considered, and the whole addition costs one extra call.

The same pattern has a stronger variant worth knowing: run the critique on a different model from the one that produced the work. A model reviewing its own output tends to defend it; a different model has no such attachment and finds things the author missed.

Cost, latency and when they matter

A four-step chain is four model calls, so it costs roughly four times a single call and takes roughly four times as long. Both numbers deserve a moment of honesty.

On cost, the comparison that matters is not chain-versus-single-prompt. It is chain-versus-the-single-prompt-plus-the-time-you-spend-fixing-its-output. For most real work the model cost is a fraction of a cent either way and your time is the expensive input, which is why the chain usually wins even though it costs more to run.

Latency is the more real constraint. A four-step chain that takes ninety seconds is fine for a task you set running and come back to; it is unusable inside an interface where someone is waiting. If a chain sits in a user-facing flow, either shorten it, run the independent steps concurrently, or show progress as each step completes so the wait is legible rather than blank.

Chains, templates and skills

Three related ideas get muddled, and the distinction is useful when deciding what to build.

A template is one prompt with fill-in fields. It solves repetition within a single step: the same prompt, different inputs. It is the right tool when your task is one stage that you do often.

A chain is several templates in sequence, with output flowing forward. It solves multi-stage work. Any step of a chain is itself a template, which is why the two features belong together — you build the step, prove it works alone, then wire it into a sequence.

An agent skill is a packaged capability: instructions plus context that an assistant loads when a task calls for it. It is closer to a chain than a template, but the assistant decides when to use it rather than you running it deliberately. If you find yourself running the same chain constantly and wishing the assistant just knew how, that is the signal to package it as a skill.

Getting started without overbuilding

The mistake people make when they discover chaining is building a nine-step pipeline for a task that needed two prompts. Start smaller than feels right.

Take a task you already do in several messages — where you paste a model's answer back in and ask it to do the next thing. That copy-pasting is a chain you are already running by hand. Write those messages down as steps and you have your first chain, already validated by the fact you were doing it.

Then improve one step at a time, the same way you would test a single prompt: change one step, run the chain, see whether the final output improved. A chain is a sequence of prompts, so everything true about testing prompts is true about testing chains — one variable at a time, judged against criteria you wrote down first.

Related articles