Chaining means splitting a complex task into smaller steps. Each step has its own prompt, and the output of one step becomes the input of the next. The model does one thing per prompt, and it does that one thing better. Chaining also gives you a place to look at the work before it moves on.
How a chain works#
Each step in a chain is a separate model call with a narrow job. You take the output of step 1, put it into the prompt for step 2, and so on until the last step writes the final result.
The biggest gain is visibility. With a single prompt you get only the final output, so you cannot see what went wrong in the middle. With a chain, every step produces something you can check, log and validate before you pass it forward.
An example chain#
Take a task like "read this customer email and write a reply". It mixes three different jobs: finding the facts, confirming they are right, and writing in the right tone. A chain gives each job its own prompt.
- Extract facts. Prompt the model to pull the order number, the problem and the date out of the email, and return them in a fixed shape.
- Validate. Check the facts in your own code, or with a second prompt. Does the order number exist? Is the date plausible? Stop or retry here if not.
- Write the reply. Give the model only the validated facts and the tone you want, and ask for the reply.
Notice that step 3 never sees the raw email. It works from facts you have already checked, which keeps the prompt short and the job simple.
Pros and pitfalls#
Chaining trades simplicity for control, and it is not free. The table shows what you gain and what you pay for.
| Pros | Pitfalls |
|---|---|
| Each prompt is simpler and more focused. | Errors compound: a wrong fact in step 1 carries through steps 2 and 3. |
| You can inspect, log and validate between steps. | Each step is a separate API call, so latency and cost multiply. |
| You can fix or retry one step without redoing the rest. | It is easy to over-engineer a task that one good prompt would handle. |
Errors compound because the model reads its input as given. It has no way to know the extracted fact was wrong, and generation is left to right, so an early mistake shapes everything after it (see Next-token prediction). This is why the check between steps matters.
The cost point is simple arithmetic: three calls cost roughly three calls' worth of tokens, and the user waits for all three in turn. See Cost for how input and output tokens are billed.
When to chain#
Do not reach for a chain by default. Start with one well-written prompt, with clear instructions and good examples.
If a single prompt keeps producing messy output despite that work, that is the signal to split it. Pick the split along natural seams in the task, such as "find", "check", "write".
A chain with no checks only moves one big prompt into three small ones, and adds the cost. Put a validation between steps wherever a wrong output would do harm.
Short line#
Chaining splits a task into prompts that each do one thing, so you can check every step. Use it when one good prompt keeps failing, because errors compound and cost multiplies.
Key takeaways#
- A chain is a series of prompts where each output feeds the next input.
- Each step is simpler, so the model does it better.
- Checking between steps lets you inspect, log and validate before moving on.
- Errors compound, and latency and cost multiply with every extra call.
- Start with one good prompt. Chain only when it keeps giving messy output.