← Blog

The buyer who clicks Buy is a browser agent now — checkout was not built for it

Prefero

Between October 2024 and August 2025, four major AI labs shipped a browser agent that can complete a purchase — Anthropic's computer use, OpenAI's Operator, Amazon's Nova Act, and Perplexity's Comet. The Buy button was built for a human finger; each of those systems has already tried to press it.

AI readiness, as most stores practice it, ends at the recommendation: structured data on the product page, crawlers allowed in, policies stated as facts — enough for an agent to find you and pick you. But the agent's job does not end there. Browser agents act: they add to cart, fill address forms, click Buy, and report an order number back to the shopper. That final stretch — the checkout flow — is the part almost no store has built for a machine consumer. CAPTCHA walls, JS-only carts, payment iframes, and ambiguous CTAs each stop the agent after it has already decided to buy from you. The shopper who delegated the purchase never sees the failure; they only notice that the order never arrives.

The three acts of an AI purchase: acts 1 and 2 already work today, act 3 is where the purchase dies
The three acts of an AI purchase: acts 1 and 2 already work today, act 3 is where the purchase dies

The buyer who does not use a mouse

The agents are not hypothetical. Anthropic shipped computer use in October 2024 — a Claude model trained to move a cursor, type, and click. OpenAI followed with Operator in January 2025, a research preview that browses the web and performs tasks on the user's behalf — booking tables, ordering groceries, buying tickets — while asking the user to take over for logins, payment details, and CAPTCHAs. Amazon launched Nova Act in March 2025, an SDK for building browser agents, with retail tasks as the headline use case. Perplexity shipped Comet in August 2025, a free early-access agent built to plan, browse, and execute tasks end to end — checkout included.

That is four consumer-grade agents in ten months, and the list keeps growing: Google demoed its Project Mariner prototype in late 2024 and has since pushed Gemini agent mode into Chrome. None of these systems is a crawler. A crawler reads pages and leaves. These agents read pages, fill forms, submit them, and read the confirmation page that follows.

Research benchmarks document how uneven that path is. WebArena, the 2024 benchmark for agent tasks on realistic websites, included a shopping site among its core environments. Stanford's APOLLO benchmark (2025) measured agents on 50 production websites — including major retailers — and found per-site success rates that varied wildly, with hard walls such as CAPTCHAs and logins among the biggest killers. The pattern is consistent: the deeper an agent gets into a real checkout, the more the environment was built for a human, and the more likely the agent is to fail.

What the agent runs into at checkout

Break the checkout path into pieces, and each piece has a wall.

  • Blanket anti-bot walls. Fraud systems often cannot distinguish a browser agent acting for a paying shopper from a credential-stuffing script. A blanket block at the cart stops both. The shopper who sent the agent never learns why nothing arrived.
  • CAPTCHAs mid-flow. Operator deliberately pauses and hands control to the user for CAPTCHAs, which means a wall at the wrong moment interrupts the delegated flow and drags the shopper back to their screen. That handoff is survivable only if the store surfaces it cleanly; most do not.
  • JS-only carts and invisible totals. Many carts compute shipping and tax client-side, after the shopper enters an address. An agent sent to "buy if the total is under $100" cannot know the total until it has already committed to the flow. Either it abandons, or it completes a purchase with a number the shopper did not approve.
  • Cross-origin payment iframes. Stripe, PayPal, and other processors render payment forms in iframes on a different origin. An agent that can read the store's DOM often cannot touch the iframe's DOM — by design, for the shopper's security. This is where most agentic checkouts stall.
  • Ambiguous CTAs and forms. "Add to bag" next to "Buy it now," client-side validation errors the agent cannot see, address fields with bespoke names. A human skims past these. An agent executes them literally, and a literal reading of a designed-for-humans form is how orders end up wrong.

A note on robots.txt, because it confuses people: hiding /cart and /checkout from search engines was once the right call, since those pages are useless to an indexer. It does nothing to stop a browser agent, which is not indexing — it is acting as the shopper's hands. The walls that matter are on the pages themselves.

What agentic checkout asks of a store

None of this requires rebuilding your stack. The same discipline that made the product page readable applies one page deeper.

  • Make the totals server-rendered. Shipping, tax, and the final price should be visible before the final click — for the agent's arithmetic as much as for the shopper's. If the total is only knowable after an interaction, the agent cannot make the decision it was sent to make.
  • One primary CTA. A single, unambiguous Buy button in a semantic <button> or form submit, with named, standard form fields carrying autocomplete attributes. Agents and password managers read the same hints — what helps one helps both.
  • Treat delegated shoppers as shoppers. Move from blanket automation blocks to risk-based challenges. A logged-in shopper's agent is not an attacker, and if your fraud rules cannot tell the difference, they are rejecting orders, not protecting anything.
  • Plan the payment handoff. Most agents pause at payment and hand the shopper the keyboard. That is the secure default, and the shopper continuing in their own browser is a success, not a failure. The failure mode is a wall before the handoff that ends the session instead of returning it to the human.
  • Return a parseable confirmation. After payment, the agent's last job is to report back: order number, items, total, delivery window. A confirmation page with that data in plain, structured HTML turns the agent into your most accurate receipt of record.

If you have not yet made the product page readable, start there — the page is an API response now, and structured data decides who wins the recommendation. The checkout list above only matters once the agent has already chosen you.

Readiness ends at the order confirmation

The readiness conversation so far has covered two acts of a three-act purchase: finding the store (structured data, crawlability, llms.txt) and choosing it (policy clarity, complete data, head-to-head preference — the dimensions our scoring methodology weighs). The third act — the transaction — is where the funnel actually converts, and it is the act almost nobody has instrumented.

That asymmetry creates a trap. A store that scores well on the first two acts and breaks on the third has optimized the wrong end of the funnel. The recommendation it worked for ends in an abandoned cart, and the shopper does not blame the checkout — they blame the agent, or the store, or both. Nobody reports the loss, because nobody saw it happen.

The fix is cheap relative to the cost of missing it. Server-rendered totals, one clear CTA, semantic forms, and a deliberate handoff at payment are all items a developer can land in a day. What they require first is the recognition that the checkout page, like the product page before it, now has two consumers — and the second one is already clicking Buy.

See where your store stands — run a free scan at prefero.me.