Human Approval Patterns for AI Agent Actions

Approval is an authorization decision

A generic “continue?” prompt is weak control. The reviewer must understand what will happen and have authority to permit it. Approval belongs after the agent has formed a concrete, validated proposal but before the side effect. If the destination, amount, content, tool, or environment changes, the old approval no longer applies.

Separate model judgment from authorization. The model may propose a refund, message, deployment, record update, or data export. Application policy determines whether it is forbidden, automatically allowed, or requires a named human role. The execution service verifies the decision. Natural-language instructions can explain policy but should not be the sole enforcement boundary.

Select the lightest control that matches consequence

Pre-action approval fits irreversible, external, privileged, high-value, or novel actions. Deterministic policy can handle low-risk calls with known constraints. Sampled review measures quality but cannot prevent a specific harmful action, so it is unsuitable where one mistake is unacceptable. Break-glass is not a shortcut for normal work; it needs exceptional identity, time limits, incident linkage, and retrospective review.

Define the approval boundary

Inventory actions and score consequence, reversibility, data sensitivity, destination trust, novelty, value, and detectability. Convert the score into explicit rules. For example, drafts may be automatic, messages to known internal recipients may use policy approval, new external recipients may require a person, and bulk sends may be prohibited until a separate campaign process is used.

Place the pause as late as possible while leaving time to decide. Approving a broad plan at run start forces the reviewer to imagine unknown future actions. Pausing after execution turns approval into notification. The useful point is after tool name and normalized arguments are known and policy has enriched them with risk context.

Present a decision packet, not a transcript

The interface should show action type, environment, acting identity, target, important arguments, before-and-after preview, data classification, expected side effects, reversibility, estimated cost, evidence, policy rule, and expiry. Highlight differences from an earlier approved or familiar action. Hide secrets while preserving enough identity for an informed choice.

Offer approve, reject, and edit only when each has defined semantics. Editing must run schema and policy validation again. Rejection should stop the call and return bounded feedback; it must not invite the model to disguise the same action under another tool. Ask for a reason when it improves policy or evaluation, but do not burden urgent low-frequency decisions with unnecessary fields.

Use a durable state machine

Persist before returning the approval request. Store a stable run and tool-call identifier, normalized arguments, policy and code version, model and prompt version, proposed effect, approval state, identity, timestamps, and idempotency key. Encrypt and restrict the record because serialized agent state may include sensitive context.

On resume, load the same state, verify integrity, re-check expiry and policy, and ensure the call has not already executed. Some runtimes restart the interrupted node; code before the interrupt may run again. Keep pre-interrupt side effects idempotent or move them after the decision.

Handle expiry, change, and unavailable reviewers

Every pending decision needs an owner, deadline, and safe timeout. Default to no execution after expiry. A new price, permission, destination state, user request, tool version, or policy version can invalidate the proposal before the deadline. Material change creates a new proposal rather than reusing approval.

Escalation should name the next authorized role and preserve a concise packet. Avoid silently routing every timeout to a more powerful approver. For urgent operations, define a break-glass procedure before the incident, including authentication, narrow scope, automatic expiry, monitoring, and mandatory review.

Prevent approval fatigue

If reviewers approve nearly everything, the boundary may be too broad or the interface may not reveal risk. Measure volume per reviewer, time to decision, approval and rejection rates, edit rate, expiry, repeated proposals, defects after approval, and actions blocked automatically. Interview reviewers about confusing fields and missing evidence.

Reduce noise by constraining tools, defining safe parameter ranges, grouping genuinely atomic actions, and automatically deciding low-risk cases with tested policy. Never solve fatigue with blanket “always approve” for a powerful tool. Sticky decisions should be limited to a run, identity, tool, argument boundary, and time window, with visible revocation.

Test the complete approval lifecycle

1. Approve, reject, edit, partially resolve, and let proposals expire.
2. Restart workers and deploy compatible changes while decisions are pending.
3. Attempt resume with the wrong user, role, thread, call, or modified arguments.
4. Submit duplicate decisions and duplicate execution requests.
5. Change external state after approval but before execution.
6. Verify logs, notification, idempotency, compensation, and result validation.

Include hostile content that tells the reviewer or agent to bypass policy. Retrieved text and model explanations are untrusted input. The approval service should render normalized fields and trusted policy context separately from untrusted content.

Approval policy worksheet

For every action, record tool, normalized effect, acting identity, possible targets, data class, monetary or operational value, reversibility, detection time, default policy, eligible approver role, expiry, evidence shown, idempotency method, and validation. Review combinations as well as individual calls: several low-value writes can become a bulk or cumulative high-impact action.

Audit decisions by policy version and outcome. Investigate frequent edits, repeated rejection, approvals followed by compensation, requests that expire without ownership, and actions reviewers consistently approve without reading. Use those findings to narrow tools, improve the decision packet, automate genuinely safe rules, or remove a capability.

Include accessibility and operational continuity in the interface review. Reviewers need clear language, keyboard and assistive-technology support, unambiguous time zones, and a way to transfer responsibility during absence. A technically durable pause is not useful when the responsible person cannot discover or understand it.

Test notification failure separately from approval state. A missing email or chat alert must not convert a pending action into approval. The durable queue remains authoritative, supports reminders and reassignment, and exposes overdue decisions to operators without revealing sensitive arguments in notification channels.

Measure reminder volume and reviewer workload so delayed decisions remain visible without creating alert fatigue.

Limitations

Human approval does not transfer all responsibility to the reviewer or guarantee correctness. People can be rushed, deceived, unauthorized, or unable to assess a technical consequence. Strong defaults, least privilege, deterministic validation, and post-action monitoring remain necessary.

Requirements vary by law, industry, organization, and action. This guide is an engineering pattern, not legal advice. Extremely high-impact decisions may require separation of duties, multiple approvers, formal records, or may be inappropriate for agent execution at all.

Related guides

Evaluate approval behavior with the agent release framework, record it through the observability guide, and define tool boundaries with the security checklist. The Agents SDK vs LangGraph comparison covers runtime tradeoffs.