Confirmation Design for AI Agents: When to Ask, When to Act, and When to Refuse
Confirmation design for AI agents should reserve human attention for consequential or ambiguous actions, using risk, reversibility, uncertainty, and scope to decide when to ask or act.
Confirmation is an allocation of human attention
OpenAI’s agent guidance treats human review as a control for sensitive actions, especially side effects such as cancellations, edits, shell commands, and sensitive MCP calls. [1] The important design insight is that confirmation is not free. Every prompt interrupts flow and asks the user to inspect a proposal. If everything requires approval, users stop distinguishing consequential requests from routine ones. A good confirmation policy therefore allocates scarce attention to moments where human judgment materially reduces risk.
The question is not “Can we ask?”
It is “Is this decision important enough that interrupting the user improves the outcome?”
Ambiguity should trigger clarification before execution
Microsoft’s HAX guidance recommends scoping services or disambiguating when the system is uncertain about the user’s goal. [2] “Schedule a call with Alex” should not become an external side effect if several Alexes exist. “Cancel tomorrow’s meeting” should not proceed if multiple meetings match. Asking a narrow clarification is preferable to performing a wrong action and then apologizing. In motivational systems, clarification also protects goal ownership because the agent should not silently fill value-laden gaps with its own assumptions.
Approval fatigue makes repetitive prompts less meaningful
Anthropic has described a pattern where users approved roughly 93 percent of permission prompts in one environment and noted that repeated approvals reduce attention over time. [3] This suggests that safety cannot depend on a wall of modal dialogs. The system should automatically handle low-risk actions inside constrained scopes, batch related approvals where appropriate, and reserve explicit confirmation for high-impact transitions. This makes the remaining prompts more salient and gives the user a realistic chance to review them carefully.
Frequency changes the meaning of a confirmation
A prompt that appears twice a week can be a decision; one that appears fifty times a day becomes muscle memory.
Risk classification should include reversibility and audience
The same technical tool may carry different risk depending on the target. Editing a private draft is different from sending it to a client. Moving a personal task differs from closing a shared ticket. Good policy considers financial consequence, external visibility, privacy, reversibility, permission escalation, and the number of people affected. It can also incorporate user-authored standing preferences such as “always ask before sending” while preventing those preferences from bypassing non-negotiable safety rules.
Refusal is appropriate when the action violates a boundary, not when the model feels uncertain
A trustworthy agent needs three distinct responses: ask when intent is ambiguous, act when the request is clear and permitted, and refuse when the action is disallowed or outside scope. Collapsing these states creates frustrating behavior. Excessive refusal blocks legitimate goals; excessive questioning creates friction; excessive action creates risk. The policy should be explainable in task language so users understand whether they need to clarify, grant a permission, choose a safer alternative, or accept that the system will not perform the requested action.
Ask, act, and refuse are different product states
Each needs its own language, UI, and recovery path.
Trustworthy agents keep humans in control without pretending humans can inspect everything
Anthropic’s trustworthy-agent framework emphasizes human control, transparency, secure interaction, and privacy. [4] In practice, control often means setting durable policies in advance rather than clicking every action. Users may choose that the agent can reschedule personal focus blocks automatically within business hours but must ask before moving meetings with other people. This transforms confirmation from repeated supervision into rule-setting. The user remains the author of the boundaries while the agent gains enough autonomy to be genuinely useful.
Protocol guidance supports visible confirmation around sensitive tools
The MCP tool specification recommends UI that makes exposed tools clear, visual indicators when tools are invoked, and confirmation prompts for operations, while also advising access controls and audit logs. [5] Product teams can use these principles to build consistent confirmation components across many tools. The confirmation should display the exact target and consequence, not a generic “Allow?” message, and it should never use gamified urgency or default choices to rush a consequential decision.
Consent screens should not be persuasive surfaces
The interface should help the user decide, not optimize for approval rate.
A mature confirmation policy is predictable enough to become part of the rules
Users should learn what the agent will do automatically and where it will stop. That predictability reduces anxiety and makes delegation easier. The best policy combines bounded permissions, uncertainty handling, reversibility, action semantics, user preferences, and risk-based review. It also monitors whether confirmations are being approved reflexively, which may signal that the system is interrupting too often. Confirmation design succeeds when users can focus their attention on meaningful decisions while routine, low-risk progress happens smoothly inside boundaries they understand. Confirmation policy should also be reviewed after incidents and near-misses. If users repeatedly cancel or correct a class of automatic action, the system should tighten the boundary rather than treating those corrections as noise. Conversely, if a low-risk confirmation is approved mechanically every time and the underlying action is fully reversible, the product can consider a standing preference. This makes confirmation adaptive without becoming manipulative: behavior changes the safety policy only when the user can see, understand, and reverse that change.
Works Cited
- 01OpenAI Developers — Guardrails and Human Review developers.openai.com
- 02Microsoft HAX Toolkit — Scope Services When in Doubt microsoft.com
- 03Anthropic — How We Contain Claude Across Products anthropic.com
- 04Anthropic — Trustworthy Agents in Practice anthropic.com
- 05Model Context Protocol — Tools Specification modelcontextprotocol.io
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.