What is Agent Experience?

An agent does not encounter a product in the same way a person does. It works through the surfaces around the product: a website, help centre, API, tool description, form, permission boundary, and handoff to a person who can make the final decision.

AX is the practical work of making those surfaces easier to discover, understand, use, and recover through. It starts with a simple question: what must be true for an agent to help someone complete this job well?

The agent’s path through a product

A useful agent journey has more than a capable model behind it. The product needs 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 judgment matters.
5. Learn: make the outcome and failed attempts legible enough to improve the next run.

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 reveal 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 vocabulary around all four moves quickly, so the AX glossary keeps a definition and an origin for each term this field guide uses.

Start with one real workflow

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.

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. It earns its value 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: taking inventory of what a product has actually made explicit. The Open Agent-Readiness Rubric does that, and says plainly that its score describes declared surfaces rather than predicting how any agent will behave.

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