Pattern Matrix/White Paper/A3

A3 · Prompt Chaining

What problem it solves

A single prompt that tries to do everything at once usually does none of it well. The first version of one financial media outlet's content-editing agent put seven things—proofreading, rewriting, unifying style, fact-checking numbers, generating headlines, writing summaries, and image suggestions—into one prompt fed to the model. The result was that "GMV grew 35%" in an article got changed to 53%: at that moment the model was in "rewrite" mode rather than "fact-check" mode, and it misread the number along the way. The later tasks got increasingly careless, and the image suggestions were always the same three boilerplate lines.

Prompt Chaining breaks a large task into several independent prompts processed in sequence. Each segment does only one thing, has its own role and the model best suited to it, and has its own success criterion. The difference from a single oversized prompt is that complexity can only be brought down by splitting; stuffing it into a bigger box does not bring it down.

Why the coordinate is "Action × Chain"

• Vertical axis · Action: A task one prompt cannot complete is split into several sequential prompts, each of which triggers a model call or tool output. The landing point is "doing" rather than single-point "thinking," so it belongs to the Action module.
• Horizontal axis · Chain: prompt1 → prompt2 → prompt3 is a typical linear pipeline, where the output of one segment is the input of the next. It is neither routing diversion nor graph-shaped dependency. It shares the Chain topology with Plan-Execute (A2); the difference is that A3 is a pure straight line with no replan, while A2 is a DAG with replan.

Core mechanism

Its engineering prototype is the Unix pipe. cat data.csv | grep ERROR | sort | uniq -c strings together several single-responsibility small programs via stdin/stdout. Each program only reads input and writes output, with no need to know who comes before or after. A prompt chain reproduces the same thing at the LLM layer, where each prompt segment is a "small program."

The extra layer beyond the Unix pipe is the gate. A Unix program simply runs empty when it matches nothing, but an LLM will confidently make things up, so a cheap programmatic check goes between two segments—not a model, but a Python if test—and on failure it retries or escalates. If the researcher stage writes "find at least three references," the gate is if len(refs) < 3, and only what passes flows on.

A few points for implementation:

• Each prompt segment uses the five-piece structure: role, task, context, format, constraints, all wrapped in XML tags. The more explicit the contract for the next segment, the lower the parse failure rate, and reliability can be measured improving by roughly 8 to 15 points.
• Each segment selects its model independently: a cheap model handles details in proofreading, a strong model handles creative rewriting, and a medium model with thinking handles number checking. Handing language details to a cheap model keeps total cost only about 30% above the single-prompt version, rather than several times higher from using a strong model at every step.
• Gates need tolerance: writing "exactly 500 words" makes the chain stall forever; write it as a range plus necessary conditions, such as "450 to 550 words" plus "must contain three arguments."
• Retries should feed back the failure reason: tell the model "where it fell short last time" rather than rerunning blindly, and the hit rate goes up.

Claude Code has produced three industrial forms of the chain: in the perceive-reason-act main loop, each tool result is a chain link (the implicit chain); a slash command is a prefabricated chain (/commit is a five-step template of status → diff → reasoning → drafting → commit); and SKILL.md is a composable chain segment (a declarative definition of a multi-step process embedded into a larger chain).

Production scenarios it fits

• The workflow has clear stages, and "what counts as acceptable" between stages can be described in one or two lines of code: content editing, contract review, customer-ticket triage. In production, most teams end up with 3 to 5 steps.
• Productizing the workflow into a reusable entry point: a slash command packages a domain-specific workflow into a prefabricated chain, where the user triggers the whole chain with one command instead of handwriting the steps each time.
• Output that needs to be traceable and trustworthy: archiving the full-chain trace lets the business side trace in reverse how the agent moved step by step from the original draft to the final draft. In the content-editing case, the trace raised editor trust from 42% to 91%, more effective than any prompt engineering.

Where it tends to go wrong

• Information starvation: each step only receives the previous step's output, so information that appeared in step 1 but was not retained in step 2 is lost when step 3 needs it. The chain passes only the previous step's output and does not automatically let early information flow downstream. The remedy is to carry a separate cumulative context object that every step can read (called the saga context in distributed systems).
• Gate tyranny: a gate set too strictly can never pass; "exactly 500 words" rejects 499 and 501 indefinitely, burning through tokens before anyone notices. The remedy is a range plus necessary conditions.
• The multiplicative effect is underestimated: a 95% single-step pass rate, strung across seven steps, leaves the full-chain pass rate at only about 70%. The longer the chain, the higher the requirement on each step's pass rate.
• Assembly of the first prompt is overlooked: a production system prompt is usually assembled from several data sources—base instructions, user identity, history, current task, tool list, style, format constraints—and hardcoding it into one long string makes the most frequently updated part impossible to maintain independently.

Key metrics

• Full-chain success rate (healthy zone >85%): a failure to pass any step's gate counts as a chain failure. Below 70% usually means a step's gate is too strict or information broke between steps. Note that it is measured per chain, not per step.
• Per-step latency p99 (healthy zone: each step's p99 <3× the median): when the chain slows down, this distribution chart finds the lagging step fastest.
• Gate retry distribution (healthy zone: 90% pass on the first try, 9% on the second, 1% on the third): when a step's retry rate suddenly rises, it is almost always a mismatch between the gate and the model's current capability.

Minimal implementation skeleton

chain = [step1, step2, step3]        # each step carries its own system_prompt + model + gate
            current = initial_input
            for step in chain:
                for attempt in range(max_retry + 1):
                    result = step.run(current)   # call the corresponding model
                    if result passes the gate:
                        current = result.output
                        break
                    elif retries remain:
                        current += "[did not meet standard: reason. retry]"   # feed back the failure reason
                    else:
                        return failure(step, trace)
            return success(current, total_tokens, trace)
            

Engineering points for implementation: gates carry tolerance; the trace's tokens and latency are written structured into the logging system; when needed mid-chain, actively retrieve the original input for reference (for example, number checking returns to the original draft so that versions produced by upstream rewriting do not contaminate the numbers).

Enterprise implementation example

The second version of the financial media content-editing agent was rebuilt into a seven-step chain: proofreading (cheap model, gate verifies that output length is no less than 95% of input), rewriting (strong model, preserves author style), style unification, number checking (medium model with thinking; the key design is returning to the original draft for reference, with the gate requiring numbers to match the original draft 100%), headline generation (outputs 3 candidates), summary writing, and image suggestions (all three categories required). Each step selects its model independently to control cost. The results: number-checking accuracy rose from 87% to 99.4%, editor trust rose from 42% to 91%, at the cost of per-article cost rising about 30% and latency rising from 12 seconds to 38 seconds. This template transfers directly to contract review, medical imaging assistance, and customer-service triage—each step with its own goal, its own model, its own gate.

Relationship to other patterns

• Plan-Execute (A2): a dual pair, one light and one heavy. A3 is a straight line, A2 is a graph. If the task can be drawn as a DAG (with parallelism and cross-step dependencies), use A2; if it is a straight line, use A3. A common hybrid form in production is A2 on the outside, A3 on the inside.
• Tool Dispatch (A1): a nesting relationship rather than a substitution. A step inside a chain may call a tool, and that step is A1 (choosing one among several tools), but it happens within one link of the chain.
• Guardrail Sandwich (A5): a chain's gate is a synchronous programmatic check, while A5's hook is a sandwich layer wrapped around tool calls before and after. Both make "the process interceptable at checkpoints."

What this pattern teaches

As long as your system holds a multi-turn conversation with an LLM, you are already using a prompt chain; the only difference is whether it is explicit or implicit. With an explicit chain you can assign a model to each segment, add gates, keep a trace, and replay failed steps; with an implicit chain you can only pray the model does not crash this time.

This page is part of the ADPS pattern white papers. Back to the pattern matrix, or see the runnable code catalog.