Prompt chaining

Why it matters

One prompt that asks a model to read a document, pull out the facts, decide a category and write a summary does four jobs at once, and when the summary is wrong you cannot tell which job failed. Prompt chaining is the first thing a working engineer does after the demo: cut the task into steps, make each step one model call, and put code between the calls that checks an output before the next step spends money on it. Interviewers ask about it because it separates people who have debugged a model pipeline from people who have prompted one.

The idea

A chain is a fixed sequence of model calls. Step one consumes the input; each later step consumes the previous step's output, perhaps with the original input alongside. The sequence is decided when you write the code, not by the model at run time, which is what makes it a workflow rather than an agent.

Where the gates go

Between any two steps, code runs a gate: a deterministic check on the output of the step just finished. A shape check parses the output against a schema, so the next step never receives malformed input. A content check tests a property the next step depends on: the draft is under 300 words, every glossary term is present. An execution check runs the output: compile the generated code, run its tests, execute the SQL against a read replica. A gate that fails stops the chain early, logs which step failed and with what, and either retries that step once with the error message or routes the item to a fallback. The money saved is every step after the failure; the time saved is the debugging you no longer do.

draft = call(DRAFT_PROMPT, brief)
if len(draft.split()) > 300 or missing_terms(draft, glossary):
    raise GateFailure("draft", draft)            # stop here, log, retry once
translated = call(TRANSLATE_PROMPT, draft)
if missing_terms(translated, glossary.target):
    raise GateFailure("translate", translated)
issues = call(CHECK_PROMPT, draft, translated)   # returns a list; empty passes

Two shapes that recur

Draft, translate, check. Step one writes the text in the source language with the terminology locked in; a gate confirms length and glossary terms. Step two translates; a gate confirms the terms survived in their target-language forms. Step three reads source and translation side by side and lists mismatches; an empty list passes.

Extract, classify, summarise. Step one pulls fields from a document into a schema; the gate is the schema plus semantic checks on the values. Step two classifies from the fields alone, a far easier task than classifying the raw document, with an enum as the gate. Step three summarises for the audience that category implies. Each step is a narrower task with cleaner input, and the gates stop a wrong extraction from becoming a confident wrong summary.

The arithmetic

Take a 1,000-token document and compare one prompt with a three-step chain. The single call reads about 1,200 input tokens with its instructions and writes 600. The chain reads 1,200 for extraction, then roughly 500 for classification over the fields, then 1,500 for a summary that sees document, fields and class: about 3,200 input tokens and perhaps 1,000 output across the three. Call it two and a half times the tokens and, since the steps run in sequence, three times the latency: three calls of two seconds each plus gates measured in milliseconds, six seconds against two. In return: accuracy you can measure per step, a log that names the failing step, and prompts you can change and evaluate alone.

When one prompt is better

A chain earns its cost when the task has stages with different skills, when an intermediate output is worth checking, or when a cheap early step can reject most inputs. It loses when the steps share so much context that passing it along costs more than doing the work once, when latency has a hard ceiling, or when the task is small enough that a capable model does it in one pass with no measurable error. A chain with no gates is just a slower prompt.

Trade-offs

Latency adds up; a chain is never faster than its steps in sequence. Every boundary is a place to lose information: a summary step that sees only the extracted fields cannot mention what the extraction missed, so decide per step whether the original input travels along. Gates are code to maintain, and a gate too strict rejects good output as readily as one too loose admits bad. Chains also tempt over-engineering: five steps for a task one call does well. Measure the single prompt first, then chain where the measurement says the errors are.

In an interview

Lead with the gates: "I split the task into fixed steps, one model call each, and put deterministic checks between them that fail early, so a bad extraction never becomes a confident summary and I know which step broke." At junior depth, name the pattern and say why the gates matter. At mid depth, design the steps and gates for a given task and give the latency and cost arithmetic. At senior depth, say when a single prompt or an agent would be better, how you measured the gain per step, and how a failed gate is retried or routed. Expect "Why not one prompt?" and "What does the chain cost?"