Prompt Chaining Use Cases: Document Processing, Code Review, and Multi-Step Research Pipelines

You hand Claude a 40-page contract and ask it to extract clauses, classify risk, and produce a legal summary — all in one prompt. You get a result. Run it again and get a different one. Third run contradicts the first two on page 22. The model isn’t confused. The task is.

Prompt Chaining splits that task into stages. Each stage does one thing, passes its output forward, and can be validated at every transition.

Before You Start

You’ll need:

• API access to any LLM with structured output support (Claude, GPT, Gemini)
• Familiarity with Pydantic AI or a similar schema-validation library for step contracts
• A task that either fails or produces inconsistent output when run as a single prompt

This guide teaches you: how to decompose a multi-step task into a specifiable chain, define contracts between stages, and validate at every gate — demonstrated through three production patterns: document processing, code review, and research pipelines.

When One Prompt Isn’t a Spec

Developer pastes a 40-page supplier contract into the context window. Prompt: “Extract all liability clauses, flag anything over $50K exposure, and give me a JSON summary for the legal team.”

The model tries to do all three at once. Extraction and classification share the same attention budget. A clause on page 22 is both a liability cap and a force majeure provision — the model picks one reading. The JSON schema it invents doesn’t match what the downstream system expects.

It worked on Tuesday. Wednesday’s 45-page version broke the extraction. Thursday’s produced a different structure entirely.

Step 1: Map the Pipeline Stages

Before you write a single prompt, decompose your task into stages. Each stage owns exactly one transformation. More than that and you’re back to the one-big-prompt problem.

Here’s what this looks like across the three use cases:

Document processing pipeline:

• Stage 1: Extract — pull raw content (clauses, entities, numbers) verbatim from the document
• Stage 2: Classify — categorize each extracted item by type and risk level
• Stage 3: Score — apply your threshold logic (flag items meeting specific criteria)
• Stage 4: Structure — output a validated JSON report for the downstream system

Code review pipeline:

• Stage 1: Parse — extract functions, classes, diffs, and dependencies from the code
• Stage 2: Analyze — evaluate each unit for correctness, style, and Refactoring candidates
• Stage 3: Prioritize — rank findings by severity and confidence
• Stage 4: Report — format findings as comments, JSON, or inline annotations

Research report pipeline:

• Stage 1: Decompose — break the research question into sub-questions
• Stage 2: Retrieve — gather and summarize sources per sub-question
• Stage 3: Synthesize — combine sub-answers into a coherent draft
• Stage 4: Validate — check the draft for internal contradictions and missing evidence

The Architect’s Rule: If you can’t name what each stage produces and what the next stage consumes, the pipeline isn’t defined yet. Stage boundaries aren’t cosmetic. They’re where you catch errors before they compound.

Step 2: Define the Step Contracts

Each stage needs a contract. Not a description — a contract. The difference: a contract specifies what the stage receives, what it returns, and what it must not do.

Contract checklist for every stage:

• Input schema: what the stage receives (field names, types, constraints)
• Output schema: what the stage produces (field names, types, required vs. optional)
• Failure mode: what invalid input looks like and how the stage should respond
• Hard constraints: what the stage must NOT do (e.g., “do not summarize, only extract verbatim”)
• Token budget: how much reasoning context this stage actually needs

That last item gets skipped constantly. It matters. An extraction stage doesn’t need chain-of-thought reasoning — it needs to scan and copy. A risk analysis stage does. Assign thinking budget where it changes the output quality. Don’t give it to stages that don’t need it.

Gate checks between stages:

A gate check is a validation step that runs after each stage before the output becomes input to the next. Anthropic’s documentation on chain prompts describes this pattern: inspect intermediate outputs, verify they meet your criteria, and branch or retry when they don’t (Anthropic Docs).

Gate checks can be:

• Programmatic — a JSON schema validator, a word count check, a regex match
• Model-based — a second prompt that reviews the first stage’s output against a rubric
• Hybrid — validate structure programmatically, validate content with a fast model

For document processing: after extraction, verify that every expected field is present and non-null before classification runs. A missing clause_type at extraction becomes an unclassifiable entry downstream.

Step 3: Sequence the Build

Build in dependency order. Start with the simplest stage that has no upstream inputs.

Build order:

1. Extraction stage first — no dependencies, simplest transformation, validates your assumption about document structure
2. Classification stage second — depends on extraction output; build the classifier against real extracted data, not mock data
3. Analysis/scoring stage third — your threshold logic and ranking can only be tested against real classified data
4. Reporting stage last — integrates everything; only makes sense once upstream stages are stable

For each stage, write your implementation brief like a function signature:

STAGE: Extract liability clauses
INPUT: Raw document text (string, max 50K tokens)
OUTPUT: JSON array of { clause_id, page, text, category }
CONSTRAINT: Do not classify. Do not summarize. Extract verbatim text only.
ERROR: If no clauses found, return empty array with reason: "no_clauses_found"

That’s the spec. Hand it to Claude, Cursor, or a PydanticAI agent — your context is already defined.

On model assignment:

Extraction is pattern-matching. Claude Haiku 4.5 handles it at $1 input / $5 output per million tokens (Anthropic Docs). Classification and analysis need judgment. Claude Sonnet 4.6 runs at $3/$15 per million tokens and covers most reasoning stages well. Reserve Claude Opus 4.8 ($5/$25 per million tokens) for synthesis or risk-scoring steps where reasoning quality directly affects the result.

This isn’t cost optimization. It’s a specification decision: you’re stating which stages require what level of reasoning, and making that explicit rather than letting the pipeline inherit an expensive model for tasks that don’t warrant it.

Step 4: Validate at Every Gate

This is where chaining earns its overhead. Chained implementations consistently outperformed monolithic stepwise prompts in controlled summarization studies, and chain-of-thought chaining produced double-digit accuracy improvements on mathematical benchmarks including GSM8K and SVAMP (Maxim AI).

The reason: errors caught at the gate don’t compound. An extraction stage that returns a malformed clause object fails at gate 1. In a single-prompt pipeline, that same error propagates through classification, scoring, and reporting before you see it.

Validation checklist per stage:

• After extraction: Check field completeness and type. Failure looks like: null clause_id, missing page number, text that’s a summary rather than verbatim content.
• After classification: Check that every extracted item has a valid category. Failure looks like: category: null, or category: "other" on a significant share of items — a signal the classifier prompt is underspecified.
• After scoring/analysis: Check that threshold logic applied. Failure looks like: high-exposure items not flagged, contradictory risk ratings on the same clause.
• After reporting: Check schema compliance against your downstream system. Failure looks like: extra fields the system rejects, missing required fields, wrong date format.

When a gate check fails, you have three options:

1. Retry the stage with more context or a stronger model
2. Branch to a fallback pipeline (human review queue for that document)
3. Fail loud — stop the pipeline with a detailed error that names what stage failed and why

Option 3 is the most underused. A pipeline that fails loudly at stage 2 is more useful than one that delivers a subtly wrong report at stage 4.

Common Pitfalls

Pro Tip

Write the gate check prompt before you write the stage prompt. If you can’t describe what valid output looks like clearly enough to give it to a model as a rubric, you don’t know your output contract yet. The gate check forces that clarity. That’s not overhead — it’s the specification work that was always required.

Frequently Asked Questions

Q: How to use prompt chaining for automated document summarization and data extraction? A: Separate extraction from summarization at the pipeline level. Run extraction first with a strict output schema — verbatim text, field-by-field, no summarizing. Then pass the extracted data to a summarization stage that operates on clean fields, not raw document text. For large documents, chunk extraction by section before aggregating.

Q: How to use prompt chaining for multi-step code review and refactoring automation? A: Gate on confidence, not just completion. After analysis, filter findings below a confidence threshold — high-severity, low-confidence results route to human review rather than automation. For refactoring specifically, add a final stage that verifies the proposed change against the original function signature before surfacing the suggestion. The extra stage catches changes that are structurally valid but semantically wrong.

Q: How to build a multi-step research report pipeline with prompt chaining? A: Decompose the research question into sub-questions in stage 1. Parallelize retrieval and summarization per sub-question in stage 2 — these steps are independent. Run synthesis in stage 3 with all sub-summaries as input. Add a contradiction-detection gate after synthesis: the step most pipelines skip, where compound errors surface in the final report.

Q: When does prompt chaining outperform a single large-context LLM call? A: Chaining wins when stage 2 correctness depends on stage 1 being right. Single large-context calls work well for single transformations — translate, reformat, summarize. They struggle with competing concerns, intermediate validation, or multi-tier model requirements. If you need to inspect and branch on intermediate state, chain it (Anthropic Docs).

Your Spec Artifact

By the end of this guide, you should have:

• A stage map: N stages, each with a name and one transformation it owns
• A contract per stage: input schema, output schema, failure mode, hard constraints, model tier assignment
• A gate check per stage transition: programmatic, model-based, or hybrid — with explicit failure branches (retry, human queue, or fail loud)

Your Implementation Prompt

Copy this into Claude, Cursor, or your AI coding tool. Fill the bracketed values with your specific pipeline requirements.

You are building a multi-step prompt chaining pipeline for [your use case: document processing / code review / research].

The pipeline has [N] stages:

Stage 1: [Name]
- Input: [field names, types, constraints]
- Output: [JSON schema with required fields]
- Constraint: [what this stage must NOT do]
- Model: [Haiku / Sonnet / Opus based on reasoning requirement]

Stage 2: [Name]
- Input: Stage 1 output (exact schema above)
- Output: [JSON schema with required fields]
- Constraint: [what this stage must NOT do]
- Model: [Haiku / Sonnet / Opus]

[Add stages as needed, following the same pattern]

Gate check after each stage:
- Schema validation: [programmatic check — field presence, type, format]
- Content validation: [model-based rubric if structure alone is insufficient]
- Failure branch: [retry with stronger model / route to human queue / fail loud with stage name and error]

Build order: Stage 1 → gate check → Stage 2 → gate check → … → Stage N

For each stage, generate:
1. The system prompt specifying the single transformation and hard constraints
2. The output schema (Pydantic model or JSON schema)
3. The gate check validator (Python schema check or rubric prompt)

Each stage function does one thing. Each gate function validates one schema. Do not combine transformations.

Ship It

You have a decomposition framework for turning any complex multi-step task into a specifiable pipeline. Document processing, code review, multi-step research — the chain structure is the same. The stages change. The contracts change. The gate checks change. The discipline doesn’t.

Deploy safe, Max.

Security & compatibility notes:

• LangChain serialization injection (CVSS 9.3): CVE-2025-68664 affects dumps()/dumpd() in custom serialization workflows on versions below 1.2.5. Current version 1.3.11 is patched. Pin to 1.2.5+ minimum.
• LangChain path traversal (CVSS 7.5): CVE-2026-34070 in the prompt-loading API, fixed in 1.2.5+. Current 1.3.11 is patched (GitHub Advisory, Vucense).
• PydanticAI v2 breaking change: The openai: model prefix now routes to the Responses API. If you’re using Chat Completions, migrate to openai-chat: (PydanticAI changelog).