Agents as Users: What Agent Experience (AX) Means
Agent experience (AX) measures how easily an AI agent can access, understand and use a product. Its origin, four areas and how to evaluate it.
Where does the term come from?
Matt Biilmann, co-founder and CEO of Netlify, proposed it on January 28, 2025 in the post “Introducing AX: Why Agent Experience Matters”. He defines it as “the holistic experience AI agents will have as the user of a product or platform”. He asks teams to start with questions such as whether it is simple for an agent to get access to operate a platform on behalf of a user, and he calls for clean, well-described APIs, plus documentation and context that are ready for machines.
A year later, on January 28, 2026, he published “One Year of AX”. There he argues that every product already has an agent experience and the only question is whether it is good or bad, because agents can often reach a product whether or not its provider wants them to. The same post organizes the field into four areas.
What are the four areas of AX?
| Area | What it means according to Biilmann | Question for your product |
|---|---|---|
| Access | An agent can reach the product on the user’s behalf, with as little friction as possible for both | Can an agent authenticate with limited permissions, or is the only path a login designed for humans? |
| Context | Managing what the agent knows during its working loop; he cites MCP and Skills, serving Markdown from documentation sites and helpful messages in command-line tools | Can your documentation be read as clean text? See how to write content that LLMs cite and llms.txt |
| Tools | Agents act through tools: protocols such as MCP, custom Skills or calls to a CLI or an API | Are the key actions exposed as tools with names and parameters? See MCP and designing interfaces for an agent to use |
| Orchestration | Treating the product as a place where an agent can be launched and given the right context, including isolated environments | Can an agent be started from inside your product, with the context of what the person is doing? |
This is one author’s framework, and he also runs Netlify, a company with a direct interest in the topic. Use it as a list of questions, not as a norm.
How is it different from UX and DX?
Netlify presents agents as a new kind of user in software development, after the person (UX) and the developer (DX). The practical difference is in how a product is interpreted:
| UX | DX | AX | |
|---|---|---|---|
| Who uses it | A person | A person who codes | A program acting for a person |
| How it perceives | Sees the screen | Reads documentation and code | Reads structure, text and tool responses |
| What it tolerates | Ambiguity, because it interprets | Imperfect documentation | Very little: what is not exposed may go unnoticed |
| Who decides in the end | The person | The person | The person who delegated, who remains responsible |
How does an agent read your product?
It depends on the agent, and not all of them look at pixels. Playwright MCP, Microsoft’s server that lets a model drive a browser, states that it uses Playwright’s accessibility tree “not pixel-based input” and that it operates purely on structured data, with no vision models needed. That is one example, not a rule for every agent: others work from screenshots.
The design consequence is concrete when the agent uses structure: a button with no accessible name or a field with no label is hard to tell apart for a screen reader and for that kind of agent. That is why it helps to know the accessibility tree. Accessibility work helps people and, along the same path, those agents.
How do you evaluate your product’s AX?
There is no standard metric. A practical method, which is editorial judgment and not a standard, is to test one real task:
- Pick a task with a clear start and end, such as creating a project or changing a plan.
- Ask an agent to do it with access only to what a third party would have: your public documentation, your API or your interface.
- Note which area it fails in: it could not get in (access), could not find the information (context), there was no action for the step (tools) or it did not know what context to start from (orchestration).
- Repeat with another agent. If one succeeds and another does not, the difference tells you what depended on the tool and what on your product.
Example
Illustrative example: a booking app wants an agent to be able to change an appointment. In the test, the agent cannot log in because access requires a code sent to the person’s phone (access). Once the person solves that, the agent cannot find the change flow because it only appears after opening an unlabeled menu (context and structure). The team offers a permission limited to “manage appointments”, labels the menu and publishes a documented action to reschedule. They test again and measure whether the task finishes well, not how many calls were made.
Who answers if the agent makes a mistake?
Before opening a product to agents, decide what permissions the agent has, what gets logged and how an action is reversed. Those decisions are developed in action approval, human-in-the-loop and autonomy levels. Here it is enough to remember that AX without human control at sensitive steps is just an open door.
Common mistakes
- Assuming an agent is just one more user and changing nothing in the product.
- Treating AX as a replacement for UX: people are still the ones who decide.
- Hiding permissions or actions inside menus the agent cannot see.
- Granting full access to avoid friction and losing human control.
- Measuring AX only by the number of calls, without checking whether the task finished well.
- Taking one author’s framework as an industry standard.
When NOT to prioritize AX
When the product depends on human presence, such as an emotional experience or a learning session, or when the risk of an agent acting without supervision is high. If your product still has basic UX problems, fix them first: an agent will not understand a confusing structure either.