Agent approvals become tolerable when they appear only where a person can change the outcome, show what will actually happen, and leave a clean path whether the answer is yes, no, or silence. Adding more confirmation dialogs doesn’t do that. A prompt that says “Allow this action?” with no detail is a click, not a review.
Put the gate where the consequence is
Microsoft’s agent runbook puts the principle in one line: “Pick deliberately per action — not one policy for the whole agent.” It describes four patterns, which work as a tiering scheme.
![The Microsoft Copilot Bible: [3 in 1] A Beginner's Guide to Harness AI in Office 365 to Automate Workflows, Generate Content, Analyze Data, and 10x Your Productivity](https://m.media-amazon.com/images/I/41+5Qv4pd2L._SL160_.jpg)
As an Amazon Associate I earn from qualifying purchases.
| Consequence | Pattern | What the human does |
|---|---|---|
| Low, reversible | Notify after the action | Glances at a log and can undo it |
| Moderate | Confirm before the action | Approves or declines a specific operation |
| High | Agent drafts, human commits | Owns the final action |
| Regulated or safety-sensitive | Qualified reviewer required | Applies professional judgment before use |
The practical consequence is that a plain yes/no confirmation is the wrong tool at both ends. It is too heavy for reversible work, which can simply be reported afterward. It is too thin for work that needs expertise, where the reviewer must be able to evaluate the operation and not merely acknowledge it.
Free tools Windows power users keep installed
One-click scans. No signup required.
The runbook’s own use-case language reflects this range: “human review for accuracy,” “mandatory specialist review before clinical use,” “marked as AI drafts for stakeholder review,” and “with human intervention in uncertain cases.” That wording comes from one Microsoft portfolio, and it is not survey data about the wider field. Likewise, the runbook’s count of about 10 of 138 use cases with explicit human review describes only that portfolio, with review implicit in most others.
#1 Best Overall
Show the reviewer something they can judge
A reviewer can only catch an error the interface lets them see. For each proposal, include:
- the exact action and its scope (which records, files, recipients, or accounts);
- the likely consequence and whether it can be reversed;
- the inputs or evidence the agent relied on;
- alternatives the agent considered, where relevant;
- for edits, a diff or before-and-after view instead of a description of the change.
Keep each review unit small enough to read. A forty-item batch behind one “Approve all” button invites the click-through you were trying to prevent. Split it, or group items by consequence so that the risky ones stand out.
Make approval apply to the operation that runs
The approval has to authorize the thing the reviewer saw. Three habits make that true:
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →- Render the request from the real proposed call, not from a separate natural-language summary the model wrote.
- Store the approved operation alongside the decision.
- Check at execution time that the operation being executed matches the approved one.
This matters for security as well as clarity. Approval alone is not a security boundary. Enforcement has to sit on the actual side effect, and OpenAI’s API guidance says as much: put tool-level checks near the tools that create side effects, because agent-level guardrails don’t necessarily run at every workflow boundary. For ambiguous or high-risk actions, it recommends pausing before the tool runs.
Rank #3
Pause and resume instead of failing the run
OpenAI’s Agents SDK documents a lifecycle that makes approvals much less disruptive. The tool’s approval rule is evaluated. If approval is required, the call stops before it executes, and the run returns pending interruptions. You resolve each by approving or rejecting it, then resume the original run from its saved state. The pattern also covers approvals raised inside nested agent tools.
The benefit is that a slow human doesn’t force the agent to start over. The approval can arrive minutes or hours later and the work continues from where it stopped.
Make “no” a useful answer
If declining dead-ends the task, people approve things they doubt just to keep going. Offer more than two buttons:
- Approve as proposed.
- Approve with changes, so the reviewer edits the operation instead of rejecting it.
- Ask for more information when the evidence is insufficient.
- Reject with a reason, which the agent can use to propose something else.
Keep the run resumable where it makes sense, so a rejection becomes input to the next attempt, not a crash.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Decide what happens when nobody answers
Every approval needs a timeout and a defined fallback. AWS guidance recommends that, typically, the operation be blocked if no one responds within the allowed window. A silent default to “proceed” turns the control into a delay. Choose the fallback per tier. For a low-consequence step, escalating to a second reviewer may be better than blocking. For a high-consequence step, blocking is the safer choice.
Match the mechanism to where the agent runs, too. A chat window, a ticket queue, and a batch job overnight each need a different way to reach a person.
Keep a record and watch for fatigue
Treat review as a control that needs its own evidence. Log reviewer identity, timestamps, the operation, the decision, and any escalation events. AWS also advises periodically reviewing workflow metrics for signs of reviewer fatigue or process inefficiency, and adjusting risk tiers accordingly. Useful signals to track include approval rates near 100%, very short time-to-decision on complex items, and queues that regularly hit the timeout. These are indicators to investigate, not proof of a problem on their own.
More prompts do not automatically mean more safety. The design literature raises fatigue as a reason for further study, but it isn’t established human-subject evidence. An open question is how well different permission approaches work for non-experts. A 2026 arXiv preprint compared 113 participants without professional software backgrounds across per-action human approval, automated per-action model review, and user-authored consequence policies. The abstract describes the design, not a winner, so don’t read it as showing that any one approach is best.
Quick Recap
A quick audit for your own agent
- Is each tool assigned to a consequence tier, instead of one policy for the whole agent?
- Does the prompt show scope, consequence, reversibility, and a diff where relevant?
- Is the displayed request generated from the real call, and is the approved call verified at execution?
- Can the reviewer edit, ask a question, or reject with a reason, and does the run resume?
- Is there a timeout with a safe fallback?
- Are decisions logged, and does someone review the metrics?
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
