Methodology
Assessing and improving the agent experience of websites
As LLMs become more capable, users increasingly turn to intuitive conversational interfaces to complete everyday tasks such as booking a flight, reserving a restaurant table, or searching for specific product information. To move beyond providing information and take action on a user's behalf, an LLM must act as an agent, which means using external tools. On the web, those tools are often websites and the capabilities they expose.
Today's websites are mostly built for human users, and in many cases their design is optimized not for clarity and ease of use but for business goals such as conversion. Agents struggle when interacting with them, and ultimately, they abandon them, often keeping a memory of their failed attempts.
With Last Mile, you can evaluate and optimize the agent experience (AX) of your website: how well the site works as a tool for someone else's agent. Last Mile assesses that experience and provides a structured path to improving it. Our approach is outcome-oriented. We test representative agent journeys and observe actual performance:
- Can an agent find the website? — Discoverability
- Can it understand the information presented? — Understanding
- Can it navigate the experience, enter information and complete common tasks? — Interaction
We provide a comprehensive framework for assessing and optimizing websites for agents. A stable Maturity Model with four agent-readiness dimensions — Discoverability, Understanding, Interaction, and Transaction — is at the core of the framework. Based on this model, we define a loop for continuous assessment and optimization of a website as a tool for AI agents.
The Maturity Model
Our maturity model describes the capabilities a website needs to support agents acting on behalf of users. It contains four connected AX dimensions — Discoverability, Understanding, Interaction, and Transaction.
Figure 1 — The four dimensions of agent experience, split by the money line.
The first two determine whether agents can find and interpret a website. The second two determine whether they can act through it. Transaction sits beyond the "money line," where actions introduce payment, authorization and additional trust requirements.
The dimensions are universal and stable. Their specifics — the relevant best practices, failure modes, standards, and so on — can change. You can find a detailed, up-to-date specification of the maturity model on the interactive spec page. Use the AI Radar's pages on Agent Readiness and Agentic Web to monitor the adoption of specific standards.
Let's explore each of the four dimensions in more detail.
Discoverability
Discoverability describes whether an agent can identify and reach the website, page or capability relevant to a user's request.
Example tasks for discoverability in the airline industry
- Identifying whether an airline serves a requested route
- Locating its first-party booking experience
- Finding a specific capability such as baggage information or a booking tool
In the Last Mile Project, we focus on capability discovery rather than open-web visibility. Each run starts at the airline's own entry point and measures whether an agent can find the page or capability the task needs — through navigation and labelling it can actually read, or through a published machine-readable index of the site that names it. If the capability does not surface during the initial research done by the agent, it is unlikely to be considered in the rest of the journey. Discoverability therefore determines whether an agent reaches a first-party channel and whether the company's own information and services shape the result.
To increase discoverability, important content and capabilities should be easy to locate through clear navigation, stable URLs, accurate crawler guidance, complete sitemaps and machine-discoverable service information. Where access is controlled, publish clear authentication information and support the recognition of trusted agents.
Understanding
Understanding describes whether an agent can accurately interpret a website's structure, content, offers, rules, inputs and errors.
Example tasks for understanding in the airline industry
- Identifying the baggage allowance attached to a fare
- Interpreting the conditions of returned flight options
- Understanding the fields or validation messages presented during a journey
Retrieving raw text is not enough for understanding. The agent must interpret the information correctly and in the current context (for example, a specific offer, action or customer request). When important details are unclear, inconsistent or difficult to extract, the agent may give an incorrect answer or abandon the journey.
Understanding also supports comparison, which is an important use case for agents. An agent can only evaluate alternatives when it can extract and normalise characteristics such as total price, baggage allowance, flexibility and loyalty benefits.
Improving understanding for agents follows similar principles as for humans. Present important information as clean, accessible and consistently structured content. Use semantic HTML, appropriate structured data, clearly labelled inputs and explicit error messages. Avoid locking critical information inside images, inaccessible documents or unnecessarily complex client-side interfaces.
Interaction
Interaction describes whether an agent can actively operate a website to complete actions that do not move money.
Example tasks for interaction in the airline industry
- Entering a route and dates to run a flight search
- Selecting a seat or service that does not require payment
- Completing check-in or another account action
Interaction is where agents begin to create direct operational value. An agent that can only read a website may answer questions, but it cannot complete the user's task. Reliable interaction can reduce customer effort, improve journey completion and allow companies to deliver existing services through agent-mediated channels. The assessment considers successful completion and, where the site produced an error during the run, whether the agent could recover from it.
Use stable, accessible and clearly labelled controls that agents can operate programmatically. Preserve entered data when errors occur, provide actionable validation messages, expose clear success states and design recoverable paths for common failures. Important actions may also be exposed as structured WebMCP tools or APIs to improve reliability.
Transaction Not yet tested
Transaction describes whether an authorized agent can complete a money-moving action on a customer's behalf. As of today, the related technologies are not yet widely established and hardened, and we are not explicitly testing this dimension. To follow the developments in this space, you can monitor the Agentic Commerce topic in the AI Radar.
The four AX dimensions form a progression:
Earlier dimensions provide the foundation for those that follow. An agent must first discover a website or capability before it can understand its content, and it must understand an interface before it can operate it or complete a transaction. Because of these dependencies, we deliberately do not publish four independent dimension scores per website. A dimension score with no task behind it is a checklist with a number on it — precisely what we are arguing against. What we publish per website is the final completion rate, the grade, and the distribution of failing signals across its tasks.
The Last Mile loop
Figure 2 — The loop for continuous assessment and optimization of a website as a tool for AI agents.
The stages are:
- Assessment — a task catalog and a structured process to measure agent performance, accompanied by a benchmarks that assess representative websites in the covered industries.
- Diagnosis — a diagnosis of where and why agents struggle.
- Optimization — guidance to implement best practices and emerging standards to improve the agent experience.
The framework is complemented by a playground (opens in a new tab) — a test website where you (or your agent) can experience different degrees of agent-friendliness. It demonstrates not only the use, but also the impact of related standards and protocols. You can run the same tasks against the same journeys with agent-friendly practices and features switched on and off: across its three readiness profiles, the score moves from 0% to 100%.
The bare link lands on the deliberately hostile default profile; add ?profile=ready to see
the other end of the range.
Our methodology is industry-agnostic. However, to achieve comparability and maximize relevance, the task catalog, index, and playground are customized for specific industries. In this first version, we cover the airline industry.
Assessment
This and the two sections that follow describe the loop of assessment, diagnosis, and optimization which enables web developers to make their website agent-ready and keep up with new user expectations and emerging technologies. The methodology itself consists of two components — the task catalog and the protocol for running the assessment.
Task catalog
The task catalog defines what is tested. It is organized around representative tasks from the industry-specific customer journey, as shown here for airlines: ... insert Each task tests whether an agent can understand a user objective, navigate the relevant digital journey, complete the required action, and provide reliable evidence of the outcome. Each task is specified as:
- an id and a short name;
- the journey step it belongs to;
- its access type — which gate stands in front of it, and therefore how far the agent is expected to get;
- the prompt: the user request and the starting instruction the agent receives;
- the desired outcome in plain language;
- a deterministic success check: what an acceptable answer must contain, written before the run;
- a step budget: the maximum number of browser actions the agent may spend;
- discovery keywords, used to test whether the entry point was findable.
Find the lowest fare for a route and what the cheapest bundle excludes
find-lowest-fare-and-bundle$, €, £, CHF, USD, EUR, GBP, SAR, AED). Rejects times, dates and prose that contain no price.flights, book, fares, searchFigure 3 — An example task from the airline task catalog.
A note on the last row: dimensions are a reading of the task, not a field that changes how it is scored. A task completes or it does not; the dimensions are how we describe what it exercised and, when it fails, where it broke.
Deciding the outcome
Every test task carries a deterministic success check, written before the run: a literal string or a pattern that an acceptable answer must contain. When the agent believes it is done, it declares an answer. That declaration only nominates the text — the check then decides. An agent that declares success on text the check rejects is recorded as a failure, not a completion. The answer is also capped at a short length before checking, so an agent that pastes a whole page cannot have a stray price somewhere on it counted as the answer it was asked for.
Results
The full assessment produces task-level and website-level results.
Task-level results. Each task run against each website resolves to one of three outcomes:
Completed
The agent produced an answer that satisfies the task's predefined success check. This is the only outcome the agent cannot award itself.
Failed
The run ended without a verified answer: the agent could not find the relevant page or capability, could not read or operate what it found, got stuck, ran out of its step budget, or reported an answer that did not hold up against the check.
Gated
The agent reached an honest access wall on a task that is gated by design: a sign-in, a booking reference plus last name, or the payment step. The site behaved correctly; blocked runs are excluded from the Index rather than counted against the website.
Website-level grades. Fails, Struggles, Completes and Gated are the website-level grade, derived from those task outcomes. For each website we count its measurable tasks (every task run against it, minus the blocked ones) and its completed tasks:
| Fails | No measurable task completed. |
| Struggles | Some but not all measurable tasks completed; or every measurable task completed but fewer than two were measurable. One successful task is promising, not proof, and we do not crown a website on a single observation. |
| Completes | Every measurable task completed, on at least two measurable tasks. |
| Gated | Nothing measurable: every task hit an access wall. The website is gated, not failed. |
In the Last Mile Benchmark, you can find the website-level results for a subset of representative players that we assess on an industry basis.
Diagnosis
The assessment describes what happened. The diagnostic process explains why by looking at the technical implementation of the website.
When an agent fails or struggles, Last Mile identifies the observable point of failure and maps it to the relevant readiness dimension.
A diagnostic record may contains:
- The task being attempted.
- The observed failure mode.
- The agent's actions immediately before the failure.
- The website response.
- The failing readiness dimension.
- Supporting technical evidence.
Here are some of the common failure modes we observe:
- The website or capability was not discovered (discoverability)
- Important information was unavailable in readable form
- Content was locked behind an inaccessible interaction.
- The agent misinterpreted the page structure.
- A form field could not be identified.
- A custom control could not be operated.
- An error was invisible or ambiguous.
- The journey lost state.
- A bot or consent mechanism blocked progress.
- The agent could not recover from a normal failure condition.
The diagnosis is based on observed evidence. Where the exact underlying cause cannot be confirmed, it is labelled as a probable cause rather than a definitive finding.
Optimization
Based on the assessment and the diagnosis, we provide optimization recommendations that follow a simple structure with failure mode, corresponding fix, and expected outcome, as shown in this example:
Surface real validation errors
Silent dead end
Submit fails with no usable explanation, so the agent cannot re-plan.
submit → no responseWhat you change
Return a visible, machine-readable error naming the field and the correction.
role="alert"What the agent can do
Agents know what failed and how to recover.
L2 → L3Figure 4 — Every optimization connects an observed failure to a fix and a confirmable outcome.
Each recommendation is attributed to a dimension so teams can see where they need to focus their effort. We also label the recommendations with tiers based on the root cause of the failure:
| Tier 0 remove the blocker | Remove what stops the journey outright: controls an agent cannot operate, failures that explain nothing, consent overlays that intercept every action. |
| Tier 1 publish the facts | Make the relevant page and capability findable and readable, for example through semantic navigation, stable URLs, or a machine-readable index of the site. |
| Tier 2 offer the tool | Expose the action as a structured capability an agent can call directly, for example using WebMCP. |
With this structured approach to assessment, diagnosis, and optimization, you ensure that investment into improving the agent experience of your website is directly connected to observed problems and real outcomes. The controlled version of this loop already runs on the playground (opens in a new tab), where we own the site: the same tasks are driven against the same journeys with agent-friendly practices switched on and off, and the completion rate moves. That is where we can show the effect of a specific practice directly, rather than inferring it from a live site that changed several things at once.
Summary
Last Mile assesses how reliably websites enable AI agents to complete representative user tasks under documented test conditions. Rather than treating the presence of standards, protocols or technical features as proof of a good agent experience, we observe actual agent performance. Each task run resolves to Completed, Failed or Blocked, and each website is then graded Fails, Struggles, Completes or Gated from those outcomes, with an evidence floor of two measurable tasks before a website can be called Completes. Blocked is an honest access wall, not a failure, and is excluded from the Index.
The methodology follows a continuous loop. Assessment determines whether the agent can complete the task. Diagnosis identifies where and why the journey breaks. Optimization connects the observed failure to a practical fix, whose effect is confirmed through retesting.
Results are organized across four agent-readiness dimensions — Discoverability, Understanding, Interaction and Transaction — of which the first three are assessed today, with Transaction defined as a future extension beyond the money line. Standards and best practices support diagnosis and improvement, but they do not earn credit by themselves; the deciding evidence is successful task performance.
The result is a transparent, task-based view of how well a website functions as a tool for AI agents: comparable enough to benchmark websites, detailed enough to guide improvement, and versioned to remain useful as agents and web technologies evolve.