There's a new kind of user in our logs. They don't read your docs. They don't churn out of frustration. They don't yell at you on Twitter when something breaks. They just retry, fail silently, and vanish — and you'd never know they were there if you weren't watching for the cadence.
They're agents. And in a lot of products, they're already the majority.
That's from a Mintlify event last month where I talked about the agent experience work I lead at Auth0. Three layers — context, tools, evals — and a public score at auth0.com/agent-experience because AX has to be a number, not a vibe. If you can't grade it, you can't ship it.
Look at any serious dev tool. Cloudflare ships MCP servers for every major product line and llms.txt across the docs. Vercel made its docs queryable as llms.txt and its deployments invokable as an MCP call. Sentry's MCP lets a model triage issues without ever opening the dashboard. Railway treats its CLI like a first-class agent surface, not a human afterthought.
None of them announced an "agent strategy." They just quietly rebuilt for a user with no eyes.
Here's the kicker, and it's the part that surprised me most: you can't skip DX to get to AX. Every clean API, every structured error, every SDK you ever sweated over for human developers? Turns out you were building for agents the whole time. They're trained on human code, human docs, human principles — the same ones you wrote. Good DX literally trained the model that's now hitting your endpoint.
The teams that respected developer experience get most of agent experience nearly for free. The teams that cut corners are about to discover — at scale, in production, with a real user watching — that an agent will retry, fail, and confidently lie to your customer about why.
Building for someone who can't be charmed turns out to be the most clarifying product work I've done in years. No goodwill buffer. No aesthetic forgiveness. No relationship to lean on. Either it works or it doesn't, and the logs don't lie.
If you're a PM trying to figure out where to start, here's how I'd think about it:
- Get headless. If your product only works through the UI, agents can't use it.
- Ship
llms.txt. Cheapest move, biggest payoff. I added one to this blog — bharath.sh/llms.txt. If a one-person site can ship one, your product has no excuse. - Expose actions. SDK, CLI, MCP server, agent toolkit, packaged skills — every surface where an agent can actually do something with your product. Pick the ones that fit your shape and make them first-class, not afterthoughts.
- Structure your errors. "Something went wrong" is a developer's problem; an agent will just confidently lie to your user about why.
And underneath all of it: evals. Pick five canonical tasks an agent should be able to complete cold. Run them on every release. Without evals, the rest decays — your llms.txt goes stale, your SDK quietly regresses, your MCP server starts returning confident garbage and nobody notices until a customer does.
Evals are how you actually know you have AX, not AX theater. They're the foundation everything else sits on.
I've been deep in the weeds on this at Auth0 for a while. Our agent evals are open source at github.com/auth0/auth0-evals. The score they produce is public at auth0.com/agent-experience. And because we couldn't help ourselves, the scorecard page itself is agent-readable. Try auth0.com/agent-experience.md.