What is AX? Agent Experience through hotel booking

Why do AI agents get stuck on hotel booking?

Suppose you are planning a trip to Tainan and want a double room for next weekend: two nights for no more than NT$8,000 in total, close to the railway station and well reviewed. In the past, you would open a booking platform, enter your dates, set a price filter, browse a few photos and check out by following the prompts. Now you hand the same instruction to an AI agent.

In the ideal case, the agent searches, compares prices, checks the stay conditions on its own and places the order once you authorize it. In practice, this automated chain is fragile. The site has rooms available, but the agent cannot find the booking entry because the button has no semantic label. After submitting the form, it cannot read the asynchronously loaded state change, assumes the submission failed and places the order again. Or it hits an unexpected re-login check at the payment redirect and has to abandon the task.

Failures like these can involve the capability of the large language model (LLM), the tool setup and the website design all at once. The same site can also give people and AI agents very different cues for acting. The WebArena study, published at ICLR in 2024, exposed the gap: across 812 multi-step tasks on simulated websites covering e-commerce, forums, code collaboration and content management, human users reached an end-to-end success rate of 78.24%, while the best-performing GPT-4 agent at the time managed only 14.41%.

These figures point to a structural gap between semantic understanding and the ability to operate an environment. As AI moves from search and conversation engines that supply knowledge to autonomous agents that handle shopping, travel, finance and system administration for people, the design question for digital products changes too: when users no longer click the screen themselves, how do you build an environment where an AI agent can also perceive accurately, obtain authorization, execute reliably and finish safely? This is the background from which Agent Experience (AX) emerged.

UX, DX and AX: who is using the website?

To see why AX is surfacing now, place it in the decades-long evolution of digital product experience. In the early software and website era, product design centered on User Experience (UX): how human senses and cognition interact with a graphical user interface (GUI), with attention to visual flow, information architecture and intuitive operation. As software became platform-based and cloud-based, companies began offering services through APIs, SDKs and command-line tools, and Developer Experience (DX) emerged. The user is now a human engineer, and a product is good or bad depending on whether the documentation is clear, the interface specification consistent and the error messages easy to debug, so that engineers can write deterministic code to connect systems.

In the era of generative AI and agents, a third kind of user appeared. In January 2025, Netlify CEO Mathias Biilmann formally extended the boundary of experience design to Agent Experience (AX) in the article “Introducing AX: Why Agent Experience Matters”. Unlike a person operating an interface directly (UX) or an engineer writing integration logic in advance (DX), an AI agent is a probabilistic system that perceives its environment at runtime, plans steps on its own and calls tools. Once a person delegates a task to AI, whether the agent can obtain authorization on the user’s behalf, read the platform’s rules and complete the operation directly affects how widely the digital service is adopted in the AI ecosystem.

In October 2026, Waldek Mastykarz, Principal Developer Advocate at Microsoft, took AX further toward measurable engineering checks in “What is Agent Experience (AX)?”. He proposed two core dimensions: Propensity, whether an agent can discover and tends to choose your service when the user has not named a tool; and Efficacy, whether, once the agent has chosen your service, it can call the right, non-deprecated interface and finish the task within a reasonable compute cost and number of steps.

Why does a UX polished for people so often lead to low Efficacy once an agent takes over? The answer lies in the underlying theory of perceptual psychology and design. In 1979, psychologist James J. Gibson introduced Affordance in The Ecological Approach to Visual Perception, meaning the possibilities for action that an environment offers a particular actor. A knee-high chair affords sitting to an adult, but to a kitten it affords hiding or climbing. Affordance is a relationship between the actor’s abilities and the features of the environment, not an objective property of the object alone.

In 1988, cognitive scientist Don Norman brought the concept into design. In “Signifiers, Not Affordances” (2008) and the 2013 revised edition of The Design of Everyday Things, he drew a key distinction: an affordance determines which actions are physically or systemically possible; a signifier is a cue the environment gives the actor to show how to operate it and what state it is in. A door affords being pushed open, but if it has a handle that makes people want to pull, the wrong signifier makes the operation fail. This is the classic “Norman door”.

Today’s internet is full of Norman doors for AI agents. People rely on color contrast, border shadows, a pointer that turns into a hand on hover, or the crowd gathering on a platform to judge where they can click and what state the system is in. Once the actor changes from a person to an AI agent, the sensory organs and execution tools change completely, and signifiers tailored to human vision and cognition stop working. When an agent lacks browser permissions or API authorization, even the most basic affordance (the possibility of action) does not exist. The core task of AX is to realign a digital environment’s affordances and signifiers once the actor is an AI.

Interface cues from a human viewpoint (UX signifiers)

<!-- Gradient and shadow look clickable, but there is no semantics or state feedback -->
<div class="btn-gradient shadow-lg" onclick="submitOrder()">
  Book now →
</div>
<div class="toast-fade">Processing, please wait...</div>

• Action cues: Color gradients, shadows and pointer changes suggest “clickable”.
• State awareness: Progress is judged from a toast pop-up that appears for about 2 seconds or a spinner animation.
• Permission checks: A CAPTCHA or SMS OTP window pops up midway through checkout.

Intuitive for people, but a “digital Norman door” for AI

Interface cues from an agent viewpoint (AX signifiers)

// Structured semantics, explicit parameter boundaries and a verifiable status code
reserve_room({
  hotel_id: "tainan_sta_01",
  check_in: "2026-11-14",
  idempotency_key: "req_9f8a7b"
}) → { status: "PENDING_USER_CONFIRM", order_id: "ORD-8821" }

• Action cues: Explicit role="button" accessibility semantics, or a structured tool schema.
• State awareness: Returns a machine-readable status and order_id, plus a separate query endpoint.
• Permission checks: Supports tiered authorization and handoff, returning control to a person for confirmation before a charge.

Aligned with what an AI can perceive and execute, creating a verifiable loop

Three ways AI operates a website

An AI agent can read the structure of a web page, recognize a screen, or call tools directly. The three approaches can be combined, and each requires different operating cues from a website.

The first is DOM and accessibility tree parsing, which borrows from accessibility design for people. Behind every web page is a DOM that defines its structural hierarchy. Following the W3C Accessible Name and Description Computation specification, the browser translates HTML semantics and ARIA attributes into an accessibility tree for screen readers. Early browser agents such as those in WebArena turn a page into structured text nodes like [1582] button "Add to Cart" to decide what to operate. This route is cheap to compute and precise, but it depends heavily on front-end semantic discipline. If a site builds a visual button from an image with no alternative text or from a bare <div>, an agent relying on the accessibility tree is simply “blind”.

The second is visual operation (Computer Use / GUI agents), which imitates human senses. Since web pages were drawn for people in the first place, Anthropic’s Claude Computer Use (2024) and OpenAI’s Operator and Computer-Using Agent (CUA) (2025) capture the screen directly, let a multimodal model recognize colors, icons and layout positions visually, and then drive a virtual mouse and keyboard. The WebVoyager study (2024) showed that an agent combining visual screenshots reached a 59.1% success rate in its test environment, better than a text-only structured setup. OpenAI reported in March 2025 a CUA WebArena success rate of 58.1%. The models and execution settings differ from those of the early GPT-4 agent, so the gap cannot be attributed entirely to visual operation. Still, coordinate-click drift, interference from dynamic pop-ups, and the high token latency and misjudgments over long flows keep a purely visual route from carrying high-risk commercial transactions.

The third is native tool protocols built for agents (API, MCP and WebMCP). Rather than make an agent guess where buttons are on a human interface, expose structured entry points to it directly (such as create_booking(hotel_id, check_in, check_out, guests)). The path runs from early function calling, through the Model Context Protocol (MCP) that Anthropic open-sourced in November 2024, to the WebMCP draft specification advanced by a W3C community group in 2026 (W3C Draft Community Group Report, not yet a W3C standard, which lets a web page register front-end JavaScript functions as tools an agent can call). Digital products are moving from a single visual interface to a dual-track interface for people and machines.

Table 1: Three operating approaches and common causes of failure

Operating approach	Core signifier the agent relies on	Representative technology and standards	Core bottleneck and failure risk
Structure parsing (DOM / accessibility tree)	Component role, accessible name, DOM hierarchy and state attributes	W3C ARIA specification, WebArena infrastructure	Missing semantic labels on the front end; unclear names on dynamically rendered elements cause misses
Visual simulation (Computer Use)	Button text, icon appearance, relative spatial position and visual changes on screen	Claude Computer Use, OpenAI CUA, WebVoyager	Coordinate drift, pop-up occlusion, confusion over asynchronously loaded state, high latency cost
Native tool calling (API / MCP)	Tool name, semantic function description, JSON Schema parameters and return structure	Function Calling, Anthropic MCP, W3C WebMCP community group draft	Ambiguous tool descriptions, broken cross-system authorization, incomplete backend state returns

Many companies hold an expectation: “Once future models get stronger, or once every interface is converted to a machine format, the AX problem will disappear on its own.” Empirical research and engineering tests point the other way.

First, a model succeeding once does not mean it is commercially reliable. The 2024 τ-bench study (an arXiv preprint), which simulates retail and customer-service interactions, introduced the passk metric, the probability that the same task succeeds on all k consecutive runs. It found that although the leading models of the time reached a single-run success rate (pass1) of nearly 50% on retail tasks, pass8, success on all 8 consecutive runs, fell below 25%. In a commercial setting involving payments and orders, that instability is enough to cause serious complaints and accounting losses.

The AX tests Microsoft shared in 2026 also show that a change that looks agent-friendly is not necessarily useful. In that CLI deployment test, after switching to JSON input, each model’s per-task cost became 4 to 11 times the original, and Claude Haiku 4.5 went from all 5 runs succeeding to only 2. In another SharePoint Framework upgrade test, explicitly telling the agent to use the CLI raised the passing configuration checks from 30/80 to 75/80. The team then edited the release notes the agent reads and observed that it used the CLI proactively on every run. These are results of different interventions and apply only to the tasks and settings tested in the article.

Booking one room: four things to confirm

Look at AX from the viewpoint of end-to-end task execution rather than just “reading the interface”, and you find that “locating the button or calling the API” is only the starting point. Don Norman used a train platform to illustrate the importance of state signifiers: when you rush onto a platform and see no train, you infer whether the train has not yet arrived or has already left from whether a large crowd of waiting passengers is still there. Likewise, when an agent submits a booking request and the system returns only a vague “processing complete”, or flashes a toast on the screen, the agent cannot confirm that the order was actually written to the database. A mature AX therefore needs to cover the full lifecycle from perception to state verification and error recovery.

Combining Gibson’s affordance theory, Norman’s signifier concept and current empirical research on agents, the working definition this site uses in practical reviews is: Agent Experience (AX) is the degree to which, when an AI agent performs a task on behalf of a person, a digital product environment lets it identify available functions, act within the authorization boundary, verify the real system state, and recover safely or hand over to a person when something goes wrong, in a closed loop. This article breaks the “AX task loop” into four core conditions and maps them directly to a company’s product safeguards and quantitative metrics. The four-stage loop is an operational review framework compiled by this site; LS-Labs has not yet published controlled-experiment data on AX task completion rates.

Table 2: The four-stage AX task loop, practical safeguard design and metrics for companies to observe

Loop stage	Theoretical and technical basis	Practical design (booking platform example)	Metrics for companies to observe and evaluate
1. Discoverable	Signifier, semantic clarity, Propensity (this layer connects directly to TSO tool selection optimization)	Define tool boundaries clearly; avoid a vague execute() and use search and booking interfaces that state their parameters and preconditions	Capability recognition rate, correct tool selection rate, unproductive exploration steps
2. Executable	Affordance, least-privilege authorization, human-agent collaboration	Support tiered authorization: let the agent check prices and hold rooms on its own, but trigger human confirmation for actual charges and non-refundable terms	Post-authorization operation success rate, permission blockage rate, token cost per task
3. Verifiable	State signifier (state feedback), outcome-oriented verification	Return a structured status code, order number and processing stage (distinguishing “submitted” from “confirmed”), and provide an independent status-query entry point for a second check	Result verification accuracy, state misjudgment rate (false positive / negative)
4. Recoverable	Fault tolerance, idempotency, safe stop	After a network interruption or timeout, support safe retries carrying an idempotency key, or return a parsable error cause and remediation advice so the task can be handed back to a person	Error recovery rate, duplicate-order rate, safe-stop rate for high-risk anomalies

For a company, this four-stage loop converts directly into an engineering team’s baseline and Lift/Drag test process. Companies do not need to guess which design is friendlier to AI; they can build a controlled empirical loop in four steps:

Through this controlled-variable loop, product and engineering teams can distinguish which failures come from the limits of the underlying model and which come from the wall a product builds for itself by lacking clear signifiers and state returns.

How GEO, TSO and AX divide the work

When AI agents step into consumers’ information gathering and purchase decisions, the strategic question companies ask most is: “Will AX become the next SEO or GEO?” To answer it, split the user journey into a full funnel from information discovery to tool use and task completion, and clarify who is responsible at each stage.

GEO (Generative Engine Optimization), which has drawn much attention in recent years, fights mainly in the upper funnel (Discovery & Citation). When a user asks an AI “Which double room near Tainan railway station do you recommend for next weekend?”, the question is how a brand uses structured data, content authority and external citation sources to get the language model to include it in the recommendation list when generating the answer. This corresponds to the front-end Propensity in Microsoft’s framework. When the user then says “OK, check whether the first one has a room tonight and book it,” the flow first passes through TSO (Tool Selection Optimization), which decides which booking tool or API is chosen. It then enters the lower funnel (Execution & Transaction), where AX (Agent Experience) takes over and handles Efficacy, from authorization, execution and verification to error recovery.

In other words, GEO, TSO and AX together form the commercial conversion funnel of the AI era. A brand with GEO but no AX becomes a dead end that AI often recommends but cannot help check out. A product with AX but no GEO or TSO is like a shop with a smooth layout hidden down a back alley, with no chance even of entering an agent’s candidate list.

That said, embracing AX does not mean a company should open the door to AI without reservation, nor sacrifice people for machines. In 2025, developer Jim Nielsen raised a reflection in “AX, DX, UX”: when company resources are limited, does over-catering to AI agents degrade the experience for human users? In fact, a healthy product architecture does not have to treat UX and AX as a zero-sum game. Clear component semantics, explicit state feedback and structured error messages are themselves the foundation of good UX and accessibility, and they benefit assistive tools for visually impaired users, ordinary people and AI agents alike.

What truly needs deliberate separation and defenses is commercial interests and security boundaries. Opening an efficient operating channel to external agents brings account hijacking, automated abuse and new kinds of security threats. For example, the 2026 W3C WebMCP community group draft explicitly lists prompt injection, tool description poisoning (tool poisoning) and misjudgment of high-risk operation intent as core security risks (see also this site’s discussions in “Has JPMorgan started blocking AI agents?” and “Is your website ready for AI agents to place orders?”). An agent contaminated by a malicious page’s prompt could call an authorized platform’s transfer or ordering function without the user’s knowledge.

Mature AX design therefore never pursues “100% frictionless full automation”. It builds explicit governance defenses into the “executable” and “recoverable” stages: OAuth authorization with finely scoped operations, mandatory human confirmation (human-in-the-loop) for transaction amounts and sensitive operations, and rate limiting and idempotency protection to stop agents from retrying out of control.

From the chair in Gibson’s 1979 account that differs by actor, to the AI agents of 2026 moving among the DOM, visual screens and the MCP protocol, the underlying logic of interface design has always been about matching actor and environment. In the UX era, product teams asked whether a product is intuitive and easy for people to use. In an era when AI acts as people’s digital agent, AX puts a more practical business question to every product owner: when your customers hand the task to AI, can your product let it finish the job safely and reliably?

References

Design theory and academic research

• Gibson, J. J. (1979). The Ecological Approach to Visual Perception. Houghton Mifflin.
• Norman, D. A. (2008). Signifiers, Not Affordances. Interactions, 15(6), 18–19. doi:10.1145/1409040.1409044
• Norman, D. A. (2013). The Design of Everyday Things: Revised and Expanded Edition. Basic Books.
• Deng, X., Gu, Y., Zheng, B., Chen, S., Stevens, S., Wang, B., Sun, H., & Su, Y. (2023). Mind2Web: Towards a Generalist Agent for the Web. NeurIPS 2023. arXiv:2306.06070
• Zhou, S., Xu, F. F., Zhu, H., Zhou, X., Lo, R., Sridhar, A., Cheng, X., Ou, T., Bisk, Y., Fried, D., Alon, U., & Neubig, G. (2024). WebArena: A Realistic Web Environment for Building Autonomous Agents. ICLR 2024. arXiv:2307.13854
• He, H., Yao, W., Ma, K., Yu, W., Dai, Y., Zhang, H., Lan, Z., & Yu, D. (2024). WebVoyager: Building an End-to-End Web Agent with Large Multimodal Models. ACL 2024. arXiv:2401.13919
• Xie, T., et al. (2024). OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments. NeurIPS 2024. arXiv:2404.07972
• Yao, S., Shinn, N., Razavi, P., & Narasimhan, K. (2024). τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains. arXiv preprint. arXiv:2406.12045

Official technical specifications and industry commentary

• W3C (2018). Accessible Name and Description Computation 1.1. w3.org
• Anthropic (2024, November 25). Introducing the Model Context Protocol. anthropic.com
• Biilmann, M. (2025, January 28). Introducing AX: Why Agent Experience Matters. biilmann.blog
• Nielsen, J. (2025, March 2). AX, DX, UX. blog.jim-nielsen.com
• OpenAI (2025, March 11). New tools for building agents (Computer-Using Agent). openai.com
• Mastykarz, W. (2026, October 6). What is Agent Experience (AX)? Microsoft for Developers. developer.microsoft.com
• W3C Web Machine Learning Community Group (2026, November 2). WebMCP — Draft Community Group Report (W3C community group draft). webmachinelearning.github.io