Terminology · AX vs AUX

Agent Experience and Agentic User Experience Are Not the Same

The language around AI products is converging faster than the definitions. Agent Experience, Agentic User Experience, AI UX and agent-first design are often used as synonyms, but they describe different design problems. The clearest distinction is the primary actor.

The distinction, in one line

AX asks whether an agent can use the system; AUX asks whether a person can safely and confidently delegate to the agent.

Both matter, and most serious AI products need both. But they are owned by different people, measured by different things, and fail in different ways. Confusing them is why teams ship an agent that works flawlessly against an API and is abandoned by its users within a month.

AX

Agent Experience

How well a software agent can understand and operate your service, API or environment.

The user is a machine

AUX

Agentic User Experience

How well a person can direct, trust, supervise and recover control from an autonomous agent.

The user is a human, over time

AI UX

AI User Experience

The broader experience of using AI-powered interfaces — copilots, generative features, recommendations.

Autonomy not implied

Method

Agent-first design

The product approach that starts from agent capability and responsibility, then designs human control around it.

Decided by the product team

01The four terms side by side

AX — Agent Experience AUX — Agentic User Experience AI UX Agent-first design
Primary actor The software agent The person delegating The person using an AI feature The product team deciding
Primary design question Can an agent understand and operate this system? Can a person safely delegate to this agent, and take control back? Is this AI feature useful, understandable and controllable in the moment? What should the agent own, and what must the human supervise?
Typical surfaces APIs, tool descriptions, schemas, docs, permissions, error responses, machine-readable contracts Intent capture, autonomy settings, confidence and evidence displays, memory views, approval queues, escalation paths Prompt interfaces, copilots, generative UI, recommendations, conversational flows Product architecture, autonomy maps, role boundaries, supervision surfaces
Success measures Task completion without human repair, low tool-call error rate, unambiguous failures Sustained delegation over time, appropriate trust, successful recovery from error, retained adoption Task success, satisfaction, perceived usefulness, feature retention Right work assigned to the right actor; supervision cost stays proportionate
Example failure An agent cannot tell which of four endpoints to call, so it guesses and silently corrupts an order An agent quietly remembers a correction the user wanted forgotten; trust collapses and usage stops A copilot produces confident text with no way to check the source The product gives an agent authority nobody is accountable for
Owner inside a company Platform, API or developer-experience team Product and design, with risk/compliance in regulated domains Product design Product leadership
Best auxfirst resource Agent-First API Design What is Agentic User Experience? What is Agentic User Experience? The agent-first design guide

↔ scroll table on mobile

02What is Agent Experience (AX)?

Agent Experience is how effectively an AI agent can understand, access and operate a digital service, API, tool or environment. The primary actor is the software agent, and the design work is largely about legibility to a machine.

AX became a real discipline once agents started acting on systems that were designed exclusively for humans. A checkout flow built around visual hierarchy and hover states is nearly unusable to an agent. An API with four similar endpoints and prose documentation forces the agent to guess.

Agent-operable interfacesServices that can be used without visual interpretation.
API and tool designUnambiguous naming, clear boundaries between similar operations.
Tool descriptions and schemasMachine-readable contracts describing what a tool does, what it needs and what it returns.
Permissions and scopesWhat an agent is authorized to do, expressed in a form it can reason about.
Error handlingFailures that state what went wrong and what to do instead, rather than a generic 400.
Machine-readable documentationContent structured for retrieval, not just for reading.

When AX is your problem: you are building a platform, API or tool that other people's agents will operate, and adoption depends on whether those agents succeed.

A useful test: if an agent using your service fails, can it tell why? If the answer is no, that is an AX problem, and no amount of human-facing UX work will fix it.

Go deeper on the machine-facing side: Agent-First API Design and API-to-agent interfaces.

03What is Agentic User Experience (AUX)?

Agentic User Experience is how a person understands, directs, delegates to, trusts and recovers control from an autonomous or semi-autonomous agent. The design problem is not a task — it is a long-running relationship with software that can act on someone's behalf.

Traditional UX assumes software waits for a person to act. Agentic systems remember, initiate, decide and keep working after the interface is closed. That changes the question from "can the user complete this task?" to "can this person confidently hand over work, and know what happens next?"

IntentHow a person expresses what they actually want, including the constraints they never say out loud.
MemoryWhat the agent retains, what the user can see, edit and delete.
InitiativeWhen the agent acts unprompted, and when that becomes intrusive.
JudgmentHow the agent shows uncertainty and evidence, so trust can be calibrated.
AutonomyWhat the agent may do alone, what needs approval, and how that boundary moves as trust develops.
TrustHow it is earned across repeated interactions, and how fast it is lost.
RecoveryHow a person intervenes, corrects, undoes or escalates when the agent is wrong.
Where each livesScored action by action on the Action Heat Ladder, evaluated against the ten AUX heuristics.

When AUX is your problem: you are building a product where people delegate consequential work to an agent, and success depends on sustained willingness to do so.

A useful test: would your users let the agent do this while they are not watching? If not, you have an AUX problem — and it is rarely solved by improving the model.

→ Full definition, patterns and heuristics: What is Agentic User Experience?

04Where AI UX fits

AI UX is the broader experience of using AI-powered interfaces — copilots, generative features, recommendations, conversational interactions. It is the widest of the four terms and the least specific.

The key distinction: AI UX does not necessarily involve autonomous action. A copilot that drafts an email you then send is AI UX. An agent that decides which emails to answer and sends them while you sleep is AUX. The design problems diverge sharply the moment the software can act without you.

Most AI UX guidance — show sources, allow editing, communicate limitations — remains valid inside agentic products. It is simply not sufficient, because it assumes a person is present at the moment of action.

Rough rule: if the human is in the loop for every consequential action, you are doing AI UX. If the human is on the loop, supervising rather than approving, you are doing AUX.

05Where agent-first design fits

Agent-first design is the product-design approach that starts with agent capabilities and responsibilities, then designs the human control, supervision and trust surfaces around them. Where AX and AUX describe problems, agent-first design describes a method.

The distinction from AI-first design matters. AI-first typically means adding intelligence to an existing product shape — the flow stays, the AI improves steps within it. Agent-first asks a harder question: if an agent can own this entire workflow, what should the product look like, and what is left for the person to do?

That question produces different architecture. Screens become supervision surfaces. Forms become intent capture. Dashboards become audit trails. The autonomy map — which actions the agent owns at which level — becomes a core product artifact rather than an implementation detail.

→ Full framework, patterns and process: The agent-first design guide, plus the pattern library.

06One product, four layers: a support agent

Take a single realistic product — an AI agent handling customer support for a SaaS company — and all four disciplines appear at once, owned by different people.

The AX layer

The agent needs to operate your systems: read the ticket queue, look up account state, check entitlements, issue a refund, update the CRM. Every one of those is a tool with a contract. If issue_refund and issue_credit are described ambiguously, the agent will eventually pick the wrong one.

Owned by: the platform teamFailure looks like: silent wrong actions

The AUX layer

A support lead is now supervising an agent that resolves tickets without them. What refund size can it approve alone? How does it show that it is unsure about an edge case? What does it remember about a repeat customer, and can the lead see that? When it gets one badly wrong, how does the lead find out, correct it, and stop it happening again?

Owned by: product and designFailure looks like: the team quietly turns it off

The AI UX layer

The lead also uses an assistant to draft responses and summarize threads — human in the loop, every time. Sources shown, edits easy, limitations clear.

Owned by: product designFailure looks like: an unusable feature nobody complains about

The agent-first design layer

The decision above all of them: should this product still be a ticket queue with an agent bolted on, or a supervision console where the agent works and the human oversees exceptions? That choice determines everything else.

Owned by: product leadershipFailure looks like: an agent with authority nobody is accountable for

Teams routinely solve one layer and assume they have solved the product. The AX layer is perfect and adoption still fails, because nobody designed the supervision experience.

07Which discipline do you need?

Who is the primary user of the thing you are designing — a person, or a software agent?

An agent → AX  Focus on tool contracts, schemas, permissions and error legibility.

A person → continue

Can the software take consequential action without a human approving that specific action?

No, a human approves everything → AI UX  Standard AI interface practice applies: sources, editability, clear limitations.

Yes → continue

Does the software persist state, memory or context between sessions?

No → closer to AI UX, but revisit the moment memory is added.

Yes → AUX  You are designing a relationship, not a task.

Would a single visible error meaningfully damage trust, revenue, safety or compliance?

Yes → AUX, urgently  Confidence signals, approval gates, audit trails and recovery paths are not polish.

No → AUX still applies, with a lighter control model.

Are you deciding what the product should be, rather than refining what it already is?

Yes → agent-first design  Start from what the agent should own, then design supervision around it.

Do other companies' agents need to use your product?

Yes → AX as well, regardless of everything above. Both layers, different owners.

Do several agents act on each other's output?

Yes → AUX + governance  Accountability across agents is a design decision, not an implementation detail.

Most serious AI products need at least two of these. The failure mode is not choosing wrong — it is assuming one is all four.

08Frequently asked

What is the difference between AX and AUX?

Agent Experience (AX) is about whether a software agent can understand and operate your system. Agentic User Experience (AUX) is about whether a person can safely delegate to that agent and take control back. AX has a machine as its user; AUX has a human in a long-running relationship with software that acts on their behalf.

Is AI UX the same as AUX?

No. AI UX is the broader experience of using AI-powered interfaces — copilots, generative features, recommendations — and does not necessarily involve autonomous action. The rough rule: if the human is in the loop for every consequential action, you are doing AI UX. If the human is on the loop, supervising rather than approving, you are doing AUX.

How is agent-first design different from AX and AUX?

AX and AUX describe design problems. Agent-first design describes a method: start from what the agent can own and be responsible for, then design the human control, supervision and trust surfaces around it. It is the approach that decides what the product should be, rather than refining what it already is.

Do I need both AX and AUX?

Most serious AI products need at least two of the four disciplines. If other companies' agents operate your product, you need AX regardless of everything else. If people delegate consequential work to your agent, you need AUX. The failure mode is not choosing wrong — it is assuming one discipline is all four.

09Where to go next

Written by

Emil Krzemiński

Founder of auxfirst, the agentic experience design practice. He develops the AUX discipline — the frameworks for designing trust and control into AI agents that act on people's behalf — and leads every engagement personally.

Cite this page

auxfirst (2026). Agent Experience and Agentic User Experience Are Not the Same.
https://auxfirst.com/agent-experience-vs-agentic-user-experience.html