Prompt Chaining

A print shop produces a product brochure in two languages. A writer drafts the English text, an editor compares it with the product sheet, and only then does a translator receive it. A wrong price found by the editor costs one corrected draft, while the same price found after translation costs a corrected draft and a second translation.

A language model can work the same way. Your code divides a task into fixed steps, and each model call receives the previous step's output. Ordinary code tests that output before the next step begins. This design is called prompt chaining. The sections below show what it gains over one large call, what it costs, and where its tests belong.

The Running Example

An online store turns each new product sheet, which lists the name, the price, and the features, into marketing copy in English and five other languages. No page may contain an invented feature or a wrong price, because a customer can hold the store to what a page says.

How a Chain Works

A prompt chain is a fixed sequence of model calls in which each call processes the output of the one before it, and code can test any output before the next call runs. Anthropic's article on building effective agents names this pattern and states its purpose: "The main goal is to trade off latency for higher accuracy." Latency is the time the whole task takes. The accuracy comes from giving each call an easier job.

Here is the store's chain in pseudocode:

let draft = callModel(WRITER, productSheet)
let problems = checkDraft(draft, productSheet)

if (problems.length > 0) {
  draft = callModel(WRITER, productSheet, problems)   // One retry, with the reasons
  problems = checkDraft(draft, productSheet)
}
if (problems.length > 0) return sendToEditor(draft, problems)

return LANGUAGES.map((language) => callModel(TRANSLATOR, draft, language))

The model never chooses what happens next, so this is a workflow and not an agent. Your code wrote the order, the retry limit, and the exit to an employee, and checkDraft is ordinary code that uses no tokens. Anthropic's article draws this test as a gate, and this course calls it a check, because it is a test inside a workflow.

Notice that the check has three exits: continue, retry with the reasons, or send the draft to an editor. Without the last two, a chain cannot act on a failure.

The Check Between the Steps

A check tests an output against something your code can state exactly. The first test is usually a schema, which is a description of the fields that an output must have and the type of each field. The writer step returns an object rather than free text, so that code can read each field:

{
  "headline": "A Quiet Blender for Small Kitchens",
  "body": "Two speeds and a glass jar that is safe for the dishwasher.",
  "price": 89,
  "features": ["Two speeds", "Glass jar", "Dishwasher safe"]
}

A schema test shows only that the object has the right form. The more useful tests compare its values with the product sheet.

A false sentence in the body passes all four tests, so an employee or a further model call would have to find it. The structured output lesson covers schemas and their limits.

A failed check needs a defined next action. The retry sends the reasons back, because the same input may produce the same mistake. A second failure goes to an employee rather than to a third attempt. Continuing with a warning is acceptable only for a harmless failure, such as a headline 2 characters too long on a page an editor will read anyway.

Where a Check Belongs

Put a check before the point where an output becomes expensive to repeat or to undo. Here that point is translation, where one wrong price becomes five. Translation can also add errors, such as a changed price or a translated brand name. A second code check on each page therefore helps too, although it runs after the translator calls have spent their tokens.

Suppose the store publishes 100 products, a writer call sends 800 tokens, and a translator call sends 700. Suppose also that 5 percent of first drafts have a defect. Each draft gets at most one retry, whose few extra tokens are left out.

In the second row, the check catches 4 of the 5 defective drafts and misses 1. Of the 4 retries, 5 percent, or 0.2, are defective again; the check sends 0.16 to an employee and passes 0.04. Translation therefore receives 1.04 defective drafts, which produce 5.2 wrong pages.

Because the check is code, it adds less than 1 percent to the tokens and removes most or all of the wrong pages. A model call as the check would add a call per product, although the evaluator optimizer lesson shows when such a call is worth its cost.

Notice where the defect stops. The check does not make the writer better, but it limits how many pages one defect can affect.

What the Chain Gains

A chain can raise accuracy for two separate reasons: each call has a smaller job, and each boundary gives code a place to test the work. The second can be calculated, while the first must be measured.

Take one product and one language. Suppose one large call that writes and translates succeeds 80 percent of the time, and each smaller call 95 percent, as in the compounding error lesson.

The second row depends entirely on the supposed 95 percent. At 85 percent per call, two calls with no check succeed about 72 percent of the time (0.85 x 0.85), worse than one large call. A chain with no check therefore has no guaranteed advantage, because it adds a step to the multiplication. These figures compare designs and do not forecast a real system.

What the Chain Costs

Time. Suppose a model call takes 3 seconds and code checks take almost none. One large call takes 3 seconds, and the two-call chain for one language takes 6. With five languages translated one after another, the chain takes 18 seconds (3 + 5 x 3), and a retry adds 3 more. The translations are independent, so they can run at the same time, as the parallelization lesson explains.

Tokens. Suppose the large call sends 1,000 tokens for one language: 500 of instructions and 500 of product sheet. The chain sends 1,500 (800 + 700), which is 50 percent more. That is still far less than an agent, which resends the full history: the workflows vs agents lesson counted 23,400 tokens for 3 agent steps.

Lost information. The translator knows only what your code passes to it. If the sheet says the brand name must never be translated and the writer's output omits that note, the translator cannot follow it. Each step must receive every fact it needs. The store therefore passes the translator a short glossary as well as the draft.

When a Chain Is the Wrong Design

Use one call when the task is small or when nothing can be tested between the steps. A one-sentence product tagline does not need a chain, and a chain with no possible check spends time and tokens for an uncertain gain.

Use ordinary code for any step that has one correct answer. Converting a price into another currency needs no model, and each step given to code removes one uncertain multiplication.

Use an agent only when you cannot write the steps in advance. If the next step depends on what an earlier step found, and the possible sequences are too many to write, no fixed chain can describe the task.

Key Takeaways

• A prompt chain is a fixed sequence of model calls. Your code decides the order and can test any output between calls, trading latency for accuracy.
• Put a check before the point where an output becomes expensive to repeat or undo, such as one draft becoming five translations.
• A check in code uses no tokens, but it catches only what your code can state exactly. A false sentence inside a valid field can pass.
• A chain without a check has no guaranteed advantage, because it only adds a step to the multiplication.
• Each step knows only what your code passes to it, so pass every fact that the step needs.

Every product here follows the same steps, but many real inputs do not. A refund request and a technical question need different instructions and tools, and routing is the pattern that sends each input to the right steps.

Practice Questions

1. A team splits one model call into three calls with no tests between them, and the results become worse. How can adding steps make a task less reliable?

<details><summary>Show answer</summary>

Each added step is another chance to fail, and nothing catches those failures. Splitting helps only if each call becomes easier by enough to offset the extra multiplication. At 85 percent per call, three calls succeed about 61 percent of the time, which can be worse than one call doing all the work.

</details>

2. Using this lesson's inputs, suppose the store translates into 10 languages instead of 5, with no check. How many wrong pages come from the 5 defective drafts?

<details><summary>Show answer</summary>

50 wrong pages. Each defective draft is translated 10 times. More languages raise the value of a check, because each defect it stops would otherwise be repeated more often.

</details>

3. A draft says in its body that a blender has a five-year warranty, which the product sheet does not mention. Every test in checkDraft passes. Why?

<details><summary>Show answer</summary>

The tests read only the structured fields. The feature test compares the features list with the sheet, and the warranty appears only in the free text of body. Catching it requires an employee, a further model call that compares the body with the sheet, or a design that builds the body from the checked list.

</details>

4. Should the check in this chain run before translation, after translation, or both?

<details><summary>Show answer</summary>

Before translation at the least, and after it if the translated pages can be tested. The first check stops a defect from repeating in every language. A second code check can catch errors that translation adds, but it cannot recover the tokens already spent.

</details>