Guide · See
What is agent experience (AX)? How to make your company navigable for AI agents
What agent experience (AX) means, where the term came from, and how to give AI agents what a new hire gets: owners, workflows, rules, access and someone to ask.
The short answer
Agent experience (AX) is how easily AI agents can understand and work inside a product or a company: finding the right information, knowing who owns what, and using tools safely. It is the agent counterpart of user experience. For a company, good AX means giving every agent what a new hire gets: named owners, the real workflow, a source of truth for each kind of data, the rules, the right access and someone to ask.
Key takeaways
- AX is to AI agents what UX is to people. Netlify’s CEO, Mathias Biilmann, introduced the term in January 2025 for products. It applies just as much to companies.
- An agent joining your company needs what a new hire needs: owners, the real workflow, sources of truth, rules, access and someone to ask. Today much of that lives only in people’s heads.
- Good company AX has five layers: knowledge, access, rules, people to ask and feedback. Build them one workflow at a time, and the same map serves your people too.
What is agent experience (AX)?
Agent experience (AX) is how easily AI agents can understand and work inside a product or a company. Good AX means an agent can find the right information, knows who owns what, uses the right tools with the right access, and knows when to ask a person. It is the agent counterpart of user experience (UX).
Inside a company, every agent is a new colleague, and often a forgetful one. Each Claude Code session, for example, starts with a fresh context window. Only its instruction files and its own notes carry over. Whatever an agent needs to know about your company has to be written down, current and easy to find. Otherwise it guesses, and a wrong guess reads as confidently as a right one.
Take a deal desk agent asked to summarize a discount request for the approver. With good AX, it knows that Salesforce holds the deal, which pricing policy applies, who signs off, and that multi-currency deals go to a person. With poor AX, it finds three versions of the pricing policy, picks one, and sends the summary to whoever approved the last deal it saw.
Where does the term agent experience come from?
Mathias Biilmann, Netlify’s co-founder and CEO, introduced the term in a blog post on January 28, 2025, “Introducing AX: Why Agent Experience Matters.” He defined AX as “the holistic experience AI agents will have” when they use a product or platform. As he tells it, AX follows two older terms: Don Norman coined “user experience” in 1993, and Jeremiah Lee coined “developer experience” in 2011.
His questions were about products. Can an agent get access to a platform on a user’s behalf? Are its APIs clean and well described? Is its documentation ready for machines to read? A year later, in “One Year of AX,” he grouped the work into four areas: access, context, tools and orchestration. He also predicted that AX would become as broadly relevant as UX. Every product already has an agent experience, he wrote: “it’s purely a question of whether it is good or bad.”
The same is true of companies. If AI agents work in your systems, your company has an agent experience. The rest of this guide is about making it a good one.
What is the difference between AX for a product and AX for a company?
AX for a product is about outside agents using what you sell. AX for a company is about your own agents doing your work. Most writing on AX covers the first, and its tools are well known:
- Docs that agents can read. The llms.txt proposal, published by Jeremy Howard in 2024, puts a short markdown file at a website’s root, with background and links to clean text versions of its key pages. Its 2026 update says thousands of sites now publish one, including OpenAI, Anthropic and Google’s Gemini for their developer docs.
- APIs that agents can operate. Biilmann’s test is whether a product has clean, well-described APIs that an agent can use on a user’s behalf.
- Connections through MCP. The Model Context Protocol, which Anthropic open-sourced in November 2024, is a standard way to connect AI assistants to the systems where data lives. A product with an MCP server can be used by any AI application that supports the protocol.
AX for a company faces the other way. Your own agents need to know how your company runs: its workflows, people, systems and rules. Howard notes that an llms.txt file could also describe a business’s structure and policies. Inside a company, though, that picture changes often and much of it is private, so it needs owners and permissions.
| Aspect | AX for a product | AX for a company |
|---|---|---|
| The agent | An outside agent, working for one of your users | Your own agent, doing your company’s work |
| What it needs | To find your product, understand it and use it | To know who owns what, how work flows, where the truth is, the rules and whom to ask |
| What good AX looks like | llms.txt and markdown docs, clean APIs, an MCP server | A digital org, standing instructions, skills, scoped connections and named approvers |
| Who owns it | Product, documentation and developer relations teams | The owner of each workflow, with IT and security |
| When it’s poor | Agents struggle with your product, and users pick one their agent can use | Agents guess, stall or escalate everything, and people redo the work |
What does an AI agent need to work inside your company?
The same things a new hire needs. Anthropic makes the comparison itself: building a skill for an agent, its engineers write, is like “putting together an onboarding guide for a new hire.” The site for AGENTS.md, an open format for instructions to coding agents, gives similar advice: include whatever you would tell a new teammate.
The difference is how they learn. A new hire picks up most of what they need from people: shadowing a colleague, asking in Slack, overhearing a decision. An agent can do none of that unless someone builds it in.
| What they need to know | How a new hire gets it | What an agent needs |
|---|---|---|
| Who owns what | Asking around, and the org chart | A named owner for every workflow, system and decision, where it can look them up |
| How work really flows | A few weeks of shadowing colleagues | The real steps, with exceptions and handoffs, not only the official SOP |
| Which system is the source of truth | Finding out which spreadsheet everyone trusts | One named source for each kind of data, and which copies to ignore |
| The rules and exceptions | The policy documents, and being corrected | Written rules with thresholds and exceptions, and hard limits enforced in software |
| The right access | An IT ticket in the first week | An identity of its own, with only the access its tasks need |
| Someone to ask | A manager and helpful colleagues | A named person for each kind of question, and a rule for when to stop and ask |
| How they’re doing | A manager’s feedback over months | Corrections that update its instructions, skills and tests |
The gaps are easy to miss, because people fill them without noticing. At the example company in Nolli’s product demo, the revenue ops lead is the only person who handles renewal exceptions, and the rule isn’t written down anywhere. A new analyst would learn it by asking the lead. An agent wouldn’t know there was anything to ask. That is key-person risk, and an agent inherits it on its first day.
Why do AI agents struggle inside most companies?
Because most companies are documented for people who can ask. Much of the know-how lives in people’s heads. What is written down is often out of date, scattered across tools, or different from how the work actually runs, a difference known as the conformance gap.
Share of 12,000 knowledge workers surveyed who say they often find that the only way to get the information they need is to ask someone or schedule a meeting.
Share of 175 realistic tasks at a simulated software company that the best agent tested completed on its own. Data science, admin and finance tasks scored lowest.
TheAgentCompany, a benchmark from researchers at Carnegie Mellon and elsewhere, puts agents inside a simulated company, with internal websites, files and colleagues to message. The authors suggest a reason admin and finance tasks scored lower than coding. AI development has leaned on coding, where public training data is plentiful. Admin and finance work runs on data that usually stays private inside companies. Their notes on failures read like a bad first week. Told by a colleague to introduce itself to someone else next, one agent skipped it and declared the task done. Another couldn’t find the right person to ask on the company chat, so it renamed a different user to that person’s name.
Models have improved since that study. Better models still don’t supply missing context. No model was trained on your discount policy, your approval chain or the reason your team ignores one column in the CRM.
Nor is more context the fix. Anthropic’s engineers treat context as a scarce resource: the more a model’s context window holds, the less reliably it recalls any one piece. Pasting the whole wiki into every prompt can make answers worse. An agent needs a map: a short index of what exists and where, with pointers it can follow when a task calls for them. Claude Code works this way. It loads its instruction files up front and searches for everything else as it goes.
What does good agent experience look like in a company?
Good company AX has five layers. Each one answers a question an agent would otherwise guess at.
- Knowledge What is true here?
Who owns what, how work flows and which system is the source of truth, written down, current and easy to search.
At the deal desk Deals live in Salesforce. The pricing policy has one current version. The sales ops manager owns the North America desk.
- Access What may I touch?
An identity of its own, with scoped connections to the systems its tasks need, and nothing more.
At the deal desk Reads Salesforce and the pricing policy. Posts drafts in Slack. Can’t approve or change a deal.
- Rules What must I follow?
Standing instructions, skills, thresholds and exceptions, with hard limits enforced by permissions.
At the deal desk Runs the same three checks in every region. Sends multi-currency deals to a person.
- People to ask Who decides when I’m unsure?
A named owner, approver and escalation path for each kind of question, and a rule for when to stop.
At the deal desk The regional owner approves. About one in ten deals goes to Sales leadership.
- Feedback How do I get better?
Corrections flow back into the instructions, skills and tests, so a mistake isn’t repeated.
At the deal desk Every edit an approver makes is logged and kept as a test case.
In practice, the layers are built from these parts:
- Knowledge that is written down, current and machine-readable. This is a digital org: a living map of people, roles, workflows, systems, documents and rules. Give every entry an owner and a last-reviewed date. Anthropic’s engineers note that names and timestamps help an agent judge what is relevant. A dated page with a named owner is worth more to an agent than a polished deck nobody maintains.
- Standing instructions. Files that agents read at the start of every session. Software teams already do this for code. AGENTS.md, now stewarded by the Linux Foundation’s Agentic AI Foundation, is used by more than 60,000 open-source projects. Claude Code’s CLAUDE.md files can hold instructions for a project, a person or a whole organization, and IT can deploy rules for everyone. The rest of the company needs the same for its work. One caution: Claude Code treats these files as context rather than enforced settings. To block an action whatever the model decides, its docs point to a hook, a check that always runs.
- Skills. Packaged know-how for a specific task, loaded only when the task calls for it. Anthropic built them because, as its engineers put it, real work requires “procedural knowledge and organizational context.” See our guide to AI skills.
- Connections with scoped permissions. MCP connects agents to your systems, and each connection should grant only what the task needs. The protocol’s own security guidance warns against catch-all scopes: a stolen broad token reaches unrelated tools, and one all-purpose scope hides what each action was for in the audit trail.
- Agent identities and least privilege. Give each agent an identity of its own instead of a person’s login. Microsoft’s Entra Agent ID, for example, gives agents the same identity protections as people and workloads, such as access policies and lifecycle management, and logs all their activity. It also lets you name a sponsor: a person accountable for each agent’s access. The OWASP Gen AI Security Project warns against “excessive agency,” which it traces to too much functionality, too many permissions or too much autonomy.
- Escalation paths and approvers. OpenAI’s guide to building agents names two triggers for handing work to a person: the agent has hit its limit on retries or actions, or the action is sensitive, irreversible or high-stakes. Write down who gets each kind of escalation, by name or role, and what the agent does while it waits. At the example company in Nolli’s product demo, the support team’s triage agent routes every ticket and hands Tier-2 cases to people. See human-in-the-loop.
- Feedback loops. Every correction should leave the agent better informed. Claude Code’s docs suggest adding to its instructions when it makes the same mistake a second time, or when a new teammate would need the same context. Do the same with skills and tests: when an approver fixes a summary, fix the rule behind it and keep the case as a test.
Most of these parts plug into the agent’s harness, the software that turns a model into an agent. A harness can load instructions and enforce permissions, but it can’t invent your owners, rules or approvers. Your company has to supply them.
How do you improve your company’s agent experience?
One workflow at a time. Pick one that agents will work in soon, make it easy for them to find their way around, prove it, then move to the next. Much of what you write down for one workflow, such as owners, systems and rules, carries over to the ones that follow.
- Pick one workflow. Choose frequent work with clear owners and results you can check, such as deal desk approvals or ticket triage.
- Map how it really runs. Talk to the people who do it, and check the systems and documents. Record the real steps, exceptions included. Our guide to mapping a process for AI shows how.
- Write down what a new hire would ask. Owners, the source of truth for each figure, the rules and thresholds, and the exceptions only one person knows.
- Connect and limit. Give the agent its own identity, a sponsor and scoped connections, read-only until it has earned more.
- Name the people to ask. An approver for each decision, an escalation path for each kind of problem, and a rule for when to stop.
- Test it in shadow mode. Let the agent work real cases without acting, and note every time it gets lost or has to ask. Each of those moments points to missing context. See shadow mode.
- Keep it current. Give each piece an owner and a review date, and update it whenever the work changes.
- Every step, system and decision in the workflow has a named owner.
- The real workflow is written down, exceptions included.
- Each kind of data has one named source of truth.
- Rules and thresholds are written where agents can find them.
- Hard limits are enforced by permissions, not only by instructions.
- The agent has its own identity, a sponsor and least-privilege access.
- Each connection grants only the scopes the task needs.
- Every decision has a named approver and an escalation path.
- Corrections update the instructions, skills and tests.
- Every piece of context has an owner and a review date.
This is the forward-deployed engineer’s playbook: learn how the work really runs, from people, systems and documents, before you build. Good AX keeps that knowledge after the engineers move on. It helps people too. The map that onboards an agent also onboards a new analyst, and renewal exceptions no longer depend on what one person remembers.
Questions people ask
Is agent experience the same as AX in a contact center?
No. In contact centers, agent experience (AX) usually means the day-to-day work environment of human support agents: their tools, processes and support. Contact-center vendors such as Genesys define it that way. This guide is about AI agents, and how easily they can understand and work inside a product or a company.
How is agent experience different from UX and DX?
User experience (UX) is how people experience a product. Developer experience (DX) is how developers experience building on it. Agent experience (AX) is how AI agents experience a product or a company: whether they can find what they need, act with the right access and know when to ask. Many improvements help all three, such as clear documentation and named owners.
Who should own agent experience in a company?
Share it. The owner of each workflow owns its context: the steps, rules, exceptions and approvers. IT and security own agent identities, connections and permissions. A small central team, often the one leading AI adoption, sets the standards and checks that the context stays current.
Is llms.txt enough to make a company ready for AI agents?
No. An llms.txt file helps outside agents read your public website. Your own agents need what isn’t public: who owns what, how work flows, which system is the source of truth, the rules, the right access and someone to ask.
How do you measure agent experience?
Watch where agents get stuck. Track how often they escalate, ask for help, get corrected or fail for lack of context, and how long it takes to get a new agent working in a workflow. Every correction that traces back to missing context points to a gap to fill.
Do we need to map the whole company before deploying agents?
No. Start with the workflows agents will work in first, and map each one well: its owners, systems, rules and approvers. The map grows with every workflow you add, and much of it, such as owners and systems, is shared across workflows.
Sources
- “How Claude remembers your project.” Anthropic, Claude Code docs, accessed October 4, 2026.
- Mathias Biilmann. “Introducing AX: Why Agent Experience Matters.” biilmann.blog, January 28, 2025.
- Mathias Biilmann. “One Year of AX.” biilmann.blog, January 28, 2026.
- Jeremy Howard. “The /llms.txt file, v2.” llmstxt.org, September 3, 2024, updated August 10, 2026.
- “Introducing the Model Context Protocol.” Anthropic, November 25, 2024.
- Barry Zhang, Keith Lazuka and Mahesh Murag. “Equipping agents for the real world with Agent Skills.” Anthropic, October 16, 2025.
- “AGENTS.md.” AGENTS.md (agents.md), accessed October 4, 2026.
- “The State of Teams 2025.” Atlassian, March 2025.
- Frank F. Xu, Yufan Song, Boxuan Li and 18 others. “TheAgentCompany: Benchmarking LLM Agents on Consequential Real World Tasks.” arXiv (2412.14161, version 3), September 10, 2025.
- Prithvi Rajasekaran, Ethan Dixon, Carly Ryan and Jeremy Hadfield. “Effective context engineering for AI agents.” Anthropic, September 29, 2025.
- “Security Best Practices.” Model Context Protocol documentation, accessed October 4, 2026.
- “What is Microsoft Entra Agent ID?” Microsoft Learn, accessed October 4, 2026.
- “Governing Agent Identities.” Microsoft Entra ID Governance documentation, Microsoft Learn, accessed October 4, 2026.
- “LLM06:2025 Excessive Agency.” OWASP Gen AI Security Project, accessed October 4, 2026.
- “A practical guide to building agents.” OpenAI, accessed October 4, 2026.
- “What is Agent Experience (AX)?” Genesys, accessed October 4, 2026.