What is agent experience (AX)?

AX, short for agent experience, is what an AI agent goes through as a user of your product: discovering what you do, getting authorized to act for a person, calling you correctly, and recovering when it gets something wrong. Netlify co-founder and CEO Mathias Biilmann popularized the term in a January 2025 essay, defining it as the holistic experience AI agents will have as the user of a product or platform. The confusing part is that the same phrase has an older meaning in customer service, where it describes the working experience of human contact center agents. Both meanings are in active use, which is why search results for the term look like two unrelated topics.

How is agent experience different from user experience?

User experience optimizes for a person who can look at a screen, infer what is possible from what is visible, and ask a colleague when something is ambiguous. An agent can do none of that. It cannot see affordances, it has a fixed context window, it has no memory of yesterday unless you give it one, and it cannot tell that a file named with an underscore is the draft. So agent experience moves the work from layout and visual hierarchy to machine-readable entry points, documentation an agent can actually fit and parse, unambiguous data, explicit permissions, and errors that say how to fix themselves. It does not replace UX. Most products now need both at once.

What does good agent experience look like in practice?

Good agent experience is a short, concrete list: a documented API, CLI or MCP server that reaches the same capabilities your UI does, docs sized and structured to fit inside a coding agent's context window, a signup and authorization path an agent can complete on a person's behalf without a human clicking through it, one canonical version of every object so an agent is never guessing which of five files is current, per-agent credentials scoped to least privilege, and rate and spend limits set for a caller that works at machine speed. Founders building developer tools describe redesigning docs specifically so a coding agent gets higher accuracy and makes fewer mistakes during integration.

Should you build a separate interface for AI agents?

Usually not a separate product, but yes to a separate surface. The practical answer from Box CEO Aaron Levie is that you now ship two things at once: software powerful enough for a person to manage agents, and software that makes the agents themselves effective. In most products that means keeping the human interface and adding a machine-readable path to the same capabilities, rather than building a second application. Start by checking whether an agent can complete your product's core job end to end without a human clicking anything. Whatever blocks it is your agent experience backlog, in priority order.

How do you improve agent experience?

Run the end-to-end test first: point a coding agent at your product with no human helping and ask it to find you, sign up, authenticate and complete your core job. Every place it stops is a ranked backlog you did not have to invent. From there the triage is usually the same three items in the same order. Measure your documentation in tokens and restructure the integration path so it fits comfortably in a context window. Audit API-to-UI parity, because whatever your interface can do and your API cannot is a hard ceiling on every agent that will ever use you. Then set per-agent credentials, spend caps and an audit log that records the human principal alongside the agent identity, since those are far cheaper to add before an incident than after one.

Agent Experience: When Your User Is an Agent

Agent experience is what an AI agent goes through while using your product: finding you, getting authorized to act for a person, calling you correctly, and recovering when it gets something wrong. It is a design discipline aimed at a user who cannot see your interface.

One warning before anything else, because it wastes a lot of reading time. The phrase has an older meaning in customer service, where it describes the working experience of human contact center staff, and Wikipedia documents both, noting the call center sense is still sometimes intended in 2026. Half the results you find will be about the other job. This piece is about AI agents as users.

What agent experience means

Agent experience, usually shortened to AX, is the experience an AI agent has as a user of your product. Mathias Biilmann, co-founder and CEO of Netlify, gave the term its current definition in a January 2025 essay: "the holistic experience AI agents will have as the user of a product or platform." He put the design questions plainly. Is it simple for an agent to get access to operating a platform on behalf of a user? Are there clean, well described APIs an agent can operate? Is there machine-ready documentation? His conclusion is the part most teams skip: this requires thinking about agents as a persona your team builds for, not as a feature you add.

That is a different claim from adding AI features to your product. It says the agent is a customer segment.

Why agent experience stopped being a UX detail

The evidence is founders describing a change that already happened to their businesses. On YC Root Access's panel of devtool founders, a group of developer tool founders were asked who their audience is. The answers had shifted under them. One put it as a trend line still in motion: "The main audience is developers, but increasingly more so it's becoming agents." Another was blunter: "The customer is usually agents. So we spend a lot of time building interfaces for agents, for instance, CLIs and skills and so on."

They do not all agree, and the disagreement is the useful part. One founder draws the line differently: "we see agents as distribution and developers as the users." That is a real fork. If agents are distribution, AX is a growth channel and you optimize for being found and recommended. If agents are the users, AX is product work and you optimize for whether the agent can actually finish the job. Most teams will end up doing both, but they cost different things and they are owned by different people, so it is worth deciding which one you are funding this quarter.

Asked what they would do differently starting today, one founder gave the answer that names the whole discipline: "consider agent experience as a first-class" part of the interface. Another, looking forward: "you've got to really think about not only developer experience, but also agent experience."

Y Combinator made the same bet institutionally. Its Software for Agents request for startups argues that agents need documentation "to enable them to discover, sign up for, and instantly start using new tools programmatically without needing a human in the loop", and that the winners here will not be incumbents adding a feature: "It'll come from startups that build explicitly for agents as first-class citizens."

The two products you are now shipping

You are now shipping two products, not one: software powerful enough for a person to direct agents, and software that makes the agents effective. The framing comes from Box co-founder and CEO Aaron Levie, speaking at a Greylock Change Agents event with investor Corinne Riley. Riley put a line back to him that he has made repeatedly in public, that we have been building software for humans and are now building software for agents, and asked what that does to a software business.

His answer refuses the either/or. Start with the constraint: "I'm very uh convinced that users are still going to want to see a lot." As long as that holds, he argues, there is a strong case for dedicated software per category, which is the opposite of the theory that agents dissolve applications into a database call.

Then the actual work: "You have to both build software that is super powerful for the user to manage the agents and then you have to build software that makes the agents really effective."

That is two products, not one, and most teams are only staffing the first. Every roadmap decision from here has to answer both questions. Does this make the human better at directing agents? Does it make the agent better at finishing the task? A feature that only does one is half a feature.

If you are on the other side of this decision, choosing which agent tools your own team runs on, the same reasoning applies in reverse when you evaluate AI developer tools.

Agent experience examples: what an agent needs from your product

An agent cannot look at your interface and infer what is possible. Strip the affordances away and a short, unglamorous list is what is left.

A machine-readable path to the same capabilities. Not a subset. The founders in that YC Root Access video described "making everything into a CLI, making data more exportable" so an agent can reach it. Whatever fraction of your interface the API cannot reach is the exact ceiling on what any agent will ever do with you.
Docs an agent can fit and parse. One founder described the shift directly: "we've redesigned a large portion of our docs to be able to fit inside a coding agent's context window very easily." The stated result was higher accuracy and fewer mistakes during integration. This is the cheapest work on the list and the most neglected, and it is the same muscle as treating developer relations as a product decision.
An authorization path an agent can complete. The ambition in that video was a world where "an agent can sign up, can pay, manage access" with no human in the loop. Whether you want that is a policy question. Whether you have thought about it is not optional.
One canonical version of everything. An agent has no way to tell which of five similarly named files is current, so every object needs exactly one authoritative location and one authoritative name.
Errors that explain their own fix. A human reads a 400 and files a ticket. An agent reads a 400 and retries the same call. The remedy belongs in the response body.

Levie's architectural point is worth stealing. Asked how he would rebuild Box knowing what agents need, he said the tech would mostly stay, because of a discipline they held for two decades: "we would never have two versions of Box." No on-premise fork, no customer-managed versions, no second place a file could live. "There's only one way to to store a document in Box." The payoff arrived twenty years later, when an agent layer got to ride on primitives where the location of any given object has exactly one answer.

Ambiguity is the tax. Levie describes an agent walking into a real enterprise where someone asks for the latest contract with a client, and finding that "there's like 43 conflicting things that look like maybe they're the latest" version of it. A colleague resolves that instantly, because they know the local convention about which filename is the draft. Nobody wrote it down, because nobody had to.

Agent experience design: build for a colleague who forgets everything

Levie's test for whether your process is agent-ready travels to any company. Redesign the workflow as if "imagine a super intelligent person showed up but they know zero about your business and they forget everything" ten minutes later. Then ask what that person would need written down.

His warning about skipping it: "if you don't re-engineer your process for agents, then you're capped" at a modest productivity gain, and he flags that the specific number he uses is invented. The direction is the point: wrap an agent around a process built for people who share tribal knowledge and you get a supercharged version of the old process, not a better one.

That gap between what the agent has and what a colleague has is a context problem, and it is solvable. The mechanics of solving it are context engineering for AI agents.

The transparency dial your human user still needs

The second product, the one for the human managing agents, has its own failure mode: showing everything.

Levie's example is what a coding agent already looks like to a non-engineer. The MCP tool names an agent surfaces mid-task are "very janky", he says, "because they're named by engineers", and most people would find the raw stream of what an agent is doing more alarming than reassuring. His team's actual design problem is a sequence of plain questions: "How do I hand that task off to an agent? How do I see the work that it's doing as it's happening and then how do I land at a point where I can go review it" and check it.

Transparency is a dial, not a switch. What that supervision surface should actually render, per user and per task, is the argument in generative UI. Too little and the person cannot supervise. Too much and you have shown them the inside of the computer. The same reasoning decides when a chat box is the wrong surface, which is the argument in conversational UI.

Making your product discoverable to agents

Agents cannot choose what they cannot find, and the discovery problem exists inside companies as well as outside them.

Arvind Jain, co-founder and CEO of Glean, described it at the same Greylock series. On agents inside a large company: "they're not going to be useful if they're not discoverable". His answer: "There has to be this concept of a searchable agent library" plus an orchestrator that knows what each agent can do. He cites one customer that built roughly 2,000 agents in six months, and says his own company has thousands internally, to the point that eight near-identical agents exist for a given task. His conclusion is that curation is a requirement, not a nicety.

Outside the company, the same pressure shows up as a distribution channel. One of the YC Root Access founders: "More and more tools will get predominantly chosen by agents, not developers". Another said the genuinely unexpected thing agents did for them was bring customers in, because coding models recommend their product unprompted.

The related maintenance argument is worth a mention because it is a startup idea sitting in plain sight. A separate YC request for startups, Self-Maintaining APIs, makes the case that in a world of coding agents "API providers shouldn't just announce changes, they should apply them", opening the pull request against the customer's codebase themselves. The pitch is "Think like Dependabot, but for APIs." Whether or not you build that, it is a good measure of how far the bar has moved.

What agents do to pricing

How to price an AI product at all is answered in AI pricing. What changes when the caller is an agent is narrower, and Levie's observation is the one to bring to your next pricing meeting: "systems of record were built for a TAM of human employees." Your seat count was capped by headcount. Agent counts are not, and he expects "a hundred times more agents than people or a thousand times more agents than people."

He does not think the seat model stretches to cover agents, but he is careful about why. You cannot "perfectly analogize the seat to the agent model" because an agent can be sharded arbitrarily, so you cannot "treat them exactly as a user seat". Box's own answer today is a split: seats for the human users and consumption-based pricing for the agents, normalized into an internal unit it calls AI units.

His stress test is a customer with 10 petabytes of data and a vendor's agent that wants to read all of it every minute. That is not a seat, it is infrastructure cost, and it needs "an agent, you know, kind of API fee" priced per interaction.

He is also blunt that walling agents out is not the play: you will not be able to "close your data off from other agents", however much some people would like to try.

The security cost of building for agents

I am a CISSP, so this is where I get uncomfortable with how the AX conversation is usually framed. Every affordance you add for agents is an authenticated, scriptable path into your product, exercised at machine speed by a caller you cannot verify socially. Good agent experience and a large attack surface are the same engineering work described by two different teams.

Note the shape of the excitement in those answers: an agent that can "use 10, 20, 100x more compute or any other service than the human would have ever been able to". That sentence is a product vision and an abuse ceiling in the same breath.

Six controls, in the order I would ship them:

Give agents their own identity. An agent acting for a user should not carry that user's session token. Issue a distinct credential per agent per customer, so you can revoke one without logging out a person.
Scope on-behalf-of authority explicitly. Biilmann's question about an agent operating a platform on behalf of a user is an authorization design problem, not a login flow. Delegated scope, an expiry, and a ceiling on what can be spent or deleted.
Read before write. Ship the read-only agent surface first, watch real traffic for a month, then open writes on the endpoints that earned it.
Log the full triple. Every action should be attributable to a human principal, an agent identity, and a specific tool call. If your audit log records only that a user updated a record, it is already wrong.
Rate limit and spend cap by default. Limits tuned for humans are decoration once a caller can retry a thousand times a minute. Set the ceiling before someone finds it for you.
Treat your agent-facing surface as untrusted input in both directions. Docs and API responses an agent reads are also an injection path into that agent. Content you return can end up executed as instruction.

Worth separating from all of this: deciding which automated traffic to allow at all is a different question, and a legitimate agent acting for a named customer is not a bot. That distinction is the subject of bot detection.

Where the advantage sits, startup or incumbent

There is a comfortable story where incumbents win this because they have the data. Levie tells the more honest version: a startup can rebuild the interface from scratch but starts with nothing in the warehouse, while an incumbent has years of data and cannot blow up an interface its customers depend on. Each advantage is the other side's constraint. Which side you are on decides your data strategy.

YC puts the opportunity plainly. While everyone else is building agents, "the biggest opportunity might be building the software that those agents depend on."

What to do this week

Run the end-to-end test. Point a coding agent at your product with no human helping and ask it to complete your core job: find you, sign up, authenticate, do the thing. Write down every place it stops. That list, in order, is your AX backlog.
Measure your docs in tokens. Take the integration path a new customer follows and check whether it fits comfortably in a context window. If it is spread across nine pages of exposition, restructure the top three.
Audit API-to-UI parity. List what your interface can do and what your API can do. The delta is your ceiling for every agent that will ever use you.
Find your ambiguity. Ask the team for one thing an agent cannot resolve that a colleague resolves instantly, usually a naming convention nobody wrote down. Write it down, then encode it.
Set the limits before you need them. Per-agent credentials, a spend cap, and an audit log carrying the human principal alongside the agent identity. All three are cheaper this week than after an incident.
Pick your side of the fork. Agents as distribution or agents as users. Fund one properly this quarter rather than both badly.

If you want the whole operating system for running a company this way, from product decisions through engineering and security, that is what I teach in AI Operating System for Startups. The wider map of how these pieces connect is in AI for startups.

Sources

Building Software for AI Agents instead of Humans (Greylock), the clip this article distills, in which Box CEO Aaron Levie sets out the two-products argument in conversation with Greylock's Corinne Riley.
SaaS with 1000x More Agents than People with Box (Greylock Change Agents), the full session that clip comes from, and the source for the Box architecture discipline, the 43-conflicting-contracts example, the transparency problem, the agent-with-no-memory test, and the pricing material.
Meet The DevTool Founders Building For AI Agents (YC Root Access), for the audience shift, the docs-in-a-context-window redesign, and agent experience as a first-class part of the interface. The video is an unlabeled montage of several founders, so the quotes here are attributed to the panel rather than to named individuals.
Software for Agents and Self-Maintaining APIs, two Y Combinator requests for startups, for the agents-as-first-class-citizens argument and the case for API providers shipping their own migrations.
Fixing the AI Agent Discovery Problem (Greylock), where Glean CEO Arvind Jain makes the searchable-agent-library argument and gives the 2,000-agents example.
Introducing AX: Why Agent Experience Matters, the January 2025 essay by Netlify co-founder and CEO Mathias Biilmann that gave the term its current definition, and Agent experience (Wikipedia) for the term's history and for the older contact center meaning that still shares the phrase.
Background on the people named: Aaron Levie and Box (Wikipedia), Corinne Riley (Greylock), and Arvind Jain (LinkedIn) of Glean.