--- title: "AX vs UX: What Transfers — and What Breaks — When the User Is an AI" description: "UX principles transfer to AI agents as goals but break as techniques. How to re-derive each one from the agent's actual constraints." pubDate: 2026-07-20 arc: theory tldr: "UX principles transfer to AI agents at the level of goals — reduce load, make actions discoverable, fail informatively — but break at the level of techniques, which all quietly assume a human is looking. Designing AX means re-deriving each principle from the agent's constraints: context load instead of attention, confabulation instead of confusion, statelessness instead of memory. Keep the why; rewrite the how." machineSummary: claim: "UX transfers to agents as goals but breaks as techniques, because techniques encode assumptions about human perception" takeaway: "re-derive each UX principle from agent constraints (context load, confabulation, statelessness) before reusing it" evidenceType: argument crossLinks: [] # cross-links intentionally empty — add [computational-kindness, deterministic-ax-metrics] when those posts are live keywords: [agent experience, AX vs UX, designing for AI as user, AX design patterns, AI user experience, agent UX, API contract design] draft: false --- ## Why agent experience (AX) matters when the user is an AI The tempting move is to treat agent experience as user experience with a find-and-replace: swap "user" for "agent," ship the same principles, feel modern. The trouble is that it half-works — which is worse than not working, because the half that fails, fails silently, in production, inside someone else's context window. Agent experience (AX) — a term [Mathias Biilmann coined in early 2025](https://biilmann.blog/articles/introducing-ax/), thirty-odd years after Don Norman [gave us "user experience"](https://www.nngroup.com/articles/definition-user-experience/) — is the discipline of designing products, APIs, and interfaces for AI agents as users in their own right. Biilmann and the community that grew around [agentexperience.ax](https://agentexperience.ax) have mapped the supply side well: what platforms should provide, summarized in his four pillars of access, context, tools, and orchestration. This piece works the other end — the demand side. What does the agent actually experience when it meets your product, and which of your UX instincts will betray you there? The honest answer — the real AX vs UX ledger — is that your instincts about *goals* survive. Your instincts about *methods* mostly don't. Every UX technique quietly encodes assumptions about human perception — bounded attention, visual salience, patience, memory, a body. Agents violate those assumptions wholesale, and bring constraints of their own that UX never had to price in. Designing for AI as user starts with re-deriving each principle from the new constraints rather than porting the technique and hoping. Here is the distinction in miniature. An agent asks your API a yes-or-no question — is this resource available? — and receives forty kilobytes of nested JSON with the answer buried four levels deep in a field named for a schema migration that happened in 2023. For a human interface this is a pagination problem; annoying, survivable, someone will squint and scroll. For an agent it is cognitive degradation. Everything you send into a context window competes with the agent's actual reasoning; the model cannot skim, so your noise is processed with the same effort as your signal, at token prices, on every single call. Same design sin as a cluttered dashboard. Entirely different mechanism of harm. That difference — same goal, different mechanism — is the whole subject. ## Core overlaps: UX principles that still apply Four principles transfer cleanly, provided you re-derive the technique. **Cognitive load becomes context load.** The founding insight of usability — minimize what the user must hold in their head — survives intact; only the substrate changes. The agent's "head" is a context window, and load is measurable in tokens. Minimal, predictable, relevance-dense responses are to agents what clean visual hierarchy is to humans. **Discoverability becomes the schema.** Humans discover affordances through visual hierarchy; agents discover them through tool descriptions, schema-first interface definitions, and API contract design. A vague tool description is a mislabeled door. The agent will still open it — agents are nothing if not game — it will just open it wrong, confidently. **Feedback becomes actionable errors.** Good UX never says "something went wrong" without a path forward, and neither does good AX. `400 Bad Request` with an empty body forces the agent to guess; each guess burns a tool call and a slice of the operator's patience. An error that states what was wrong and what to send instead converts a failure loop into a one-step correction — and idempotent actions make retrying that correction safe rather than hazardous. **Consistency becomes contract stability.** Humans learn interfaces; agents pattern-match against everything they have ever seen. Follow conventions, version explicitly, and deviate only where the deviation is the product. ## Key divergences: assumptions that break when users are agents **Attention management breaks.** There is no above-the-fold. The agent reads everything you send and nothing you don't, so techniques built on salience — visual emphasis, progressive disclosure by layout — dissolve. Progressive disclosure survives only in structural form: summaries with hooks to request detail, not details hidden behind hover states. **Persuasion breaks, then backfires.** Urgency banners, social proof, delight micro-copy — emotion-first patterns don't convert agents; they confuse them, wasting context on content the agent cannot act on. Worse, persuasion aimed at agents has a name when it works: prompt injection. The manipulative end of the UX toolbox doesn't transfer to AX; it converts into an attack surface, and any AX taxonomy needs that adversarial chapter UX never wrote. **Human pacing breaks.** Agents arrive in bursts, parallelize, and never need the confirmation modal to slow down and think. Timing, throughput, and batching assumptions all need re-deriving — and state management moves from "the user remembers" to "the transcript remembers, until it doesn't." An agent may hold state within a session and lose it entirely between sessions; design contracts so that any single call carries enough context to be understood alone. **And one constraint UX never had: the user confabulates.** A confused human asks a question. A confused model fills the gap with something plausible — an imagined parameter, a remembered-wrong endpoint — and the agent acts on it. Ambiguity in human design costs comprehension; ambiguity in agent-facing design costs *truth*. This single property justifies most of AX's extra strictness. Is the agent a human-like user, then, or just another programmatic client? Neither, and the middle matters: it consumes like a machine (structured, high-throughput, transport-level boring) and interprets like a reader (semantics, naming, descriptions all carry meaning). REST semantics with human-quality prose in the descriptions. That hybrid is the design target, and it is why neither your API guidelines nor your design system alone will produce good AX. ## Design patterns and contracts for reliable agent interactions Three AX design patterns cover most of the distance. **Contract-first affordances:** every action an agent may take is explicitly described — inputs, outputs, side effects, preconditions — in the schema itself, treating the tool description as primary UI, not documentation. **Actionable errors with idempotent retries:** every failure names its cause and its fix; every mutation tolerates being sent twice, so uncertainty stops being dangerous. **Capability negotiation:** expose what is possible *for this caller, now* — entitlements, rate limits, feature flags — rather than letting the agent discover walls by walking into them. Each pattern is the old principle (discoverability, feedback, forgiveness) re-derived for the new user. ## Measuring success: metrics and experiments for AX Here is the quiet advantage of designing for agents: unlike human experience, agent experience is measurable to the token. Tokens consumed per completed task, tool calls per task, retry and error-recovery loops, time-to-first-successful-call against your API — these are deterministic KPIs, no survey required. The cheapest experiment in the field: hand an agent a real task against your product, count the calls it takes, read the transcript where it got confused. That transcript is a usability study that wrote itself. Measurement for AX deserves its own piece, and will get one. ## Checklist for converting a UX flow into an AX-ready flow Five imperatives, in order. Return the minimum relevant payload, structured predictably. Describe every action's contract where the agent will read it. Make every error name its fix, and every mutation safe to retry. Expose capabilities and limits before the agent finds them the hard way. Then run one agent through the flow end to end and read the transcript before believing any of your answers. Two failure modes from our own field notes, flatly stated. A task decomposed cleanly over an API until one step — account configuration — existed only in the web UI; the agent hit the wall mid-workflow and had to hand the task back to the human. Remediation: state machine-actionability in the contract, so the boundary is discoverable before it is load-bearing. And: an agent with delegated write access could not answer *which account am I operating as* — no identity introspection existed — so a cautious human declined the write. Remediation: any surface that grants agents write scopes should let them read their own identity first. Both failures were correct API behavior. Both were bad agent experience. That gap is this blog's entire beat. ## The takeaway The implication worth ending on: your product already has an agent experience. Agents are already arriving — over HTTP, wearing the [user-agent header that has named them since the nineties](https://datatracker.ietf.org/doc/html/rfc1945) — and encountering whatever un-designed experience your API happens to emit, with [llms.txt](https://llmstxt.org) and markdown mirrors still the exception. The only open question is whether anyone on your team has designed that experience on purpose. Finding out costs one afternoon: give an agent a task, and read what it does when it gets confused. Unlike your human users, it files its complaints mid-task, in writing.