Agent experience (AX) describes how well an AI agent copes with a product, from finding and picking it to using it, and it is not the working life of call-centre staff, which the same phrase also names. Netlify's CEO coined the term in January 2025, and we heard Netlify CTO Dana Lawson put it on the main stage of Infobip Shift 2026 in Zadar, the conference we attended, as a formula:
UX + DX = AX
We read about 25 LinkedIn posts and their comment threads from October 2026, vendor research and the first measurements of agent traffic, and our conclusion is less dramatic than the formula. Most of AX is the discipline good developer experience always asked for, applied to a user who reads exactly what is written and never asks a question, and two parts are new: deciding what an agent is allowed to do, and deciding whether agents are customers or a threat to your business model.
This post sets out what people mean by AX, where they agree and where they split, and the order in which we would act: measure agent traffic, fix errors and APIs, add files such as llms.txt, and design the limits at the same time as the access.
What is agent experience (AX) for AI agents?
Agent experience means designing a product, API or website for a user who is software: the agent has to work out what the product is for, get the same result on every call and find a way forward when a call fails. Netlify's knowledge base frames AX around the same three needs.
The idea goes back to the essay "Introducing AX: Why Agent Experience Matters", published by Netlify's CEO on 28 January 2025, which treats the agent as a third user persona next to the end user (UX) and the developer (DX). Teams call the practice agent experience design, and some agencies use the label agentic experience for something else.
Why does one term mean four things?
The same three letters carry at least four meanings in October 2026. The original is the agent as a user of your product. Some agencies use "Agentic Experience" for a delivery model, how to afford building agent-heavy products when AI does parts of the work and seniors direct the system.
Product designers frame it as a third question after UX (is it usable by people) and AI experience (do people trust, steer and correct it): is it usable by an AI agent acting on someone's behalf. In contact centres, finally, "agent experience" means the working life of human support staff, and those pages dominate search results for the phrase. In this post AX means the experience of the AI agent as the user.
Where do the LinkedIn posts agree?
Three points came up in nearly every thread. Agents are users now, and power users increasingly tell their agent what to do instead of clicking through an interface. Structure beats surface, since agents read structure and docs rather than visual hierarchy, so the API is where an agent learns the product and a form built from clickable divs leaves it guessing which button does what.
The third point is the human who must be able to step in, so making things easy and making them safe is one design task. The catch is a person who stays formally accountable slowly loses the practical ability to judge, until oversight becomes routine approval.
Where do they split?
The first split is whether it is early. Some commenters think it is far too early for the ordinary person to use agents, while a Sentry analysis of three months of agent visits found AI reading its docs about twice as much as people do, and server logs from DevTune, shared in the replies, put AI fetches of docs above 10 times human views, a figure its author calls rough. The two sides describe different users: ordinary people are early, developers are not.
The second split is llms.txt. One practitioner watched an agent follow an in-page pointer to llms.txt and pull four relevant docs pages, while Sentry found llms.txt in about 0.1% of coding-agent fetches and DevTune in about 1.7%, against around 9% for URLs ending in .md.
Several posts note Google has said Search does not use the file, and one describes researchers who registered package names listed in companies' llms.txt files and received a callback within four minutes, which makes the file a security surface; we have not seen the research ourselves.
The third split is about business models. Some argue for letting users bring their own agent through APIs or an MCP server instead of hosting the agent in your product and paying for every token. Others argue a delivery app treats a shopping agent as a threat because its model lives on the screen, in paid placements and upsells an agent never sees, and Salesforce is reported to meter agent access through usage credits. Agent-friendly and revenue-friendly pull apart as soon as revenue depends on a human looking at a page.
What should a team do about AX first?
Our position is to count agent traffic first, fix errors and APIs second, add llms.txt and similar files third, and design the limits alongside the access, because the first measurements say agents already read documentation at scale, skip the front door and take every word as written.
How do you find out how many agents use your product?
Check your server logs before you design anything. Cloudflare reported on 28 September 2026 a 48% share of agents in Wrangler CLI use the previous week, up from a quarter in March, and most teams answer the question for their own product only with a guess. Sentry and DevTune did the counting in logs, and DevTune adds a caveat worth remembering: Claude Code identifies itself in the user agent, while Cursor and Codex often do not, so any count is a floor.
User agents undercount, so count a second signal next to them: requests with an Accept: text/markdown header and requests for .md URLs, which few browsers send. We would treat the gap between the two numbers as an estimate of the agents not naming themselves.
After counting, measure two things, as Microsoft's developer team suggests in its AX guide of 6 October 2026: propensity, whether agents choose your product, and efficacy, whether they use it correctly. Treat every best practice as untested until an agent has run it several times, since a single run proves little.
Why fix errors and APIs before llms.txt?
Think of the API as the hallway an agent walks through and of docs, skills files and llms.txt as the signage. Test it by taking the signage away: if the agent still gets through, the hallway works, and if it does not, a better llms.txt will not fix it.
The evidence supports the order. In Microsoft's small tests an agent used the tool correctly in 5 of 5 runs when a warning named the failing approach and in 1 of 5 when it got a more direct docs tip, and Claude Haiku 4.5 completed 2 of 5 deployments through a CLI with a JSON input mode against 5 of 5 with regular arguments.
An agent recovers when an error says what failed and what to try next, in a form software parses, and stalls on a sentence written for a human; Netlify's knowledge base makes the same point. Cloudflare said in the same 28 September announcement it generated a new CLI from the OpenAPI schema behind its docs and SDKs, covering more than 3,000 operations against about 280 in Wrangler.
Markdown comes next, because HTML is expensive for a model. Vercel reported on 3 February 2026 a blog post dropping from about 500 KB of HTML to 3 KB of Markdown, Cloudflare's Markdown for Agents (12 February 2026) cut one post from 16,180 tokens to 3,150, and DevTune's logs show coding agents reading .md URLs about five times as often as llms.txt.
In a post of 23 April 2026 Neon reported llms.txt on 93% of the more than 250 documentation sites it polled, so adopting the file is cheap and common, but treat it like code: someone should review every edit, since agents read it as an install guide.
How do you design limits for an agent?
Access without limits is the half of AX making headlines for the wrong reasons. Resend, the email API company, describes the pattern in its agent experience guide: instant onboarding without a sales call, limited-scope API keys agents create, rotate and delete themselves, an audit log separating agent actions from human ones, and human confirmation for risky actions. One rule flips a decade of UX instinct: in AI products, removing a step takes away the moment a person would have caught the mistake, so a little friction protects the user.
The test for every checkpoint you add is whether the person reviewing it has the time, the competence and the authority to say no, because a checkpoint nobody is able to refuse is only a log entry.
The literal-reader view gives a second rule. A caller who follows the contract exactly does everything the contract allows, because it has no instinct for what you meant to leave out. So a limit written in the docs is signage, and only a limit enforced in the permission is a limit. Put the rule in the key's scope, not in a sentence an agent is asked to respect.
Are agents your customers or a threat?
Decide before an agent decides for you. If your revenue depends on banners, upsells and screen time, AX exposes the conflict immediately, and blocking agents as bots will lose you the customer who sent one; if it depends on outcomes, an agent is one more sales channel, and the useful work is making your product the one an agent picks. DoorDash and Uber are reportedly testing orders placed by agents inside Google's Gemini, which shows where the contest is heading: from who has the best app to who the customer's agent chooses.
Our rule of thumb: if more than half of your revenue needs a person to see a screen, plan for agents as a risk first, and if most of it comes from the outcome of a transaction, plan for them as a channel first.
Who owns AX, and who learns it?
Some call AX nobody's job today, and others doubt it will consolidate as a discipline. We would not hire for it yet in a small team; we would give it to whoever owns the docs and the API and run it as a checklist, with a role following when the numbers justify it.
The harder question is who will be senior in ten years if AI takes over junior work, because AI amplifies what a person already knows: an experienced engineer gets several times better and an inexperienced one produces bad work several times faster. Lawson, whom we heard at Shift, told ShiftMag on 28 September 2026 she sees teams of five to ten with separate roles giving way to one to three people covering work end to end, and summed AX up as "A great developer experience is an agent experience." Our conclusion is practical: AX tasks such as reading agent logs, rewriting an error message and reviewing what an agent did are judgment work, and they are the small jobs juniors should be handed, because the judgment gets built there.
A first task looks like this: take one real agent failure from the logs, rewrite the error behind it, rerun the same task and compare. If the agent still fails, the message is not fixed yet. The rerun does the reviewing, so a senior reads results instead of every line, which is how the junior gets room to learn.
How does Workspace apply AX on its own website?
We started with our own site, since it is the cheapest place to see what an agent gets. workspace.hr serves an llms.txt pointing to an information sheet for AI assistants in English and Croatian, with a JSON version of the same data, and a request with Accept: text/markdown returns the page as Markdown with an x-markdown-tokens header. We also publish an auth.md describing how an agent registers over OAuth 2.0, and agent skills under /.well-known/agent-skills. Our earlier post on making a website visible to AI search engines covers the same ground from the reader's side.
Given the order above, our next step is the one we would recommend first: counting agent requests in our own logs before adding more files. On client work we sit on the consuming end of other people's APIs every day. Boat4You syncs 13,752 yachts from MMK and NauSYS daily, so we know what an undocumented field or a vague error costs a team forced to guess. A daily sync has no judgment either: it reads what is written and writes what it reads, which is the nearest thing we run to an agent today.
Count first, then rewrite one error message
AX comes down to one habit: look at your product from the side of a caller who reads exactly what is written, never asks a question and has no way to call your sales team. Four checks take an afternoon.
- Count the requests from known AI user agents in your server logs for the last 30 days, and note how many hit docs,
.mdURLs and/llms.txt. - Trigger your five most common API errors and read each one as an agent would: does it say what failed, give a code and name the next step?
- Request your main docs page with
curl -H "Accept: text/markdown"and compare the size with the HTML version. - Write down what an agent is allowed to do with your product, who is able to revoke it, and which actions need a human to say yes.
If you want a second pair of eyes on your site, API or product, we run this audit as part of discovery. Reach out to book a discovery session.
