Approval is not a decorative button
A good approval gate changes what the system is allowed to do. Until approval arrives, the action must remain pending. Rejection should produce a recorded reason or corrected instruction, not silently disappear.
The gate belongs at the point where risk becomes meaningful: sending a customer response, changing a commercial record, deploying code, issuing a refund, or modifying production data.
What the reviewer needs
Reviewers should not reconstruct the agent’s reasoning from logs. The interface needs to present the proposed action and the minimum evidence required to judge it.
- The request and relevant source context.
- The proposed action and affected system.
- Validation results, policy checks, and unresolved uncertainty.
- Approve, reject, edit, and escalate paths.
- A durable record of who decided what and when.
Move the boundary deliberately
Some low-risk actions may earn automatic execution after repeated, measured success. That should be an explicit product decision backed by evaluation data and incident review—not a quiet configuration change.
For higher-risk work, the approval gate remains part of the system even when the agent becomes more capable.