Everyone's building the rails for AI shopping. No one checks if the train arrives.

We sent two rival frontier AI agents to book a stay on a real European booking site. Six out of six attempts stopped at the same step. Then we did the part that actually matters: we proved it was the site, not the agents.

Some technical problems announce themselves loudly. The quieter ones tend to be more expensive.

Last week we pointed two of the most capable AI models in the world — OpenAI's GPT‑5.2 and Anthropic's Claude Opus 4.8 — at a real, live German vacation‑rental booking site. Not a sandbox, not a staged demo. The actual site, approached the way a real customer's AI assistant would approach it. We asked each model to do something a person does without thinking about it: pick arrival and departure dates and begin a booking.

Six runs, three per model. Every one of them stopped at the same place — the date selection. No crash. No error message. The server returned a calm, untroubled HTTP 200 every single time. From the site's side, nothing happened: no failed transaction, no abandoned cart, not a line in a log to investigate. The agent simply could not complete the one gesture that starts every booking, and eventually it gave up and moved on — the way a customer would.

That is the whole problem in miniature. The site never knew it had just lost a sale. It had no way to know.

We checked whether our agents were simply the problem

A single failed run proves very little. Agents are non‑deterministic, and any one model has its own blind spots. So before drawing a conclusion, we did the step almost nobody does: we checked whether our agents were simply not good enough. We ran the same two models against a comparable control — the same kind of task, one a capable agent should complete without trouble. They did, cleanly, every time. Same agents, same class of task, opposite outcome. The failure was in the site, not the bot.

Separating "your site is the problem" from "the agent isn't good enough" is the entire game. It is also the step the market is mostly skipping.

Everyone's building the rails

The timing is hard to miss. On June 12, Fortune ran the headline "AI shopping agents are coming. No one is ready for them." Three days earlier, Checkout.com's 2026 research reported that 72% of merchants believe consumers will adopt agent‑led shopping faster than merchants can prepare — while just 3% of transactions today involve an agent at all. A very small base, a very steep slope, and a readiness gap merchants themselves admit. Meanwhile Visa wired its network into OpenAI's models, and Mastercard launched "Agent Pay for Machines" with some thirty partners — Stripe, Adyen, and Checkout.com among them. The rails for agent commerce are being laid, quickly and seriously.

Rails are good. But a rail only matters if the train arrives.

We have already watched the first real attempt at agent checkout stumble in public. OpenAI retired its Instant Checkout in March. The main reason was unglamorous: conversion. People researched inside the chatbot and then completed the purchase on the retailer's own site, where Walmart measured roughly three times the conversion. The execution side was rough, too — onboarding merchants was, in OpenAI's own words, an arduous process, and only about a dozen Shopify merchants ever integrated. The discovery layer worked. The transaction layer did not.

That split — discovery works, completion doesn't — is not unique to OpenAI. In April, an academic benchmark called ClawBench ran frontier agents through everyday tasks on real websites and measured completion rates between 6.5% and 33.3%, against the 65–75% those same models score on the tidy sandboxes the industry usually quotes. The single most common failure was filling in forms correctly. Our booking agent stopping at a date field is not an unlucky exception. It is the rule, arriving on schedule.

So the binding constraint on agent commerce is not the payment token. It is whether an agent can finish on your particular site — which is a property of your site, not of the announcement.

A score is a prediction. A receipt is proof.

A small industry of "agent‑readiness" tools has appeared to answer exactly this, and most of them score signals: do you publish an llms.txt, expose an MCP endpoint, ship clean structured data, keep a sensible bot policy. That work is useful, and we're glad it exists. But it answers a different question than the one that pays the bills. A checklist asks whether your site emits the signals an agent could use. It does not ask whether a real agent actually finishes. Those are not the same question — and a site can score full marks on the first while quietly failing the second, stranding a paying customer's agent at a date‑picker with a 200 in the logs and nothing to investigate.

Readiness by declaration is not the same as readiness by proof. A score is a prediction. We wanted a receipt.

Producing one that holds up takes more than running an agent once and writing down what you saw. Most of the work goes into trying to prove ourselves wrong before we'll believe a failure: ruling out coincidence, ruling out an agent that was simply having a bad day, and never trusting a single run. Only a stall that survives all of that — reproducible, and not explained by the agents themselves — earns the word "finding." The rigor is the product; pointing an agent at a website is the easy part.

The output is not an opinion or a number out of a hundred. It is a documented, reproducible record — the flow, the runs, the exact step, and the evidence that the fault is the site's. We're open about how we reach it, and we name no one. The site in this story stays anonymous; that is deliberate, and for European readers it should read as what it is — responsible disclosure, not a callout.

A demo shows that an agent can do something. Production shows whether the site lets it. Between those two there is a surprisingly wide valley, and a number of "agent‑ready" sites are about to find they're standing in it.

The fix is already arriving

None of this is a reason for gloom. An agent struggles with a custom date widget because it is reading pixels and guessing — interpreting a picture of a control instead of being told how the control works.

The emerging fix is to stop making it guess. WebMCP, now in origin trials in Chrome 149, lets a site describe its forms to an agent directly instead of leaving it to screen‑read; one early implementer reported roughly 90% less token usage and far steadier runs. That is the shape of the opportunity. We find the silent failure; standards like WebMCP are how it gets closed. The sites that wire this up first will be the ones an agent can actually buy from — while their competitors keep scoring well on a checklist and losing the sale they never saw.

DACH and the wider EU tend to run a step behind the US on deployment, and for once that lag is worth something. It buys time — time to get completion right before the volume arrives, in a market that has usually preferred evidence to enthusiasm.

Because the agents are coming to your checkout whether it's ready or not. The useful question isn't "what's our readiness score." It's smaller, and harder: when an agent tries to buy from us, does it finish? The honest way to answer that isn't to estimate it. It's to watch one try.

Readiness isn't a score. It's a receipt.