Key takeaways
- A useful human-in-the-loop example names the exact action that stops. “Review the output” is too vague to implement or audit.
- The same process can mix automatic steps, exception review and blocking approval. Human-in-the-loop is a step-level choice, not a label for the whole workflow.
- The reviewer needs the source record, proposed effect, reason for escalation and safe alternatives in one payload. Making them reconstruct context turns approval into queue work.
- Every gate needs a rejection and expiry branch. A workflow that only models approval will strand work the first time a reviewer says no or is away.
- Keep the gate only while it catches meaningful errors or carries real accountability. Sample the automatic path and measure overrides before removing it.
Read each example as an action contract
Google Cloud describes the human-in-the-loop pattern as a predefined checkpoint where execution pauses while an external system waits for a person. That definition is narrow enough to be useful. The system can prepare a draft, gather records and run deterministic checks before the checkpoint. Only the effect that needs authority has to wait.
Compare examples using six fields: the pending effect, the reason it was gated, the reviewer, the evidence packet, the allowed decisions and what happens when nobody decides. These fields expose whether “human review” is a real control or an inbox with good intentions.
| Workflow and pending effect | Gate shape | What the person sees | Expiry path |
|---|---|---|---|
| Support: send a reply that offers a remedy outside the standard policy | Blocking exception approval by the support lead | Customer request, order history, policy boundary, proposed remedy and the exact outgoing message | Return to the unassigned exception queue; send nothing |
| CRM: overwrite an account's industry and employee-band fields | Automatic on agreement; block only when two sources conflict | Existing value, candidate values, source URLs, timestamps and the downstream segments that would change | Keep the old value and create a data-quality task |
| Knowledge base: publish a small correction to an internal troubleshooting article | Post-action sampling with complete version rollback | Before-and-after diff, cited source, pages linking to it and whether the edit changes a customer-facing instruction | Sampling has no pending request; failed review restores the prior version |
| Onboarding: grant a new joiner access to a restricted workspace | Blocking approval by the resource owner; two people for privileged access | Identity, manager request, role, exact scopes, duration and conflicting entitlements | Deny the request and ask the manager to submit a narrower scope |
| Document intake: accept extracted fields from a low-risk supplier form | Deterministic validation, confidence-triggered exception review and a random sample | Source crop, extracted value, validation result, similar fields and why the case crossed the review rule | Quarantine the document; preserve the original for manual entry |
Worked example: a support reply that crosses policy
A support workflow classifies a delayed-order complaint, checks the order record and drafts a reply. The normal policy permits a replacement shipment. The draft instead offers two free months because the customer reports three earlier failures. The proposed remedy is outside the written rule, so the workflow creates proposal SUP-4821-v1 and stops before send.
The support lead sees the complaint, shipment timeline, earlier tickets, relevant policy paragraph, proposed remedy, message text and two in-policy alternatives. They can approve the exact draft, edit the remedy and message, reject it with a reason, or return it for more evidence. An edit produces SUP-4821-v2; the v1 approval cannot authorize it.
If nobody decides within four business hours, the request moves to the duty lead. At the end of the support day it expires and returns to the exception queue. The system sends no placeholder and does not silently fall back to its preferred answer.
The useful human contribution is exception judgment, not proofreading. Spelling, required-field checks and policy lookup can run before the gate. The person decides whether this customer warrants a deliberate exception and owns the resulting promise.
Why these examples use different review patterns
The support message is externally visible and difficult to take back, so it waits. The knowledge-base correction has a complete version rollback and a limited audience, so sampling can catch drift without putting every edit in a queue. CRM enrichment is useful at volume, but conflicting sources signal the precise case where human context adds value.
NIST's AI RMF calls for human-oversight processes to be defined, assessed and documented according to organizational policy. It also says the needed risk-management level follows the organization's risk tolerance. That points away from one universal gate and toward an explicit rule per effect.
- Use blocking approval for effects that commit, disclose, grant, pay, send or otherwise become hard to reverse.
- Use exception review when code can identify the ordinary path and a named condition marks the ambiguous case.
- Use sampling when individual errors are recoverable but silent drift across many runs would matter.
- Use deterministic validation instead of a person for schema, range, duplication and required-field rules.
The review packet should make disagreement possible
Microsoft's HAX guidelines are grounded in research on human-AI interaction. The practical lesson for a gate is that the interface must let a person understand, correct and dismiss the system's output. A green confidence badge and an approve button do the opposite: they frame confirmation as the expected behavior.
Show source facts before the recommendation, name what the system does not know, and offer a safe alternative. Record an edit as a distinct outcome rather than treating it as approval. That difference becomes essential when you later ask whether the gate caught substantive errors or reviewers merely changed tone.
Test the unhappy paths before calling the example complete
- Submit the same proposal twice and prove only one request is active.
- Change the payload after approval and prove the old decision is rejected.
- Let the request expire and prove the effect does not execute.
- Try an unauthorized reviewer and prove the decision is refused and logged.
- Approve twice from two browser tabs and prove the workflow resumes once.
- Remove the primary reviewer and prove the escalation route has a real owner.
The runtime-pattern guide specifies those transitions. The example is finished only when rejection and absence work as reliably as approval.
Limitations and when not to use this
- These are simulated operating examples, not evidence that all-agents or any named system supports the described applications, connectors or controls.
- The access and supplier examples touch security and commercial records. Apply your own authorization policy, retention rules and qualified review; this page does not replace them.
- Human approval cannot legitimize a prohibited action or compensate for a reviewer who lacks time, evidence, competence or real authority to refuse.
Sources
- Choose a design pattern for your agentic AI system — Google Cloud Architecture Center Accessed 30 July 2026
- AI Risk Management Framework Core — NIST Accessed 30 July 2026
- Guidelines for Human-AI Interaction — Microsoft HAX Toolkit Accessed 30 July 2026
Design your own approval gate
Describe one proposed action and turn its consequence, reversibility and uncertainty into a review contract you can copy.
Design your own approval gateUli Prantz
Builds and operates all-agents
Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.