Prompt Chaining

Redaktion ·

What prompt chaining actually is

Prompt chaining just means this: instead of having a language model finish a big task in one call, you split it into several calls in a row. The output of step one becomes the input for step two, that output becomes the input for step three — and so on, until the finished result comes out the other end. Rather than one giant prompt that wants everything at once, you build a small chain of clear, single-purpose steps.

Here’s an example. You want to turn a customer interview into a blog article. With chaining it looks like this — step one pulls the key points out of the transcript, step two arranges them into an outline, step three writes the text along that outline, step four trims and smooths it. Each step is its own LLM call with its own narrow job.

It sounds like more work, and it is. But that split is exactly the point: each call only has to get one thing right, not five at the same time.

Why it often beats a mega-prompt

The obvious alternative is the mega-prompt: a single, long instruction that carries every requirement at once. “Read the transcript, pull the key points, build an outline, write an 800-word article in our voice, with subheadings and a conclusion.” Sometimes it works. But it gets unreliable the moment the task genuinely has several parts.

The reason is simple: when a model gets lots of different instructions at once, it has to split its attention. When each instruction runs on its own, it can give one goal its full focus. In practice that means the mega-prompt happily forgets one of its five requirements, and the single step doesn’t.

There’s a second effect on top. If the model makes a mistake in step two of a six-part mega-prompt, it often builds steps three through six on that mistake — and all you see at the end is the skewed final result, with no idea where it went wrong. In a chain, you can check after each step before moving on. And that’s exactly where it clicks: chaining gives you checkpoints, a mega-prompt gives you only one final product.

Gates: checking before you move on

The real value of a chain isn’t just the split, it’s what you put between the steps. A gate is a check that decides whether a step’s output is good enough to continue — or whether it needs to be corrected, retried, or stopped.

Gates can look very different:

  • Schema check: Did the step return clean JSON with all required fields? If not, it doesn’t move on, it runs again.
  • Rule check without AI: Is the output too long, is a term missing, does it contain a forbidden phrase? Plain code handles that, no model needed.
  • LLM as judge: A separate call rates the previous step’s output (“Does this draft meet the brief? Answer yes/no with a reason”).
  • Human in the loop: Especially when something goes outward at the end — an email, a post, customer communication — a sign-off stage belongs in between.

Gates are what separate a chain from simply stringing calls together. They stop an early mistake from poisoning the whole pipeline, and they make the system debuggable: if something fails, you know immediately which gate caught it.

What you trade for it

Chaining isn’t a free win. Several calls instead of one means more latency — the chain is slower than the single big prompt, because each step waits on the one before it. And it tends to cost more tokens, because intermediate results pass through the model more than once.

Against that sit three solid upsides: higher accuracy, because each step works in focus; easier debugging, because you see every step on its own; and more control, because you can step in at every gate. For simple one-off requests it rarely pays off. For anything that has to run reliably in production and consists of several parts, it almost always does.

In practice that means: not every chain has to be long. Often two or three steps with a single gate in between are enough to turn a shaky mega-prompt into something dependable. If you want to wire up whole pipelines with several models and tools, you quickly land at AI agents and pipeline frameworks — chaining is their simplest building block. How to write the individual steps themselves is covered in the entry on prompting techniques.

FAQ

What is the difference between prompt chaining and a mega-prompt?
A mega-prompt packs all requirements into a single call. With chaining, the task is split into several calls whose outputs build on each other. The mega-prompt is faster and cheaper, the chain is more accurate and easier to control.
When should I use chaining instead of a single prompt?
As soon as the task consists of several independent sub-steps, each of which can fail — such as extract, then structure, then write. For a clear single request without nested logic, one prompt is enough.
What are gates and why do I need them?
A gate is a check between two steps that decides whether an output may continue. It can be a schema check, a code rule, a second LLM call acting as judge, or a human sign-off. Gates stop an early mistake from poisoning the whole chain.
What are the downsides of prompt chaining?
More latency, because each step waits on the previous one, and generally higher token costs, because intermediate results pass through the model more than once. In return you get higher accuracy, easier debugging, and more control.
How long should a prompt chain be?
As short as possible. Often two to three steps with a single gate in between are enough. Length is not a goal in itself — each extra step costs latency and tokens, so use only as many steps as the task truly needs.