Shopping & Checkout Agents

9 min read

Y15
Playbook · Domain Playbooks

Shopping agents: the checkout is not the hard part. The catalog is.

OpenAI launched Instant Checkout on 29 September 2025 with the largest agent distribution on earth behind it, and pulled it back on 4 March 2026 with fewer than fifteen Shopify merchants live — not because payments were unsolved, but because product data was. Price, availability, variants, multi-item carts and loyalty status turned out to be the things nobody could get right at scale. Build a shopping agent on that lesson: assume the catalog is stale and adversarial, verify the item at the moment of purchase, and spend your remaining engineering on proving delegated authority at the one step that cannot be undone.

STEP 1

Read the Instant Checkout retreat correctly, because it is the best evidence available.

The natural reading is that agentic commerce is early. The more useful reading is that the difficulty was distributed the opposite way to everyone's roadmap. Payments — the part that sounded hard, that got the protocols and the press — worked. What did not work was merchant enablement: onboarding stores, showing accurate product information, supporting a cart with more than one item, connecting loyalty memberships. Purchases moved back to merchants' own storefronts, reached through an in-app browser or an ordinary tab.

  • The merchant has no incentive to hand you a clean feed. A structured product feed to an agent removes the merchant's merchandising, upsell, and brand surface, and gives them a customer relationship mediated by someone else. "Their integration was hard" and "their integration was not in their interest" produce identical symptoms.
  • Catalog data is stale by default, everywhere. Price changes, stock moves, promotions expire, variants sell out. Any snapshot older than minutes is a claim, not a fact — and an agent that quotes a stale price has not made an error the user will forgive, because they experienced it as a lie.
  • Carts and loyalty are where the model of "a purchase" breaks. Real baskets have several items, a discount code, a delivery choice, a membership tier and a return policy attached. An agent architecture that treats a purchase as one product plus one card will hit that wall the first week it meets a real shopper.
  • So the winning shape, today, is discovery in the agent and transaction on the merchant's surface. That is where OpenAI landed, and it is the right default for you too — the agent does the search, the comparison and the cart preparation, and hands off to the merchant's own checkout, which is already correct about price, tax, stock and loyalty because it is the system of record.

This does not make native checkout wrong forever; it makes it a bet on merchant adoption rather than a technical project. If your agent operates inside one vertical with a handful of partners you can integrate deeply, native checkout is achievable and better. Across the open web it is a distribution problem that the largest distributor in the market could not solve in five months.

STEP 2

Ground the item, then re-verify at the moment of purchase.

The characteristic failure of a shopping agent is not buying nothing. It is buying the wrong thing confidently — the 2023 model instead of the 2025 one, the refurbished listing, the third-party seller, the small when the user said medium. Every one of those is a grounding failure, and grounding in commerce has a shelf life measured in minutes.

  • Every purchasable claim carries a source and a timestamp. Price, availability, seller identity, condition, shipping estimate. If the agent cannot cite where and when it learned a fact, it may present it but must not act on it. See hallucination and grounding.
  • Re-fetch immediately before the irreversible step, and diff. A price that moved, a stock level that dropped, a variant that changed — any delta between the basket the user approved and the state at submission stops the run and returns to the human. This one check removes the majority of "the agent bought the wrong thing" incidents.
  • Variant identity is a distinct problem from product identity. Size, colour, capacity, region, edition, bundle. Assert on the specific variant identifier, never on the product title, because titles are marketing text and marketing text changes.
  • Marketplace listings need a seller check. On any platform with third-party sellers, "the product" is a page and "the offer" is a row on it. The agent must reason about the offer — seller, condition, fulfilment — or it will reliably choose the cheapest row, which is reliably the one a human would not.
  • Constrain the search space before you optimise inside it. An agent told to find the best price will find a grey-market importer. Allowlist retailers, or require a policy the agent can check (returns accepted, ships from this country, sold by the brand) and treat everything else as unavailable.
STEP 3

The payment is the one action that cannot be undone. Gate it outside the model.

Almost everything a shopping agent does is reversible: searching, comparing, filling a basket, even starting a checkout. Submitting payment is not, and no amount of prompting makes a model a reliable last line of defence. The gate belongs in your code, and the authority it checks belongs to the user, not to the agent.

  • Delegated authority should be explicit, scoped and verifiable. This is what the emerging protocol layer is for: Google's AP2 expresses user intent as a digitally signed Mandate; ACP, the open standard maintained by OpenAI and Stripe, covers agent-ready checkout, payment delegation and order lifecycle; Visa's Trusted Agent Protocol signs agent identity into HTTP headers from the network side. They are not interchangeable and none has won — treat them as a moving layer, and see AP2 and agent commerce for the comparison.
  • Whatever the protocol, hold a signed record of what the user approved. Item, variant, maximum total, merchant, and time window. That artifact is what makes a disputed charge resolvable and what turns "the agent bought it" from an argument into a record.
  • Never give an agent a raw card number. Use a network token, a virtual card with a per-transaction limit, or the merchant's own delegated-payment flow. A scoped credential converts the worst case from unbounded to bounded, which is the only meaningful risk control available here.
  • Confirm on value and irreversibility, not on every step. A confirmation dialog on each action trains the click. Gate the submit, gate anything above a threshold the user set, gate anything non-returnable, and let the rest run — the placement argument in human-in-the-loop applies almost verbatim.
  • Decide who eats the mistake before launch. When an agent buys the wrong item, someone pays for the return. If that policy is undefined at launch it will be defined by whoever complains loudest, and the answer will be worse than the one you would have chosen deliberately.
STEP 4

Product pages are attacker-writable, and the attacker is a merchant.

A shopping agent reads text that sellers control and that is already optimised to influence a ranking algorithm. Sellers have spent two decades learning to write for whatever machine reads their listing; they will adapt to this one faster than to any previous one, and the payoff is a sale rather than a rank.

  • Descriptions, specs, review bodies and seller Q&A are untrusted input. Deliver them to the model in a delimited block described as attacker-supplied. The same discipline as prompt injection 101, in a domain where the attacker has an ordinary commercial motive rather than a criminal one.
  • No text on a page may be able to complete a purchase. The purchase decision reads structured fields — price, variant ID, seller ID, stock — that come from an API or a parser you control, never from prose the model was persuaded by. If a paragraph in a product description can move the agent's choice, you have built a new SEO channel and it will be found.
  • Watch the exfiltration direction too. A shopping agent holds a delivery address, an order history and often a payment token. An injected page that induces it to submit those to a form is a straightforward attack with an obvious payoff.
  • Reviews are the highest-yield surface and the least defended. They are user-generated, adversarially written and specifically designed to be persuasive. Summarise them if you must; never let them decide.
STEP 5

If you are the merchant, your problem is telling an authorised agent from a scraper.

The other half of this domain is rarely written down. Merchants have spent years building defences that treat automated traffic as fraud, and those defences do not distinguish a bot buying on behalf of a real customer from a bot scraping prices. Today, the most common merchant-side experience of agentic commerce is a blocked checkout.

  • Signed agent identity is the mechanism, and it is arriving. Visa's Trusted Agent Protocol signs agent identity into request headers precisely so that a merchant can recognise an authorised buyer; the security primitives behind that class of scheme are in agent identity and attestation.
  • Decide your posture deliberately, not by default. Blocking agents, allowing identified ones, or publishing a machine-readable catalog are three different commercial strategies. The current default — block everything that looks automated — is a decision you are making by not making it.
  • A machine-readable surface is the cheapest thing you can ship. A structured feed with price, stock and variants beats an agent screen-scraping your site, for both sides: you get accuracy and attribution, the agent stops guessing. See agents.json and OpenAPI for agents.
  • Expect the returns rate to differ and measure it separately. Agent-mediated purchases have a different error distribution from human ones. Tag them at the order level from day one, because you cannot reconstruct the tag afterwards and it is the number that decides whether the channel is worth supporting.
STEP 6

Evaluate on cart accuracy and reversal rate, never on conversion.

Conversion is the metric the business will ask for, and it is the one that most rewards an agent behaving badly: an agent that buys quickly, buys the cheapest listing, and skips confirmations will convert beautifully for a quarter and then be measured in returns, chargebacks and churn.

  • Cart accuracy before submission. Given a stated intent, did the agent assemble exactly the right items, variants and quantities? This is scoreable offline against a fixed set of intents and it is the single most informative number in the domain.
  • Reversal rate as the cost metric. Returns, cancellations and disputes attributable to agent-placed orders. This is the true cost of the errors that conversion hides, and it lands on a different team's budget, which is why nobody measures it unless you insist.
  • Stale-quote rate. How often the price or availability the agent stated differed from the state at checkout. This is the trust metric — users forgive a slow agent and do not forgive a wrong price.
  • Build the golden set from real intents, including the ambiguous ones. "Get me more of the coffee I bought last time" and "something like this but cheaper" are the actual queries, and they are where a specification-following agent quietly substitutes its own judgement.
  • Keep an adversarial slice permanently. Listings containing injected instructions, misleading titles, wrong-variant traps and third-party offers that look like the brand's. It grows every time you add a retailer.

Ship discovery and cart assembly first, hand the transaction to the merchant's own checkout, and re-verify price and variant immediately before any irreversible step. That configuration captures most of the user value, avoids the merchant-integration problem that stopped the best-distributed attempt so far, and keeps the one unrecoverable action behind a gate your code owns. The agent's job is to arrive at the right basket; the merchant's checkout is already correct about money, and correctness about money is not a feature you should be re-implementing.

Related: browser agents for the surface most of this runs on and the three-surface split for which browser it should be, agent identity and permissions for the authority model behind step 3, and adapting a playbook for the method behind this one.