There’s been a new term in town for a while now: agentic experience design, or AXD. And if you’re a UX designer, your first instinct is probably to panic and then wonder, is this actually something we do, and if so, how much of it? I naturally wondered the same, so I tried to find out.
And what I found is that yes, it’s our job, but not all of it, and that difference matters.
TL;DR
Agentic experience design (AXD) is the design discipline focused on how humans and AI agents share a workflow. It was introduced in early 2025 by Netlify CEO Mathias Biilmann. For UX designers, AX means designing three new interfaces (voice UI, chat UI, and agentic UI) while applying skills you already have: interaction design, user research, information architecture, and UX writing. The new parts? Understanding LLM behaviour, designing for probabilistic outcomes, and learning prompt design.
Where the term agentic experience comes from
The concept of agentic experience was introduced by Mathias Biilmann, CEO of Netlify, in January 2025. His framing was straightforward, we already have:
- UX (how humans experience products) and
- DX (how developers experience platforms)
Now that AI agents are starting to act autonomously within our products, we need a third category: the experience AI agents have as users of a product or platform.
His original focus was infrastructure. How does an agent access your platform? Are your APIs clean enough for an LLM to actually use them? Can a user’s AI agent do anything useful inside your product, or does it just hit a wall?
Real problem that is also mostly a developer experience problem. The UX angle on agentic experience is different, and that’s where we live.
What agentic experience means for designers
You’re not just designing for the human anymore. You’re designing for the human and the agent operating in the same space, each with their own needs, their own way of navigating, and their own way of failing. We can break it into 3 parts:
- the human-side experience – how users delegate tasks to agents, receive outcomes, maintain trust
- the agent-side experience – how the agent perceives and navigates the interface
- the human-agent collaboration experience – how the two actually collaborate in real time
For me, personally, the most interesting part is the human-agent collaboration experience, because it’s a new form of teamwork, and we already live in this timeline.
It’s not chatbot UX and it’s not just voice UI. It’s designing the space where a person and an autonomous system share a workflow, and it needs to work.
The three interfaces we’re designing for now
If you’ve been paying attention to what clients are starting to ask for, you’ve probably already touched at least one of these.
Voice UI
Voice UI is the most familiar in concept, least familiar in practice. There’s no screen, no click, no fallback to reading. Everything is conversation, designing for rhythm, for silence, for the moment the agent doesn’t understand, for keeping someone oriented without any visual anchors.
Chat UI
Chat UI looks like something we’ve been doing for years. It’s not. The difference between designing a scripted chatbot flow and designing for an LLM-backed chat interface is like the difference between doing everything by the book and designing for someone who will say absolutely anything, in any order, and still expect a coherent response.
Agentic UI
Agentic UI is the newest and the one most teams aren’t ready for. The agent isn’t responding to questions, it’s taking actions. Booking the meeting, editing the document, sending the email. The user set a goal and walked away. What we design is the transparency layer: how does the person know what the agent did? How do they catch a mistake? How do they stop it, override it, hand it back to manual control? Who is accountable? No settled patterns for this yet. We’re building them as we go.
What UX designers already know that applies to agentic experience
The good news is that UX designers are better positioned for this than almost anyone else on a product team.
Interaction design maps directly to agentic flow design. We already think in multi-step processes, error states, edge cases. When the agent executes the steps instead of the user, the design questions are the same: what happens when something goes wrong? Where does the human take back control? How does the system communicate its current state?
User research maps to AI behaviour evaluation. Same methods, different subject. Instead of “does this button make sense,” we’re asking “does this person trust what the agent just did?” and “what mental model do they have of how the AI makes decisions?” Still a research question that is still our work.
Information architecture maps to knowledge architecture. How content and data are structured determines what an agent can actually do with it. If you’ve ever designed navigation for a complex system, you’ve already done the conceptual work that underlies how an agent “sees” a product. This one is often overlooked, and honestly a real differentiator.
UX writing maps to conversational and prompt design. Writing system instructions for an agent, its tone, constraints, how it handles things it can’t do – is a content design problem. It borrows from what we already know about clarity and user expectations. New territory, but our territory.
What’s actually new about designing for agentic experience
In this industry, we always have to learn something new, either trends, practices, or something else entirely. But, isn’t that genuinely exciting? We live in interesting times, it might be tough out there now, but there is so much more to learn, and the pace is really fast.
Understanding how large language models work – not technically, but conceptually – is now the basics. Not what’s happening inside the model, but why outputs vary, what context windows mean for conversation design, why latency is a constraint in a way it wasn’t before.
Designing for uncertainty is new. Classic UX is deterministic: user does X, system does Y. AI introduces probabilistic behaviour, the agent might do something you didn’t anticipate, and the design has to hold up when it does. Graceful degradation, confidence indicators, easy override paths – these aren’t patterns we inherited, it’s something we are learning and figuring out now.
Knowing how to write prompts is its own thing. Writing instructions that reliably shape agent behaviour is learnable, but it takes practice. It’s not the same as UX writing, even though the skills overlap.
Where’s the line between agentic experience and developer experience?
If a human will see it, hear it, interact with it, or make a decision based on it – that’s agentic experience territory. Transparency layer, control mechanisms, onboarding, error recovery, conversation flows.
If it’s machines talking to machines – agents communicating with each other, orchestration logic, tool-calling architecture, API documentation for LLMs – that’s developer experience and backend.
Both layers are often invisible to the end user, but for completely different reasons. The API layer is invisible because it’s infrastructure. The UX layer should be invisible because we designed it well enough that it feels effortless.
How we’re applying agentic experience design at Notch
I am working on an internal workshop planning tool, something our team actually needed. You pick the type of workshop, the methodology (Design Thinking, AI workshops, and others), and the tool plans the structure and estimates the cost. Sounds simple. But the design decisions behind it aren’t – how does the interface communicate what the AI is basing its estimate on? What happens when the output doesn’t match the facilitator’s expectations? How much should the user be able to override, and at what point? Those are agentic experience questions, even if we didn’t call them that when we started.
One of my colleagues is working on a client project, a purpose-built AI CV writing tool for the employability sector. A key worker inputs a few lines about a jobseeker, the agent produces a complete employer-ready CV. What makes it an agentic experience project isn’t the AI underneath – it’s everything around it. How do you set the right expectations for what the agent can and can’t do? How do you design for a user working with people in vulnerable situations, where a wrong output isn’t just annoying but potentially harmful? How much control does the key worker have, and when? UX questions. They just happen to be about an AI agent’s behavior, not a button’s placement.
We didn’t wait until we had all the answers to start. The discipline is still forming, the patterns are still being figured out, and honestly, that’s not a bad place for a UX team to be. We’re experts at designing in uncertainty.
Frequently asked questions about agentic experience
What is agentic experience (AX)?
Agentic experience is a design discipline focused on how humans and AI agents share a workflow. It covers the human-side experience (delegating tasks, receiving outcomes, maintaining trust), the agent-side experience (how the agent perceives and navigates an interface), and the collaboration experience between the two.
How is agentic experience different from traditional UX?
Traditional UX is deterministic: the user acts, the system responds predictably. Agentic experience introduces probabilistic behaviour – an AI agent may take actions autonomously, and the design must account for transparency, override controls, and trust-building patterns that don’t exist in conventional interface design.
Who introduced the term agentic experience?
The term was introduced by Mathias Biilmann, CEO of Netlify, in January 2025. His framing positioned AX alongside UX (user experience) and DX (developer experience) as a distinct category for the experience AI agents have when interacting with a product or platform.
What skills do UX designers need for agentic experience design?
Core UX skills – interaction design, user research, information architecture, and UX writing – transfer directly. The new additions are a conceptual understanding of large language models, designing for uncertain and probabilistic outcomes, and prompt design as a content discipline.

