AI agents in SaaS need an approval experience, not an approve button

Agents are arriving faster than the design for them

AI agent UX has become a practical question for most SaaS product teams this year. Gartner predicts that 40 percent of enterprise applications will include task-specific AI agents by the end of 2026, up from less than 5 percent in 2025. An agent does not just answer a question. It changes records, sends messages and moves money inside someone else's business.

Gartner also predicts that more than 40 percent of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. That last reason is partly a design problem. Risk control in a product is a set of screens: what the agent shows before it acts, who approves it, and what anyone can see and reverse afterwards.

The approve button is where oversight goes to die

The first version of most agent features puts a confirmation dialog in front of every action. It feels safe. In practice it trains people to stop reading.

Human factors research saw this long before language models. Raja Parasuraman and Victor Riley's 1997 review of how people use automation described two failure modes. Misuse is over-reliance, where people stop monitoring a system that is usually right. Disuse is abandonment, often driven by false alarms. An agent that asks for approval fifty times a day produces both: reviewers click approve without reading, and the ones who do read decide the feature is more work than it saves.

This is the same pattern behind why the AI features people like best can lead to worse decisions. An approval nobody reads is not oversight. It is a liability with a button on it.

Match autonomy to risk and reversibility

The fix is not more approvals or fewer. It is deciding, action by action, how much the agent may do alone. Two questions settle most cases. Can the action be undone? And what does a wrong one cost, and to whom?

The answers place each action on a ladder. Suggest: the agent proposes and a person does the work. Draft for approval: the agent prepares the change and a person approves it. Act with undo: the agent acts and the change stays reversible for a set window. Act and report: the agent acts and records it.

Tagging a support ticket can act and report. Updating a customer's billing address can act with undo. Issuing a refund or emailing a customer should be drafted for approval, because neither can be taken back. Most products jump from the first rung to the last and skip the third, which is the one that makes autonomy safe.

Show the plan before the work

For anything above a single small action, an agent should show its plan before running it: which records it will touch, which systems it will write to, and what it will send, in plain language. A plan is far easier to review than a finished result, and it is where a misunderstood request gets caught.

Microsoft Research's Guidelines for Human-AI Interaction, published at CHI 2019, describe the same principle as scoping services when in doubt: when a system is unsure of what a person wants, it should disambiguate before acting rather than guess. For an agent, that means asking one clarifying question, or presenting two interpretations, before touching anything.

Design the approval around the change

When an action does need approval, the screen should be about the change, not the agent. Show what will be different afterwards, as a before and after for the fields involved. Show the scale: how many records, which customers, how much money. Show the reason the agent gave, in one line.

Then give the reviewer real choices: approve, edit before approving, reject with a reason, or send it to someone else. Approvals of the same kind should arrive as one batch with exceptions pulled to the top, rather than as fifty identical dialogs. The goal is that the person approving spends their attention on the cases that need it.

Undo is the cheapest trust you can buy

Microsoft Research's guidelines also call for efficient correction, and its HAX Toolkit lists undoing automated actions among the patterns for it. In agent features, undo does more for trust than any explanation. A reversible action lets people let go, because a mistake costs a click rather than an incident.

Undo needs real design work: a clear window in which the change can be reversed, a visible way to reverse it from wherever people notice the problem, and an honest account of what cannot be undone. A sent email or a processed payment is final, which is exactly why those actions stay at the approval rung.

The activity log is the agent's dashboard

Every action an agent takes should land in an activity log: what it did, to which record, when, at whose request, and why. The same guidelines ask systems to make clear why they did what they did, and the log is where that explanation lives after the moment has passed.

In B2B products the log is not a debugging tool. It is the screen administrators, security teams and auditors will use to decide whether the agent stays switched on. It needs the same care as any admin panel table: filters by record, user and action type, exceptions surfaced first, and a link from every entry to the change it made.

Earn autonomy per action, not per agent

Autonomy should be granted to an action, not to the whole agent. When a team approves the same kind of action again and again without editing it, that action is a candidate to move up a rung. When an action is reversed or corrected, it moves down. Decide the rule in advance and show it to the people affected, so a change in what the agent may do never arrives as a surprise.

The point

The interesting part of an AI agent is what it can do. The part that decides whether customers keep it switched on is everything around that: the plan they review, the change they approve, the undo they reach for and the log they audit. Design those first, and the agent earns the autonomy the demo promised.