Key takeaways

Agent Experience (AX) describes how well an AI agent, acting as a user of your product, can discover your API, call it reliably, and recover when something fails. Netlify CEO Matt Biilmann coined the term.
AX isn’t developer experience running faster. A human shrugs off vague docs and infers what you meant; an agent’s task can break entirely on that same ambiguity, which forces different design decisions, not just tidier versions of old ones.
The shift matters because a growing share of how software gets built, and how people even find products, is now mediated by agents. A product an agent can’t figure out is increasingly a product that’s invisible, no matter how good it is for a human clicking around.
Good AX doesn’t sideline the person behind the agent. It’s designed so the agent gets a better outcome specifically so the human it’s acting for does too, which is the actual point of doing this at all.
AX quietly serves non-developers as much as developers, because an agent acting on a Domain Expert’s behalf needs the exact same discoverable, reliable, recoverable interface a developer’s agent does.

You’ve spent years, maybe your whole career, making sure your product’s documentation is clear, your onboarding doesn’t lose people, and your API errors actually tell a developer what went wrong. That work has a name: developer experience, DX, and it’s been a real discipline for a long time. Now picture the exact same product, except the thing reading your docs, calling your API, and reacting to your error messages isn’t a person anymore. It’s an AI agent, working on a person’s behalf, often without that person watching each individual step. Everything you optimized DX for was built around a human’s patience, judgment, and ability to fill in gaps. None of that transfers automatically to an agent, and that gap is exactly what Agent Experience is a response to.

What Agent Experience actually means

Agent Experience, AX, describes how well an AI agent, acting as a user of a product or platform, can do three specific things: discover what the product does and how to use it, call it reliably and get a consistent result, and recover when something goes wrong instead of getting stuck. Netlify’s CEO, Matt Biilmann, coined the term, and it’s caught on because it names something a lot of teams were bumping into without a shared word for it: their product might be genuinely great for a human, and still nearly unusable for an AI agent trying to act on a person’s behalf.

Those three properties, discovery, reliability, recovery, aren’t arbitrary. They map to the actual places an agent gets stuck. It can’t find the right endpoint or capability in the first place. It calls something correctly but gets an inconsistent or ambiguous result back. Or it hits an error and has no path forward because the failure wasn’t designed to be legible to anything but a human staring at a stack trace.

Why this isn’t just “developer experience, but faster”

It’s tempting to treat AX as DX with a deadline, the same good practices, just applied more urgently because agents move fast. That undersells what’s actually different. A human developer who hits unclear documentation has options an agent doesn’t: they can guess based on experience, check a community forum, ask a coworker, or just try three things and see what sticks. That tolerance for ambiguity is a real, essential part of how DX has worked for decades. Good docs help, but a skilled, patient human can often route around bad ones.

An agent generally can’t do that same routing, or does it far less reliably. Ambiguity that a human shrugs off can break an agent’s task completely, not because the agent is less capable, but because “infer what the author probably meant from context and prior experience” is a much harder, much less reliable operation for a machine acting programmatically than it is for a person with years of accumulated pattern recognition. That means the fixes are different too. A more thorough paragraph of prose might help a human. An agent often needs a structured, predictable response it can parse without needing to infer anything at all: a clear status, a specific error code, a documented next step. Good AX isn’t “more DX.” It’s design decisions aimed at a genuinely different kind of reader, one that fails differently than a human does.

The white space nobody else is claiming

Here’s the part worth sitting with: the natural failure mode of “let’s design for AI agents” is to end up designing only for the agent, and quietly lose sight of the person the agent is supposed to be helping. Every competitor building agent-facing tooling right now is functionally doing that to some degree, because it’s the easier version of the problem. Netlify’s stated position is the opposite bet: design seriously for the agent as a user, specifically so the human on the other end of that agent gets a better result, not so the agent becomes the product’s actual audience. Humans stay the central characters. The agent is the very capable assistant doing the legwork, not the one the work is ultimately for.

That distinction sounds subtle until you watch what it changes in practice. A platform optimizing purely for agent throughput might quietly make it harder for the human supervising that agent to see what’s happening, if faster automation is the only goal. A platform practicing real AX keeps a human checkpoint (a Deploy Preview, a pull request, a clear log) visible and legible at each step, precisely because the agent’s job is to get a person to a good outcome faster, not to remove that person from the loop entirely.

What an agent platform actually has to get right

It helps to think about this at the product level, not just the API level. An agent platform, in the fullest sense, is any product or service that AI agents interact with as users on someone’s behalf. For that product to actually get used inside agent-driven workflows at all, it has to support the same three things at the whole-product level, not just in a single API call: can an agent discover what this product can do for the person it’s helping, can it act on that reliably, and if something breaks, is there a real path to recovery, or does the whole task just fail silently. Products that get this right don’t just have good technical documentation. They’ve thought about the entire path an agent takes from “here’s what my user wants” to “here’s confirmation it worked,” and made every step of that path something a machine can actually follow.

Netlify’s own webinar on how developers build for AI agents today walks through what this looks like in practice, and it’s worth watching if you’re the one deciding how your own product should behave once an agent, not a person, is the one calling it.

Why this matters more than it might seem to right now

It’s easy to file AX under “nice to have, eventually,” the same way some teams once treated mobile responsiveness as optional before it clearly wasn’t. The shift underneath AX is bigger than a UX nicety: a growing share of how software actually gets built now runs through coding agents that recommend platforms, deploy to them, and describe them to the humans they’re working for. A growing share of how people research and choose products runs through AI answers, not a search results page a human scrolls through. If an agent can’t figure out how your product works, can’t call it reliably, or hits a dead end when something fails, you’re not just providing a slightly worse experience to a niche technical audience. You’re becoming harder to find, harder to recommend, and harder to use, across a channel that’s only growing, regardless of how good your product actually is for the human who eventually gets there.

AX serves the Domain Expert too, not just engineers

There’s a version of this that sounds like it’s only relevant if you write APIs for a living. It isn’t. When a non-developer describes a tool to a coding agent and that agent goes and builds, deploys, and configures it on their behalf, every one of the discovery, reliability, and recovery properties that make up good AX are working (or failing) on that person’s behalf, even though they never see an API response directly. The Domain Expert building their first real application is depending entirely on the agent they’re using having a good Agent Experience with whatever it’s calling underneath. Good AX, in that sense, isn’t a developer concern that happens to matter to everyone else too. It was always meant to reach exactly that person, one layer removed.

FAQs

Who coined the term Agent Experience?

Netlify’s CEO, Matt Biilmann, coined Agent Experience (AX) in 2025, describing how well an AI agent, acting as a user of a product, can discover its API, call it reliably, and recover when something fails.

Is Agent Experience just developer experience for AI agents?

Not exactly. DX assumes a human who can infer intent past unclear documentation. An agent generally can’t do that same inferring reliably, so AX requires different design, structured and predictable responses an agent can parse, not just clearer prose a patient human could work around.

Does designing for AI agents mean designing against human users?

No, and this is the actual point of doing AX well. The goal is for the agent to get a better result specifically so the human it’s acting for does too. Products practicing real AX keep human checkpoints, like a preview or a clear log, visible at each step rather than removing the person from the loop.

Why does Agent Experience matter if I don’t build APIs for a living?

Because a growing share of software gets built and found through agents acting on people’s behalf, including non-developers describing what they want to a coding agent. If that agent can’t discover, reliably call, and recover from failures in what it’s working with, the person behind it gets a worse outcome, even if they never see the API directly.

What are the three things good Agent Experience actually requires?

Discovery (can an agent find out what a product does and how to use it), reliability (does calling it produce a consistent, predictable result), and recovery (when something fails, is there a clear, actionable path forward instead of a dead end).

Design for the agent, build for the human

If an agent is going to act on your behalf, or on your users’ behalf, the platform underneath it has to be legible enough for that agent to actually get the job done. See what that looks like in practice, then go build on infrastructure that was designed with exactly this in mind, starting at netlify.new.