On this page · 10 sections
  1. Where the term came from
  2. The meanings you will meet
  3. The agent’s path through a product
  4. What AX changes in practice
  5. AX sits beside UX, DX, and GEO
  6. Who works on agent experience
  7. What the evidence says so far
  8. AX is not a universal score
  9. What to do first
  10. Frequently asked questions

Agent Experience (AX) is the quality of a product as AI agents experience it while doing work on behalf of a person. An agent does not encounter that product the way a person does. It works through the surfaces around it: a website, help centre, API, tool description, form, permission boundary, and handoff to a person who can make the final decision.

Scope: This guide uses Agent Experience (AX) for AI agents acting for people. The same words carry other meanings, including the working life of human contact-centre staff, and the meanings section below sorts them out.

AX is the practical work of making those surfaces legible enough that an agent can find the right route, use a capability correctly, and get back on track when something breaks. It starts with one question: what must be true for an agent to help someone complete this job well?

Where the term came from

The AI-agent sense of the term is attributed to Mathias Biilmann, chief executive and co-founder of Netlify, in a post titled “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” (biilmann.blog). The post presents AX as the next step after user experience and developer experience, and asks three practical questions: can an agent get access to a platform on a user’s behalf, are there clean and well described APIs, and is there documentation ready for machines to read?

The post is dated 28 January 2025 in its byline, checked on 8 October 2026, and the article index of agentexperience.ax, a community site hosted by Netlify, gives the same date. One soft spot remains: Netlify’s own page states that “Netlify coined the term in 2025” (netlify.com), which is a first-party claim.

Independent writers credited Biilmann quickly. On 19 February 2025, Zeno Rocha of Resend wrote that “a couple of weeks ago, Mathias Biilmann coined the term AX” (resend.com), and Jim Nielsen discussed the post on 2 March 2025 (blog.jim-nielsen.com). So the AI sense is attributed to Biilmann, in early 2025, and nobody owns the definition. No standards body has adopted one.

The meanings you will meet

A search for “agent experience” returns pages that use the phrase in at least five ways. Each usage answers a different question, and mixing them up leads teams to fund the wrong work.

Meaning What it describes Where you will see it
AI agents as users of your product (this guide’s sense) What an outside agent, sent by a person, meets in your site, docs, API and tools Biilmann and Netlify; agentexperience.ax; Resend; Nordic APIs; Microsoft, for coding agents using developer technology
Coding agents inside your own engineering work How well your repository, prompts and habits set up the coding agents your engineers use DX’s “Agent Experience” product, which asks the coding agent to score each session (getdx.com, April 2026)
AI experience design How people experience AI features: trust, transparency and behaviour Marta Fernandez expands AX as “AI Experience Design” (Medium)
Human agents in contact centres The tools, processes and working conditions of customer-service staff Genesys and other contact-centre vendors
Agent readiness (a neighbouring term) Whether a website, codebase or organisation has prepared for agents, usually as a checklist or score Website scanners such as Cloudflare’s; Factory’s repository levels; Microsoft’s organisational assessment

Two of these deserve a note. The contact-centre usage came first: ICMI, which publishes for contact-centre leaders, wrote about “AX (agent experience)” in September 2022 and pointed back to a 2019 report on the state of agent experience (icmi.com). It is an established field with its own vendors and metrics.

The coding-agent sense shares the name but not the owner, and “is it a coding agent?” is the wrong test. Ask instead whose technology the agent is using, and for whom. If a developer’s coding agent is building with your SDK, API or CLI, that developer is your customer and the agent is an outside user of your product: that is outward AX, the same discipline as a shopping agent on your website. If your own engineers’ agents are working in your own repository, the work is about engineering effectiveness and sits closer to developer productivity, which is what DX’s product scores. Say which one you mean on first use. This site uses the outward meaning throughout.

One current framing. On 6 October 2026, Microsoft published “What is Agent Experience (AX)?” by Waldek Mastykarz. It defines AX as “the experience AI agents have when discovering, choosing, and using your technology”, and adds that practising AX means improving that experience and measuring whether you did (developer.microsoft.com). The post says the idea applies to any AI agent, but its method and examples centre on coding agents using developer technology: developers ask agents “to build with your SDK, API, or CLI”, and the vendor watches what the agent produces. That is outward AX in this guide’s sense, applied to developer tools, and its measurement vocabulary (bare baseline, lift and drag, agent profile, task cost) is covered in how to measure agent experience. This site’s scope is wider: any job a person delegates to an agent, including the moments where the agent has to ask for approval, hand work back, recover from a failure or stop at a boundary.

The agent’s path through a product

A useful agent journey needs more than a capable model. The product has to help the agent move from a person’s goal to a responsible next step.

  1. Orient: understand the goal, relevant context, and boundaries of the job.
  2. Discover: find the right page, documentation, capability, or route.
  3. Act: select and use a tool or workflow with the context it needs.
  4. Collaborate: ask for approval, preserve context, or hand work back when judgement matters.
  5. Learn: make the outcome and failed attempts legible enough to improve the next run.
The agent's path through a productFive steps an agent takes through a product, Orient, Discover, Act, Collaborate and Learn, with the surfaces it relies on at each; what it learns feeds the next run.STEPRELIES ONNEXT RUN1OrientThe person's request,the job and its limits2DiscoverWebsite, help centre,documentation3ActAPI, tool description,form4CollaboratePermission boundary,approval, handoff5LearnRecord of the outcomeand of failed attempts
The agent's path through a product, with the surfaces it relies on at each step. Open the diagram

Any one of these steps can make an otherwise capable system feel unreliable. An agent can find a product but not know which tool applies. It can complete work but lose the reason for it at a handoff. It can retry a failure without making the next attempt safer. These are product-surface problems as much as they are model problems.

What AX changes in practice

AX turns vague requests to “make it work with agents” into concrete design work. A team can inspect the workflow in front of it and ask:

  • Is the task and its stopping point clear?
  • Can the agent distinguish the right path from nearby but different ones?
  • Does each capability say what it is for, when not to use it, and what it returns?
  • Are constraints, permissions, and important state visible at the moment of choice?
  • When something goes wrong, can the agent explain the situation and move to a safe next step?
  • Can a person understand what happened, take over when needed, and improve the workflow later?

The answers show where to focus: a clearer tool description, better documentation, a narrower workflow, a more useful approval screen, or a recovery path that preserves the work already done.

AX sits beside UX, DX, and GEO

User Experience focuses on how people use a product. Developer Experience focuses on how people build with it. GEO focuses on making useful information discoverable in AI-mediated search. AX is concerned with the product experience an AI agent has while acting for someone.

These disciplines overlap, but they are not interchangeable. A beautiful human interface can be hard for an agent to navigate. A capable API can still be difficult to select or use correctly. A discoverable page can still lead to an unclear workflow. Good AX connects the journey across those boundaries without removing the person from the loop. The side-by-side comparison sets the four out in a table, and the AX glossary keeps a definition and an origin for each term this field guide uses.

Who works on agent experience

The groups below are listed by type, in alphabetical order, with examples in alphabetical order too. Inclusion describes who publishes on the topic. It is not an endorsement or a ranking, and most of these groups sell something connected to their framing.

  • Dedicated AX sites. agent-experience.dev collects agent engineering patterns. agentexperience.ax, hosted by Netlify, publishes principles and a curated reading list. agentexperiences.com uses AXO for being both cited by AI systems and usable by agents, and grades its own evidence openly, calling its main framework “a structured heuristic, not a validated model”. auxfirst.com separates AX from agentic user experience, the view of the person who delegates. Each ties its vocabulary to its own framework or practice.
  • Design research and independent writers. Jim Nielsen and Nordic APIs publish explainers and comparisons. Nielsen Norman Group’s “AI Agents as Users” (April 2026) treats agents as a user group that design has to account for.
  • Platform and developer-tool vendors. Anthropic, Cloudflare, DX, Microsoft, Netlify, Resend, Speakeasy, Stainless and Vercel publish guidance, frameworks or scanners, each connected to its own products.
  • Research groups. Academic preprints have begun to test parts of the idea, from website design for shopping agents to the quality of tool descriptions. The next section covers two of them.
  • Standards and specification communities. The Model Context Protocol maintainers, the W3C community group drafting WebMCP, and the authors of conventions such as llms.txt and AGENTS.md define many of the surfaces agents read. The standards guide tracks where each one stands.

For transparency: this site is written by an independent practitioner who offers AX workflow reviews, so read its framing with that in mind.

What the evidence says so far

The term is under two years old, and the evidence behind it is thin and uneven. Three findings matter, each labelled with the kind of evidence it is.

  • One controlled study of one site (preprint). Said Elnaffar and Farzad Rashidi built two versions of the same prototype shop, with identical catalogue, prices and stock, one designed for people and one for agents. Across five tasks, three browser agents and 300 runs, strict success rose from 74 of 150 runs (49.3%) to 134 of 150 (89.3%) (arXiv 2607.12056). The authors call it “preliminary evidence”. It covers one site, it does not show which individual change mattered, and none of the changes was a named standard such as llms.txt or MCP.
  • A large scan plus a controlled test (preprint). Peiran Wang and colleagues examined the descriptions of 10,831 MCP servers and found quality problems widespread, including repeated tool names, wrong parameter meanings and missing return descriptions. In controlled tests, repairing descriptions changed which tool models chose. When functionally equivalent servers competed, descriptions that met their quality standard were picked 72% of the time against a 20% baseline (arXiv 2602.18914). It is one team’s study and has not been replicated.
  • Readiness scores are checklists, not validated predictors (vendor tools). At launch, Cloudflare described its scanner as scoring four dimensions: discoverability, content, bot access control and capabilities, and the live scanner now groups its checks differently (blog.cloudflare.com). Ora’s ranker runs 127 checks across four layers, and is-agentic.com, built with Vercel, reads a smaller set of essentials from the same scan (ora.ai, 20 August 2026). The checks differ, so scores from different tools are not comparable, and neither launch post publishes a study showing that a higher score means agents complete more tasks.

Taken together, they give early, specific support for the idea that the surfaces an agent reads change what it does. Nothing yet supports a single number that sums up AX. Both studies are single-team preprints, so treat them as reasons to test your own workflow rather than as results to expect.

AX is not a universal score

One number cannot describe every agent, model, product, or task. AX is a practical lens for making delegated work clearer, safer, and easier to improve, and it is useful when a team can point to a real workflow and say what changed for the better.

A checklist is still useful for a different purpose: seeing which parts of one job a product is ready for. The Open Agent-Readiness Rubric checks one job at a time and gives a profile rather than a score that claims to predict how any agent will behave.

What to do first

Do not begin by asking how much autonomy a product can support. Begin with a job people actually want to delegate: reconcile an account, research a vendor, prepare a brief, resolve a support issue, or update a record. Give that job a clear start, observable outcome, and a reason to pause or return work to a person.

Then follow the agent’s path through the product. Notice where it cannot find a route, cannot tell two actions apart, lacks context, hits a consequential choice, or cannot recover. The most valuable improvement is usually the smallest change that makes the next attempt more useful and more understandable.

Three next steps, depending on where you are:

  1. To learn the field in order, continue with the AX framework in one page, the next step in the reading order on the guides page.
  2. To take stock of a product, check one real job with the agent-readiness rubric, knowing it is not a prediction.
  3. To test one real workflow, follow how to run an AX review, which walks a single job from goal to handoff.

Frequently asked questions

What is Agent Experience? Agent Experience, or AX, is the quality of a product as experienced by an AI agent doing work on behalf of a person. It covers whether the agent can understand the job, find the right path, use a capability with the right context, recover from uncertainty, and hand work back well.

Who coined agent experience? In the AI-agent sense, the term is attributed to Mathias Biilmann, chief executive of Netlify, in his post “Introducing AX: Why Agent Experience Matters”. The post is dated 28 January 2025, and Netlify states that it coined the term, which is a first-party claim. Other writers, including Zeno Rocha of Resend in February 2025, credited Biilmann within weeks. The contact-centre use of “agent experience” is separate and was in use earlier. No standards body owns either definition.

What does AX mean in AI? In an AI context, AX is short for Agent Experience: the experience an AI agent has of a product while it carries out a task for a person. The contact-centre meaning of AX, the working environment of a human support agent, is a separate field that was in use before the AI sense, so it is worth naming which one you mean on first use.

Is agent experience the same as agent readiness? No. Agent readiness usually names a checklist or score of whether a website, codebase or organisation has put certain things in place, such as a sitemap, a Markdown version of each page or an AGENTS.md file. Agent experience is the quality of what an agent actually meets while doing a job. A readiness check can point to gaps, but none of the public scanners reviewed for this guide has published evidence that its score predicts whether agents complete tasks, so treat a score as an inventory rather than a verdict.

What makes a product agent-friendly? Agent-friendly products make their purpose, paths, capabilities, constraints, state, and next steps clear. The aim is to keep human control while making delegated work easier to understand, inspect, and improve.

How should a team start improving Agent Experience? Start with one useful workflow rather than a broad autonomy ambition. Follow the journey from a person’s goal through discovery, tool selection, execution, handoff, and recovery. Then improve the smallest surface that prevents a useful next attempt.

Is Agent Experience the same as UX, DX, or GEO? No. UX centres the person using a product, DX centres the people building with it, and GEO concerns discoverability in AI-mediated search. AX connects the product surfaces an AI agent relies on while acting for a person.

What is an agent experience platform? The phrase carries the same split as the term itself. In the AI sense it names a product that scores, monitors or helps improve how AI agents use a website, API or codebase, and the scope differs from one vendor to the next. In the contact-centre sense it names the software a human support agent works in all day. Neither is a standard, so when you meet the phrase, check which agent it means and what the platform measures before you set it beside the guidance here.

What is agent experience analytics? Agent experience analytics is the measurement side of AX: the record of what agents attempted on a product, where they stalled, what they retried and whether the person got the outcome they asked for. It reads the evidence a product team already keeps, from the agent’s side. The four metric families show how to set it up without collapsing AX into one number.

Start with the workflow people want to delegate, then make the product around it easier to use well.