--- title: "Agentic UX: Decide What the Agent Does, Shows, and Teaches" publishedAt: "2026-11-06" summary: "Agentic UX is usually framed as one autonomy dial. Shipping it in a real product takes a second: whether the user ends up knowing where the work lives." author: "Ben Skoog" authorImage: "/ben_skoog.jpeg" --- Agentic UX is the design of products where an AI agent takes actions for the user, not only answers. The guides that rank for it agree on the basics: decide what the agent may do without asking, ask before anything risky or irreversible, show what it did, and make it easy to undo or take over. That advice is right. It is also only half of the job once the agent is working inside a real product, in a real customer's account. The other half came from our customer calls, not from a pattern library. The product leaders we work with who serve non-technical customers did not ask us for fewer confirmations or more autonomy. They asked that the customer should still know where things live after the agent is done. One wanted setup to teach, because customers who have clicked through it once file fewer support tickets later. Another said plainly that write access through their MCP server could set every setting for the customer, and that this was the problem: the customer would never learn the product. So shipping an agentic feature in an existing product is mostly a permissions and trust problem, not a model problem, and trust has two parts. One is whether the agent should act without asking. The other is whether the user should see the work, or do it themselves with the agent beside them. For each action, the vendor picks one of three modes: **do it silently, do it and then show it, or walk the user through it.** That choice belongs to the software company, not to an autonomy slider in the end user's settings. ## What the agentic UX guides get right The ranking guides are worth reading, and they converge. Victor Yocco's [practical UX patterns for agentic AI in Smashing Magazine](https://smashingmagazine.com/2026/02/designing-agentic-ai-practical-ux-patterns/) lays out six patterns across the life of an action: an intent preview before significant actions, an autonomy dial, an explainable rationale after acting, a confidence signal, an action audit with undo, and an escalation pathway. He calls the intent preview non-negotiable for irreversible, financial or data-sharing actions. Onething Design's [agentic AI UX design guide](https://www.onething.design/post/agentic-ai-ux-design) lists the same principles in a different order: bounded autonomy, transparency, user control, predictability, and feedback, with autonomy growing as trust grows. Greg Nudelman's [UX Magazine piece](https://uxmag.com/articles/secrets-of-agentic-ux-emerging-design-patterns-for-human-interaction-with-ai-agents) adds approval flows for risky actions and pause controls. The platform builders say the same thing in their own documentation. The [MCP specification](https://modelcontextprotocol.io/specification/2025-11-25/server/tools) says there should always be a human in the loop with the ability to deny tool invocations, and that clients should prompt for confirmation on sensitive operations and log tool usage for audit. Anthropic's [framework for safe and trustworthy agents](https://www.anthropic.com/news/our-framework-for-developing-safe-and-trustworthy-agents) describes Claude Code starting with read-only permissions and asking before it modifies anything, while showing its planned actions as a checklist the user can adjust. All of this answers one question: how much should the agent do before it asks? None of these sources asks what the user should know when the agent is done. ## The second dial: does the user need to know where it lives? An agent that acts as the customer changes the customer's account. Every change is also a lesson the customer did or did not get. For some actions, nobody cares. For others, the customer will need to find that setting again next month, or explain it to a colleague, or change it when their business changes. That gives three modes instead of two: | Mode | What the agent does | Good for | |---|---|---| | Do it silently | Acts, records it in the log, says nothing unless asked | Reading data, filling defaults, work the user will never touch again | | Do it, then show it | Acts, then brings the user to what changed and explains it | Setup steps the user should recognize later, changes with a preview | | Walk them through it | Points to the screen, explains the choice, lets the user click | Settings the user owns and will change again, anything they must understand to run their business | Confirmation sits on top of all three. A refund needs approval whichever mode it is in. A default time zone does not, whichever mode it is in. The two dials are independent, and most guides only describe the first. ## What we saw on calls We will describe two calls, without names. The first was with the sales leader at a reservation software company whose customers are small, independent operators, many of them wary of AI. We were showing how much faster setup goes when the agent uses the product's own tools instead of clicking through the interface: collect the information once, set it up in the back end, refresh the page, done. They liked it and did not want it yet. Their reason was not risk. It was support load. Customers who step through setup themselves know where the clicks are, and they need less help later. And a customer who is afraid of AI should not have the product rearranged under them on day one. What we agreed on was the middle mode. The agent does as much as it can, then shows the user what it did and walks them through what is left. Their go-live test was concrete: log into a blank trial and watch the agent get a new customer through the first critical setup steps. The second was a demo with a hospitality software team. Their product has a lot of settings, automations and previews, and new customers get overwhelmed by them. One of their team described exactly the trade-off above: they could build an MCP server with write access to customer accounts and set everything correctly, but then customers would never get to know the product, and would keep going back to the agent instead. They wanted customers to own where things live and to go through the screens that were built for it, with the agent there for every question. Our answer was that the split is theirs to define: which work the agent does through the product's tools, and which it shows the customer how to do. Neither team was asking for less agent. Both wanted the work done. They just knew which parts of the work their customers had to understand, and that is knowledge no design pattern can supply. ## Why the vendor sets the split, not the end user The pattern libraries put the autonomy dial in the user's hands. In a consumer assistant that makes sense. Inside a B2B product it mostly does not, for three reasons. **The vendor knows which settings matter.** A first-time customer cannot tell which settings they will need to understand later. The vendor's support team can, because they answer those questions every week. **The vendor carries the consequences.** If the agent changes something and the customer is confused next month, the ticket goes to the vendor. If money moves the wrong way, the vendor answers for it. **Confirmation is per action, not per tool.** Stripe's own [MCP documentation](https://docs.stripe.com/mcp) is the clearest public example. Creating a refund and sending money from a Treasury account are marked for human confirmation in the Stripe Dashboard, while most other writes are not, and Stripe notes that confirmation depends on the action, not only the tool name, because one write tool covers many actions. That is a vendor deciding, action by action, where a person has to be involved. The same reasoning applies to the do, show or teach choice. The end user can still stop the agent or take over. But the defaults come from the vendor, set per action, before the feature ships. ## Too many confirmations make it less safe The easy way to make an agentic feature feel safe is to confirm everything. It does not work. Pickaxe's [guide to human-in-the-loop agents](https://pickaxe.co/post/human-in-the-loop-ai-agents) describes it from experience: by the fiftieth approval, the author was no longer reading them, only clicking, and concludes that too many checkpoints make an agent less safe, not more. The fix is to spend confirmations only where a person can realistically catch a mistake, and use the other two dials for the rest. A change the user should understand belongs in the "do it, then show it" mode, not behind an approval prompt. Showing teaches. A prompt the user clicks through teaches nothing. Yocco gives three numbers to watch once the agent is acting, which turn trust into something a team can measure: Chart of three agentic UX operating thresholds from Smashing Magazine: more than 85% of intent previews accepted without edits, turn off automation for a task whose reversion rate goes above 5%, and a healthy escalation rate between 5% and 15% *Three operating thresholds from Victor Yocco's agentic UX patterns in Smashing Magazine: plan acceptance, reversion rate and escalation rate.* - **Plans accepted without edits:** above 85% means the agent understands what users want. - **Reversion rate:** if users undo more than 5% of a task type, turn off automation for it. - **Escalation rate:** 5% to 15% is healthy. Lower usually means the agent is guessing; higher means it is not doing the job. These are a starting point from one author, not an industry standard. But they are the right kind of measure, because they tell you which actions to move between modes. ## How we build it into the agent In our own product the [in-app agent](/agent/in-app) acts as the signed-in user, in their account, with their permissions and nothing more, and every call is logged. It works through the product's MCP server or API where the product has a tool, and falls back to the browser where it does not. When it sets up a new account, it does it with the user, showing the work as it goes. Where a team wants its customers to learn a screen, the agent can guide them to it instead of making the change in the background, and that split is part of how the team sets the agent up. We wrote more on why a product's own agent matters here in [what an in-app agent is](/blog/what-is-an-in-app-agent). What we would tell a product team shipping its first agentic feature: 1. **Start read-only, then add writes one at a time.** Each write you add needs a mode (silent, show, or teach) and a confirmation decision. Our guide to [what to expose to your customers' AI agents](/blog/what-to-expose-to-your-customers-ai-agents) goes deeper on which tools belong where. 2. **Write the split down per action.** A short table like the one above, owned by product and support together, beats a global autonomy setting. 3. **Act as the user, never a shared admin key.** Trust starts with the agent being unable to do anything the user could not. 4. **Show work in the product, not in a transcript.** Bring the user to the screen that changed. A chat log that says "done" is not showing. 5. **Measure undo and escalation by task type,** and move actions between modes based on what you see. ## The work does not stop when the user leaves There is one more place where agentic UX in a product differs from the pattern libraries. Those patterns describe a session: the user asks, the agent acts, the user reviews. Customer work does not fit in a session. Setup stalls halfway, the customer closes the tab, and the job is still not done. That is why we think of the important work as a job the AI owns for each customer, not a chat. A [service](/services) is a job like "get every new customer through setup" that the AI keeps working after the user leaves. In the jobs we have built, it notices the account is stuck, follows up by email, and picks up in the app where the customer left off. The same three modes apply. Some of the job's actions are silent, some are shown the next time the customer signs in, and some wait for the customer to do them with the agent's help. The UX question just moves from one session to the life of the account. ## FAQ ### What is agentic UX? Agentic UX is the design of products where an AI agent takes actions on the user's behalf. It covers what the agent may do without asking, when it must confirm, how it shows what it did, and how the user steps in, undoes or takes over. ### When should an AI agent ask for confirmation? Before actions that are irreversible, move money, share data, or that a person could realistically catch a mistake in. Not before everything: approval prompts that appear constantly stop being read. ### Who should decide how autonomous the agent is? In a B2B product, mostly the software company, per action, because it knows which settings customers need to understand and it carries the consequences. End users should always be able to stop the agent or take over. --- Aimdoc gives your product an agent that does the work as each customer, in your product, with the split between doing, showing and teaching set by you. See the [in-app agent](/agent/in-app) and [services](/services), or [start free](https://app.aimdoc.ai/signup).