Agentic User Experience (AUX) is the discipline of designing how people delegate to AI agents over time. It covers what an agent may do, when it must ask, what it remembers, how it shows uncertainty, how a user intervenes and how trust is earned or lost across repeated interactions.
AUX is not a rebrand of UX. It is the layer UX never needed, because software could not previously act on its own. The difference in one line: classic UX designs a task; AUX designs a relationship with something that keeps working after you close the tab.
Traditional UX assumes that software waits for a person to act. Agentic systems can remember, initiate, decide and continue working after the interface is closed. That changes the design problem from helping a user complete a task to helping a person manage a relationship with software that can act on their behalf.
AUX does not replace UX. It adds the missing layer for delegation: intent, authority, memory, transparency, escalation, recovery and trust.
Three assumptions break:
| Classic UX assumes | Agentic systems are |
|---|---|
| Reactive — software responds to input | Proactive — the agent may act unprompted |
| Session-based — each visit is self-contained | Relationship-based — memory and trust carry across time |
| Deterministic — the same input gives the same result | Probabilistic — the same request may produce different work |
Every established UX method inherits at least one of those assumptions. Usability testing observes a session. Task flows presume determinism. Neither tells you whether someone will still be delegating in six weeks.
Four capabilities separate an agent from a very good feature. Each creates design problems that did not exist before.
The agent retains context between interactions. This is what makes it useful — and it introduces questions no conventional interface had to answer: what is stored, for how long, who can see it, who can correct it, and what happens when the user wants something forgotten.
The agent can act without being asked. Helpful initiative feels like competence; unwanted initiative feels like intrusion. The line between them is a design decision, and it varies by person, context and stakes.
The agent chooses between options under uncertainty. Users cannot calibrate their trust unless the agent distinguishes "I am confident" from "I guessed" — and most systems present both identically.
The agent acts without approval at the moment of action. This is the source of the value and nearly all of the risk. Autonomy is not a switch; it is a spectrum that should move as trust is earned.
Trust should move a system rightward along this spectrum; consequence should move it leftward. Scoring which actions belong where is the job of the Action Heat Ladder.
Capabilities tell you what an agent can do. The Evolution Curve tells you where a product sits on the maturity ladder — and it is the honest way to locate yourself before designing anything.
The reason the curve matters: the further right you move, the harder it becomes to swap you out. A stage-01 chatbot is replaceable in an afternoon. A stage-04 system carrying six months of context on your team is not. That is the AUX moat — built from time, trust and accumulated context, and it cannot be cloned by a competitor with more capital.
| Term | Primary actor | Core question |
|---|---|---|
| UX | A person operating software | Can the user complete the task? |
| AI UX | A person using an AI feature | Is this AI feature useful, understandable and controllable in the moment? |
| AUX | A person delegating to an agent | Can this person safely hand over work — and take control back? |
| AX | A software agent operating a system | Can an agent understand and operate this service? |
The rough rule: if a human approves every consequential action, you are doing AI UX. If the human supervises rather than approves, you are doing AUX.
→ Full comparison, with failure modes and a decision tree: Agent Experience vs Agentic User Experience
Principles are good for conviction. Patterns are what you actually ship. These six are the structural building blocks of agentic interaction — repeatable, layerable, remixable.
A short exchange that clarifies the user's goal before the system acts. It avoids one-shot prompting, where agents jump to conclusions and erode trust. Establishes mutual alignment.
Make reasoning visible. Expose sources, uncertainty, and logic in ways that are digestible but not distracting. Help users calibrate trust. Make agents feel self-aware, not mysterious.
Reshape the interface in response to evolving tasks, surfacing the right tools and previews. Maintains spatial memory while adapting — feels like the product thinks alongside you.
Every agentic system needs obvious ways to undo, revise, or override. These provide psychological safety — when users know they can recover, they engage and explore more deeply.
Recall not just facts, but contextual relevance across time. Past decisions, preferred formats, recurring tasks — transparent and editable. Shifts from convenience to continuity.
Agents initiate tasks — drafts, outlines, queries — then invite the user to shape them. Creates co-authorship momentum without locking into fixed outputs. Assistant becomes collaborator.
→ The wider catalog of 24 interaction patterns: the auxfirst Pattern Library
These ten heuristics are how we evaluate an agentic experience in an audit. Each is a question you can ask of any product where an agent acts on someone's behalf.
→ Full heuristics with evaluation guidance: the AUX Heuristics
Trust is not one thing, and agentic products lose it in four distinct ways.
Does it work?
The agent completes what it says it will, reliably enough to depend on.
Does it understand my situation?
The agent applies the right constraints, conventions and history rather than generic competence.
Does it know when not to act?
The agent recognizes the edge of its competence and stops, asks or escalates.
Is it working for me?
The agent's incentives are legibly aligned with the user's interests.
These are earned in order and lost out of order. Functional trust is the entry requirement; advocacy trust is what survives a mistake.
An agent that researches accounts, drafts outreach and updates the CRM. The delegation question is not whether the copy is good — it is whether a rep will let it send. AUX decides what goes out unreviewed, what waits in an approval queue, and what the agent remembers about a prospect between touches.
An agent resolving tickets without a human in the loop. The design work is the authority boundary: what refund size it approves alone, how it signals an edge case, how a supervisor discovers and corrects a bad resolution before it becomes a pattern.
An agent reconciling transactions or flagging anomalies. Auditability moves from nice-to-have to requirement: every conclusion must be reconstructable, and "the model was confident" is not a defence.
Agents adjusting pricing, promotions or assortment. Consequences are commercial and immediate, so autonomy is usually earned incrementally — recommend, then act-within-guardrails, then act. → See AI agents in retail for the full landscape.
A coding agent working across a repository. Memory and recovery dominate: what it knows about the codebase, how a developer sees what it changed, and how they undo work that went sideways three steps back.
A scorecard across seven dimensions. Score each from absent to designed, and treat any dimension at absent in a high-consequence flow as a blocker rather than a backlog item.
| Dimension | The question to ask |
|---|---|
| Intent clarity | Can a user express what they want, including constraints, and confirm the agent understood before it commits? |
| Authority legibility | Can a user state, without guessing, what the agent may do without asking? |
| Confidence signalling | Does the agent distinguish a confident answer from an uncertain one — visibly, at the moment of decision? |
| Memory transparency | Can a user see, correct and delete what the agent remembers about them? |
| Escalation design | Is there a defined trigger and path to a human, with context carried across? |
| Auditability | Can someone reconstruct what the agent did and on what basis, after the fact? |
| Recovery | Can a user interrupt, undo, correct and teach — during the work, not just after it? |
Working through this on a live product usually surfaces disagreements a team did not know it had. That is the point.
Someone must own the agent's behavior as a product decision, not an engineering side-effect. In regulated domains, add risk or compliance early rather than at launch review.
The work produces durable specifications: an autonomy map, a memory strategy, an escalation model, an interaction blueprint and a trust scorecard. These outlive any single release and become the criteria future changes are judged against.
AUX decisions belong before build, not after a failed pilot. The cheapest moment to decide what an agent may do alone is before anyone has written the code that lets it.
Product-level AUX still fails if the surrounding organization is not ready to supervise agents. → The five-layer agentic organization playbook
If you want help doing this work: work with an agentic experience agency.
Agentic User Experience — the discipline of designing how people delegate to, supervise and recover control from AI agents.
No. AI UX covers AI-powered interfaces generally, including ones where a human approves every action. AUX specifically addresses autonomous or semi-autonomous action — where the software can act without a person approving that specific action.
No. AUX is the discipline — the problems to solve. Agent-first design is a method for building products in which agents are primary actors. You can use the method without having solved the discipline, and teams frequently do.
Probably not yet — but revisit the moment it gains memory or acts without per-action approval. Those two changes are what turn an AI feature into a delegation relationship.
Usually product and design together, with risk or compliance involved in regulated domains. The failure mode is nobody owning it and engineering deciding autonomy by default.
Sustained delegation over time, appropriately calibrated trust, successful recovery from errors, and retained adoption after the first visible failure — not task-completion rates alone.
The term was named publicly by Dharmesh Shah in April 2026, in a post arguing that the agent had become a user in its own right. auxfirst did not coin the phrase; we built the discipline underneath it — the frameworks, patterns, heuristics and trust architecture that turn a named observation into something a product team can actually design against. Where this page and another auxfirst page define the same concept, this page is canonical.