Agentic UX: design principles for AI agents that act on a user's behalf

Agentic UX principles govern how a person hands an AI system a goal and bounded authority to act across tools. The core ones: decide whether the task needs an agent, set authority per action, approve the exact change, enforce limits outside the model, define what stop does, design for half-finished runs and keep a history people can act on.

Published lists of agentic UX principles, including the ones cited below, name qualities an agent should have: transparent, controllable, collaborative. This guide states each principle as a decision your team can make, and test, for one delegated task.

What is agentic UX?

Agentic UX is the design of the experience around an AI system that does more than answer. It takes a goal, plans steps, calls tools and changes records in other systems on a person's behalf. The interface stops being only the place where work happens and becomes the place where work is handed over, watched, stopped and checked. The Tcules definition of agentic UX puts the weight on the objective and bounded authority a person delegates.

A neighbouring term gets mixed up with it. "Agent experience," or AX, which Netlify's CEO Mathias Biilmann introduced in January 2025, is about the AI agent as the user of your product: whether an agent can reach, understand and operate your platform. Agentic UX is about the human who delegates to the agent. Both matter; they are different design problems.

Why "transparency and control" are not enough as principles

Published principle sets agree on the broad qualities. UXmatters lists clarity of intent, transparency, user control and feedback among its seven. Microsoft Design calls transparency, control and consistency foundational for all agents. Smashing Magazine organises six patterns around before, during and after an action. These are sound. Two research findings show why they need a sharper form before a team can build to them.

An explanation can raise acceptance without raising accuracy. In a CHI 2021 study by Bansal and colleagues, explanations made people more likely to accept the AI's recommendation whether or not it was correct. That study tested decision support, not agents. The inference for agentic products is ours: a plan that reads well can be approved because it reads well.

Approval can turn into a reflex. Anthropic has written that constant permission prompts can lead to "approval fatigue," where people might not pay close attention to what they approve (Anthropic, October 2025). Older human-factors research points the same way: a 2010 review by Parasuraman and Manzey found automation bias in both naive and expert participants, and found that training or instructions did not prevent it.

So "be transparent" and "keep the user in control" are goals, not specifications. The principles below say what to show, where to ask and what must hold even when the person does not look closely. The published lists we reviewed also say little about the moment most specific to agents: a run that has partly succeeded.

What are the design principles for agentic UX?

Eight principles, in the order a team meets them when it designs one delegated task.

1. Decide whether the task needs an agent at all

Anthropic separates workflows, where a model and tools follow predefined code paths, from agents, where the model directs its own process and tool use. Its advice is to find the simplest solution possible and add complexity only when needed, because agentic systems often trade latency and cost for better performance and carry the potential for compounding errors (Anthropic, "Building effective agents").

For the interface, the difference is concrete. A workflow's steps can be shown in full before it runs, so a person can inspect and approve the whole thing once. An agent's path is decided as it goes, so the person needs checkpoints, a stop and a way to read what happened. A useful test: if you can write the steps down before the run starts, you may be designing a workflow with an AI step, and a person can review it in full before it runs.

2. Set authority per action, not per product

Levels of automation were never meant to be set once for a whole system. Parasuraman, Sheridan and Wickens (2000) describe automation applied separately to four functions: gathering information, analysing it, selecting a decision or action and carrying out the action. An agent can gather and analyse freely, propose a change, and still need a person before it carries the change out.

OpenAI's published approach for its Operator browser agent follows the same shape. The Operator system card (January 2025) describes a policy requiring confirmation before actions such as purchases, sending email and deleting calendar events, and a full restriction on some tasks, such as buying or selling stocks. One product, several levels of authority, decided action by action.

Set the level by what is at stake, whether the action can be undone, how good the evidence is and whether the person can step in. In Tcules' ConnectX work, model freedom was bounded through eight defined situations connecting intent, tools, data, modules and action.

3. Ask for approval of the change, not the plan

"I'll tidy up your inbox" is a plan. It cannot be approved in any meaningful way, because the person cannot see what will change. An approvable request names the objects affected, the exact change, their current state and what cannot be undone. One confirmation example in the Operator system card shows the start of this: the agent reports that it has selected every email under a named label and is about to delete them, then asks whether to proceed. It names the objects and the change, but not what cannot be undone.

Given the Bansal finding, keep the approval surface about consequence rather than persuasion. A count of affected records, a before-and-after of the change and a plain note on reversibility help a person judge. A fluent rationale can help them agree without helping them judge.

4. Spend confirmations where the consequence is

Confirmations work when they sit in the right place. Before adding them, OpenAI ran its unmitigated model on 100 prompts resembling expected Operator tasks and found 13 errors. Eight could be easily reversed within minutes; five were to some degree irreversible or possibly severe, including an email sent to the wrong recipient and an incorrect food-delivery order. OpenAI reports that confirmations reduced that risk by about 90% on its own measure (Operator system card). These are the vendor's figures for its own early-2025 agent, not an industry benchmark.

The cost of confirmations is attention. Anthropic's answer for Claude Code was to bound the environment instead of asking about each step: in its internal usage, sandboxing reduced permission prompts by 84% (Anthropic). The design principle we draw from both: ask before actions that change the world and are hard to reverse, make reversible steps undoable instead of asked, and shrink what the agent can reach so fewer questions are needed. A confirmation on every step teaches people to click through.

5. Enforce the boundary outside the model

An instruction to the agent is not a permission. The OWASP guidance on excessive agency in LLM applications advises implementing authorisation in downstream systems rather than relying on the model to decide whether an action is allowed, limiting tools and permissions to what the task needs, and requiring human approval for high-impact actions.

The failure this prevents is public. In July 2025, SaaStr founder Jason Lemkin had placed a project on Replit under a code and action freeze. Replit's agent deleted the production database anyway, wiping records for more than 1,200 executives and over 1,190 companies (Fortune; The Register). Replit's CEO called it unacceptable, said the company had implemented automatic separation of development and production databases, and said a planning-only mode was in progress (Fortune).

Even a well-built agent decides for itself when to ask. In OpenAI's evaluation of 607 tasks, Operator asked for confirmation, on average, 92% of the time one was needed, which leaves roughly one needed confirmation in twelve unasked (Operator system card). So the interface should state only what the system enforces. If the product says "read-only" or "nothing changes without your approval," that promise has to live in the tool permissions, identity and policy layer, not in a prompt.

6. Define what "stop" does

Anthropic describes agents that pause for human feedback at checkpoints and run with stopping conditions, such as a maximum number of iterations (Anthropic). Operator adds a supervision rule: on some sensitive sites, such as email, execution pauses automatically when the person becomes inactive or navigates away (Operator system card).

A stop control needs defined behaviour before anyone presses it. Is it a pause that can resume, or a cancel? Does a tool call already in flight finish or get abandoned? What has already changed? After a stop, show the state of the work. A stop that returns no account of what happened leaves the person unsure whether to redo the task or undo it.

7. Design for the half-finished run

This is the moment most specific to agents. Step one succeeds, step two fails, and the external system may or may not have received the request. The product needs to show what changed, keep the valid progress and confirm the external result before offering a retry.

Payments engineering has a well-known answer on the system side. Stripe's idempotency keys let a client retry a request after a connection error without creating a second object or applying an update twice. The interface equivalent: show "Retry" only when retrying is safe or deduplicated, and otherwise show "Check what happened" first.

Approvals age too. If price, inventory, permissions or the affected records can change between approval and execution, check that state again before acting, and send stale work back for a fresh decision. Anthropic's guidance that agents should get ground truth from the environment at each step, such as tool results, applies to the person as well as the agent (Anthropic).

8. Keep a history people can act on, taken from the system of record

In the Replit incident, the agent told Lemkin a rollback would not work in that scenario. He then recovered the data manually (Fortune). An agent's own account of what it did is not a record.

A usable history comes from the systems the agent touched. It shows what changed, which approval covered it, who approved it, what can be reversed and what cannot. It also keeps human disagreement: in Tcules' BuildTwin work, an engineer reviewing AI quality-control results could change a status with a reason and raise an issue against the observation, so the correction stayed in the record.

A checklist for one delegated task

Pick one task you are considering handing to an agent and answer each question before building.

Test the answers with scenarios where the agent is right, uncertain, wrong and half-finished. Watching people approve quickly on the happy path tells you little about whether they will catch the wrong one.

Where this work sits

These decisions belong in the product, not in a policy document beside it. Tcules designs AI copilot and agent experiences around the authority actually being delegated: what the agent may do, when a person decides, and how either can stop, correct or finish the work. For how evidence and uncertainty should scale with the decision a person is asked to make, see trust and transparency in AI-first interfaces.