---
title: "What Is Agent Experience (AX)?"
description: "Agent experience (AX) is how AI agents discover, choose, and use your product. This guide uses the AI-agent meaning, not the contact-center one."
canonical: "https://www.agentrail.co/blog/agent-experience"
author: "Sidhant Goyal"
published: "2026-10-17T00:00:00Z"
last_updated: "2026-10-23T05:59:19.709Z"
---

# What Is Agent Experience (AX)?

Agent experience (AX) is how AI agents discover, choose, and use your product. Genesys and Salesforce also use the phrase for human contact-center work. This guide is the AI-agent meaning.

![Three glass layers labeled user experience, agent experience, and developer experience](https://images.ctfassets.net/1htfyfnn1o5y/6LwGJswoANUFo21v3Nzd4g/cfcca80f24d4e749f0b0f43b93311c1c/hero_image-1.png?w=1600&fm=webp&q=72)

If you searched for agent experience from a contact center, you want a different definition. [Genesys defines agent experience (AX)](https://www.genesys.com/definitions/what-is-agent-experience-ax) as the quality of a human agent's day-to-day work environment, including the tools, processes, and support systems that shape how effectively they serve customers. Salesforce's contact-center products are a second home for that human-rep meaning. On 29 April 2025, [Kat Holmes, Chief Experience Officer](https://www.salesforce.com/blog/agent-experience-design/), used the same words for something else: optimizing digital environments so AI agents can operate in them. This guide follows that AI-agent meaning. Mathias Biilmann had already defined it in January 2025, in the essay linked below. Coaching, schedules, and handle time are not covered here.

Agent experience is the experience an AI agent has when it discovers, chooses, and uses your product. Practicing it means changing the surfaces the agent actually reads and calls, then checking whether the next attempt does better. The agent might be a coding agent in an editor, an assistant acting for a user, or a client calling your MCP server. You usually don't operate it. You still own the docs, the API, the SDK, and the errors it trusts.

On 26 August 2025, [Gartner predicted](https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025) that 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from less than 5%. The same note estimates that by 2028 a third of user experiences will shift from native applications to agentic front ends. Both lines are forecasts, not measurements of your funnel. They're why a definition that only covers human reps sends a platform team to the wrong work.

> **Key Takeaways**
>
> Genesys, and Salesforce's contact-center products, use agent experience for a human service rep's work environment. This page is the other meaning: an AI agent as a user of your product.
>
> Mathias Biilmann defined that meaning on 28 January 2025: the holistic experience AI agents will have as the user of a product or platform.
>
> Developer experience still matters. AX adds the agent a developer sends, which won't forgive a deprecated method just because the human docs are clear.
>
> Two questions cover the practice. Propensity: did the agent find and choose you? Efficacy: did it use you correctly once it had?
>
> A lab task on one agent profile isn't your production traffic. Measurement lives in [how to measure agent experience](https://www.agentrail.co/blog/how-to-measure-agent-experience).

## Agent experience is the agent's encounter with your product

Agent experience is the holistic experience an AI agent has as a user of a product or platform. The phrase, in this sense, comes from [Mathias Biilmann's essay on 28 January 2025](https://biilmann.blog/articles/introducing-ax/). He was CEO of Netlify. [Netlify's current AX page](https://www.netlify.com/agent-experience/) repeats the definition and points back to that essay. We didn't coin it, and this guide won't pretend otherwise.

Biilmann's questions are still the scope test. Can an agent operate the platform for a person? Are the APIs described so an agent can follow them? Are the docs and SDKs in a form a model can use? A no is still an experience. The agent routes around you, or it tells the user your product is broken.

Holmes's essay reaches a compatible place. An AI agent has goals and limits, even though it doesn't feel your brand. If it meets a broken process or inconsistent names, it can't finish. The person who sent it then has a bad experience too. This page stays on your environment as an outside agent meets it. Designing the internals of an agent you ship is a related craft, and it isn't the whole of AX.

The encounter has a shape. The agent arrives with a task, touches a surface you control, and either continues or stops. [Agent behavior](https://www.agentrail.co/blog/agent-behavior) describes paths that often don't match a human tour of the same site. [Agent analytics](https://www.agentrail.co/blog/agent-analytics) is how you count many attempts. AX is the experience those records are about.

Two boundaries keep the definition small. Getting an answer engine to mention you is a different job. An agent can arrive and still fail. A trace of an agent you operate is a different record, covered in [agent observability versus agent experience](https://www.agentrail.co/blog/agent-observability-vs-agent-experience).

## AX extends developer experience. It does not replace it

Developer experience is what a human goes through while building on your platform. Agent experience is what the agent goes through when that human sends it to do the building. Netlify's FAQ states the split. The two overlap, and they serve different users. A silent failure in a customer's agent is an AX failure even when a human, reading slowly, could have succeeded.

Docs quality is part of AX. It isn't the test. [Microsoft's developer blog](https://developer.microsoft.com/blog/what-is-agent-experience-ax/), on 6 October 2026, puts the failure in one scene. A developer asks an agent to build with your SDK. The agent picks a competitor, calls an API you deprecated, or reports success on a broken build. The human docs can still be excellent. The human wasn't the one reading them on a short budget.

That budget isn't a metaphor. In [Measuring Agents in Production](https://arxiv.org/abs/2512.04123) (Pan et al., revised 3 February 2026), 68% of deployed agents in the study execute at most 10 steps before a human intervenes. The authors surveyed 306 practitioners from April to November 2025, then focused on 86 production or pilot systems. Short agents don't browse like a patient developer. They take the first page that looks authoritative, call the first sample that parses, and stop. [Agent experience optimization](https://www.agentrail.co/blog/agent-experience-optimization) is the fix once you know which step died.

DX work is still worth doing. Humans review and ship. AX adds a user you can rerun, five times with a change and five times without. That advantage disappears if you only survey the humans.

## Two questions decide it: propensity and efficacy

Propensity asks whether the agent finds your technology and chooses it. Efficacy asks whether the agent uses it correctly once it has. [Waldek Mastykarz, writing for Microsoft on 6 October 2026](https://developer.microsoft.com/blog/what-is-agent-experience-ax/), uses those two questions as the core of AX. Other eval tools say discovery and selection, or quality. The labels can move. The split should stay.

Test propensity with a task that doesn't name you. "Add email sending to this app" is a propensity task if you sell email. Watch what the agent reaches for. Test efficacy with a task that names you. Watch whether it calls the current API or one you removed. A win on the second test can hide a loss on the first. Customers who already chose you send the named task. Everyone else sends the unnamed one.

[Microsoft published a worked example](https://developer.microsoft.com/blog/what-is-agent-experience-ax/), and it stays tied to its setup. They upgraded SharePoint Framework projects in GitHub Copilot Chat, with Claude Sonnet 4.6, on Windows, five runs. The bare setup passed 30 of 80 configuration checks. Telling the agent to use CLI for Microsoft 365 raised that to 75 of 80. The instruction only helps a developer who knows the CLI, or who installed a skill that carries it. The trail showed a better lever. The agent was already fetching the release notes. The team fixed the notes. Later runs used the CLI with no new skill. Microsoft's caveat applies. Each result holds for that scenario and that agent profile. Yours may differ. Don't copy 30 of 80 onto an industry slide.

On that same upgrade, a context7 MCP server added no meaningful lift. Its tools didn't load in three of five runs, and weren't called in the other two. An extension the agent doesn't load isn't part of the experience. The release notes were, because the agent was already reading them. When you need definitions for quality and cost, use [how to measure agent experience](https://www.agentrail.co/blog/how-to-measure-agent-experience). A single vendor's run count isn't a benchmark.

## The surfaces the agent actually touches

The experience is whatever the agent reads or calls. You can't change the model. You can only influence the harness through its vendor. Everything else on the path is yours.

- **Website.** Pricing, limits, and status, when the agent uses them to decide if you fit. A limit hidden in a screenshot gets skipped or misread.
- **Docs.** Release notes included, and the version the URL implies. An agent that retrieves during the task sees an edit on the next run. A model that only saw your docs in training doesn't.
- **API and errors.** Agents trust the body you return. A success status with a warning in prose is how a broken setup gets reported as done.
- **SDK, CLI, and samples.** An unpinned scaffolder can stamp a years-old version. The agent will treat it as current if you handed it over.
- **MCP and other extensions.** Skills and tool servers steer the agent only when they load. They're part of AX. They aren't AX by themselves.

[Agent discoverability](https://www.agentrail.co/blog/agent-discoverability) covers whether an agent can find the docs, the API, and the MCP server. That's the front of propensity, not the whole experience. An agent can find you and then misuse you.

Extras such as `llms.txt` or another MCP server are hypotheses until you measure them on tasks your users actually give. The context7 result above is one case where an extra source didn't help. Ship the surface the agent already reads before you add one it has to be told to load. A lab task on the SDK still isn't the full encounter. Production attempts also cross the website and the account system. [Agent analytics](https://www.agentrail.co/blog/agent-analytics) is how you count that path. AX is what the agent went through.

## An open product lets the user bring an agent

An open agent experience lets the user's own agent operate your product. A closed one asks the user to leave that agent and use the one you embedded. Biilmann's 2025 essay draws the line. Closed integrations were easier to ship, because cross-product conventions were thin. Treat the open side as a choice you can test, not as a law.

The test is propensity. If success requires opening your app and clicking your copilot, a coding agent that stays in the editor will fail or route around you. A thin API behind a polished human interface still looks incapable to that agent.

[McKinsey's 2026 survey](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai), fielded from 4 May to 8 June with 1,719 respondents, puts a number on the miss. Thirty-two percent said their organization had skipped at least one software purchase because agentic coding tools could build it. [Agent-led growth](https://www.agentrail.co/blog/agent-led-growth) covers that buying motion. We don't claim to have coined the phrase. The question here is simpler. When the agent shows up, can it finish?

Open doesn't mean every internal tool is public. It means a person can delegate a task to an agent they already use. A public sample that can't act for a signed-in user is only half an experience.

## Watch a real attempt, then change the surface that failed

A lab task shows propensity and efficacy for one agent profile. Production traffic shows the tasks agents already attempt, including the ones your script missed. You want both. A five-run sample isn't the market.

Move to traffic as soon as attempts exist. The failures that repeat are slightly off-script: an old tutorial, a regional auth error, a tool description that doesn't match the handler. The release-notes story is the pattern for the edit. Change a page the agent already fetched before you add an extension most users will never install. [How to measure agent experience](https://www.agentrail.co/blog/how-to-measure-agent-experience) is the metric set. This page won't restate it.

Before traffic is thick, a readiness scan shows how agents see the website, docs, and app, with JavaScript and without it. Findings include evidence and a fix prompt. [Agent readiness](https://www.agentrail.co/agent-readiness) is that scan. It's included. It doesn't reconstruct a live task, and it isn't a contact-center quality score. It answers a prior question. If an agent arrived right now, what could it read?

We reconstruct the live attempt separately, as a journey across website, docs, APIs, SDKs, and MCPs. The scan is what you see with no visitor. The journey is what a visitor did. Don't average a simulation into the same chart as production attempts. A simulation is a scripted run: 10 free a month, then $1.

## Start with one unnamed task and one named task

Write two tasks in the words your users would use. Leave the product name out of the first. Put it in the second. Run both on one fixed agent profile, and read the path rather than the closing summary. If you skip the path, a confident wrong answer looks like a pass.

Change a surface the agent already opened. Docs, error text, and the repo sample are the usual place to start. Add a skill only when the bare run had no other way to learn the constraint. Don't change the model in the same run, or you won't know which edit mattered.

If traffic already exists, check that your script resembles the task that actually shows up. Traces versus visitor records are in [agent observability versus agent experience](https://www.agentrail.co/blog/agent-observability-vs-agent-experience). If you don't want a harness today, scan the surfaces you think are fine and fix one finding before you add an extension. The scan is at [agent readiness](https://www.agentrail.co/agent-readiness).

## Frequently asked questions

### What is agent experience?

Agent experience, in the AI-agent sense, is the holistic experience an AI agent has as a user of a product or platform. It covers whether the agent can discover the product, choose it, use the current interface, and recover when something breaks. Mathias Biilmann published that definition on 28 January 2025. How to measure it is a separate guide.

### Is this the same as Genesys or Salesforce agent experience?

Genesys uses agent experience for a human contact-center agent's work environment. Salesforce's contact-center products sit in that same human-rep lane. [Kat Holmes](https://www.salesforce.com/blog/agent-experience-design/), on 29 April 2025, used the words for environments AI agents can operate. This page follows that essay. It isn't a workforce guide.

### How is AX different from UX and DX?

User experience is a person's encounter with a system. Developer experience is a developer's encounter with a platform. Agent experience is an AI agent's encounter with your product, usually while acting for a person. They diverge when the human path succeeds and the agent's short attempt doesn't. Netlify's public FAQ draws the same line.

### Does a docs site that humans like count as good AX?

It's a good start, and it isn't the test. Deployed agents in the MAP study often stop within a handful of steps, and they trust samples a human would question. Microsoft's 30 of 80 is one profile, not a universal docs score. Watch an attempt on your own surfaces.

## Conclusion

Agent experience is how an AI agent discovers, chooses, and uses your product. Genesys and Salesforce's contact-center line use the same name for a human rep's workday. Holmes's design essay, and Biilmann's 2025 definition, are the line this guide follows.

Propensity and efficacy are the two questions. The surfaces you can change are the website, the docs, the API, the SDK, and MCP. A five-run lab on one model is a start. Traffic is the rest. Measure it with [the metric guide](https://www.agentrail.co/blog/how-to-measure-agent-experience), and see what an agent can already read on [agent readiness](https://www.agentrail.co/agent-readiness).