What agent experience means
Agent experience (AX) is how well AI agents can discover, understand and use your product: your API, your MCP server, your CLI, your docs. The term was popularized in 2025 by Netlify's Mathias Biilmann, by analogy with user experience (UX) and developer experience (DX). Where UX asks how a person feels using your product, AX asks whether an agent working for that person can finish the task.
It is not the same as the agent experience of a support team or contact center, which is about the people answering customers. Here the agent is software, and it is your user.
Why it matters now
Coding agents, research agents and assistants already call APIs, run CLIs and connect to MCP servers on someone's behalf. When they get stuck, they behave differently from people:
- They do not file tickets. An agent that cannot finish retries, guesses at arguments, works around the problem, or gives up and tries another product.
- They fail quietly. A request that returns 200 with the wrong data looks like success in your logs.
- They never call what is missing. If your product lacks the tool an agent needs, no log line ever records the gap.
So a product can have plenty of agent traffic and a poor agent experience at the same time, and nothing on your dashboards will say so.
What good agent experience looks like
| Area | What agents need |
|---|---|
| Discovery | Docs an agent can fetch and read: llms.txt, Markdown pages, a README section written for agents |
| Tools and commands | Clear names and descriptions, typed inputs, one obvious way to do each task |
| Errors | Messages that say what went wrong and what to do next, not just a status code |
| Authentication | Flows an agent can start and a person can approve, such as OAuth or a device code |
| Limits | Rate limits and quotas that are documented and answered with a clear retry signal |
| A way to speak up | A tool, command or endpoint where the agent can report what blocked it |
How to measure agent experience
Logs, traces and usage analytics tell you what agents called and how long it took. They cannot tell you what the agent was trying to do, what it expected, or which capability it went looking for and did not find. For that, ask the agents.
When an agent hits a wall, have it report:
- What it was trying to do, in its own words.
- What it expected, and what happened instead, including the error text.
- How the task ended: blocked (it could not finish), worked around (it finished another way) or friction (it finished after retries or guessing).
- What would have helped: the missing tool, parameter or doc.
Counted over time, those reports become AX measures you can act on: the share of tasks that end blocked, the tools that cause the most friction, the capabilities agents ask for most, and the docs that confuse them.
Hear from the agents using your product
Agentback collects these reports for you. It adds a
send_feedback tool to your MCP server, a feedback command to your CLI, and a public address any agent can post to over HTTP. The tool description tells agents when to report, so you do not have to change their prompts.Reports land in one inbox, sorted by status, with the agent's name and model, the tool involved and your product's version. You can read them there, get them by email, or hand them to your coding agent through Agentback's MCP server and ask it to fix what blocked agents most.
An agent experience checklist
- Publish docs agents can read, and link them from
llms.txt. - Give every tool and command a description that says when to use it.
- Return errors that tell the agent what to do next.
- Let agents start sign-in and let people approve it.
- Give agents a way to report what blocked them, and read what they say.
- Fix the most common blocked tasks first, then watch the share of blocked reports fall.