AI agent approval UX is the decision surface where a person accepts, rejects or changes a consequential proposed action. It is not a confirmation dialog with a generated summary. Reviewers need the exact action, changed state, authority, evidence, uncertainty, alternatives and limits on reversal. If the screen hides those elements, the workflow has added human latency without adding meaningful oversight.
The approval interface must remain connected to runtime state. The OpenAI Agents SDK human-in-the-loop guide describes interruptions, review of tool calls and resumption from serialized run state. That pattern makes a review technically possible; product design determines whether the reviewer can decide well. The proposal shown on screen should be the proposal later executed, protected by a hash or version and revalidated against mutable business state.
Define the decision and the right reviewer
State what approval authorizes: one action with exact arguments, a bounded batch, a plan, or continued agent access for a limited interval. Avoid vague buttons such as 'Allow' when the actual effect is sending a message, changing an account or releasing funds. Determine reviewer eligibility from role, scope, amount, jurisdiction, conflict-of-interest rules and current delegation. The assignee should be able to decline ownership without approving or rejecting the business action.
Match review effort to consequence and reversibility. Low-risk, easily reversible actions can use compact review. High-impact or irreversible actions require richer evidence, stronger authentication and possibly two independent decisions. A reviewer must have time, expertise and access to source records. Escalation is part of the interface: show who can resolve missing authority or conflicting evidence and preserve the queue state while that happens.
Build the screen as a decision packet
| Section | Reviewer question | Required content | Unsafe omission |
|---|---|---|---|
| Action | What exactly will happen? | Tool, target, normalized arguments and timing | Friendly summary without parameters |
| Delta | What changes from current state? | Before and after values with material fields highlighted | Showing only proposed state |
| Authority | Who requested and who may approve? | Requester, policy rule, reviewer scope | Assuming queue membership equals authority |
| Evidence | Why is this action justified? | Source-linked facts, freshness and conflicts | Agent-generated rationale alone |
| Risk | What can go wrong? | Impact, affected parties, reversibility and uncertainty | Generic confidence score |
| Alternatives | What safer choices exist? | Edit, defer, reject, partial action or escalate | Approve-or-block binary |
| Execution | What happens after approval? | Expiry, revalidation, notification and verification | Implying approval equals completion |
Use progressive disclosure without hiding material facts. The first view should show identity, action, delta, top evidence, risk and commands. Expanders can hold source passages, policy text and trace details. Keep labels stable and use domain language. Highlight changed values, not decorative warnings. For a batch, summarize totals and outliers and let reviewers inspect every item; never approve hidden rows. The layout should support keyboard navigation, screen readers, zoom and narrow displays without truncating amounts, dates or identifiers.
Show evidence with freshness and provenance
Every material claim should link to an authoritative source record or clearly identify itself as an inference. Show source owner, observed time, effective time and transformation when relevant. If two records disagree, show the conflict rather than an agent-written compromise. Let reviewers open source context without losing their place. Sensitive evidence should follow existing access controls; assignment to an approval queue does not automatically authorize every underlying document.
Do not use confidence as a substitute for evidence. A score is useful only when calibrated for this decision and paired with a threshold and known limitations. Prefer concrete uncertainty: address could not be verified, policy effective date is ambiguous, or supplier record changed after proposal. The NIST AI RMF Playbook organizes suggested actions across Govern, Map, Measure and Manage; a review packet operationalizes those functions at the point of a human decision.
Make deltas and reversibility unmistakable
Render before-and-after values for fields that change and identify unchanged fields that materially constrain interpretation. For financial actions, show amount, currency, source, destination, fees and schedule. For access, show subject, resource, current role, proposed role, duration and inherited permissions. Explain whether reversal restores the prior state, creates a compensating event or is impossible. 'Can be undone' is misleading when notifications, external transfers or disclosures remain.
| Property | Interface treatment | Decision control | Post-decision check |
|---|---|---|---|
| Reversible and local | Compact delta with undo window | Single authorized reviewer | Confirm state and expose undo |
| Reversible by compensation | Explain residual effects and compensation owner | Explicit acknowledgement | Verify both original and compensation records |
| Irreversible | Persistent warning beside action details | Strong authentication and possible dual review | Confirm execution and notify affected owner |
| Batch action | Totals, outliers and item drill-down | Per-item exclusion and batch cap | Reconcile every item |
| Time-sensitive | Visible data age and approval expiry | Revalidate before execute | Show stale or superseded result |
| Third-party effect | Recipient, channel and disclosure preview | Recipient authority check | Delivery and content evidence |
Offer commands that support judgment
Provide approve, reject, edit, request information, defer and escalate where the domain supports them. Require a reason when it improves accountability or downstream learning, but use structured reason codes with optional notes rather than forcing ceremonial text. Editing creates a new proposal that must be validated and, if material, reviewed again. Never let a reviewer alter a displayed value while the runtime executes the original hidden argument.
Place the primary command according to risk and organizational policy, not a universal design habit. Avoid preselected approval, countdown pressure and keyboard shortcuts that can trigger irreversible actions without a confirmation appropriate to consequence. Reauthentication should occur close to decision time for high-risk actions. The human approval design guide covers routing and gate placement; this decision-packet approach specifies what the reviewer needs once work arrives.
Handle stale proposals and concurrent changes
Record the target state version when the agent creates a proposal. At display time, warn if material data changed. At execution, enforce optimistic concurrency or re-read preconditions. A stale approval should not silently apply to a changed amount, recipient or permission. If revalidation changes material arguments, invalidate the approval and present a new delta. For benign changes, policy may allow execution while recording the differences checked.
Approvals need expiry. Set it from data volatility and risk, not reviewer convenience. Show remaining validity and what will happen on expiry. Prevent duplicate decisions from multiple open tabs by using an atomic state transition and return the winning result to later reviewers. A completed decision should display who acted, when, against which proposal version and whether execution succeeded. Approval and execution are separate states and should never share one ambiguous success message.
Design for effective human oversight
The European Commission's AI Act overview identifies human oversight, logging, documentation, robustness and risk management among obligations for high-risk systems. Applicable legal duties depend on context and jurisdiction, but the design lesson is broader: oversight must give a person real authority and enough information to intervene. A rubber-stamp queue with no alternatives, source access or time is not effective merely because a person clicked.
The NIST Generative AI Profile similarly treats human-AI configuration, risk measurement and incident learning as connected concerns. For the interface, that means documenting which control the reviewer supplies, testing whether people can recognize missing or conflicting evidence, and feeding reversals and post-approval defects back into workflow evaluation. Human review should have a measurable risk-management purpose, not serve as an unexplained compliance ornament.
Monitor reviewer behavior without blaming individuals for system design. Track time to decision, source opens, edits, requests for information, reversal, agreement between qualified reviewers and post-approval defects. Very fast universal approval can indicate clear low-risk work or automation bias; investigate with sampling. Very slow review may signal missing evidence or excessive queue scope. The AI workflow approvals planning guide helps teams define ownership and escalation around these measures.
Test the interface and preserve decision evidence
Test with representative reviewers and realistic time pressure. Include long identifiers, multiple currencies, conflicting sources, stale state, partial batches, expired delegation, mobile layouts and assistive technology. Run comprehension tasks: ask reviewers to identify target, delta, evidence weakness, reversibility and next state. Measure decision correctness, not preference alone. Simulate unavailable source systems and ensure the interface blocks or clearly limits decisions that require them.
The durable record should include proposal and display versions, evidence references, policy result, reviewer identity and authority, commands, reason, timestamp, authentication context, execution preconditions and final result. Protect the record from silent mutation and apply retention and access rules. The AI agent control plan connects this evidence to permissions and audit trails. Avoid screenshots as the canonical record; store structured values that can be queried and rendered later.
Key takeaways
- Authorize an exact proposal, not a vague continuation of agent autonomy.
- Show action, delta, authority, evidence, risk, alternatives and execution behavior.
- Label source freshness, conflicts and inference instead of relying on generated rationale.
- Explain whether reversal restores state, compensates later or cannot undo effects.
- Invalidate or re-review proposals when mutable business state changes materially.
- Measure reviewer comprehension and downstream defects, then preserve a structured decision record.
Frequently asked questions
Should every agent tool call require approval? No. Gate actions by consequence, authority, uncertainty and reversibility. Over-approval creates delay and habituation without improving decisions.
Can reviewers edit an agent proposal? Yes, when the domain allows it, but the edit becomes a new validated proposal. Material changes may require another reviewer or renewed evidence.
What is the most important item on an approval screen? The exact action and its delta. Evidence and authority then explain whether that change should be allowed.
Conclusion
AI agent approval UX creates control only when a qualified person can understand and change the outcome. Build a decision packet around exact arguments, current-state deltas, source-linked evidence, authority, consequence and alternatives. Revalidate at execution, distinguish approval from completion and preserve structured evidence. This turns human review from a ceremonial pause into a defensible decision point that helps both the reviewer and the automated workflow behave responsibly.