Chaining prompts

Complex tasks are often better handled as a sequence of focused prompts than as one prompt doing everything. That sequence is a prompt chain: each prompt takes an input, produces an output, and that output becomes the next prompt’s input.

The concept is straightforward, but execution takes care, because chains introduce a failure mode single prompts do not have.

In a prompt chain, the output of each step becomes the input to the next. A mistake in an early step propagates forward and compounds.

The basic structure of a chain

A prompt chain has three parts: the prompts themselves, the outputs they produce, and the handoff between them.

Step 1 prompt  →  Step 1 output
                        ↓
Step 2 prompt + Step 1 output  →  Step 2 output
                                        ↓
Step 3 prompt + Step 2 output  →  Final output

The handoff is where most of the engineering happens. At each step, you embed the previous output into the next prompt as the context the instruction applies to. The next prompt does not need to know how that output was produced, only that it is in the right format.

This is why output format matters more in a chain than in a standalone prompt. The cleaner step one’s output, the easier it is for step two to work with.

Error propagation: the main risk of chaining

A single-prompt failure is contained: you get a bad output, revise, run it again. In a chain, an early failure is passed forward as though correct. The next step works with bad input and produces output that is wrong but not obviously so, because it looks structurally correct while built on a flawed foundation.

This is error propagation, the main risk of chaining. The longer the chain, the more opportunities for an early error to compound into a final output that is hard to trace.

Defending against error propagation

Treat each step’s output as something to be checked, not passed forward automatically.

This means two things. First, design each step so its output is easy to inspect. A structured list is easier to verify than a paragraph. If you can see at a glance whether step one did its job, you catch errors before they propagate.

Second, insert explicit validation steps where the stakes are high. A validation step checks the previous output against criteria and flags problems before the chain continues.

Validation prompt: Here is the output from the previous step.
                   Check whether it meets the following criteria:
                   [criteria list]
                   If it does not, describe what is wrong.
                   If it does, respond with "PASS".

This adds a step whose job is to catch exactly the errors that would otherwise compound.

Keeping handoffs clean

A few habits make chains more reliable:

Ask for structured outputs at each step. A numbered list, a JSON object, a table: anything with unambiguous structure the next prompt can reference. Prose is harder to parse and more likely to carry ambiguity forward.

Be explicit about where the input came from. Add a label: “Here is the list of complaints extracted in the previous step.” This keeps the model oriented and reduces misinterpretation.

Keep each step’s scope narrow. A step that does too much produces output that is harder to verify and harder for the next step to use. The decomposition principles from the previous lesson apply to individual steps as much as the overall task.

When chaining is not the right tool

Chaining adds complexity. It works well for linear, well-defined tasks. For exploratory tasks, where you do not know in advance what intermediate outputs will look like, a chain can become brittle. If step two assumes step one produces a list, but step one sometimes produces a paragraph, the chain breaks.

In those cases, a more flexible approach fits better: having a human or model review each step before deciding the next. That pattern is the foundation of what gets called an agent, a topic for a different course.

In the next lesson, we’ll move to Chapter 6 and chain-of-thought prompting, where the model decomposes its own reasoning rather than you decomposing the task.