API strategy
Agent infrastructure
Platform integration
Agent experience (AX) is the design discipline for how AI agents reach and act on products. How AX differs from DX and UX, and what good AX looks like in 2026.
Agent experience is the new design surface. The question this article answers: what does it actually mean to design for AI agents, and how does that differ from designing for human developers or human end users?
The short version: agent experience (AX) is the quality of how an AI agent perceives, reaches, and acts on a product. It overlaps with developer experience (DX) but isn't the same thing. A great DX can produce a terrible AX. A great AX often requires rebuilding assumptions that DX took for granted. Over the next five sections, we'll define AX, contrast it with DX and UX, walk through the design principles that hold up in production, and look at where most SaaS products fail the AX test today.
This isn't a vocabulary exercise. The companies treating agent experience as a real design discipline are the ones whose agents work. The ones treating it as "our API, but for robots" are the ones whose agents stall in PoC.
Agent experience is the quality of an AI agent's interaction with a product. That means everything from how the agent discovers what the product can do, to how it decides which action to take, to how it recovers when something goes wrong. AX is to agents what UX is to humans and DX is to developers — a design discipline focused on a specific consumer of your product.
The term was coined by Netlify CEO Mathias Biilmann in a January 2025 essay, "Introducing AX: Why Agent Experience Matters," building on the lineage of UX (Don Norman, 1993) and DX. It caught on quickly because teams building agents had already noticed the underlying phenomenon: two SaaS products could have identical REST endpoints, identical OpenAPI specs, identical auth flows — and one would let an agent complete a task in three calls while the other would loop, fail, and burn tokens. The difference wasn't capability. It was experience.
AX has four core dimensions:
These aren't theoretical. Every production agent project hits all four within the first month. The teams that built for AX from the start ship. The teams that bolted AX onto a DX-shaped product spend the next quarter fighting their own contracts.
DX and AX share a lot of surface area. Both care about good documentation, sensible naming, consistent error handling, and stable contracts. The differences come from the consumer.
A developer reads docs, makes judgment calls, holds context across a session, and remembers the conventions of your product after the third call. An agent does none of that reliably. It works from a tool description and a prompt. It does not remember that endpoint X returns a paginated list while endpoint Y returns the whole thing. It does not infer that status: "pending" and state: "in_progress" mean the same thing in two parts of your API. It does not know that you renamed customer_id to account_id six months ago and the old name still works but only on certain routes.
Here's where the two diverge in practice:
The biggest practical difference: developers build a mental model of your product. Agents don't. Every tool call is, to a first approximation, the agent's first encounter with your product. Designs that assumed accumulated developer context — like "obviously you'd call /auth before /orders" — quietly break.
A related point: good DX is necessary but not sufficient for good AX. If your API is undocumented and inconsistent, no agent will work against it. But making it well-documented and consistent — the bar for great DX — still leaves you short of the bar agents need. AX is a strict superset of the constraints DX imposes.
UX and AX feel more obviously different, but the comparison is worth making because some teams collapse them. They argue an agent is "just another user" and the same UX principles apply.
They don't.
A human user can see context. They look at a screen, register which buttons are dimmed, notice a tooltip, infer that something requires payment, and adjust. They reason from layout. Agents can't. They have access to whatever the product chose to expose through machine-readable channels — and nothing else. The agent does not see your dimmed button. It does not know the button exists.
A human user also tolerates ambiguity differently. If a form has a field called "reference," the user might pause, but they'll usually figure out from context whether to put a PO number or an internal note. An agent will either guess (badly) or fail. The cost of ambiguity is much higher because the agent's only repair mechanism is to try again, possibly making things worse.
The UX/AX overlap is real but narrow. Both care about clear language. Both care about reducing the cognitive load of completing a task. But UX assumes a user who can see, infer, and improvise. AX assumes none of that. Every affordance has to be explicit, machine-readable, and unambiguous.
The practical implication: products that have invested heavily in UX still often have terrible AX. The capability the human user takes for granted — clicking a button that has been visible on the page for two years — is exactly the capability that was never exposed through the API. That's the 2% problem. UX has matured. AX hasn't started.
What does it actually look like to design for agents? Here are the principles that survive contact with production agent traffic.
An agent reads a tool description and a parameter schema, then decides whether to invoke. If the description is vague ("manages customer records") or the parameters are loosely typed ("data: object"), the agent will either skip the tool or call it wrong. Tool descriptions are not marketing copy. They are runtime instructions. Write them like you'd write a docstring for a function someone has to call without reading the source.
A good tool description names the verb ("create," "update," "search"), the noun ("customer record," "invoice line item"), the prerequisites ("requires an authenticated session with write scope"), and the side effects ("sends a confirmation email to the account owner"). A bad tool description says "handles customer operations."
Developers chain calls. Agents sometimes do, but you can't rely on it. Every tool should be designed as if it's the only call the agent will make. That means input validation can't assume a prior call set up state. Errors have to be self-contained. Outputs need enough context that the next call (if there is one) can be reasoned about independently.
This pushes back on REST conventions. REST is a stateless architectural style that nonetheless assumes clients hold session state across calls. Agents aren't reliable at holding that state — each tool call is closer to a genuinely stateless interaction. The patterns that work look more like RPC than REST: explicit verbs, full payloads, minimal implicit state.
This is the single most under-invested part of AX. When a developer hits an error, they read the stack trace and the docs. When an agent hits an error, it gets a string. If that string is "Invalid request," the agent has nothing to work with. If it's { "error": "missing required field 'customer_id'", "hint": "call /search_customers first to retrieve a valid customer_id" }, the agent has a path forward.
Good AX error design treats errors as first-class affordances. They tell the agent what went wrong, what would fix it, and (when possible) what tool to call next. We covered the related patterns for tool calling reliability and webhook delivery elsewhere, but the principle is the same: agents need structured recoverability, not just status codes.
Agents that run as a shared service account are an audit and security disaster waiting to happen. Every agent action should be attributable to a real authenticated user, with that user's permissions and data visibility honoured. This is non-negotiable for any product that handles regulated data, customer PII, or anything subject to a security review. We've written a practical guide to OAuth for agents that walks through delegated access patterns.
The AX implication: your tool surface needs to expose user-scoped operations, not god-mode admin endpoints. An agent acting for User A should not be able to see User B's data, even by accident.
Agents do not handle breaking changes the way developers do. A developer reads a changelog, updates the SDK, fixes the broken calls. An agent reads a tool description that hasn't been updated, calls the old endpoint, gets a 404, and loops. We covered this in depth in API versioning when agents are the consumer — the short version is that the deprecation cliff that worked for developer audiences is a much harsher event for an agent population, and the design needs to plan for it.
The pattern repeats across every established B2B SaaS company we've talked to. The product was built for the UI. The API was built for partners and the integrations team — covering maybe 2% of what the product actually does. There's no tool manifest. Auth is API-key based. Errors are HTTP status codes and a string. Documentation lives in three different places and only one of them is current.
When the AI team starts building agents on top, they hit the AX gap immediately. The agent can't reach 98% of the product. The 2% it can reach is wrapped in a contract that was never designed for an LLM consumer. The team's two options look like:
The third path — and the one we'd argue is the right one for any company with more than a handful of products — is to treat AX as a generated layer rather than a hand-built one. Scan the existing product surface (codebase, internal APIs, whatever's actually there). Generate tools that meet the AX bar: self-describing, user-scoped, structured errors, stable contracts. Maintain those tools as the product changes, automatically. This is what we mean by Tools-as-a-Service and it's the operational shape AX needs to take if you want it to keep up with a moving product.
The pattern of failure is consistent enough that it deserves a name. We've called it the agent API gap before. AX is the design discipline that names what's missing from the gap-closing work. It's not enough to expose more endpoints. The endpoints have to be designed for agent consumption.
AX is the design problem. The operational question is who builds and maintains the tools that meet the AX bar — and at what cost.
Pontil is a Tools-as-a-Service platform. We sit in the tools layer of the agent stack and make SaaS products accessible to AI agents. Our connector generation works against the APIs and codebases that exist today, so AX-shaped tools don't require a multi-year API rewrite. The runtime executes as the authenticated user, which handles the per-user scoping that AX requires. And because the tools are generated and maintained against the source system, AX stays current as the product changes — no separate connector team holding the bar manually.
This is the part of AX that doesn't make it into design articles: the work is continuous. A great tool description today becomes a stale one in six months. A well-scoped auth flow drifts as the product adds new permissions. Designing for AX is a discipline. Holding the AX bar at portfolio scale is an engineering practice. We build the second so your team can focus on the first. If you want to see what that looks like in practice, the product page walks through the three components.
The companies that move first on AX are not going to be the ones writing think-pieces about it. They're going to be the ones whose agents work — and whose customers notice. The market signal is already visible: enterprise buyers are starting to ask, in security reviews and procurement conversations, whether a SaaS product is "agent-ready." That question is shorthand for AX, even when the asker doesn't have the vocabulary yet.
The deeper shift is organisational. Today, AX falls between teams. The API team owns the API. The AI team owns the agents. Nobody owns the experience the agent has of the product. That's the structural reason most agent projects stall — the design discipline that would fix the gap has no home. The companies that figure this out will name an AX owner, give them authority across API and AI, and treat the tools layer as a product surface in its own right.
Whether that owner sits in product, engineering, or platform doesn't matter much. What matters is that someone has the mandate to ask: when an agent meets our product, what experience does it have? And then to do something about the answer.
Stay up to date on the ever changing agentic landscape.
GET STARTED
Start with a 30-minute discovery call
contactus@pontil.com
