Pattern Matrix/White Paper/A3

Problem

A single prompt that handles proofreading, rewriting, style, number checking, headlines, summaries, and image suggestions makes several constraints compete for attention. A rewrite step may alter a figure from the source, and later steps then propagate the error.

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.

Classification: 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.

Solution and mechanics

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 programmatic check sits between stages and retries or escalates on failure. In a research chain, for example, the gate can validate topic coverage, source type, and traceability against project policy before allowing the next stage to run.

A few points for implementation:

• Each prompt segment uses an explicit contract: role, task, context, format, and constraints can be represented with structured tags so the next step can validate the output.
• Each segment selects its model independently: Proofreading, creative rewriting, and number checking may use different models and tools. Choose each model from step-level evaluation and calculate the whole-chain cost from replay.
• Gates need tolerance: do not require an exact word count when the business accepts a range. Express content requirements separately from length tolerance.
• 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).

Applicability

• The workflow has clear stages, and acceptance between stages can be expressed with deterministic checks or a concise rubric: content editing, contract review, and customer-ticket triage.
• 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: A full-chain trace lets reviewers move backward from the final draft through each input, output, gate result, and human change.

Known failure modes

• Information starvation: information needed downstream can disappear during an intermediate handoff. Carry a separate cumulative context object that every step can read, similar to a saga context.
• Gate tyranny: brittle exact-value conditions can reject usable results indefinitely. Use business tolerances and explicit necessary conditions.
• The multiplicative effect is underestimated: When every step has a failure probability, adding steps lowers full-chain success. Use local step-level results to calculate chain risk and remove unnecessary links.
• 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.

Verification and metrics

• Full-chain success rate: Failure at any gate counts as a chain failure. Inspect whether failures concentrate in model output, data transfer, or gate rules.
• Per-step latency distribution: Compare the median and tail for each step to locate a slow model, tool, or external dependency.
• Gate retry distribution: A sudden increase at one step calls for inspection of input drift, model changes, and gate criteria.

Reference implementation

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).

Illustrative scenario

Consider a financial-media editing Agent that separates proofreading, rewriting, style normalization, number checking, headline generation, summarization, and image suggestions. Number checking returns to the original draft or an authoritative data source rather than trusting the rewritten text. Each step has its own schema, model choice, and gate, and the trace records where a figure was read, checked, or changed. The same structure can support contract review, medical assistance, or customer-service triage, but each domain needs its own gates.

Related 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 (A4): a chain's gate is a synchronous programmatic check, while A4's hook is a sandwich layer wrapped around tool calls before and after. Both make "the process interceptable at checkpoints."

Design conclusion

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.