Key takeaways
- Put the gate immediately before the consequential effect, after the system has prepared enough evidence for a decision. Earlier creates guesswork; later creates notification.
- Bind approval to an immutable proposal ID and normalized payload. Any material edit creates a new proposal and invalidates the old decision.
- Give reviewers a short evidence packet: requested effect, source facts, policy test, uncertainty, alternatives and consequence. More context can make the decision worse when the key fact gets buried.
- Model approve, approve-with-edit, reject, cancel, expire and escalate as normal outcomes. Each one needs an owner and destination.
- Authorization, expiry and idempotency are enforcement rules, not interface copy. The runtime must reject stale, duplicate and unauthorized decisions.
Place the gate at the last responsible moment
A gate placed too early asks a person to approve a plan before the real amount, recipient, fields or wording exist. A gate placed after execution is a notification. The useful position is the last point where the effect is fully specified but has not happened.
Google Cloud's architecture pattern describes a predefined checkpoint where the agent pauses and an external system waits for review. Keep the pause narrow. A workflow drafting twelve replies can prepare all twelve, then gate each actual send. It need not hold database reads or deterministic policy checks while the reviewer is away.
| Too early | Useful checkpoint | Too late |
|---|---|---|
| Approve “contact the customer” before a message exists | Approve this text, recipient and promised remedy before send | Review the sent-message notification |
| Approve “update the account” before fields are resolved | Approve this before-and-after diff before the write | Inspect the changed record later |
| Approve “grant access” before scopes and duration are known | Approve named scopes, resource, identity and expiry before grant | Receive the access-created event |
Write the seven-field gate contract
- 01TriggerCodeState the machine-readable condition that creates review: action type, threshold, policy exception, conflicting evidence or random sample. “Low confidence” is incomplete until the score, calibration set and boundary are named.
- 02Immutable proposalAI judgmentNormalize the exact effect into a payload and assign a version or hash. Include target, action, parameters and relevant before-state. Any material edit creates a new proposal.
- 03Evidence packetCodePut source facts, policy rule, reason for escalation, uncertainty, consequence and safe alternatives beside the proposal. Link to the original record; do not replace it with a model summary.
- 04Decision authorityHuman approvalName eligible roles, required expertise, delegation, separation of duties and whether the requester may approve. Check authorization again when the decision arrives.
- 05OutcomesHuman approvalDefine approve, approve-with-edit, reject, return-for-evidence, cancel, expire and escalate. Give every outcome a destination and record a reason where it changes policy or payload.
- 06Time policyCodeSet the decision deadline, reminder cadence, business-hours behavior and escalation owner. Expiry must resolve to a safe state; it cannot mean “approve by silence.”
- 07Single-use resumeCodeConsume a decision token once, verify it matches the proposal version, then execute or branch idempotently. Duplicate, stale and late decisions become recorded no-ops.
Worked contract: publish a customer-facing status update
Trigger: the proposed update includes an incident cause or recovery-time commitment. Proposal: normalized status text, affected services, audience and proposal hash. Evidence: incident timeline, observed metrics, current responder notes, wording that remains uncertain and the last public update.
Authority: incident commander or delegated communications lead; the drafting system and engineer who proposed the cause cannot approve. Outcomes: approve exact text, edit and create a new version, reject, request evidence, or cancel because the incident state changed.
Time: remind after ten minutes, escalate after twenty and expire after thirty because stale incident language is dangerous. Resume: verify the approved hash, re-check that the incident is still open, publish once and record the resulting status-page version.
Design the review surface around the disagreement
Reviewers should be able to answer three questions without opening five systems: what will happen, why is it proposed, and what could go wrong? Put the original facts before the system's recommendation so the recommendation does not become the frame for every decision.
Microsoft's HAX guidelines treat correction, dismissal and control as core parts of human-AI interaction. In a gate, that means edit and reject cannot be secondary links hidden below the approve button. Use neutral button weight, require a reason for policy exceptions, and show which facts were model-produced rather than sourced.
- Show a diff for writes and edits, not just the new value.
- Show the final recipient, destination and scope beside the action.
- Separate source evidence from model inference and operator notes.
- State the consequence in plain language: “this sends now,” not “continue.”
- Offer a safe alternative such as save draft, narrow scope or return to queue.
Keep enforcement outside the model and the notification
The model may propose that a gate is needed, but code or policy should enforce it. The same applies to authorization, proposal matching, expiry and idempotency. A Slack message is a delivery channel. It is not the source of truth for whether the action is allowed.
NIST's playbook asks organizations to identify system capabilities that need oversight, define the roles involved and test oversight under deployment-like conditions. Test more than the happy path. Revoke the reviewer's role mid-request, deliver the decision twice, alter the proposal and let the deadline pass.
| Test | Required result |
|---|---|
| Unauthorized decision | Rejected; request remains pending; attempt is logged |
| Payload changed | Prior approval invalid; new proposal needs a new decision |
| Duplicate approval | One resume and one effect; later decisions are no-ops |
| Expired request | Safe branch runs; late approval cannot revive it |
| Notification failure | Pending state survives; retry does not duplicate the request |
| Reviewer unavailable | Named escalation or cancellation occurs on schedule |
Hand the contract to the runtime and the metric owner
Once the seven fields are stable, choose a runtime blueprint and define its events. The proposal, presentation, decision, expiry, resume and final effect need separate timestamps. Without them, you cannot distinguish reviewer delay from notification or execution delay.
Limitations and when not to use this
- This is a software and process design method, not legal, employment, financial or security advice. Applicable rules may require a particular reviewer, record, explanation or prohibition.
- A well-designed gate still fails when reviewers lack time, training, evidence or permission to disagree. Interface work cannot repair an organizational conflict.
- Approval does not expand the underlying actor's authority. Enforce access and policy independently before executing the approved effect.
Sources
- Choose a design pattern for your agentic AI system — Google Cloud Architecture Center Accessed 30 July 2026
- AI RMF Playbook: Map — NIST Accessed 30 July 2026
- Guidelines for Human-AI Interaction — Microsoft HAX Toolkit Accessed 30 July 2026
Generate the seven-field contract
Use the free designer to turn one action into a gate placement, review packet, outcome set and escalation rule.
Generate the seven-field contractUli 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.