Key takeaways
- Set approval requirements by impact, reversibility, uncertainty, sensitivity, and authority—not by whether the output came from AI.
- An approval request must include the proposed action, evidence, changed fields, expected effect, deadline, and rollback path.
- Repeated failures and high-risk or irreversible actions are strong triggers for human intervention.
- No response is a workflow state: define expiry, reassignment, safe default, and customer communication before launch.
01
Approval is not a universal answer to risk
Requiring a person to click every output creates a queue, not control. People learn to approve repetitive work without reading it, and urgent exceptions arrive in the same channel as harmless drafts. Start by classifying the action the system wants to take.
Assess customer or financial impact, reversibility, data sensitivity, uncertainty, legal or policy exposure, and whether the system has authority. Drafting an internal headline is different from publishing a health claim, changing a live budget, deleting a customer record, or sending an outbound message. The source of the suggestion matters less than the consequence of acting on it.
02
Define four modes of authority
A useful operating model separates observe, recommend, act with approval, and act inside a bounded policy. New workflows begin in observation or recommendation mode. The team compares proposed actions with actual decisions, measures false alarms, and learns what evidence reviewers need before granting more authority.
OpenAI’s practical guide to agents identifies repeated failure and high-risk actions as triggers for human intervention. Add business-specific triggers: unsupported claims, missing consent, sensitive segments, spend beyond tolerance, conflicting CRM state, customer distress, or unavailable tools. A confidence score alone is not a complete escalation rule.
Swipe to compare every column
| Mode | System behavior | Example |
|---|---|---|
| Observe | Record what it would do | Flag possible duplicate companies |
| Recommend | Propose action and evidence | Suggest reallocating a small test budget |
| Approve | Pause before side effect | Publish a claim or contact a lead |
| Bounded action | Execute inside explicit limits | Create an internal task with reversible fields |
03
Design an approval packet someone can judge quickly
Show the proposed action, object, before-and-after state, evidence and provenance, policy or rule that triggered review, expected consequence, uncertainty, deadline, and rollback. Highlight the changed information instead of forcing the reviewer to reconstruct the whole task from a transcript.
The reviewer needs approve, reject with reason, edit, request evidence, and escalate. Store the decision and the context used at that moment. Later data may change, so the audit record should explain why the decision was reasonable then rather than rewriting history around the final outcome.
04
Plan for the day the approver is unavailable
Set expiry, backup owner, queue priority, and the safe default. A promotional draft can wait; a customer expecting a confirmed appointment may need a transparent fallback. Never let a timeout silently convert into approval. If the system cannot proceed safely, it should stop, preserve state, and tell the next person what remains unresolved.
Review queue age, approval time, rejection reasons, edits after approval, overrides, false escalations, missed escalations, and downstream incidents. Approval gates should become narrower and more precise as evidence grows—not simply disappear because the queue became inconvenient.
Primary sources and further reading
Use the source material to validate details against your own context and current platform configuration.
- OpenAI: A practical guide to building agents
- NIST AI Risk Management Framework
- NIST Generative AI Profile
- Pre-Exec Bench: Guardrails for agentic systems
This field note follows the XenGrowth editorial policy: primary sources where available, visible limitations, material review dates, and no invented first-hand experience.
Stay with the problem



