Most agentic UX advice tells you to add a “confirm before you act” step. Almost nobody tells you when you shouldn’t need one.
I recently used two different AI agents, and they made very different calls.
The first one was a coding agent. I asked it to “clean up the names in this module.” It renamed a variable across forty files, ran the tests, and gave me a short summary when it was done. It showed no preliminary plan. It didn’t ask, “Shall I proceed?” It simply did the work.
The second was an email assistant integrated into a completely different tool. When asked to reply “thanks, received” to a message that clearly required nothing more, it paused and asked: “I have drafted this reply. Should I send it?”
Neither agent did something wrong, exactly. But put side by side, the difference feels backwards. The agent that touched dozens of files just went ahead. The agent sending one harmless email asked for permission first.
If you’ve built or used AI agents, you must have likely observed the same thing. Sometimes friction arises where it isn’t needed, while it lacks where it matters most.
So, how should an agent decide when to simply get the work done and when to pause and consult you first? In this blog, I will explain a simple way to approach this issue: a framework for assigning the right level of autonomy to each action, thereby preventing teams from adding unnecessary approval steps in some cases, while leaving risky actions on autopilot in others.
A big list of patterns doesn’t tell you which one to use
If you’ve read recent articles about agentic UX, you have probably seen the same advice again and again: ask before acting, show a plan first, get approval at checkpoints, keep the user updated, let actions be undone, and be clear about what the agent can and can’t do.
These are all real and useful. I have spent a lot of time studying them myself. But almost none of that writing answers the harder question: for this specific action, which pattern applies, and how much friction does it actually need?
Without a clear way to decide, teams fall into one of two mistakes.
Mistake one (over –gating)
This means asking the user to confirm almost every action, because it feels safer that way. But it doesn’t actually make things safer, it just wears people down.
Once someone has clicked “Approve” over and over on things that were clearly fine, they stop reading before they click. Eventually they are approving everything on autopilot, including the one action that actually needed a second look.
It’s a lot like cookie banners. Nobody reads them anymore. People just hit “Accept All” and move on. So the approval step is still technically there. It’s just not doing its job anymore.
Mistake two (under-gating)
Giving the agent too much freedom because asking for approval all the time is annoying. This works until something goes wrong. A coding agent might merge changes that no one reviewed. A support agent might promise a refund it wasn’t authorized to offer. An AI agent might make an expensive or risky decision before anyone even notices.
When teams analyze what happened, the explanation is often: “The agent was allowed to do that.” And therein lies the problem. At the time, the agent was granted broad autonomy, but no one stopped to consider whether every action warranted such a level of trust.
Both failures stem from the same root cause: treating autonomy as a global setting rather than as a decision to be made on an action-by-action basis, depending on what is actually at stake.
Two questions, not one setting
The framework I have found useful and the one I want to walk through here starts with two questions. You can ask about any action an agent is about to take, not about the agent as a whole:
Can this be undone, and how cheaply? A drafted email that hasn’t been sent is trivially reversible. A sent email is not. A code change on a branch is cheap to revert. A production deploy is not. A reordered to-do list costs nothing to fix. A wire transfer does.
If this goes wrong, how far does the damage spread? Renaming a local variable affects one file. Sending an external email affects your relationship with a customer. Modifying a shared production database affects everyone downstream. Filing a legal document affects the company.
Call these two things reversibility and impact. If that sounds familiar, it should, it’s the same reversibility/blast-radius risk matrix used in change management and incident response, just applied here to individual agent actions instead of infrastructure changes. What’s new isn’t the matrix itself. It’s using it as the actual design decision for agent products, action by action, instead of a background risk exercise that only the ops team ever sees.
If you cross-reference these two variables, you get a simple grid and more importantly a predetermined answer regarding the appropriate level of friction for each quadrant. I call this the “autonomy dial,” because the goal is not to set a single level of autonomy for the entire agent, but rather to adjust the dial independently for each action it might perform.
The autonomy dial: reversibility × impact, and the four default responses that fall out of it. (Image Caption)
Four quadrants, four defaults. Let me walk through what each looks like with actual agent behaviors, because the grid means nothing until you see it applied.
Reversible + low impact: “just do it.”
The coding agent renaming variables across forty files, as long as it’s working on an uncommitted branch, belongs here. So does an agent reordering a personal to-do list, adjusting the formatting of a document, or trying three different search queries before settling on one.
Nothing here needs a plan preview, a confirmation dialog, or even much visibility beyond “here’s what I did.” Adding friction to this quadrant is pure cost. It’s the number-one source of the confirmation fatigue that erodes trust in every other quadrant.
Irreversible + low impact: “notify, don’t ask.”
This is the quadrant people most often get wrong, because “irreversible” sounds scary and triggers a reflex to add a checkpoint. But irreversibility only matters in proportion to impact. An agent that sends a Slack message to a private scratch channel, logs a note to itself, or posts an internal comment on a draft document can’t take that action back, but if it’s wrong, the cost of being wrong is a mildly awkward message, not a disaster.
The right pattern here is autonomous execution with a lightweight, glanceable notification (“I posted a note in #eng-notes”) rather than a pre-action approval gate. This is also where a lot of “agent memory” writes belong: remembering a stated preference is technically hard to fully undo, but low-stakes enough that asking permission every time is overkill. Surface it, let the user correct it, don’t gate it.
Reversible + high impact: “act, but make it easy to reverse.”
A coding agent modifying a shared feature branch, a document agent rewriting a shared spec, an agent restructuring a spreadsheet used by a whole team.
These can affect multiple people, but the damage is recoverable if you catch it fast. The right investment here isn’t a blocking checkpoint before the action. It’s strong progress visibility during the action and a real undo after it, not a vague “review changes” link, but an actual one-click revert to the prior state.
Teams that build a good rollback mechanism can often afford to be more autonomous here than instinct suggests, because the safety net does the work a checkpoint would otherwise have to do.
Irreversible + high impact: “stop and ask.”
Sending an external email to a customer, executing a financial transaction, deploying to production, deleting a shared file, submitting a legal or compliance document.
This is the only quadrant where a blocking human-approval checkpoint is unambiguously worth the friction it costs. If you use this pattern here and nowhere else, it will actually get read, because the user hasn’t been trained to click through it on autopilot.
The dial isn’t fixed: confidence moves it
Impact and reversibility describe the action. They don’t describe how sure the agent is that it’s about to do the right thing, and that matters too. A third variable, the agent’s own confidence, nudges an action one notch along the dial in either direction. But “confidence” only means something if you can point to the number behind it. In practice, three signals do the job, and they’re all things you can actually log:
Per-action success rate over a rolling window. Not “the agent overall,” but this specific action type, e.g. “reply to a Tier-1 billing ticket” or “rename a local variable,” measured over its last N executions.
User correction and undo rate on that action type. How often a human edited the draft, reverted the change, or overrode the outcome after the fact. This is a better signal than success rate alone, because it catches the cases where the action “succeeded” by the system’s own check but a human still didn’t trust it.
N consecutive clean runs before a gate relaxes. A concrete threshold (say, 20 in a row with no correction) that has to be hit before an action is allowed to move down a friction level, rather than a vibe-based “it’s been fine lately.”
A low-confidence action, one that’s new or has a thin or mixed track record on these signals, gets pushed toward more friction than its quadrant would otherwise suggest. An agent attempting a database migration it hasn’t run before should ask, even if past migrations of this type were routine.
A high-confidence action, with a strong rolling success rate, a near-zero correction rate, and a long clean streak, can earn its way toward less friction over time. An agent that has correctly triaged the last fifty support tickets of a given type, with zero human corrections on any of them, can reasonably be trusted to triage the fifty-first without a checkpoint, even though “reply to a customer” nominally sits in a higher-friction quadrant.
The failure mode this invites is real, and worth naming. A streak looks identical whether the action is genuinely safe or has simply not yet hit the input that breaks it. Fifty clean support-ticket replies tell you very little if all fifty were the same easy refund-status question. “Hasn’t broken yet” is not the same signal as “won’t break.” Two guards keep the streak honest.
First, the track record has to be stratified by input variation, not just repetition count. A clean streak across a deliberately diverse sample of the action’s real input distribution counts; fifty near-identical cases don’t.
Second, cap how far a streak can move an action regardless of length. A track record can pull an action down one notch on the dial (say, from “stop and ask” to “act, but make it reversible”), but never straight to “just do it.” The irreversible-and-high-impact quadrant keeps a human in the loop no matter how long the streak, because that’s exactly the quadrant where a rare, high-cost miss is what you’re guarding against.
I think of this as a trust ratchet. Autonomy for a specific action expands gradually as the agent earns a track record on that specific action, and contracts immediately, not gradually, the moment it gets that action wrong or a human corrects it. Trust should be slow to build and fast to lose.
A single miss should reset the streak counter to zero and, for anything above the lowest-friction quadrant, drop the action back a full notch rather than just pausing the count. Most agentic products currently do the opposite: they grant broad autonomy on day one because it demos well, and only add friction reactively after something breaks.
Putting it to work
If you’re building an agentic feature, the exercise that actually changes outcomes is not “read the pattern list and pick a few.” It’s this:
List out every distinct action your agent can take. For each one, ask the two questions: can this be undone, and cheaply? If it goes wrong, how far does the damage spread? Plot the action on the grid. Let the quadrant set your default level of friction, not your gut instinct or how nervous the action makes your legal team feel.
Then revisit the grid every time the agent gains a new capability, because a single new tool, say, giving your coding agent the ability to run git push, can move an entire cluster of actions from one quadrant to another overnight.
Done honestly, this exercise usually surprises teams in both directions: they find low-stakes actions they’ve been needlessly gating, and high-stakes actions they’ve been letting run free because nobody had mapped the actual blast radius.
The point isn’t less friction. It’s friction spent where it counts.
The instinct in agentic UX right now is to treat every added confirmation as a safety win and every removed one as a risk. Neither is true in isolation. A confirmation step you add to a trivial action doesn’t make the product safer.
It spends down the user’s attention, and attention is the exact resource you need intact for the one action that actually deserves it. Autonomy isn’t a single global switch you set once when you ship the product. It’s a dial, set independently for every action your agent can take, based on what happens if that specific action goes wrong and how hard it would be to take back.
Get that calibration right, and users stop experiencing your agent as either recklessly autonomous or exhaustingly needy. They start experiencing it as something that knows the difference.
About Author
Virendra Singh Panwar, is an alumnus of IIT Gandhinagar. He is passionate about exploring emerging technologies and turning them into business advantage. Virendra works with startups and global tech leaders to help them leverage cutting-edge innovations for greater productivity, scalability and returns.
