An agent asks a reviewer to approve every action. The first request is a $12 refund. The tenth is a role change. The fiftieth is a bulk export. The reviewer learns the fastest path is to click “approve” before opening the details.
Human approval can reduce risk, but only when the reviewer has a real chance to understand and change the decision. If the workflow generates too many low-value approval prompts, the review step becomes a ritual, and the most important action gets the same attention as a harmless tag update.
Approval fatigue is not solved by removing humans from the loop or by adding a more capable model. It is a workflow-design problem: which decisions need approval, what evidence the reviewer sees, how actions are grouped, and what happens when the reviewer disagrees. This article lays out a risk-based approach for AI agent workflows that keeps approvals meaningful without turning them into a bottleneck.
Approval is a scarce control, not a checkbox
An approval has value only if it changes what would otherwise happen. A user who approves a specific payment after checking its target, amount, and evidence is exercising control. A user who clicks “approve all” because the queue has 300 items is not.
Before adding an approval step, ask:
- What risk does this approval reduce?
- What evidence does the reviewer need to see?
- What authority must the reviewer have?
- What action is blocked until approval happens?
- Can the action be undone or compensated later?
- What should happen if no one reviews it in time?
If you cannot answer those questions, the approval control is probably decorative. It may still add latency and labor while leaving the actual failure path untouched.
OWASP’s LLM06:2025, “Excessive Agency,” recommends minimizing permissions and requiring human approval for high-risk actions. The phrase “high-risk” is doing important work: not every operation deserves the same interruption. (OWASP, LLM06:2025 Excessive Agency)
Classify actions by consequence before deciding who approves
Approval policy should be attached to the action, not to the agent as a whole. An assistant may safely add an internal label but need approval to send a customer email and a stronger approval to issue a refund.
A practical risk table might look like this:
| Action | Typical risk | Possible control |
|---|---|---|
| Draft a summary | Low; no side effect | No approval; label as AI-generated |
| Add a reversible internal tag | Low to moderate | Auto-apply within a narrow schema; easy undo |
| Send a customer reply | Moderate; external communication | Review during pilot; automate only bounded templates |
| Change account ownership | High; access and workflow impact | Authorized approver, exact target and diff |
| Issue a refund or payment | High; financial side effect | Amount threshold, policy check, explicit approval |
| Delete or export restricted data | High; often difficult to reverse | Strong authorization, separate confirmation, audit |
The categories depend on your product. A “tag” can be consequential if it triggers a compliance workflow; an email can be low-risk if it is a pre-approved transactional notice. Make the classification explicit and review it when the business process changes.
1. Approve the exact proposal, not “the agent’s plan”
A reviewer should approve a concrete action: target record, operation, parameters, evidence, and expected effect. “The agent wants to update this account” is too vague.
For a record update, show a before/after diff. For a refund, show the payment, amount, currency, eligibility rule, and whether a prior refund exists. For a message, show the exact text and recipients. The approval should bind to that precise proposal version.
If the model changes the amount or target after the review screen opens, invalidate the approval. If the record changes before execution, re-read it and require re-approval when the change affects the decision. This is a time-of-check/time-of-use boundary: the reviewer authorized one state, not every future state.
The server must validate the approver’s authority at execution time. A button hidden from unauthorized users is not enough. The approval record should contain the reviewer identity, proposal hash, policy version, timestamp, and final execution outcome.
2. Route low-risk actions away from the human queue
The most direct way to reduce fatigue is to stop asking humans to approve actions that do not need them. Low-risk, reversible operations can often be automated with deterministic limits and a visible audit trail.
Examples include:
- applying a topic tag from a closed vocabulary;
- saving a draft without sending it;
- adding a suggested label to an internal queue;
- generating a proposed update that a user can undo;
- refreshing an index or cache from trusted source data.
Automation should still be bounded. Enforce field constraints, per-tenant limits, and access checks in code. The model may choose a label, but the backend validates it against the allowed set. If the classifier returns an unknown value, route to review rather than inventing a new category.
Do not use approval as a substitute for authorization. A reviewer cannot legitimize an action the user had no right to request unless the reviewer is explicitly acting with that authority and the audit record says so.
3. Use thresholds that reflect risk, not queue convenience
Thresholds can route actions by amount, sensitivity, confidence, reversibility, or data scope. They should be defined by the business policy and enforced below the model.
For example:
- automatic refund only for a confirmed duplicate charge under a configured limit;
- human approval for larger amounts or conflicting payment state;
- no automated deletion of customer records;
- review for a permission change affecting an administrator role;
- no action when the model’s required fields are missing.
Avoid universal confidence thresholds. A model score may not be calibrated, and “0.92 confidence” does not mean the same thing across tasks or model versions. Use observable criteria: policy checks passed, source data agrees, schema is valid, target is unambiguous, and action is within limits. For subjective judgments, calibrate against human labels and monitor disagreements.
If a threshold changes, treat it like a policy release. Version it, evaluate the affected slices, and keep a rollback path. Otherwise approval volume may spike or fall without anyone knowing which rule changed.
4. Design the review queue as a workbench
A queue should reduce the cognitive effort of review, not merely move the agent’s uncertainty to another screen.
Each item should show:
- the requested outcome in plain language;
- the exact proposed operation and target;
- the source records or evidence used;
- the policy checks that passed and those that failed;
- what the model could not determine;
- whether another action already occurred;
- controls to approve, edit, reject, ask the user, or escalate.
The reviewer should be able to inspect evidence without leaving the workflow, but the system should not display data the reviewer is not authorized to see. Use a concise summary first and make details available on demand. A 100-line model rationale is not a substitute for the relevant source record and policy rule.
Batch review can help for low-risk homogeneous items. Show the number of records, summarize the action, surface exceptions, and let the reviewer remove individual items. Do not batch together actions with different consequences just because they arrived in one run.
5. Prioritize and cap review volume
If every uncertain case goes to the same queue, the queue eventually becomes the product. Prioritize by impact and deadline. A suspected unauthorized payment should outrank a low-priority content tag. A task close to expiration may need escalation even when it is not the highest severity.
Set a review capacity budget. If the incoming rate exceeds staffing, the system should respond deliberately: narrow automation, pause new tasks, route to a different qualified team, or explain a longer wait. It should not silently auto-approve when the queue is full.
Useful operational metrics include:
- queue age and backlog by action class;
- reviewer time per item;
- approvals, edits, rejections, and “need more information” outcomes;
- overturned approvals and downstream corrections;
- duplicate or stale proposals;
- items approved without opening evidence;
- percentage of escalations that become completed tasks.
The last metric helps detect a queue that only accumulates work without resolving it. The “approved without opening evidence” metric is not a definitive measure of fatigue, but a sharp increase can signal that the review surface is no longer useful.
6. Give reviewers a meaningful disagreement path
Approvers should not be forced into “approve” or “reject” when the right response is “the agent has the wrong customer,” “the source is stale,” or “I need clarification.” Provide structured rejection reasons and a path to request more information.
Capture corrections in a way that improves the system:
- was the target wrong?
- was the action disallowed?
- was the source data incomplete?
- did the proposal use an outdated policy?
- did the reviewer have context the agent lacked?
These categories help decide whether to change retrieval, data quality, policy, prompt, or tool schema. Do not feed every reviewer edit straight into prompt examples; the edit may reflect an exception or an inconsistent human choice.
For a rejected high-risk action, keep the operation in a terminal or review-needed state. Do not automatically ask another agent to generate a new proposal until the reason is understood. Otherwise the system can turn one rejection into a series of increasingly aggressive attempts.
7. Do not let review become a security bypass
An approval path can itself be attacked. A malicious document may tell the agent to send a proposal to a particular employee. A user may try to influence the displayed rationale. A reviewer may approve based on a misleading summary while the underlying parameters differ.
Controls should include:
- server-side authorization of both the requesting actor and approver;
- reviewer assignment from trusted policy, not model-supplied names;
- approval bound to a proposal hash and current resource version;
- separation of duties where the action warrants it;
- secure display of source material and escaped output;
- an audit event for approval, edit, rejection, and execution;
- idempotency so a duplicate click does not repeat the action.
Approval is not a permission token that the model can forge. The server should confirm that the approver is authorized for that specific action and that the approved proposal has not changed.
8. Measure fatigue without punishing fast reviewers
Fast approval is ambiguous. A reviewer may be experienced and confident, or may be clicking through a queue they no longer trust. Do not set a blanket minimum review time; that can punish efficient staff and create artificial delays.
Use multiple signals:
- sample a portion of approved cases for independent audit;
- compare approval patterns by risk and reviewer workload;
- monitor edit and reversal rates;
- ask reviewers whether evidence was sufficient;
- examine whether reviewers open the source records;
- compare queues before and after introducing batch approval;
- monitor the time from proposal to decision and downstream errors.
If approval accuracy drops while queue volume rises, reduce the number of low-risk interruptions, improve grouping, or narrow the feature. Do not simply increase mandatory clicks. A control that people bypass mentally is not functioning as intended.
9. Calibrate automation with shadow and staged modes
Before expanding autonomy, compare agent proposals with existing decisions in shadow mode. The model should not execute writes during this stage. Review disagreement by action type and source of truth. Human behavior may itself be inconsistent, so domain owners should resolve policy questions rather than treating every historical action as ground truth.
A practical progression is:
- Draft-only, no side effects.
- Shadow proposals alongside the existing workflow.
- Human approval for a narrow, well-defined action.
- Bounded automation for reversible, low-risk cases.
- Broader automation only after the exception path and kill switch are proven.
The exit criteria should reflect consequences. A label can tolerate a different error rate from a payment or access change. Keep difficult and rare cases in review even when the common path is automated.
Distinguish approval from confirmation
Approval is a policy decision made by someone authorized to decide whether an action is allowed. Confirmation is a user acknowledging that the system is about to do something on their behalf. A workflow may require both, but they are not interchangeable.
For example, an employee may confirm that they want an address changed, while only a shipping administrator can approve an exception outside the normal change window. A system that treats the employee’s confirmation as the administrator’s approval has collapsed two different authorities into one click.
Design the UI and audit trail so the role is clear. Record who requested the action, who approved it, and who executed it. If the requester is also allowed to approve, the policy should explicitly permit self-approval. For sensitive financial or access changes, a separation-of-duties rule may require different people; enforce that in code, not with a prompt instruction.
The model may explain why approval is needed or prepare the evidence packet. It should not select an approver based on a name found in a document. Route to a trusted queue derived from policy and resource ownership.
Match reviewers to the decision they can make
Reviewers need domain knowledge and authority that match the proposal. A support agent may verify whether a response is accurate and empathetic, but may not be authorized to approve a refund above a threshold. A security analyst may evaluate access scope, but not decide whether a customer receives a contractual credit.
Use role-specific queues and review forms. Show the evidence relevant to the decision and hide unrelated material. A reviewer who has to infer the business context from a long transcript is more likely to approve the model’s summary than the underlying action.
Where decisions are subjective, define the rubric with the responsible team and include examples of acceptable and unacceptable outcomes. Where decisions are deterministic, encode the rule and reserve human review for exceptions. Asking people to repeatedly approve actions that code could validate adds fatigue without adding judgment.
Track reviewer disagreement. If reviewers routinely disagree with one another, the policy may be underspecified. A model cannot consistently satisfy a rule that the organization has not agreed on.
Use queue capacity as a safety signal
A rising queue is not just an operations inconvenience. It can mean that the model is producing too many uncertain proposals, a policy changed, a source system is degraded, or the review threshold is too broad.
Define queue thresholds that change system behavior. For example, if the high-risk queue exceeds its service target, pause new autonomous writes and keep creating drafts. If a low-risk queue grows, batch similar cases or reduce unnecessary review. The correct response depends on the action class; never clear a backlog by silently approving pending items.
Give the queue an explicit backpressure behavior. If reviewers are unavailable, tell the user that the task is pending and provide a status reference. If the task has a deadline, say whether it will expire. If the action cannot safely wait, stop it and ask the user to retry through the established manual path.
Measure queue age and throughput alongside model quality. A 98% proposal acceptance rate may still be a poor product if each proposal requires five minutes of review and the queue takes two days to clear.
Show evidence, not a persuasive monologue
Reviewers need the facts that support a decision, not a long generated explanation that sounds confident. Show source records, values, timestamps, policy checks, and any fields the model could not resolve. If the agent cites a source, make the reference open the authorized original or a safe excerpt. Do not make the reviewer trust an unverified summary of evidence.
Avoid relying on a model-generated confidence score as the reason to approve. A score may not be calibrated and can vary across tasks or model versions. Use deterministic checks for exact conditions, and treat uncertainty as a reason to inspect or route—not as a probability that the proposal is correct.
Minimize the data shown in the review panel. A reviewer who only needs to approve a refund amount may not need the complete conversation history. Keep access checks active in the review UI and log views. Approval screens are still access-controlled products, not a reason to make all context visible to every reviewer.
When the reviewer rejects a proposal, preserve the specific reason without asking them to write a postmortem. Short reason codes such as wrong_target, policy_exception, or missing_context can make recurring patterns visible, while an optional note captures nuance. Do not force a single category when the issue is genuinely unknown. Review the taxonomy with the teams that will act on it.
A reviewer-oriented checklist
Before shipping an approval workflow, verify:
- Each approval corresponds to a concrete, immutable proposal.
- The reviewer sees target, parameters, evidence, and policy outcome.
- The server validates reviewer authority at execution time.
- Low-risk actions are not needlessly sent to the queue.
- Queue capacity, priority, and expiration behavior are defined.
- Reviewers can edit, reject, request context, and escalate.
- Approval fatigue and downstream reversals are measured.
- The agent cannot change the proposal after approval.
- A kill switch stops pending writes without deleting audit history.
- Corrections feed a reviewed improvement process, not blind prompt tuning.
The right goal is not “a human approves every agent action.” It is “a human spends attention where it can change a consequential decision.” Reduce routine interruptions, make risky proposals understandable, and preserve a safe path when the reviewer is unavailable. That is how approval remains a control instead of becoming another button people learn to ignore.