"A human reviews everything" sounds reassuring in a security questionnaire and collapses immediately at production volume. If Claude drafts two thousand customer replies a day and one overloaded reviewer rubber-stamps them, you have the cost of review without its protection. Human-in-the-loop design is the engineering discipline of deciding — deliberately, per use case — where human judgment enters the workflow, and making that judgment real rather than ceremonial.
Three placement patterns
Most designs use one of three shapes, and the right one depends on what a mistake costs.
Human approves before action. The model drafts; a person edits and sends. Nothing reaches a customer, a contract, or a system of record without sign-off. This is the right default for external communications, legal and financial documents, and anything irreversible. The model's job is to get the person to 80% faster, not to replace them.
Human reviews after action. The output ships automatically, and people audit a sample afterward. This fits high-volume, low-stakes work — internal tagging, ticket routing, search summaries — where an occasional error is cheap and quickly corrected. The review's purpose shifts from catching individual mistakes to detecting quality drift.
Human handles the exceptions. The system processes what it can confidently and routes the rest to people. This is the workhorse pattern for document processing and support automation: the majority flows through automatically, and humans spend their time on the genuinely hard cases instead of skimming easy ones.
Escalation needs a trigger
Exception-based designs live or die on how cases get flagged for human attention. Useful triggers include: the model's own signal (instruct Claude to say explicitly when information is missing or the request is ambiguous, and route those responses to a queue); programmatic validation failures (extracted totals that don't reconcile, JSON that fails schema checks, required fields absent); business rules (any refund above a threshold, any message mentioning legal action, any request touching regulated data); and user signals (a "talk to a person" option that always works, thumbs-down feedback that triggers review).
Whatever the trigger, the escalation path must be a real workflow with an owner and a service-level expectation — a named queue someone works daily, not an email alias nobody reads.
Keeping reviewers effective
Human review degrades in predictable ways, and good design compensates. Approval fatigue is the big one: a reviewer who approves hundreds of near-identical items stops reading them. Counter it by keeping automatic what can be automatic — send humans only the cases where their judgment changes the outcome — and by tracking edit rates. If reviewers modify less than a trickle of items, either the model is excellent or the review is theater; sampling audits tell you which.
Reviewers also need context and authority. Show them the source material alongside the draft, not just the draft. Make rejection cheap: one click to send a case back or take it over entirely. And feed their corrections back into the system — recurring edits are your best source of prompt improvements and new evaluation cases, as covered in test before you trust.
Write it down for the auditors
Security and compliance teams will ask where humans sit in the workflow, and "it depends" is not an answer. Document, per use case: which outputs are auto-released versus gated, what triggers escalation, who reviews, and what gets logged. Log the review events themselves — who approved what, when, with what edits — so you can answer questions later. This record does double duty: it satisfies auditors and gives you the data to loosen or tighten gates deliberately as the system proves itself, rather than by drift.
A common maturity path is to start with approval-before-action, measure edit rates for a quarter, then move well-performing categories to exception-based handling with sampled audits. Loosening a gate on evidence is sound engineering. Loosening it because everyone got busy is how incidents happen.
Where to go next
Review gates work best alongside measurement — see evaluating LLM features for building the eval sets that justify each gate, and building a customer support assistant for these patterns applied to a concrete design. The launch checklist covers the rest of the pre-production list.