Prompt Chaining

Prompt chaining splits a job into a listed sequence of model calls, where each call reads the last call's output and your code, not the model, chooses the next hop. A check between hops can drop a bad intermediate result before it becomes the next prompt. That design is a workflow, unlike an AI agent, which would pick the next hop from what it just saw.

We have not sold a build under the name prompt chaining, and most of what we have built is a workflow in the sense of our agentic workflows guide. A person can write the steps, and a model fills some of them. Prompt chaining is that shape when several of those steps are model calls whose output feeds the next.

What is prompt chaining?#

The join lives in your code: each hop is its own prompt, with its own job, and hop two sees hop one's output only because you passed it. A hop that fails a programmatic check never becomes that input.

Do not mix this with chain-of-thought, which is one call asked to write its reasoning before the answer, because prompt chaining is several calls. The reasoning of hop one is useful only if hop two is supposed to read it, and even then a field on a schema beats a paragraph.

Anthropic's Building effective agents post, checked 10 November 2026, still lists prompt chaining as the first of five workflow patterns. Those patterns are chaining, routing, parallel calls, orchestrator-workers, and evaluator-optimizer. Code owns the path in all of them except orchestrator-workers, where a lead model chooses the subtasks.

OpenAI's cookbook describes the same mechanism as a multi-step prompt, generating text, feeding it into the next prompt, and optionally branching or re-running when a check fails.

A chain is the right shape when someone who knows the job can list the hops before the first call runs. Typical hops are outline then check then write, extract then draft then translate, or classify then retrieve then answer. Each hop is a smaller job than the original, so you pay extra latency and you get a place to stop.

How prompt chaining works#

Walk one request through a three-hop chain. The first call does one subtask and returns a result, preferably as structured output, so the next prompt reads fields rather than prose. Code then runs a gate: a schema check, a rule, a lookup against a store you trust. If the gate fails, the hop retries from the same inputs, or the run stops. If it passes, the second call sees only what the gate let through.

The gate is why a chain can be safer than stuffing the whole job into one prompt. A single prompt that is right 95 percent of the time still fails one call in twenty, and you only find out at the end. A chain that checks after each hop can throw away a bad outline before it writes a document from it.

Without a gate, error compounds the same way it does in an agent loop. Our AI agent page already runs the arithmetic. At 95 percent reliability per step, a 5-step run finishes clean about 77 percent of the time, a 10-step run about 60 percent, and a 20-step run 36 percent. A 20-hop chain with no check between hops is the same product. The length of the chain is a reliability choice, not a wording choice.

Tool calling can sit inside a hop, as long as the hop after it is still the one you named. The model may look something up, but it does not get to pick hop three.

On the trademark drafting system, the path is already this shape even when only one hop is a model. The matter is normalised, authorities are retrieved, a draft is written into a five-section schema, validators check structure and citations, and a failed check retries only from retrieved evidence. The attorney never sees a draft that skipped the gate. We did not call that prompt chaining. It is the gate we would put between hops if the draft itself were split into two model calls.

Prompt chaining vs a single prompt#

A single prompt asks one call to do the whole job: extract, reason, format, and stay inside the rules, and that is the right starting point. We already tell buyers to start with the simplest design that works, one well-built prompt, then retrieval or a fixed workflow, and to accept an open loop only when those fall short.

Split the job when you can name the subtasks and you have a check for the intermediate. The extra calls cost latency and tokens, and they buy a smaller task per call, a place to stop, and a trace that shows which hop broke.

They also buy a new failure: hop two faithfully writes from hop one's mistake. A fluent second hop is not a proof that hop one was right, so put the check in code. Prompt engineering still matters inside each hop, because a chain of vague prompts is only a slower single prompt.

Pass structured output between hops so the next prompt does not have to parse a paragraph. A schema-valid object can still hold a wrong value, so the gate after the parse is a business rule, not only a JSON check. That is the same split we already use wherever code consumes a model result.

Prompt chaining vs agents and agentic workflows#

Prompt chaining, plan-and-execute, and the ReAct pattern get grouped as agentic on ranking pages, but they are not the same design.

In a chain, you listed the hops. In ReAct, the model writes a thought, calls a tool, reads the observation, and chooses the next action from it. In plan-and-execute, a planner writes the whole step list once, an executor runs it, and the planner returns only when a result breaks the plan. The planner can invent the list, and a chain cannot, because the list already exists in code.

Vendors use "agentic workflow" for both a scripted path with model calls in it and a loop where the model picks the next step. We keep those as workflow and agent, and the agentic workflows guide is the longer version of that split, so review prompt chaining as a workflow.

Build the chain when a person can write the hops, including retries that always repeat the same call. Build an agent when the next tool depends on a result you could not list before the run. Most document and reconciliation systems we have built are fixed pipelines. The chief-of-staff agent needed a loop, because it works across more than a hundred systems and each step reads what the last one returned before choosing the next.

On the fund reconciliation system there is no model on the path at all. The matching rules are explicit and versioned in code. That is still the workflow habit a chain should keep: the order lives where you can read it, not in the model's next sentence.

When the next hop cannot be listed#

Skip the chain while a single well-built prompt still holds, with retrieval if the failure is a missing fact. Add hops only when you can name them and check them.

Skip it the other way too. If you cannot point at the case where the next hop has to be chosen from a result you have not seen yet, you do not have an agent problem. You have a chain you have not written down. The graph engineering fork is the same advice in another vocabulary: if a person can write the steps, write them.

A chain with no gate is a slower single prompt that fails later. A chain whose hops you cannot list is an agent under a workflow's name. Put the order in code, put a check between hops, and only then spend the extra calls.