← Back to Blog
Guide· 13 min read

How Voice Agents Confirm Actions: A Field Guide to Human-in-the-Loop Design

Every agent that can act on your behalf now has a confirmation step, but no two agents ask the same way. A field guide to how ChatGPT, Gemini Spark, Claude Code, OpenClaw, and mrmr actually gate write actions, and the five questions to ask of any agent before you trust it with your apps.

TL;DR: Every serious AI agent now ships a confirmation step. But “it asks before it acts” tells you almost nothing, because confirmation designs differ in the ways that matter: what triggers the gate, where the gate lives, what you actually see before approving, what your approval covers and for how long, and what happens when the agent works in the background. This is a field guide to how the agents you can use in 2026 (ChatGPT’s agent, Gemini Spark on Mac, Claude Code, OpenClaw, and mrmr) answer those five questions, and what the differences mean for your safety. The short version: the question is no longer “does this agent ask?” It’s “how, exactly?”

How AI agents confirm actions: a field guide comparing confirmation gates across ChatGPT, Gemini Spark, Claude Code, OpenClaw, and mrmr: what each one asks before it sends, deletes, or runs.

An agent that can send messages, move meetings, delete records, and run code on your behalf needs some kind of gate between its intent and your accounts. Everyone in the industry agrees on that now, and almost every product page says some version of “you’re always in control.” The phrase has become table stakes.

The gate itself is not table stakes. Two agents can both offer a confirmation step and be separated by the entire distance between safety and theater: one approval covers exactly this message to exactly this channel and is enforced by software the model can’t talk out of; the other covers “the agent wants to do something” and lives in a prompt. Both say “human in the loop.” We’ve covered what that term means and how asking about everything breaks it; this piece is about the mechanics underneath: how the agents actually shipping in 2026 draw the line.

Because the implementations diverged, and the differences are not cosmetic.

Why every agent asks, and why they don’t ask the same way

The template came from OpenAI’s agent launch in July 2025. ChatGPT agent, working on its own virtual computer, “requests permission before taking actions of consequence,” certain critical tasks like sending email require active oversight in a Watch Mode, and the model is trained to refuse things like bank transfers outright. Notably, OpenAI framed the explicit confirmation as a defense against prompt injection, an admission that an agent browsing the real web will encounter instructions trying to hijack it, and that a confirmation step is the backstop when that happens.

Every serious agent since has some version of this. But they were built for different jobs, and their gates are shaped accordingly: an agent working inside a sandboxed browser has different failure modes than a coding agent running shell commands on your repository, and both differ from a voice agent that operates your everyday apps in real time. So before comparing products, it’s worth fixing the axes of comparison.

The five questions to ask of any confirmation design

When you evaluate an agent that can act, these are the questions that separate a real safeguard from a label:

  1. What triggers the gate? A fixed classification of action types (reads never ask, writes always do), or the model’s own estimate of consequence in the moment? The former is auditable; the latter is a judgment call made by the component you least trust.
  2. Where does the gate live? In the model’s instructions, or enforced by the application below the model? A rule only the model can follow is a suggestion; large language models are non-deterministic, and injected content can be persuasive.
  3. What do you actually see before approving? The exact recipient, content, and record being changed, or a vague summary? An approval you can’t review in a few seconds isn’t review.
  4. What does your approval cover, and for how long? Does “yes” authorize one specific action, one for the session, or a whole class of future actions forever? Each grant type trades convenience against blast radius.
  5. What happens when work runs in the background? An agent that keeps working after you walk away either pauses at every write, or it doesn’t, and that answer defines how much trust “hands-free” actually requires.

Keep those five open. Every agent below can be read through them.

The field guide: how real agents confirm actions

ChatGPT agent: confirmation as a trained behavior

OpenAI’s agent asks permission before consequential actions, requires active oversight in Watch Mode for tasks like sending email, and refuses high-risk actions like bank transfers entirely. The gate is a mix: the model is trained to ask, and OpenAI’s own writeup lists explicit user confirmation as one mitigation among several for prompt injection. Your approval covers the action in front of you, and you can interrupt or take over at any time. The design leans on the model’s judgment of what counts as “consequential”, which OpenAI mitigates with training, monitoring, and refusals rather than with a deterministic classification. That’s a defensible trade for an agent whose toolset is open-ended; it’s also why the confirmation experience can vary between runs. In July 2026, ChatGPT Voice reached the desktop app, letting users start and steer agents by voice, which puts this same confirmation model at the center of voice-driven work.

Gemini Spark on Mac: the persistent agent, confirmation by exception

Google’s Spark is a different shape: a 24/7 agent that runs in the cloud and acts across your digital life under your direction, with a Mac desktop version handling local files and desktop workflow automation. The voice entry point is a press-and-hold key that reads your screen and turns rambling speech into drafts. Spark’s public documentation at press time describes actions “under your direction” rather than a specific confirmation scheme, and at $100 a month through Google AI Ultra (US-only beta) it’s aimed at people for whom the agent’s judgment is the product. For a persistent agent, one that acts when you’re not there, the questions about background writes and approval scope are the sharp ones, and Google hasn’t published detailed answers yet.

Claude Code: rules enforced by the software, not the model

Claude Code, Anthropic’s coding agent, ships the most explicit answer to question 2 that any major vendor has put in writing: “Permission rules are enforced by Claude Code, not by the model. Instructions in your prompt or CLAUDE.md shape what Claude tries to do, but they don’t change what Claude Code allows.” Its permission system is a tiered table (reads run freely within your working directories, shell commands prompt except for a built-in read-only set, file modifications always prompt) plus a rule engine where deny beats ask beats allow in fixed precedence. Approvals can be one-time, session-scoped, or saved permanently as allowlist rules per repository (“yes, and don’t ask again”). It’s the developer-workflow answer: frequent, repetitive actions get promoted to allowlists you curate, and the gate itself can’t be talked out of asking. The trade is that an allowlist is a standing grant to a class of actions: the safeguard is only as current as the rules you last reviewed.

OpenClaw: approvals bound to exact commands

OpenClaw, the open-source personal-agent framework behind the Mac-mini-as-agent-host phenomenon, takes the allowlist idea further down to the command line. Its exec approvals bind an approval to “exact request context and, when possible, one concrete local script/file operand”. And if the system can’t identify exactly one direct local file for an interpreter command, approval-backed execution is denied rather than guessed. That is fail-closed by construction: ambiguity refuses to run. Combined with conservative defaults everywhere else (unknown chat senders get a pairing code instead of a working agent, control-plane tools like config access are owner-only, and read-only profiles are a documented pattern), OpenClaw’s answer to question 4 is the strictest on this list: your approval covers one identified command, and nothing inherits it.

mrmr: approvals bound to exact actions and arguments

mrmr is a voice-first agent for Mac, which makes the confirmation design unusually load-bearing: voice removes the friction of acting, so the gate has to be reviewable at speaking speed. Its design answers the five questions like this:

  • What triggers the gate: a deterministic classification, not the model’s mood. Every action through a connected app is checked against its name: verbs like SEND, CREATE, UPDATE, DELETE are writes; verbs like GET, LIST, SEARCH are reads. A write verb anywhere in the action wins, and critically an unrecognized action defaults to mutating, so a newly added write tool can never execute unconfirmed. The bias is fail-closed, the same principle Saltzer and Schroeder called fail-safe defaults half a century ago.
  • Where the gate lives: in the app, below the model. A write is refused with a “confirmation required” error unless you have approved a card matching that exact action and its exact arguments. Change the recipient or the message text after approval and the old approval no longer counts: the model must come back with a new card. A prompt-injection attack can’t talk the gate out of asking, because the gate isn’t listening to the prompt.
  • What you see: a card with the action in plain language and one field per important argument (the channel, the message, the title, the due date), resolved to the human names you’d recognize, not raw IDs. Built to be read in a few seconds.
  • What the approval covers: that one action, once. There is no “always allow sends”: trust is granted per action. The few exemptions are deliberately narrow and low-blast-radius: reads never ask, pasting into the app you’re focused on never asks, and marking a task done skips the card because it’s trivially reversible, but only when the patch is only a status toggle; the same call carrying a content change confirms like everything else. Local, on-device actions like adding an Apple Reminder run without a card, while deleting an entire reminders list, a bigger blast radius, asks first.
  • What happens in the background: sub-agents (longer delegated runs) do reads freely while working, and every proposed write pauses the run and shows you the approval card before it executes. Stop a run, and a write it was waiting on is discarded, not sent. And the same philosophy extends to your own code: every saved script carries a confirmation flag that defaults to on, and only you can exempt a script in its own header: the agent can never grant itself that exemption.

The pattern across all of this is one sentence: trust is bound to a specific action with specific arguments, enforced by software, and never inherited.

What the comparison actually shows

Three distinct philosophies emerge, and they map cleanly onto the five questions:

  • Consequence-estimated confirmation (ChatGPT agent): the model judges what’s consequential and is trained to ask. Flexible for an open-ended toolset; the gate lives, in part, in the component you least trust, backed by monitoring and refusals.
  • Curated allowlists (Claude Code, OpenClaw): you grant standing permission to classes of actions, and the software enforces the rules regardless of what the model tries. Efficient for high-volume, repetitive work; the grant is a standing one, and its blast radius grows with every rule you forget to prune.
  • Exact-action binding (OpenClaw’s exec approvals, and mrmr’s confirm cards across every connected app): every approval is one specific action with specific arguments, and ambiguity fails closed. Maximum review per action, and the ask-per-write cost is paid constantly, which is only tenable if the exemptions are ruthlessly calibrated so the cards you do see are worth reading.

None of these is uniformly “safest.” An allowlist beats a card for your hundredth npm test; a card beats an allowlist for your first Slack message to a new channel. What’s not defensible is the fourth pattern the market keeps drifting toward: a confirmation step that exists in the prompt and nowhere else, presented as a safety feature. Given non-deterministic models and injection attacks that ride in on the content agents read, a gate the model can skip is not a gate.

Why this matters

Voice agents are making acting cheap. Saying “reschedule the demo and tell the room” is faster than any keyboard workflow, and speed is exactly what makes the confirmation design the product: you will approve many actions a day, quickly, which means the properties that used to be nice-to-haves (what you see, what the approval covers, where the gate lives) are now the entire safety story. Before you hand an agent your apps, ask the five questions. And be suspicious of any agent that can’t answer them in one sentence each, because the vendors who can, will.

Sources

Frequently asked questions

What does a human-in-the-loop confirmation look like in an AI agent? At minimum, the agent pauses before an action with real consequences and shows you what it intends to do before executing. A well-designed one shows the exact details (recipient, content, record), binds your approval to that exact action, and enforces the pause in the application itself rather than trusting the model to follow instructions. The full framework is in What Is Human-in-the-Loop AI?.

Which AI agents ask for confirmation before acting? ChatGPT’s agent asks permission before consequential actions and requires active oversight for critical tasks like sending email. Claude Code prompts for shell commands and file edits except for built-in read-only commands and rules you’ve allowlisted. OpenClaw requires per-node exec approvals, binding each approval to an exact command and operand. mrmr shows a confirmation card before every write action in a connected app. Gemini Spark acts “under your direction” but hasn’t published detailed confirmation behavior at press time.

What’s the difference between an approval allowlist and an exact-action approval? An allowlist (“always allow npm run * in this repo”) is a standing grant to a class of future actions: efficient for repetitive work, but its blast radius grows as you forget to prune it. An exact-action approval authorizes one specific action with specific arguments and nothing else: maximum review per action, at the cost of approving more often. Most agents mix both; the design question is which one the consequential actions get.

Why does mrmr skip confirmations for some actions? Because confirming everything trains you to rubber-stamp (see approval fatigue). Reads never ask because there’s nothing to approve. Genuinely low-risk, reversible actions (pasting into the app you’re focused on, marking a task done, adding a local reminder) skip the card so the confirmations that remain are worth reading. Anything unrecognized defaults to asking, and high-blast-radius local actions like deleting an entire list confirm like everything else.

Can a prompt-injection attack bypass a confirmation step? It depends on where the gate lives. An instruction that says “confirm consequential actions” lives in the model, and injected content can influence the model; that’s the attack vector. A gate enforced by the application, below the model, binds execution to an approved action with exact arguments, so manipulated instructions can’t substitute a different action or different arguments. The confirmation still appears; the attacker just can’t change what’s on it without the change being visible.

Try it

mrmr is a voice-first AI agent for Mac. It takes real action across your work apps and your Mac, and it’s built around the design this piece describes: a deterministic gate below the model that binds every approval to an exact action and its exact arguments, calibrated exemptions so the cards you see are worth reading, and background sub-agents that pause for every write. It’s currently in private beta.

Join the private beta → Book a 20-minute setup call →

Related reading:

Private beta

Get private beta access

Book a short setup call or join the invite list for Agent Mode access.

Book 20-min setup Join private beta