Prompt chaining: splitting a big task into steps that work

Prompt chaining is splitting one big request into a sequence of smaller ones, where each step takes the last step's output as its input. It works for two reasons. A single prompt that asks the model to read, judge, write and format all at once gets an average of four jobs rather than four good jobs. And when that one prompt produces something wrong, you have no way to tell which part broke, so your only repair is to rewrite the whole thing and hope.

Why one giant prompt underperforms

Consider a prompt that says: read these call notes, work out what the client actually cares about, draft a follow up email in our tone, and list the action items with owners and dates. That is four distinct kinds of work. The model writes its answer in one continuous pass, front to back, with no ability to go back and revise, so whatever it committed to in the opening sentence constrains everything after it. If it started the email warmly, the action list at the bottom inherits that softness and the deadlines come out vague.

Constraints also compete. Every requirement you add to a single prompt slightly dilutes the others, and past a certain number one of them quietly stops being honored. You can watch this happen: add a ninth instruction and the third one goes missing, with nothing in the output to tell you it did. Splitting the work means each call carries three or four constraints instead of twelve.

The debugging argument is the strongest one. With one prompt, a bad email tells you nothing. Was the deadline never pulled out of the notes, or was it pulled out and then buried by the tone instruction? With a chain, you open step one, see that the deadline is missing from the extracted list, and fix exactly that. A chain turns an opaque failure into a located one.

The four moves: extract, transform, format, check

Most useful chains are some arrangement of the same four moves.

• Extract. Pull specific facts out of messy input, verbatim where possible, into a fixed set of fields. This is the only step that touches the raw source, and it is the easiest step to verify because every claim can be traced back.
• Transform. Reason over the extracted facts: classify them, prioritize them, decide what follows. This step sees a clean short list rather than nine hundred words of mess, which is most of why it performs better.
• Format. Turn the result into the shape you need. Keeping this separate matters more than people expect, because a prompt asked to think hard and simultaneously emit strict structure tends to do only one of the two well, as making an AI return the exact format you asked for sets out.
• Check. A separate call that compares the output against the source with a specific checklist. Be honest about its ceiling: a model checking a model shares the same blind spots. It is good at catching omissions and direct contradictions, and poor at catching a statement that is wrong but sounds right.

A worked example: call notes into a client email

Before, as one prompt: "Here are my notes from the Harbor Foods call. Write a follow up email and list the action items." What comes back reads well, mentions two of the five commitments, confidently proposes a next meeting for a date nobody discussed, and assigns half the actions to "the team".

After, as a chain of four calls:

1. Extract. From the notes below, list every commitment anyone made. For each one give the person who committed, exactly what they committed to, and any date stated. Quote the phrase from the notes that supports it. Where no owner or date was stated, write "not stated". Do not infer anything.
2. Human checkpoint. You read twelve short lines in under a minute. You see that the pricing sheet was promised by Mark, not Priya, and you correct it. You also see "not stated" against the launch date, which is right, because nobody said one.
3. Transform. Here is the confirmed list. Sort it into three groups: what we owe them, what they owe us, and open questions with no owner.
4. Draft and check. Write an email to Dana under 150 words confirming what we owe with dates, asking for the two items we need, and naming the one open decision. Use only facts from the list. Then, in a fresh call: compare this draft against the list and report any commitment missing from the email and any statement in the email that is not in the list.

The invented meeting date cannot happen in the second version, because the drafting step never sees the raw notes and has nothing to fill a gap with. That is the real mechanism at work: each step is given less room to improvise. The same structure applies to anything a meeting notes tool hands you, where the summary is plausible prose and the commitments buried in it are the part you actually need to be correct.

The handoff is where chains break

Pass structured data between steps, not the previous answer's prose. It is tempting to paste step one's reply straight into step two, preamble and all, but a chatty answer carries hedges like "it appears that" and "possibly around March", and the next step reads those as content. A field list with values cannot hedge.

Pass only what the next step needs. Carrying the original source through every stage refills the context window you just cleared and reintroduces the noise the extraction step removed. The exception is the check step, which needs the source precisely because its job is comparison.

Fix the shape of the handoff early and keep it stable. When step two always receives the same four fields, you can rewrite step three without touching anything else, swap a cheap model in for the mechanical steps, or rerun one stage after a failure instead of the whole chain. If some steps need examples of what good output looks like, the same principle applies there too, and a couple of worked examples usually stabilizes a step faster than more instructions do.

Where the human belongs

Put the checkpoint where an error is cheapest to spot, which is almost always after extraction rather than after drafting. Reading a list of twelve extracted facts against your memory of the meeting takes under a minute, and a wrong name jumps out. Auditing a polished two hundred word email against nine hundred words of notes takes five minutes, and you will miss things, because fluent writing suppresses suspicion.

The second checkpoint belongs immediately before anything irreversible: sending to a client, publishing, paying, deleting. Between those two points, let the chain run.

When chaining is overkill

Chains cost something real: more calls, more waiting, more billed text, and more places for a small mismatch to break the whole run. They pay for themselves on repetition and on tasks where a mistake is expensive. They do not pay for themselves on a one off request you can read in full and correct yourself, and a well built single prompt handles far more than people assume once it contains the task, context, constraints, format and audience.

The third column is where chaining stops. When you cannot write the steps down in advance because the next one depends on what the last one returns, you are describing an agent rather than a chain, and you trade predictability for flexibility. Most work that people reach for agents to do is a fixed chain wearing a costume.

What to do next

Take the prompt you currently rewrite most often and count the kinds of work it is doing. If the answer is more than two, split it at the seam between reading and writing: one call that extracts facts into fields, one call that produces the output from those fields only. Run both versions on the same input and compare them on the thing that matters, which is usually how many corrections you have to make by hand. Then write the steps down, with a note of what each one expects to receive and return, and keep them where you will find them again rather than in a chat window; a prompt library you will actually reuse is what turns a chain into something a colleague can run. If a single step keeps misbehaving inside the chain, the cause is usually one of the ordinary prompt mistakes, not the chain design.