Production AI Series

AI Workflow Patterns Cookbook [2026] Edition

64 practical recipes with a reference library of 109 production AI workflow patterns.

Purnendu Das

64 Recipes 109 Patterns Asset Pack

Reader Edition

Copyright and Review Notice

AI Workflow Patterns Cookbook [2026] Edition is a practical field guide for building reliable production AI workflows.

Working TitleAI Workflow Patterns Cookbook [2026] Edition: 100 Production-Ready Patterns for Building Reliable AI Systems.

AuthorPurnendu Das. Public profile: linkedin.com/in/das-purnendu.

Code and architecture examples are illustrative. Production systems should be reviewed for security, compliance, privacy, and business policy before deployment.

Preface

From Prompts to Production Workflows

This book is for builders who have moved past AI demos and now need systems that survive real documents, real users, real mistakes, and real deadlines.

Most AI projects start with a prompt. Production systems do not end there. They need input adapters, OCR or vision models, classifiers, schemas, validation rules, review queues, retries, audit logs, cost controls, and monitoring.

The goal of this cookbook is practical: give you reusable patterns for reliable AI automation in document-heavy business systems. The stack matters less than the discipline: constrain the model, validate every output, log the evidence, and give humans a clean path to review what matters.

Use workflows when steps are known. Use agents when steps are dynamic. Use rules when correctness is mandatory. Use human review when impact is high.

Author

About Purnendu Das

Purnendu Das is a GenAI engineer focused on building production-ready AI systems that solve real business workflow problems.

His work centers on RAG architectures, LangChain and LangGraph workflows, multi-agent systems, LLMOps, document intelligence, and enterprise AI orchestration. This cookbook reflects that practical bias: start with a real workflow, constrain the model, validate the output, keep humans in the loop where risk demands it, and measure what happens after deployment.

Practitioner FocusProduction GenAI systems, RAG, agents, workflow orchestration, evaluation, and document-heavy enterprise automation.

Public Profilelinkedin.com/in/das-purnendu

Contents

Reader Guide

How to Use This Book

This cookbook is designed for scanning first and deep reading second. Start with the path that matches your current project, then use each recipe as a production design checklist.

Document Automation PathRead Chapters 5-13 first. Focus on intake, classification, OCR or vision extraction, structured output, confidence, missing fields, validation, review, and semantic repair.

Agentic Workflow PathRead Chapters 17-19, then the advanced durable execution patterns. Focus on routing, tool authorization, human gates, checkpoints, replay, and interrupt-and-resume.

Production Reliability PathRead Chapters 20-25. Focus on prompt versioning, evaluation, cost, latency, PII, audit logging, deployment, rollback, and operational dashboards.

2026 Architecture PathRead the Advanced Patterns section. Focus on structured outputs, long context, RAG, reasoning models, local SLM routing, programmatic prompt optimization, gateways, and drift detection.

How Each Recipe Is Meant to Work

ScanRead the pattern card, flow, and checklist first. You should know in one minute whether the pattern belongs in your system.

ImplementUse the schema, pseudocode, or prompt as a starting point. Replace domain terms with your internal objects and rules.

ValidateBefore production, ask what can fail, how it is logged, when a human reviews it, and how the workflow rolls back.

Decision Lens

CostCan a rule, cache, local model, or smaller model handle this before a frontier model is called?

QualityDoes every accepted output have schema validity, business validity, source evidence, and evaluation coverage?

ControlCan the workflow pause, retry, recover, audit, and explain itself when the model is wrong?

Part I

The Workflow-First Mindset

Before recipes, we need a shared operating model. Reliable AI is not one model call. It is a chain of constrained decisions, evidence capture, validation, and recovery.

Mindset

Why AI Workflows Fail in Production

Traditional automation fails when the rules are incomplete. AI automation fails when uncertainty is hidden.

Use This ForShifting teams from prompt demos to controlled production workflows.

DeliverableA shared mental model for uncertainty, validation, review, and monitoring.

Watch ForAny place where model output becomes business data without validation.

An LLM is useful because it can reason through messy language, incomplete context, and varied formats. Those same properties make it unsafe to treat as a deterministic function. It may omit fields, infer values that were never present, return malformed JSON, classify the same document differently after a small wording change, or produce a fluent explanation for a wrong answer.

The production mistake is not using AI. The mistake is building as if the AI step were always correct. A reliable workflow assumes the model is powerful but fallible. It surrounds the model with constraints, validation, logging, and review.

Input→Preprocess→Classify→Extract→Validate→Review→Decide→Store→Monitor

Production control loop: AI is one decision inside a controlled system. Validation decides whether the workflow accepts the result or routes it through recovery.

Common Production Failure Modes

Output ShapeInvalid JSON, missing keys, unexpected enum values, extra commentary, truncated responses.

Business MeaningWrong classification, copied wrong total, failed to notice contradiction, mixed two entities.

OperationsOCR latency, rate limits, retry storms, duplicate jobs, expensive prompts, weak audit trails.

Production rule: Never let a model response become a business decision until it has passed schema validation, business validation, and risk-based review routing.

The Shift

Move from prompt-first thinking to workflow-first thinking. Prompt-first thinking asks, "How do I get the model to answer?" Workflow-first thinking asks, "How do I turn uncertain model output into a controlled business process?"

Every output has a schema.
Every critical field has evidence.
Every validation failure has a next action.
Every retry has a reason and limit.
Every human correction feeds evaluation.
Every production run is traceable.

Architecture

Anatomy of a Reliable AI Workflow

A reliable workflow is a pipeline of small, observable decisions rather than one large magical call.

Use This ForDesigning the first reliable version of an AI workflow.

DeliverableA layered workflow with input, AI decision, validation, recovery, review, and observability.

Watch ForLarge model calls that hide several responsibilities inside one step.

A production AI workflow usually has seven layers. Some systems combine them in one service. Others separate them across queues and workers. The design choice depends on throughput, latency, cost, and compliance needs. The layers stay the same.

Layer	Purpose	Example Output
Input	Accept files, emails, API payloads, or events.	Document received, attachment list, metadata.
Preprocess	Clean, split, OCR, chunk, and normalize content.	Text blocks, page images, OCR quality score.
AI Decision	Classify, extract, summarize, route, or plan.	Structured JSON with confidence and evidence.
Validation	Check format, business rules, references, duplicates.	Passed, failed, warning, needs review.
Recovery	Retry recoverable failures and isolate bad jobs.	Retry scheduled, fallback model used, dead-letter.
Human Review	Present exceptions and collect corrections.	Approved, corrected, rejected, escalated.
Observability	Track quality, latency, cost, drift, and audit history.	Trace, metrics, prompt version, reviewer decision.

The Minimum Viable Production Workflow

receive_document()
text = run_ocr(document)
classification = classify(text, schema=DocumentType)
extraction = extract(text, schema=schema_for(classification.type))
validation = validate(extraction)

if validation.requires_review:
    create_review_task(document, extraction, validation)
else:
    save_verified_result(extraction)

log_workflow_run(document, classification, extraction, validation)

This simple pipeline gives you the skeleton for most recipes in the book. You can add queues, specialist models, external APIs, and agentic behavior as needed. Start with a workflow that can explain itself.

How to Use This Book

The Cookbook Pattern Template

Every recipe follows the same shape so you can scan, compare, and implement quickly.

Use This ForKeeping recipes consistent and easy to compare.

DeliverableA repeatable pattern template your team can reuse in design docs.

Watch ForPatterns that skip failure modes, review strategy, or cost notes.

Each recipe begins with a pattern card. It tells you when the pattern is useful, when to avoid it, which components it needs, and which risks deserve attention.

Pattern Name Problem When to Use When Not to Use Architecture Diagram Step-by-Step Flow Prompt / Schema Validation Rules Failure Modes Retry Strategy Human Review Observability Cost Notes Security Notes Production Checklist

How to read: Use the table of contents as a map. Start with the chapter family that matches your current workflow, then use each checklist as the production gate.

Components

Core Building Blocks

Most recipes are combinations of the same reusable components.

Use This ForBuilding a shared vocabulary across product, engineering, and operations.

DeliverableA component map for intake, extraction, validation, review, retry, audit, and evaluation.

Watch ForComponents that are missing owners, metrics, or rollback behavior.

Input AdapterReceives files, emails, forms, webhook events, or batch jobs and converts them into a common envelope.

OCR LayerTransforms page images into text, tables, coordinates, and quality metadata.

ClassifierDetermines document type, intent, risk, business category, or downstream route.

ExtractorConverts unstructured content into structured fields with evidence and confidence.

ValidatorApplies schema, format, business, cross-field, and external checks.

Rules EngineExecutes deterministic policy such as thresholds, eligibility, routing, and approval requirements.

Review QueueTurns exceptions into reviewer tasks with context, evidence, and correction fields.

Retry EngineRetries only recoverable failures, with capped attempts and logged reasons.

Audit LogRecords model, prompt, input references, output, validation status, user changes, and timestamps.

Evaluation DatasetStores golden examples for regression tests, prompt changes, and model upgrades.

The recipes name these components explicitly so designs stay portable across services, workflow engines, and SaaS modules.

Part II

Document Intelligence Patterns

The highest-value enterprise AI workflows often begin with messy documents. These patterns turn emails, PDFs, scans, invoices, and regulated case packets into structured, validated records.

Recipe 1

Document Intake Pattern

Standardize every incoming document before any model sees it.

Document Intake Pattern

Turn unpredictable incoming files into a consistent processing envelope.

DifficultyLow to medium

Best ForEmail intake, uploads, batch jobs

Avoid WhenInputs are already normalized

ComponentsAdapter, storage, queue, log

Problem: Document workflows often fail before AI starts. Attachments arrive with missing names, duplicate files, unsupported formats, huge scans, password-protected PDFs, or no business context.

Email/API/Upload→Normalize→Store Raw→Create Envelope→Queue Job

Implementation Sketch

{
  "document_id": "doc_456",
  "source": "shared_inbox",
  "received_at": "2026-05-29T10:20:00Z",
  "original_filename": "case_packet.pdf",
  "content_type": "application/pdf",
  "page_count": 12,
  "checksum": "sha256:...",
  "tenant_id": "tenant_123",
  "status": "received"
}

Validation Rules

Reject unsupported file types before OCR.
Calculate checksum to prevent duplicate processing.
Capture tenant and source metadata.
Limit size and page count by product tier or policy.

Failure Modes

Unreadable file.
Encrypted PDF.
Duplicate attachment.
Missing business owner.

Production Checklist

Raw file stored immutably.
Checksum recorded.
Unsupported files routed to review.
Metadata envelope created.
Job is idempotent.
Intake errors are visible in dashboard.

Recipe 2

Document Classification Pattern

Route each document to the right extractor, rule set, and review policy.

Document Classification Pattern

Classify documents with confidence, reason, and fallback route.

DifficultyMedium

Best ForMixed document packets

Avoid WhenDocument type is guaranteed

ComponentsClassifier, router, review queue

Problem: A single inbox may contain invoices, receipts, bank statements, contracts, application forms, IDs, and unknown attachments. Using one extractor for all of them increases errors and cost.

OCR Text→Classifier→Confidence Gate→Specialized Extractor→Review if Unknown

Classifier Output

{
  "document_type": "invoice",
  "confidence": 0.91,
  "reason": "Contains invoice number, billing address, line items, and total due.",
  "needs_review": false
}

Prompt Template

You are classifying business documents.
Return only valid JSON.

Allowed document types:
- invoice
- receipt
- application_form
- bank_statement
- contract
- identity_document
- unknown

Use unknown if the document does not strongly match one type.
Include confidence from 0 to 1 and a short reason.

Do not rely only on the label. Store the model reason and confidence. Use thresholds and business rules to route low-confidence classifications to review.

Routing Rule

if classification.document_type == "unknown":
    route_to_review("Unknown document")
elif classification.confidence < 0.80:
    route_to_review("Low classification confidence")
else:
    run_extractor_for(classification.document_type)

Production Checklist

Allowed labels are enumerated.
Unknown is an explicit route.
Confidence threshold is configurable.
Classifier accuracy is measured by type.
Misclassifications feed evaluation.
Specialized extractors are versioned.

Recipe 3

OCR, Vision, and LLM Extraction Pattern

Choose the right document understanding path: OCR for precise text, vision for layout, and hybrid routing when production quality depends on both.

OCR, Vision, and LLM Extraction Pattern

Convert documents into structured fields using text, layout, and visual evidence.

DifficultyMedium

Best ForScans, PDFs, forms, visual tables

Avoid WhenSource data is already structured

ComponentsOCR, vision model, extractor, evidence store

Problem: Document AI teams now have two powerful paths: traditional OCR followed by LLM extraction, and native multimodal extraction where the model reads page images or PDFs directly. The production question is no longer "Should we OCR?" It is "Which pages, fields, and failure modes deserve OCR, vision, or both?"

PDF/Image→Quality Router→OCR Path→Vision Path→Reconcile→Validate

Extraction routing chart: choose the cheapest reliable path first, then escalate only the pages or fields where visual structure changes the answer.

Choose the Extraction Path

Path	Use When	Watch For
OCR + Text LLM	Digital PDFs, clean scans, text-heavy forms, high-volume low-cost workflows.	Lost layout, table column drift, OCR latency, low-contrast text misses.
Vision-Native Extraction	Complex layouts, scanned forms, stamps, signatures, handwriting, charts, and spatial relationships.	Higher cost, page limits, slower latency, harder token accounting.
Hybrid Layout Analysis	Business-critical fields need both exact text and visual structure.	Conflicting OCR and vision values must be reconciled, not silently merged.

Hybrid Routing Rule

if pdf.has_digital_text and ocr.quality >= 0.90:
    use_text_extraction()
elif page.has_complex_layout or table_validation_failed:
    use_vision_extraction()
else:
    run_ocr_then_escalate_failed_fields_to_vision()

Recommended OCR Record

{
  "page": 2,
  "text": "Total Amount Due: $1,250.00",
  "quality": 0.94,
  "rotation_detected": 0,
  "tables_detected": 1,
  "blocks": [
    {
      "text": "Total Amount Due: $1,250.00",
      "bbox": [72, 680, 310, 704]
    }
  ]
}

Rules of Thumb

Use page numbers in every extraction prompt.
Ask for source text snippets for critical fields.
Detect low OCR quality before extraction.
Use vision-native extraction when spatial layout is part of the answer.
Store whether each field came from OCR, vision, or reviewer correction.
Split very long documents by page ranges or logical sections.
Keep raw OCR output so reviewers can inspect evidence.

Cost note: OCR can dominate latency in large document pipelines, while vision-native extraction can dominate model cost. Track OCR time, vision model time, text model time, queue time, and validation time separately.

Production Checklist

OCR quality score stored.
Vision escalation criteria are explicit.
Page numbers preserved.
Table regions handled separately.
Low-quality scans routed to vision, re-OCR, or review.
Critical fields include source evidence.
OCR and vision latency are monitored separately.

Recipe 4

Schema-Constrained JSON Extraction

Make the model return data your code can trust enough to validate.

Schema-Constrained JSON Extraction

Constrain fields, types, enums, and null behavior before validation.

DifficultyMedium

Best ForAPIs, databases, review UI

Avoid WhenTask is pure creative writing

ComponentsSchema, constrained decoder, parser, validator

Problem: Free-form model output is difficult to parse, compare, validate, or review. A schema makes AI output operational. In modern production systems, prefer enforced structured outputs or constrained decoding when your provider or framework supports it; prompt-only JSON should be the fallback, not the default.

2026 default: Treat malformed JSON as an infrastructure smell. Use API-level JSON schema enforcement, typed SDK helpers, constrained decoding libraries, or framework-level structured output wrappers before you build custom syntax-repair loops.

Schema gate: structured output turns model text into an object contract. Failures after this point should usually be semantic or business-rule failures.

Invoice Extraction Schema

{
  "document_type": "invoice",
  "invoice_number": "string | null",
  "vendor_name": "string | null",
  "invoice_date": "YYYY-MM-DD | null",
  "line_items": [
    {
      "description": "string",
      "quantity": "number | null",
      "unit_price": "number | null",
      "amount": "number | null"
    }
  ],
  "subtotal": "number | null",
  "tax": "number | null",
  "total": "number | null",
  "confidence": "number"
}

Prompt Rules

Return only JSON that matches the schema.
Use null when a value is not present.
Do not infer missing values.
Normalize dates as YYYY-MM-DD when possible.
For currency amounts, return numbers without symbols.
Include line items only when visible in the document.

Failure Modes

Model invents missing values.
Numbers include currency symbols.
Dates are ambiguous.
Line items are merged or split incorrectly.

Retry Strategy

Retry malformed JSON with a repair prompt.
Retry missing required fields only if evidence exists.
Do not retry if document type is wrong.
Escalate repeated schema failures.

Production Checklist

Schema is versioned.
Null policy is explicit.
Enums are closed.
Parser rejects extra commentary.
Schema failures are logged.
Review UI mirrors schema fields.

Recipe 5

Field Confidence Pattern

Do not score only the whole document. Score each important field.

Field Confidence Pattern

Attach confidence, evidence, and validation status to each extracted field.

DifficultyMedium

Best ForHigh-value extraction

Avoid WhenFields have no business impact

ComponentsExtractor, scorer, review UI

Problem: A document-level confidence of 0.90 can hide one dangerous low-confidence field. Reviewers need to know which fields deserve attention.

{
  "field_name": "invoice_total",
  "value": 1250.00,
  "confidence": 0.88,
  "source_page": 2,
  "source_text": "Total Amount Due: $1,250.00",
  "validation_status": "passed"
}

Review Trigger

critical_fields = ["invoice_total", "vendor_name", "account_number"]

for field in extracted_fields:
    if field.name in critical_fields and field.confidence < 0.85:
        send_to_review(field, reason="Low confidence critical field")

Design note: In the review UI, sort fields by risk rather than by document order. The reviewer should see the fields that matter first.

Production Checklist

Critical fields are configured.
Each field has source evidence.
Confidence is separated from validation.
Review threshold differs by field.
Reviewer corrections are captured.
Field accuracy is monitored.

Recipe 6

Missing Field Detection

A missing field is not always an extraction failure. Sometimes the document does not contain it.

Missing Field Detection Pattern

Separate not found, not applicable, unreadable, and extraction failed.

DifficultyMedium

Best ForRequired business fields

Avoid WhenAll fields are optional

ComponentsExtractor, validator, review queue

Problem: When a field is null, your system needs to know why. An account number may be absent, hidden by OCR failure, not applicable to the document type, or missed by the model.

{
  "field_name": "account_number",
  "value": null,
  "missing_reason": "not_present",
  "evidence": "No account number found in pages 1-4.",
  "needs_review": false
}

Missing Reason	Meaning	Next Action
not_present	The document does not appear to contain the field.	Accept if optional; review if required.
not_applicable	The field does not apply to this document type.	Accept.
unreadable	OCR quality prevents reliable extraction.	Re-OCR or human review.
model_failed	Evidence exists but extraction failed.	Retry or use specialist extractor.

Production Checklist

Nulls include missing reason.
Required fields are configured by document type.
Unreadable fields show OCR evidence.
Not applicable fields bypass review.
Missing field rates are tracked.
Field prompts are tested on edge cases.

Recipe 7

Validation Chain Pattern

Layer validation from simple syntax checks to business meaning.

Validation Chain Pattern

Pass model output through predictable layers before accepting it.

DifficultyMedium

Best ForAll production AI workflows

Avoid WhenExploratory internal prototypes

ComponentsSchema, rules, APIs, review

LLM Output→JSON Schema→Field Format→Business Rules→Cross-Document→Review

Validation ladder: validate from cheap deterministic checks toward expensive semantic checks. Route only unresolved failures to review.

Example Validation Rules

assert invoice.total >= 0
assert invoice.invoice_date <= today()
assert sum(item.amount for item in invoice.line_items) + invoice.tax == invoice.total
assert vendor.status != "blocked"
assert not duplicate_invoice(invoice.vendor_id, invoice.invoice_number)

A validation chain should return a structured report, not just true or false. That report powers retries, review queues, dashboards, and audit logs.

{
  "status": "failed",
  "requires_review": true,
  "failures": [
    {
      "rule": "invoice_total_matches_line_items",
      "severity": "high",
      "message": "Total 1250 does not match subtotal plus tax 1210."
    }
  ]
}

Production Checklist

Validation returns a report.
Rules have severity levels.
Validation failures map to actions.
Rules are tested independently.
Review UI displays failed rules.
Rule changes are versioned.

Part III

Human-in-the-Loop Patterns

Human review is not a failure of AI. It is how reliable systems handle risk, ambiguity, policy, accountability, and trust.

Recipe 8

Human Review Queue Pattern

Use AI to reduce review volume, not to hide decisions from reviewers.

Human Review Queue Pattern

Turn uncertain outputs into prioritized reviewer tasks.

DifficultyMedium

Best ForRisky or regulated workflows

Avoid WhenEverything legally requires full review

ComponentsRules, queue, UI, audit log

Golden rule: AI should not replace human review where risk is high. AI should reduce the amount of review needed and make the remaining review easier.

Review funnel: a good queue narrows high-volume AI output into a small set of high-value decisions, then turns reviewer corrections into evaluation data.

Review Triggers

Send to review if:
- confidence < 0.80
- mandatory field missing
- extracted value conflicts with a business rule
- document type is unknown
- transaction value exceeds threshold
- model output changed after retry
- document contains sensitive or high-impact decision data

Review Task Payload

{
  "task_id": "review_789",
  "priority": "high",
  "reason": "Invoice total mismatch",
  "document_id": "doc_456",
  "fields_to_review": ["invoice_total", "tax", "line_items"],
  "evidence_pages": [1, 2],
  "sla_due_at": "2026-05-30T10:00:00Z"
}

Production Checklist

Review reasons are explicit.
Tasks show evidence and failed rules.
Reviewer decisions are audited.
Corrections feed evaluation data.
SLA and priority are visible.
Review queue metrics are monitored.

Recipe 9

Semantic Repair Retry

In modern systems, syntax should be enforced at the output layer. Retries should focus on business meaning, evidence, and recoverable semantic failures.

Semantic Repair Retry Pattern

Repair values that failed deterministic validation without blindly rerunning the whole workflow.

DifficultyMedium

Best ForRule failures, contradictions, missing evidence

Avoid WhenInput is invalid or policy-blocked

ComponentsStructured output, retry engine, validator

Problem: Older LLM systems spent many retries fixing broken JSON. Modern structured output APIs and constrained decoding make syntax failures much less interesting. The harder production problem is semantic repair: the JSON is valid, but a field contradicts evidence, violates a business rule, or lacks a citation.

Semantic Repair Prompt

The previous structured extraction passed JSON schema validation
but failed business validation.

Failed rule:
invoice_date_must_not_be_future

Current value:
invoice_date = "2027-04-12"

Task:
Re-check only invoice_date against the source evidence.
Return the same schema.
Change only fields that are required to fix this validation failure.
If the document does not contain a reliable invoice date, return null
and set needs_review = true with the reason "invoice_date_unverified".

Retry Decision

recoverable = [
    "failed_business_rule",
    "missing_evidence",
    "cross_field_mismatch",
    "low_confidence_critical_field"
]

if failure.reason in recoverable and retry_count < 2:
    retry_with_semantic_repair(failure, constrained_schema=True)
else:
    send_to_review_or_dead_letter(failure)

Do not use retries as hope. Retry when the failure is recoverable and specific. Send the case to review when the document is ambiguous, the evidence is missing, or two retries produce conflicting values.

Production Checklist

Retry reason is logged.
Retry count is capped.
Syntax is handled with structured outputs where possible.
Repair prompt includes the failed business rule.
Non-recoverable failures are not retried.
Changed fields are compared after retry.
Retry rate is monitored.

Recipe 10

Model Fallback Pattern

Start cheap and fast, escalate only when the job deserves it.

Model Fallback Pattern

Use a tiered model strategy for cost, latency, and quality control.

DifficultyMedium

Best ForHigh-volume workflows

Avoid WhenOne model is mandated

ComponentsModel router, evaluator, cost monitor

Small Model→Validate→Escalate if Needed→Larger Model→Review if Still Failing

Fallback ladder: optimize spend by making model choice a policy decision tied to validation results, not a hard-coded default.

Escalation Rules

if output.valid and output.confidence >= 0.90:
    accept(output)
elif is_high_value(document) or repeated_failure(output):
    retry_with_stronger_model()
else:
    send_to_review(output)

Use fallback for quality, not as a substitute for validation. A larger model can still be wrong. It only changes the probability distribution, not the need for control.

Hybrid engine note: For high-volume workflows, the first tier can be a small local model running inside private infrastructure. Use it for simple classification and low-risk extraction, then escalate to a frontier model only when validation fails, confidence is low, or the business impact is high.

Production Checklist

Escalation rules are explicit.
Model choice is logged per run.
Cost impact is measured.
Quality is compared by model tier.
Fallback does not bypass review.
Model upgrades run against golden data.

Part IV

End-to-End Workflow Recipes

Patterns become more useful when they are composed into real business systems. These chapters show invoice automation and regulated document intake as practical reference architectures.

Recipe 11

Invoice Extraction Workflow

Extract, validate, match, approve, and audit invoices without pretending every invoice is clean.

Invoice Extraction Workflow

A full accounts-payable style document workflow.

DifficultyHigh

Best ForAccounts payable automation

Avoid WhenPayment approval cannot be delegated

ComponentsExtractor, matcher, validator, approval gate

Invoice→OCR→Header Extractor→Line Items→PO Match→Approval→Payment System

Invoice control diagram: extraction, reconciliation, matching, review, and approval are separate responsibilities with separate audit records.

Key Business Rules

if invoice_total != subtotal + tax:
    send_to_review("Total mismatch")

if duplicate_invoice(vendor, invoice_number):
    block_payment("Duplicate invoice")

if invoice_total > approval_limit(requester):
    require_manager_approval()

if vendor.bank_account_changed:
    require_security_review()

Recommended Fields

HeaderInvoice number, vendor, date, due date, currency, purchase order.

AmountsSubtotal, tax, discounts, shipping, total, balance due.

Line ItemsDescription, quantity, unit price, amount, tax code, category.

Observability

Extraction accuracy by field.
Average cost per invoice.
Review rate by vendor.
Duplicate detection rate.
Approval cycle time.

Production Checklist

Duplicate invoice check exists.
Totals reconcile with line items.
PO matching is separate from extraction.
High-value invoices require approval.
Vendor changes are controlled.
Payment actions are human-gated.

Recipe 12

Regulated Document Intake Workflow

A neutral enterprise example for document-heavy AI automation where accuracy, review, auditability, and compliance matter.

Regulated Document Intake Workflow

Classify attachments, extract case data, validate requirements, and prepare operations review.

DifficultyHigh

Best ForCompliance-heavy operations

Avoid WhenCase rules are not documented

ComponentsIntake, classifier, rule validator, review queue

Email Inbox→Attachment Collector→Document Splitter→Classifier→OCR/Vision→Field Extractor→Rule Validator→Operations Review

Documents to Expect

Document	Extraction Focus	Review Risk
Application form	Applicant, requested action, dates, identifiers.	Missing required fields or conflicting dates.
Supporting statement	Summary facts, amounts, dates, related parties.	Values conflict with the primary form.
Authorization letter	Approver, scope, effective period, signature evidence.	Expired or incomplete authorization.
Intake email	Intent, urgency, requested action, attachments.	Hidden instructions or missing attachments.

Case Signal JSON

{
  "case_id": "case_123",
  "business_category": "regulated_intake",
  "requested_action": "review_required",
  "supporting_documents": {
    "application_form": true,
    "authorization_letter": true,
    "identity_document": false
  },
  "validation_summary": {
    "required_documents_present": false,
    "conflicting_dates": false,
    "signature_required": true
  },
  "review_reasons": ["Identity document missing", "Signature requires review"]
}

Pattern value: Regulated intake is a strong reference architecture because it combines email automation, document classification, OCR or vision extraction, validation, human review, and auditability in one neutral story.

Production Checklist

Email body is processed as evidence.
Attachments are classified individually.
Primary and supporting document extractors are separate.
Required document rules are deterministic.
Reviewer can override with reason.
Audit history captures every status change.

Part V

Agentic Workflow Patterns

Agents are useful when the path is dynamic. They are risky when the task is better handled by deterministic steps. These patterns use agents carefully.

Recipe 13

Multi-Agent Routing Pattern

Use a router when tasks vary enough to require specialist workers.

Multi-Agent Routing Pattern

Route dynamic tasks to specialist agents while preserving control boundaries.

DifficultyHigh

Best ForVariable multi-step tasks

Avoid WhenSteps are fixed and simple

ComponentsRouter, specialists, policy guard

User/Job→Router Agent→Specialist→Critic/Validator→Human Gate

Agent routing topology: the router does not merely pick a worker; it also narrows permissions and defines which actions need human approval.

When to Use

The workflow path changes based on content.
Multiple specialist tools or knowledge areas are needed.
The user request is open-ended but bounded by policy.

When Not to Use

The task is simple classification.
Latency must be very low.
The steps are already known.
You need deterministic audit behavior at every step.

Router Output

{
  "route": "regulated_case_specialist",
  "confidence": 0.87,
  "allowed_tools": ["document_search", "risk_rules"],
  "blocked_tools": ["send_email", "approve_external_action"],
  "reason": "The packet includes an application form and supporting statements."
}

Production Checklist

Router has closed set of routes.
Tools are allowlisted by route.
Agent actions are logged.
High-impact actions require approval.
Fallback deterministic path exists.
Agent quality is evaluated separately.

Recipe 14

Tool-Calling Pattern

Let the model request tools, but let your system authorize and validate tool execution.

Tool-Calling Pattern

Use tools for retrieval, calculation, validation, and external systems.

DifficultyHigh

Best ForAPIs, search, calculations

Avoid WhenTool effects are unsafe

ComponentsTool registry, policy, validator

Tool Call Contract

{
  "tool": "lookup_vendor",
  "arguments": {
    "vendor_name": "Acme Supplies"
  },
  "purpose": "Validate vendor status before invoice approval."
}

Policy Gate

if tool not in allowed_tools_for_route:
    deny("Tool not allowed for this workflow")

if tool.has_external_side_effect and not human_approved:
    require_approval("External action requires human approval")

result = execute_tool(validated_arguments)

Security rule: Never let text inside a document directly authorize tool calls. Treat document text as untrusted input, especially when it contains instructions.

Production Checklist

Tool arguments are schema validated.
Tools are allowlisted by workflow.
External actions require human approval.
Tool results are logged.
Tool errors are recoverable.
Prompt injection tests include tool misuse.

Recipe 15

Human-Gated Agent Pattern

Agents may recommend high-impact actions. Humans approve them.

Human-Gated Agent Pattern

Require explicit approval before risky external changes.

DifficultyHigh

Best ForTool actions with business impact

Avoid WhenHuman approval is only performative

ComponentsPolicy gate, approver UI, audit log

Agent Proposal→Policy Check→Human Approval→Execute Tool→Audit

Approval Payload

{
  "proposed_action": "approve_invoice",
  "impact": "Payment may be released",
  "amount": 1250.00,
  "evidence": ["Invoice total validated", "Vendor active", "PO matched"],
  "risks": ["Bank account changed within 30 days"],
  "requires_approval_from": "finance_manager"
}

Good approval screens summarize the recommendation, evidence, failed checks, and alternatives. They do not force the human to reconstruct the whole model conversation.

Production Checklist

High-impact actions are cataloged.
Approval includes evidence and risk.
Approver identity is logged.
Rejected actions train future rules.
Agents cannot self-approve.
Emergency manual override exists.

Part VI

Reliability, Evaluation, and Production

Once workflows reach users, the work becomes measurement: versions, test datasets, costs, latency, security, auditability, and deployment discipline.

Recipe 16

Prompt Versioning Pattern

A prompt is production logic. Version it like code.

Prompt Versioning Pattern

Track, test, compare, and roll back prompt changes.

Problem: Small prompt changes can alter extraction behavior. Without versioning, you cannot explain why yesterday's invoices passed and today's invoices fail.

{
  "prompt_id": "invoice_extractor",
  "prompt_version": "v4",
  "model": "model_name",
  "schema_version": "invoice_schema_v2",
  "released_at": "2026-05-29T09:00:00Z",
  "change_summary": "Added null policy and stricter line item instructions."
}

Release Flow

Edit Prompt→Run Golden Dataset→Compare Metrics→Canary→Release→Monitor

Production Checklist

Every run stores prompt version.
Prompt changes have summaries.
Golden tests run before release.
Rollback path exists.
Prompt and schema versions are linked.
Metrics are compared after release.

Recipe 17

Golden Dataset Evaluation

If you cannot measure workflow quality, you cannot safely improve it.

Golden Dataset Evaluation Pattern

Create labeled examples that protect you from regressions.

A golden dataset is a set of representative inputs with expected outputs. It should include easy cases, common cases, and painful edge cases. Start small and make it real.

Evaluation loop: the dataset is not a static artifact. Production failures, reviewer corrections, and model upgrades all feed the next regression run.

Dataset Record

{
  "case_id": "invoice_edge_014",
  "document_id": "doc_sample_014",
  "expected": {
    "document_type": "invoice",
    "invoice_number": "INV-7731",
    "total": 1250.00
  },
  "tags": ["scanned", "two_page", "table"],
  "risk": "medium"
}

Metrics to Track

Field AccuracyExact or normalized match by field.

Review RatePercent of cases sent to humans.

Cost/LatencyAverage tokens, runtime, and retries.

Production Checklist

Dataset includes edge cases.
Expected outputs are reviewed by humans.
Metrics are field-level.
Prompt changes run against dataset.
Model upgrades are compared.
Failed production cases become tests.

Recipe 18

Cost and Latency Monitoring

A workflow is not production-ready until you can explain where time and money go.

Cost and Latency Monitoring Pattern

Measure each workflow segment separately.

Cost Drivers

OCR pages.
LLM input tokens.
LLM output tokens.
Retries.
Human review time.
Storage.
External API calls.

Segmented measurement: track OCR, model calls, retries, review, and external APIs independently so optimization targets the real bottleneck.

Run Log

{
  "workflow_id": "wf_123",
  "document_id": "doc_456",
  "ocr_latency_ms": 2400,
  "model_latency_ms": 4200,
  "validation_latency_ms": 80,
  "queue_wait_ms": 1200,
  "input_tokens": 3200,
  "output_tokens": 450,
  "estimated_cost": 0.036,
  "review_required": true
}

Optimization Order

Remove unnecessary model calls with caching and rules.
Reduce input tokens with better chunking and preprocessing.
Use small-model-first routing where quality holds.
Batch jobs that do not need immediate response.
Parallelize independent extraction tasks.

Real-Time Drift Signals

{
  "workflow_id": "wf_123",
  "model_version": "provider_model_2026_05",
  "prompt_version": "invoice_extractor_v7",
  "field_name": "invoice_total",
  "value_embedding_id": "emb_789",
  "confidence": 0.81,
  "validation_status": "warning",
  "review_correction_delta": true,
  "drift_cluster": "new_vendor_format_may_2026"
}

Latency and cost dashboards tell you whether the system is expensive or slow. Drift dashboards tell you whether behavior is changing. Track embeddings or semantic fingerprints for selected outputs, then compare clusters across model versions, prompt versions, tenants, document templates, and time windows.

Production Checklist

Latency is split by stage.
Cost is estimated per document.
Retries are included in cost.
Review time is measured.
Output drift is monitored by field and document type.
Rate limits are monitored.
Alerts exist for cost spikes.

Recipe 19

PII Redaction Pattern

Send only the data the model needs. Mask the rest before it leaves your trust boundary.

PII Redaction Pattern

Identify, mask, tokenize, or remove sensitive fields before model calls.

Raw Text→PII Detector→Redacted Text→LLM→Rehydrate if Allowed

Trust boundary: sensitive source values stay inside the private system. The model receives only the minimum masked context required for the task.

Redacted Payload

{
  "text": "Applicant [PERSON_1] operates at [ADDRESS_1]. Tax ID [TAX_ID_1].",
  "redactions": [
    {"token": "[PERSON_1]", "type": "person_name"},
    {"token": "[ADDRESS_1]", "type": "address"},
    {"token": "[TAX_ID_1]", "type": "tax_id"}
  ]
}

Security Notes

Do not send unnecessary PII to the model.
Mask sensitive fields in logs and review screens.
Separate redaction maps from model prompts.
Apply tenant-specific retention rules.

Production Checklist

PII categories are defined.
Redaction happens before LLM call.
Logs mask sensitive fields.
Rehydration is access-controlled.
Retention policy is enforced.
Security tests include prompt injection.

Recipe 20

Audit Logging Pattern

Auditability is the memory of a production AI system.

Audit Logging Pattern

Record enough context to explain, debug, and defend workflow decisions.

Audit Event

{
  "event_id": "evt_001",
  "workflow_id": "wf_123",
  "document_id": "doc_456",
  "event_type": "validation_failed",
  "model": "model_name",
  "prompt_version": "invoice_extractor_v4",
  "schema_version": "invoice_v2",
  "actor": "system",
  "timestamp": "2026-05-29T10:40:00Z",
  "details": {
    "rule": "invoice_total_matches_line_items",
    "severity": "high"
  }
}

What to Log

System ContextWorkflow, document, tenant, model, prompt, schema, tool versions.

Decision ContextClassification, extraction, validation report, review reason, final action.

Human ContextReviewer, correction, approval, rejection, override reason.

Operational ContextLatency, tokens, cost, retries, errors, queue timestamps.

Production Checklist

Every workflow run has trace ID.
Prompt/model versions are logged.
Human overrides require reasons.
Logs protect sensitive fields.
Audit events are immutable.
Retention policy is documented.

Recipe 21-25

Deployment Architecture Pattern

Choose an architecture that matches volume, latency, risk, and team maturity.

Queue-Based Microservice Workflow

Use queues to isolate OCR, model calls, validation, review, and persistence.

API Gateway→Queue→OCR Worker→LLM Worker→Validation Service→Database→Review UI

Deployment control plane: queues absorb bursts, worker pools scale independently, validators gate persistence, and trace events make every accepted or rejected decision auditable.

This architecture is strong when documents are slow, large, or bursty. It lets OCR workers, LLM workers, and validation services scale independently.

Serverless AI Workflow

Use event-driven functions for lower operations overhead.

Serverless works well for variable traffic and document jobs that can tolerate asynchronous processing. Keep long-running OCR and model calls behind queues, and make each function idempotent.

Multi-Tenant SaaS Architecture

Separate tenant data, configuration, prompts, review queues, and retention policy.

{
  "tenant_id": "tenant_123",
  "workflow_config": {
    "classification_threshold": 0.82,
    "pii_redaction": true,
    "retention_days": 365,
    "review_sla_hours": 24
  }
}

Blue-Green Prompt Deployment

Deploy prompt and schema updates with rollback.

Run a new prompt version for a small percentage of traffic. Compare validation failures, review rate, field accuracy, latency, and cost. Promote only when metrics improve or remain acceptable.

Rollback Pattern for AI Workflows

Roll back prompts, models, schemas, and rule configurations without redeploying the whole application.

Production Checklist

Workflow steps are idempotent.
Queues have dead-letter handling.
Prompt config is deployable separately.
OCR and LLM workers scale independently.
Review UI is connected to audit log.
Rollback is tested before launch.

Part VII

Expanded Recipe Pack

These compact recipes add more implementation depth for the full edition. Use them as expansion cards, sprint tickets, or workshop modules.

Bonus Recipes

20 Additional Production Patterns

The first 25 recipes are the core book. These additional patterns make the manuscript more complete for teams building enterprise-grade AI workflow systems.

How to Expand a Compact Recipe

Each following card can become a complete chapter by adding four things: a concrete business scenario, an architecture diagram, one prompt or schema, and a validation checklist. The pattern is intentionally short here so the book remains skimmable while still giving you a richer content base.

26. Document Splitter Pattern

Use this when a single PDF contains multiple logical documents, such as a regulated case packet with application forms, supporting statements, authorization letters, and IDs.

SplitterClassifierReview

Flow: Run page-level classification, group adjacent pages by type, assign confidence to each boundary, and route uncertain boundaries to review.

Guardrail: Never split a document on model confidence alone. Use page numbers, headers, repeated titles, and attachment metadata as supporting evidence.

27. Unknown Document Fallback

Use this when your intake channel receives unexpected files. Unknown should be a first-class state, not an error.

RoutingSafetyReview

Flow: Classify as unknown, capture the closest candidate labels, store evidence, and ask a reviewer to label the document for future evaluation.

Guardrail: Do not force unknown documents into the nearest known extractor. That usually creates high-confidence bad data.

28. Table Extraction Pattern

Use this for invoices, statements, schedules, application tables, status tables, and transaction rows.

OCRTablesValidation

Flow: Detect table regions, extract rows separately from narrative text, normalize columns, then reconcile row totals against document totals.

Guardrail: Validate row count and column alignment. A perfect-looking JSON array can still be shifted by one column.

29. Source Citation Pattern

Use this when reviewers, auditors, or downstream systems need evidence for every extracted value.

EvidenceAuditReview UI

Flow: Store value, page number, bounding box if available, source text, and confidence. Show the citation next to the field in review.

Guardrail: Validate that source text actually supports the extracted value instead of merely appearing near it.

30. Cross-Document Matching

Use this when one decision depends on multiple documents, such as invoice-to-PO matching or contract-to-authorization validation.

MatchingRulesRisk

Flow: Extract candidate identifiers, normalize entities, calculate match confidence, run deterministic rules, and send conflicts to review.

Guardrail: Matching by name alone is risky. Combine names with dates, amounts, addresses, reference numbers, or account identifiers.

31. Extract-Then-Normalize

Use this when source documents contain messy but meaningful formats, such as currency symbols, local dates, abbreviations, and handwritten notes.

ExtractionNormalizationEvidence

Flow: Store raw extracted value, normalized value, normalization method, and validation status. Keep both raw and normalized values.

Guardrail: Do not overwrite raw evidence. Normalization can be wrong, and reviewers need the original text.

32. Entity Resolution Pattern

Use this to map extracted names to known vendors, customers, applicants, counterparties, or legal entities.

IdentityMatchingHuman Review

Flow: Generate candidate matches, score them with deterministic and semantic features, auto-accept only above a strict threshold, and review the rest.

Guardrail: False merges are worse than missed matches in most enterprise systems.

33. Duplicate Detection Pattern

Use this for invoices, case packets, contracts, and repeated uploads.

IdempotencyRiskBlocking

Flow: Compare checksum, source metadata, extracted identifiers, dates, totals, and semantic similarity before accepting a new record.

Guardrail: Distinguish exact duplicates from revised documents. A revised document needs version handling, not silent rejection.

34. External API Validation

Use this when extracted values need verification against authoritative systems, such as vendor master data, account systems, tax APIs, or address services.

APIValidationFallback

Flow: Validate arguments, call the external system, record response metadata, and classify failures as business failures or service failures.

Guardrail: API outages should not look like invalid documents. Use separate error types and retry policies.

35. Contradiction Detection

Use this when documents may disagree, such as requested values in an email versus values in a supporting form.

SemanticsValidationReview

Flow: Extract facts from each source, compare normalized values, rank contradictions by business impact, and show both citations to the reviewer.

Guardrail: Do not treat wording differences as contradictions unless the business fact differs.

36. Random Sampling Review

Use this to measure quality even when documents pass automation.

QualitySamplingDrift

Flow: Sample accepted outputs by document type, model version, tenant, risk tier, and time period. Feed reviewer corrections into metrics.

Guardrail: Sampling only failures will make your system look worse than it is. Sampling only easy successes will make it look safer than it is.

37. Multi-Level Approval

Use this when approvals depend on value, risk, authority, regulation, or customer tier.

ApprovalSLAAudit

Flow: Calculate approval level, assign reviewers, track SLA, require reasoned decisions, and escalate stale tasks automatically.

Guardrail: The model can recommend an approval level, but deterministic policy should decide the required authority.

38. Reviewer Correction Loop

Use this to turn human review into system improvement instead of one-off cleanup.

FeedbackEvaluationPrompting

Flow: Store before value, corrected value, reason code, reviewer, field, prompt version, and source citation. Promote repeated corrections into test cases.

Guardrail: Do not train from corrections without checking whether the reviewer was right.

39. Planner-Executor Agent

Use this when a task needs dynamic sequencing, such as investigating a case packet with missing documents and multiple external checks.

AgentsPlanningTools

Flow: Generate a plan, validate allowed steps, execute one step at a time, revalidate after each tool result, and stop for human approval before impact.

Guardrail: Plans should be treated as proposals. Your workflow engine should own execution.

40. Critic Agent Pattern

Use this when a second model pass can catch reasoning, extraction, or policy mistakes before review.

AgentsQualityReview

Flow: Ask the critic to check output against evidence, schema, and policy. Accept critic feedback only through structured validation.

Guardrail: A critic is not a validator. It can miss errors and create new ones.

41. Circuit Breaker Pattern

Use this when repeated model, OCR, or API failures could create retry storms.

ReliabilityQueuesRecovery

Flow: Track failure rate by dependency. When the threshold is crossed, stop new calls, queue jobs safely, and notify operators.

Guardrail: A circuit breaker needs a recovery test. Otherwise, it becomes a permanent outage.

42. Dead-Letter Queue Pattern

Use this when jobs cannot be processed automatically after capped retries.

RecoveryOperationsAudit

Flow: Move failed jobs to a dead-letter queue with reason, attempt history, input reference, and suggested manual recovery action.

Guardrail: A dead-letter queue is not a trash can. It needs ownership, SLA, and reporting.

43. Cache-Before-LLM Pattern

Use this to avoid repeated model calls for identical documents, repeated classifications, or stable reference lookups.

CostLatencyInvalidation

Flow: Key cache entries by document checksum, task, prompt version, schema version, and model version.

Guardrail: Invalidate cache when prompts, schemas, models, or business rules change.

44. Token Budget Guard

Use this when long documents threaten cost, latency, or context limits.

CostChunkingControl

Flow: Estimate tokens before each call, choose page ranges or sections, summarize non-critical areas, and preserve full evidence for critical fields.

Guardrail: Do not trim away the evidence needed to validate high-impact fields.

45. Failure Reason Taxonomy

Use this to make dashboards actionable and prioritize improvement work.

ObservabilityAnalyticsOperations

Flow: Classify failures into input, OCR, classification, extraction, validation, policy, dependency, and human workflow categories.

Guardrail: Keep the taxonomy small enough that engineers and operators use it consistently.

Implementation Playbook: Minimum Data Model

A production workflow needs stable identifiers across every stage. The following table is a practical starting point for a database schema or event contract.

Record	Purpose	Important Fields
workflow_run	One end-to-end processing attempt.	workflow_id, tenant_id, status, started_at, completed_at, trace_id.
document	Raw file and metadata.	document_id, checksum, source, page_count, storage_uri, received_at.
model_call	Every call to a model.	model, prompt_version, schema_version, token_count, latency_ms, cost.
extracted_field	Structured field with evidence.	field_name, value_raw, value_normalized, confidence, source_page, source_text.
validation_result	Rule and schema outcomes.	rule_id, severity, status, message, next_action.
review_task	Human exception handling.	reason, priority, assignee, due_at, decision, correction_payload.
audit_event	Immutable record of decisions.	actor, event_type, before, after, reason, timestamp.

Implementation Playbook: Review Screen Requirements

A good human review screen is not just a form. It is an evidence console. It should show the field, extracted value, confidence, failed rules, page preview, source citation, prior attempts, and reviewer action in one focused workflow.

Show why the item was routed to review.
Highlight fields in risk order.
Display source page and source text beside each field.
Allow approve, correct, reject, escalate, and mark unreadable.
Require reason codes for overrides.
Capture corrections as structured data.
Show SLA and priority.
Write every reviewer action to the audit log.

Implementation Playbook: Production Dashboard

Your dashboard should help operators answer three questions: Is the workflow healthy? Is quality improving? Where are we spending money?

HealthQueue depth, success rate, failure rate, dead-letter count, dependency errors, retry rate.

QualityField accuracy, review rate, correction rate, classifier confusion, drift by document type.

EconomicsCost per document, OCR time, model time, tokens per document, review minutes per case.

Part VIII

Advanced 2026 Production Patterns

These recipes close the biggest gaps for modern production AI systems: multimodal documents, enforced outputs, durable agents, RAG, LLM gateways, trust boundaries, memory, streaming, tenant isolation, and evaluation automation.

Advanced Recipes

19 Patterns for Modern AI Engineering

A production cookbook should not stop at OCR, JSON parsing, and queues. Modern teams also need patterns for vision-native documents, structured decoding, reasoning models, long context, RAG, durable agent execution, multi-provider infrastructure, local SLM routing, drift detection, and adversarial input handling.

What This Section Adds

The earlier chapters make the system reliable. This section makes it current. It adds architectural patterns that are now common in senior production discussions: model gateways, enforced structured output, durable orchestration, memory isolation, multimodal extraction, RAG evaluation, and CI-driven evals.

2026 AI Workflow Stack Blueprint

Market-leading AI workflow systems are no longer a single prompt wrapped in a queue. They are compound systems where models, tools, rules, retrieval, evaluation, and observability run as one controlled loop. The book's advanced recipes are organized around the three pressures senior engineering teams feel most: cost, evaluation, and maintainability.

2026 AI Workflow Stack
  |
  +-- Compound AI Loops
  |     LLM reasoning + code rules + retrieval + tool calls + human gates
  |
  +-- Programmatic Optimization
  |     DSPy-style prompt compilation + golden datasets + CI evals
  |
  +-- Production Control Plane
        model gateway + local SLM routing + drift detection + audit logs

Modern AI stack: the model is no longer the architecture. Top-tier systems coordinate workflow logic, evaluation, and a production control plane as versioned software.

CostRoute routine work to rules, caches, retrieval, or small/local models before escalating to frontier models.

EvaluationUse golden datasets, LLM-as-judge rubrics, retrieval metrics, and reviewer correction loops to measure quality continuously.

MaintainabilityVersion prompts, schemas, routing policy, models, tools, and workflow graphs as production artifacts.

46. Vision-Native Extraction Pattern

Use this when page layout, handwriting, stamps, signatures, charts, or visual table structure matters more than raw OCR text.

MultimodalDocumentsExtraction

Flow: Render pages as images, send selected pages to a multimodal model, request structured fields with page references, then validate values against the same schema and business rules used by OCR pipelines.

Use when: OCR confidence is low, layout is complex, tables are visually dense, or the document is a scanned form.

Avoid when: Digital text is clean and cheap OCR already gives high-quality text. Vision calls can be more expensive and slower.

47. Hybrid OCR + Vision Fallback

Use OCR as the default path and multimodal extraction as a targeted fallback for pages that fail quality checks.

FallbackCost ControlQuality

Flow: Run OCR, score page quality, extract normally, then escalate only low-quality pages or failed fields to a vision model.

Decision rule: Escalate when OCR quality is below threshold, table validation fails, field evidence is missing, or reviewer corrections frequently point to visual layout issues.

Guardrail: Do not mix OCR and vision outputs without reconciliation. Store which engine produced each field.

48. Enforced Structured Output Pattern

Use API-level structured outputs, constrained decoding, or typed output libraries when malformed JSON must be impossible or rare.

Structured OutputSchemaReliability

Flow: Define a JSON schema or typed model, bind it to the model call, reject schema-incompatible responses at the API boundary, then run business validation after parsing.

Why it matters: Prompting the model to "return JSON" is weaker than forcing the output channel to comply with a schema.

Guardrail: Enforced structure solves syntax. It does not prove the extracted value is correct.

49. Reasoning-Informed Extraction vs. Standard Extraction

Use a reasoning model when the extraction requires multi-step comparison, contradiction resolution, policy interpretation, or cross-document inference that a fast standard model repeatedly fails.

ReasoningCostValidation

Flow: Start with a standard extractor, run deterministic validation, escalate only the hard cases to a reasoning model, then validate the final structured output exactly like any other extraction.

Use reasoning when: A 50-page contract has conflicting addenda, a case summary conflicts with detailed rows, or the model must reconcile multiple pieces of evidence before choosing a value.

Guardrail: Reasoning models can reduce semantic mistakes, but they do not replace citations, business rules, or human review for high-impact decisions.

50. Long-Context vs. Chunking Decision Pattern

Use this when documents or document sets are too large for a naive prompt but may fit inside modern long-context windows.

ContextChunkingCost

Flow: Estimate token volume, classify task type, compare long-context cost against chunk-and-aggregate cost, then select one of three modes: full context, section chunking, or retrieval-first extraction.

Use long context when: Cross-document reasoning is required and the full set is still affordable.

Use chunking when: Extraction is local, documents are repetitive, or you need predictable cost and retries.

51. Hierarchical Extraction Pattern

Use this for long documents where local section extraction must be reconciled into one final record.

Long DocumentsAggregationReconciliation

Flow: Split by document structure, extract each section, produce section summaries, reconcile conflicts in an aggregation pass, then validate the final merged object.

Best for: Contracts, medical records, regulated case bundles, and technical reports.

Guardrail: The final aggregation pass must preserve citations back to original pages, not only section summaries.

52. Retrieval-Augmented Extraction Pattern

Use retrieval when only a subset of a large corpus is relevant to the extraction or decision.

RAGExtractionCorpus

Flow: Index documents with metadata, retrieve candidate chunks for each field or question, rerank results, extract with citations, and validate against source evidence.

Best for: Enterprise knowledge bases, procedure libraries, case history, compliance documents, and multi-document operations files.

Guardrail: Extraction quality depends on retrieval quality. Track context precision and context recall, not just final answer quality.

53. Agent Memory Boundary Pattern

Use this when agents need session history or long-term knowledge without leaking data across tenants, users, or workflows.

AgentsMemoryIsolation

Flow: Separate working memory, episodic session memory, and persistent memory. Scope each memory store by tenant, user, workflow, and permission.

Memory types: Working memory for the current task, episodic memory for prior steps in the same case, and long-term memory for approved reusable facts.

Guardrail: Treat memory as untrusted retrieval. Validate memory before it affects a business decision.

54. LLM Gateway Pattern

Use a centralized gateway between your application and model providers for routing, rate limits, cost attribution, authentication, logging, and policy enforcement.

InfrastructureRoutingGovernance

Flow: Send all model calls through one gateway, attach tenant and workflow metadata, apply provider routing policy, log cost and latency, and enforce allowed models.

Best for: Teams using multiple models, multiple providers, multiple tenants, or strict cost controls.

Guardrail: Gateway fallback must preserve output contracts. A fallback model that cannot honor the schema should not be treated as equivalent.

55. Semantic Caching Pattern

Use semantic caching when similar prompts or document fragments repeatedly ask for the same answer.

CostEmbeddingsLatency

Flow: Embed the request, search prior requests by similarity, verify that the cached answer is safe for the current tenant and version, then reuse or refresh.

Best for: FAQ workflows, procedure explanation, repeated classification, and stable reference lookups.

Guardrail: Never share semantic cache entries across tenants unless the content is explicitly global and non-sensitive.

56. Trust Boundary Pattern

Use this to separate trusted system instructions from untrusted user input, document text, retrieved chunks, emails, and web content.

SecurityPrompt InjectionTools

Flow: Label every content source, isolate untrusted text in data fields, forbid untrusted text from changing tools or policies, and scan suspicious instructions before agent execution.

Prompt rule: Document content is evidence. It is not instruction.

Guardrail: Tool authorization must live outside the model prompt. The model can request a tool; your policy engine decides whether it runs.

57. Durable Agent Execution Pattern

Use this when agent workflows need to survive crashes, timeouts, human waits, rate limits, and external system failures.

AgentsDurabilityOrchestration

Flow: Persist state after each step, checkpoint tool results, make actions idempotent, resume from the last safe checkpoint, and record the execution graph.

Best for: Multi-step case review, vendor onboarding, compliance review, and any workflow with human approval.

Guardrail: Durable execution is not only retry logic. It needs explicit state, replay rules, and idempotent side effects.

58. Interrupt-and-Resume Pattern

Use this when an agent must pause for human approval, missing information, or policy escalation and then continue with the same state.

Human GateStateAgents

Flow: Agent reaches a gate, serializes state, creates a review task, waits for human input, validates the response, and resumes from the checkpoint.

Best for: External actions, high-value approvals, sensitive data access, and uncertain tool calls.

Guardrail: The resumed agent should receive the approved decision, not unrestricted access to the reviewer conversation.

59. Agent Replay and Debug Pattern

Use this to reproduce failed agent runs and compare behavior after prompt, model, tool, or policy changes.

DebuggingReplayEvaluation

Flow: Capture inputs, prompts, model versions, tool calls, tool outputs, state checkpoints, and random seeds when available. Replay from the start or a chosen checkpoint.

Best for: Debugging failed workflows, building regression tests, and explaining production incidents.

Guardrail: Replay should be side-effect safe. Never re-send emails, payments, approvals, or external writes during debug replay.

60. LLM-as-Judge Evaluation Pattern

Use a separate evaluator model to score quality at scale when human labels are limited or expensive.

EvaluationJudgeCI

Flow: Define a rubric, provide source evidence and expected behavior, ask the judge to score specific dimensions, then sample judge decisions for human calibration.

Metrics: Correctness, completeness, groundedness, citation support, policy compliance, and refusal quality.

Guardrail: A judge model is a measurement tool, not truth. Track judge agreement against human reviewers.

61. Programmatic Prompt Optimization Pattern

Use this when hand-tuned prompts stop improving and you have an evaluation dataset that can score outputs automatically.

DSPyEvalsMaintainability

Flow: Define the task as a typed signature, build a small pipeline, choose metrics, compile or optimize prompts against the dataset, then freeze the optimized program as a versioned artifact.

Best for: Repeated classification, extraction, routing, reranking, and answer synthesis where a measurable metric exists.

Guardrail: Optimization can overfit. Hold out a test set, include adversarial examples, and compare cost and latency before promotion.

62. Hybrid Engine Pattern: Local SLM First

Use this to route simple, high-volume work to small local models and reserve frontier models for ambiguous, high-risk, or validation-failing cases.

SLMRoutingCost

Flow: Classify task complexity, run small-model extraction or classification first, validate outputs, escalate only failures or high-impact cases to a stronger model.

Best for: Tenant-private workloads, high-volume intake classification, simple metadata extraction, and workflows with strict cost ceilings.

Guardrail: Local model routing needs parity tests. Measure quality by document type and tenant before replacing a frontier model path.

63. Real-Time Drift Detection Pattern

Use this to catch silent behavior changes in production when model providers, prompts, document templates, or user populations shift.

ObservabilityEmbeddingsDrift

Flow: Log field values, validation failures, reviewer corrections, model versions, and embeddings of selected outputs. Compare distribution changes over time and alert on semantic or operational drift.

Signals: Rising review rate, field confidence shift, changed output embedding clusters, new failure reasons, and prompt/model version deltas.

Guardrail: Drift alerts must point to a workflow segment. A generic "quality changed" alert is too vague for operators to fix.

64. Fine-Tune vs. Prompt Decision Pattern

Use this when prompting, retrieval, and validation are not enough to meet accuracy, latency, or cost targets.

AdaptationFine-TuningEvaluation

Decision tree: Improve prompts first, add examples second, improve retrieval third, tune only when you have stable labels, repeated task shape, and measurable gains.

Best for: Repeated classification, narrow extraction style, domain-specific formatting, and high-volume workflows where latency or cost matters.

Guardrail: Run the fine-tuned model against the golden dataset and adversarial cases before production rollout.

Advanced Architecture Checklist

Structured outputs are enforced where the provider or framework supports it.
OCR, vision, and hybrid extraction have explicit routing criteria.
Reasoning models are reserved for tasks that justify extra latency and cost.
Long-context use is justified by task value, not novelty.
RAG pipelines track retrieval quality separately from answer quality.
Prompt optimization is driven by eval metrics, not manual string tweaking alone.
Small/local model routes have parity tests against frontier-model baselines.
Agent memory is scoped by tenant, workflow, user, and permission.
All model calls pass through a gateway or equivalent policy layer.
Semantic drift alerts compare production behavior across model and prompt versions.
Prompt injection tests include uploaded documents and retrieved chunks.
Agent runs can pause, resume, and replay safely.
LLM-as-judge evals are calibrated against human review.
Tenant-level cost, latency, and review time are attributable.
Streaming UI states do not bypass final validation.
Fine-tuned models pass regression tests before deployment.

Appendix

Prompts, Schemas, Checklists, and Glossary

Reusable Extraction Prompt

You are extracting structured data from a business document.
Return only valid JSON matching the schema.
Use null when a value is not present.
Do not infer values that are not visible.
For each critical field, include confidence, source_page, and source_text.
If the document is unreadable, return needs_review = true with reason.

Reusable Validation Report Schema

{
  "status": "passed | failed | warning",
  "requires_review": "boolean",
  "review_reasons": ["string"],
  "failures": [
    {
      "rule": "string",
      "severity": "low | medium | high",
      "field": "string | null",
      "message": "string"
    }
  ]
}

Production Launch Checklist

Every model output has a schema.
Critical fields include confidence and evidence.
Validation rules are tested.
Human review path exists.
Retries are capped and logged.
Dead-letter queue exists.
Prompt and model versions are logged.
Golden dataset is established.
PII policy is implemented.
Cost and latency dashboards exist.
Rollback path is tested.
Audit log is immutable.

First Edition Pattern Index

#	Pattern	Primary Use
1	Document Intake	Normalize incoming files and metadata.
2	Document Classification	Route documents to specialized extractors.
3	OCR, Vision, and LLM Extraction	Extract from scans and PDFs with text, layout, and visual evidence.
4	Schema-Constrained JSON	Make outputs parseable and validatable.
5	Field Confidence	Prioritize review by field risk.
6	Missing Field Detection	Explain null values correctly.
7	Validation Chain	Layer schema, format, and business checks.
8	Human Review Queue	Route exceptions to reviewers.
9	Semantic Repair Retry	Recover specific business-rule and evidence failures safely.
10	Model Fallback	Balance cost, speed, and quality.
11	Invoice Workflow	Accounts payable automation.
12	Regulated Document Intake	Case packet triage and operations review.
13	Multi-Agent Routing	Dynamic specialist routing.
14	Tool Calling	Controlled external API usage.
15	Human-Gated Agent	Approval before high-impact actions.
16	Prompt Versioning	Track and roll back prompt changes.
17	Golden Dataset	Measure quality and prevent regressions.
18	Cost and Latency Monitoring	Understand production economics.
19	PII Redaction	Protect sensitive data.
20	Audit Logging	Explain and defend decisions.
21	Queue-Based Microservice	Scale slow document pipelines.
22	Serverless Workflow	Run event-driven automation.
23	Multi-Tenant SaaS	Separate tenant configuration and data.
24	Blue-Green Prompt Deployment	Release prompt changes safely.
25	Rollback Pattern	Recover from bad AI configuration changes.

Future Expansion Pattern Library

This section gives the full book its long-term shape beyond the 64 practical recipes already included. A larger edition can expand patterns 65-109 into full recipes with diagrams, prompts, schemas, validation rules, and implementation notes.

#	Pattern	Use It For	Primary Risk
65	Document Splitter	Breaking packets into logical documents.	Splitting one document into many or merging two documents.
66	Unknown Document Fallback	Routing unexpected files safely.	Forcing a wrong label because unknown is not allowed.
67	OCR Preprocessing	Deskewing, rotating, denoising, and preparing scans.	Over-processing and destroying evidence.
68	Table Extraction	Line items, schedules, statement rows, and record tables.	Column drift and row merging.
69	Source Citation	Showing where each field came from.	Storing citations that do not actually support the value.
70	Cross-Document Matching	Matching invoices to POs or case packets to attachments.	False matches across similar entities.
71	Few-Shot Extraction	Improving extraction for repeated document families.	Examples biasing the model into inventing fields.
72	Extract-Then-Normalize	Keeping raw values separate from normalized values.	Losing original evidence during cleanup.
73	Field-Level Retry	Retrying only fields that failed validation.	Inconsistent values across retry attempts.
74	Partial Extraction Recovery	Saving usable fields when some fields fail.	Accepting incomplete records without review.
75	Entity Resolution	Matching vendors, applicants, counterparties, and customers.	Merging two different entities.
76	Duplicate Detection	Finding duplicate invoices, case packets, or contracts.	Blocking legitimate repeated documents.
77	Versioned Prompt Extraction	Comparing extraction behavior by prompt version.	Changing prompts without regression data.
78	Regex Validation	Checking account numbers, tax IDs, dates, and codes.	Rejecting valid regional formats.
79	Cross-Field Validation	Checking totals, dates, limits, and dependent fields.	Rules that do not match business exceptions.
80	External API Validation	Checking vendors, sanctions, addresses, policies, or licenses.	API outages blocking the workflow.
81	Contradiction Detection	Finding conflicts inside or across documents.	Over-flagging harmless wording differences.
82	Rule + LLM Hybrid Validation	Combining deterministic checks with semantic review.	Letting semantic validation override hard rules.
83	Validation Summary Report	Explaining pass/fail status to humans and systems.	Reports that are too vague to act on.
84	Exception-Based Review	Sending only policy exceptions to humans.	Hiding low-confidence results that pass rules.
85	Random Sampling Review	Measuring quality on accepted documents.	Sampling too little to detect drift.
86	High-Risk Review	Reviewing high-value, high-impact, or regulated cases.	Risk rules that lag behind business change.
87	Multi-Level Approval	Escalating decisions by value, risk, or authority.	Approval bottlenecks without SLA visibility.
88	Reviewer Correction Loop	Turning human fixes into training and evaluation signals.	Corrections stored as text notes instead of structured data.
89	Review SLA Queue	Prioritizing review by due date and business urgency.	Old tasks getting buried behind new tasks.
90	Audit Trail Review	Showing who changed what and why.	Editable audit history.
91	Disagreement Resolution	Handling reviewer/model or reviewer/reviewer conflict.	No clear tie-break authority.
92	Feedback-to-Prompt	Using recurring corrections to improve prompts.	Overfitting prompts to a few complaints.
93	Planner-Executor Agent	Breaking dynamic tasks into planned steps.	Plans that drift from allowed policy.
94	Specialist Agent	Assigning narrow expertise to focused agents.	Specialists disagreeing without arbitration.
95	Critic Agent	Reviewing proposed answers before acceptance.	Critic adding latency without measurable quality gain.
96	Memory-Bounded Agent	Giving agents only the memory needed for the task.	Leaking old context into new decisions.
97	Policy-Governed Agent	Constraining agent actions by explicit policy.	Policies written as vague natural language only.
98	Agent Fallback	Returning to deterministic workflows when agents fail.	No fallback path when the agent stalls.
99	Agent Evaluation	Measuring planning, tool use, success rate, and safety.	Only evaluating final answer quality.
100	Circuit Breaker	Stopping calls during repeated vendor/model/API failure.	Retry storms and cascading failure.
101	Dead-Letter Queue	Isolating jobs that cannot be processed automatically.	Dead letters never reviewed.
102	Idempotent Workflow	Safely retrying without duplicate side effects.	Duplicate approvals, payments, or records.
103	Async Processing	Handling slow document jobs without blocking users.	No user-visible status or recovery path.
104	Batch Processing	Reducing overhead for non-urgent jobs.	Batch failures hiding individual bad records.
105	Cache-Before-LLM	Avoiding repeated model calls for known inputs.	Serving stale results after policy changes.
106	Token Budget Guard	Capping prompt size and output spend.	Truncating evidence needed for accuracy.
107	Model Version Tracking	Explaining behavior changes after model upgrades.	Comparing runs without model metadata.
108	Workflow Tracing	Following one document across services.	Logs that cannot be joined by trace ID.
109	Failure Reason Taxonomy	Grouping errors for dashboards and improvement work.	Every failure becoming "other".

Glossary

ExtractorA component that converts unstructured content into structured fields.

ValidatorA component that checks output against schema, formats, rules, and evidence.

Review QueueA worklist for humans to approve, correct, reject, or escalate AI outputs.

Golden DatasetLabeled examples used to evaluate prompts, models, and workflow changes.

Dead-Letter QueueA holding area for jobs that cannot be processed automatically.

Audit LogAn immutable record of workflow events, decisions, versions, and actors.

Production AI Systems

Patterns for the work after the demo.

A practical field guide for turning uncertain model output into reliable workflows with schemas, validation, human review, retries, observability, cost controls, and deployment discipline.

Document intelligence
Validation chains
Human review
Production control

AI Workflow Patterns Cookbook [2026] Edition

Copyright and Review Notice

From Prompts to Production Workflows

About Purnendu Das

Table of Contents

Part I - Workflow Mindset

Part II - Document Intelligence

Part III - Review and Recovery

Part IV - Agentic Workflows

Part V - Production Systems

Companion Sections

How to Use This Book

How Each Recipe Is Meant to Work

Decision Lens

The Workflow-First Mindset

Why AI Workflows Fail in Production

Common Production Failure Modes

The Shift

Anatomy of a Reliable AI Workflow

The Minimum Viable Production Workflow

The Cookbook Pattern Template

Core Building Blocks

Document Intelligence Patterns

Document Intake Pattern

Document Intake Pattern

Implementation Sketch

Validation Rules

Failure Modes

Production Checklist

Document Classification Pattern

Document Classification Pattern

Classifier Output

Prompt Template

Routing Rule

Production Checklist

OCR, Vision, and LLM Extraction Pattern

OCR, Vision, and LLM Extraction Pattern

Choose the Extraction Path

Hybrid Routing Rule

Recommended OCR Record

Rules of Thumb

Production Checklist

Schema-Constrained JSON Extraction

Schema-Constrained JSON Extraction

Invoice Extraction Schema

Prompt Rules

Failure Modes

Retry Strategy

Production Checklist

Field Confidence Pattern

Field Confidence Pattern

Review Trigger

Production Checklist

Missing Field Detection

Missing Field Detection Pattern

Production Checklist

Validation Chain Pattern

Validation Chain Pattern

Example Validation Rules

Production Checklist

Human-in-the-Loop Patterns

Human Review Queue Pattern

Human Review Queue Pattern

Review Triggers

Review Task Payload

Production Checklist

Semantic Repair Retry

Semantic Repair Retry Pattern

Semantic Repair Prompt

Retry Decision

Production Checklist

Model Fallback Pattern

Model Fallback Pattern

Escalation Rules

Production Checklist

End-to-End Workflow Recipes

Invoice Extraction Workflow

Invoice Extraction Workflow

Key Business Rules

Recommended Fields