Agentic commerce, explained

Discovery is the first stage of an AI agent’s purchase attempt: the agent has to be allowed to fetch your store, find the products in it and read what each one is. A store that fails discovery is never evaluated, compared or bought from, so no improvement later in the journey can make up for it.

AI agents abandon carts for mechanical reasons rather than emotional ones. A human leaves because of price, trust or hesitation; an agent leaves because something in the page could not be operated. That difference is useful, because mechanical failures are reproducible and therefore fixable.

An agentic commerce protocol is a standard that lets an AI agent transact with a merchant directly, reading a catalogue and completing a purchase through a defined interface, rather than by driving a storefront designed for a human with a mouse. Four names come up: ACP, UCP, AP2 and MCP. They are not four candidates for the same job.

An agentic readiness checklist is the set of concrete, checkable properties that decide whether an AI shopping agent can find, understand and buy from a store. Almost all of them are data and markup rather than design, and most can be fixed in an afternoon.

Agentic checkout is the step where an AI shopping agent turns a chosen product into a paid order. As of 28 August 2026 there are two live patterns: ChatGPT sends the shopper to the merchant’s own checkout, while Google AI Mode, Gemini and Microsoft Copilot complete the purchase inside the assistant. This page is maintained rather than published once, because the answer has already changed twice.

Since March 2026, a shopper who buys through ChatGPT completes the purchase on your own checkout rather than inside the chat. Whether it succeeds depends on four things in order: whether the agent can find your catalogue, read your prices and terms as text, compare you against an alternative, and drive your checkout as far as the payment step. Failing any one of them ends the purchase, and most stores fail at least one without knowing.

Agentic commerce is shopping carried out by an AI agent acting on a person’s behalf: the shopper states an intent, and software finds candidate products, compares them, and completes the purchase. The shopper may never load the storefront, but as of 2026 the purchase itself often completes on the merchant’s own checkout.

The case for agent readiness is not a forecast about how large agentic commerce will become. It is that a store can be absent from it without any signal, that the absence is usually accidental, and that most of the remedy is data hygiene which pays for itself elsewhere. Framed as a bet on a trend it invites an argument about the trend. Framed as an unmonitored failure it invites a decision.

A first agent readiness audit fits in an afternoon if you work in the order an agent meets your store and resist fixing things as you find them. Check permission, then enumeration, then legibility, then checkout, recording what you find rather than repairing it. Fixing as you go is what turns an afternoon into a fortnight and leaves the audit unfinished.

Test on change rather than on a schedule. Agent readiness is not a property you achieve and keep: it is broken by ordinary events, a theme update, an app install, a consent banner, a bot rule change, and each of those ships without anybody thinking about agents. A calendar cadence catches breakage late. Testing on the events that cause it catches it while somebody still remembers what changed.

Most of what makes a store work for AI shopping agents is data hygiene you would want anyway: prices and availability as structured data, terms as text, a checkout that works signed out on a phone. Almost nothing requires adopting a protocol or building anything new. The one thing worth doing now is making sure your bot rules are a decision rather than an inheritance.

There is no industry figure that answers this for your store, because the number depends on your category, your customers and whether you are permitting agent traffic at all. What you can do is measure your own, from server logs for agent requests and from analytics for the people assistants refer, while accepting that both undercount and that neither can be backfilled.

Server logs are the only place an AI agent’s visit is recorded, because the request is served whether or not any JavaScript runs. Identify agents by user agent token against each vendor’s published list, corroborate with the address the request came from, and treat any hardcoded list as something that decays, because new agents appear and tokens change without notice.

Google Analytics can show you people who arrived from an assistant, because those are real browser sessions carrying a referrer. It cannot show you agent requests themselves, because most never run the JavaScript that reports a pageview. Analytics answers the referral question and your server logs answer the agent question, and confusing the two is how stores conclude that nothing is happening.

Asking ChatGPT whether it can see your store is the least reliable way to find out, because an assistant answering from memory produces the same confident sentence whether or not it fetched anything. What decides the answer is mechanical: whether your robots and CDN rules permit the fetch, whether your catalogue can be enumerated, and whether your product data is readable once retrieved.

An AI agent recommends a product by comparing candidates against a shopper’s stated constraints, so being recommended depends on whether your data answers those constraints. A store that states its price, availability, shipping cost and terms can be compared. A store that leaves any of them unstated is not judged badly, it is judged conservatively, which usually amounts to the same outcome.

An AI agent arrives at your store cold, fetches a small number of pages, and keeps only what it can read as text or structured data. It does not run your scripts the way a browser does, does not hover, does not wait, and does not have a session. Everything your storefront does to make a page feel good is invisible to it, and everything it needs has to be stated rather than shown.

A store that is invisible to AI agents usually looks completely healthy to its owner. The signs are specific and checkable: product data that only exists once scripts have run, terms published as images, a sitemap that lists collections rather than products, and bot rules written for training crawlers that also catch shopping agents. None of them affect how the store looks to a person, which is why they survive.

Visibility to an AI shopping agent is decided by whether it is permitted to fetch your pages, whether it can enumerate your catalogue, and whether your product data is readable once it arrives. Those are different from the things that make you visible in search, so a store can rank well and still be effectively absent from an assistant’s view of the market.

Test in the order an agent meets your store: whether it can find your catalogue, read your product data as text, work out your true total, and drive your checkout to the payment step. Each test rules something out rather than proving success, because only a completed attempt proves success. Run them in order, since an early failure makes every later result meaningless.

You find out by sending an agent and watching where it stops. An AI agent reads your store as data rather than as a rendered page, so nothing you can see in a browser tells you whether one can find your products, understand your prices and terms, or reach your payment step. The failure is invisible from the inside, which is why guessing is the one approach that does not work.

Appearing in an AI channel where the purchase completes in-channel is decided by your product record rather than your product page, which means feed completeness, freshness and identifier coverage matter more than the page level work most stores invest in. Search ranking does not transfer, because ranking rewards a page satisfying a query and this rewards a record answering a constraint.

There is no form to submit and no ranking to buy. Appearing in an assistant’s shopping results is the outcome of three conditions: your pages can be fetched, your catalogue can be enumerated cheaply, and your published data answers the constraints a shopper stated. Each one is checkable today, and failing an earlier one makes the later ones irrelevant.

Shopify documents ChatGPT shoppers completing on the merchant’s own checkout in an in-app browser, and Google AI Mode, Gemini and Microsoft Copilot completing in the AI channel’s Shopify-powered direct checkout. The split determines where your risk sits, and it has moved once already, so it is worth rechecking rather than memorising.

Retail Dive reported on 25 March 2026 that OpenAI had announced the previous day it was retiring the first version of Instant Checkout, with checkout moving back to merchant sites. For merchants that is favourable, because the thing being tested is now their own checkout and they keep the customer and the order data, and it is a larger obligation, because a checkout failure now costs the order outright.

An assistant built around answering with sources rewards merchants whose facts are stated plainly and can be attributed to a page. For a store that means the specifics a buyer needs should exist as clear statements rather than being implied by imagery or buried in marketing register, because a claim that cannot be quoted is a claim that cannot be used.

When a purchase completes inside the channel, the product record rather than the product page is what competes, so feed completeness, freshness and identifier coverage do more work than anything on your storefront. That inverts the usual priority order, where a store invests in pages first and treats the feed as an export.

An assistant choosing a product works through the constraints a shopper stated, filters candidates that fail them, and chooses among the survivors. Most of what decides the outcome is therefore arithmetic on published facts rather than judgement about quality, which is why a store with a genuinely better offer can lose to one that simply published its shipping cost.

What any assistant needs from your store is the same: permission to fetch, a catalogue it can enumerate, and product data that answers a shopper’s constraints. Where a purchase completes varies by assistant and changes, so that part belongs in vendor documentation rather than in an article, while the readiness work is identical and can be verified today.

Shopify’s help centre groups Microsoft Copilot with Google AI Mode and Gemini as assistants whose shoppers complete their purchase in the AI channel’s Shopify-powered direct checkout. As with those, your product data carries the sale rather than your storefront, and the work that makes you competitive is the same work that serves every other assistant.

Shopify’s help centre says shoppers using Google AI Mode complete their purchase in the AI channel’s Shopify-powered direct checkout without leaving the conversation. Since your storefront is not in the path, your feed and your published product data decide everything, and the ordinary levers of merchandising, design and on-site persuasion do not apply.

Shopify’s help centre says shoppers using Google AI Mode, Gemini or Microsoft Copilot complete their purchase in the AI channel’s Shopify-powered direct checkout without leaving the conversation. For a Shopify merchant that means your checkout is not in the path at all and your published product data carries the entire sale, which changes what is worth fixing first.

Whether any assistant can buy from your store is decided by three things that do not vary between them: whether you permit the fetch, whether your catalogue can be enumerated, and whether your published data answers the constraints a shopper stated. What does vary is where the purchase completes, and that changes often enough that the reliable answer comes from each vendor’s current documentation rather than from an article.

Every step in a custom checkout was added deliberately by somebody, which makes it the place where agent purchases most often end. The failures are not exotic: required account creation, fields that appear at the last step, custom controls that are not real form elements, and state kept client side across a redirect that an in-app browser does not preserve.

A headless storefront is not inherently unreadable to agents, and a purely client rendered one usually is. The distinction is whether the facts exist in what the server sends or only after the client application has run, and modern rendering choices make that a setting rather than a rebuild for most stacks.

On Salesforce Commerce Cloud the catalogue is rarely the problem and the storefront usually is, because it is custom and was built for people looking at screens. The second and less technical problem is ownership: agent readiness spans catalogue, storefront, checkout and edge security, which in an enterprise are four teams, so the work stalls on who is accountable rather than on difficulty.

Wix storefronts render a great deal on the client, which is the specific agent readiness risk: a product page can look complete and serve markup with no price, no variant options and no availability. Since you control the template less than on a self hosted platform, the leverage is in filling every product field the platform exposes and stating facts in copy that would otherwise live only in layout.

Squarespace stores tend to be strong on design and weak on published fact, because the platform makes it easy to express a shipping threshold or a returns window as part of a layout rather than as text. You control less of the markup than on a self hosted platform, which makes the things you do control, your copy, your policies and your product fields, matter more.

Adobe Commerce stores usually have rich catalogue data and complex storefronts, and the agent readiness problem is almost always the join between them. Attributes exist, variant pricing is modelled properly, and the served page carries a fraction of it because the theme was built for a person looking at a screen.

BigCommerce carries more structured catalogue data natively than most platforms, which is a real advantage for agent readiness. The gap is usually presentation rather than data: a headless or heavily customised storefront can hold excellent catalogue records and publish pages where the price and variants only exist once the client application has rendered them.

WooCommerce gives you control over everything, which means nothing is decided for you: structured data, feeds, caching and checkout behaviour are all outcomes of the plugins and theme you chose. The two specific risks are plugin sprawl, which adds overlays and checkout steps, and an SEO plugin whose product markup is assumed to be complete when it is frequently missing the fields that matter.

A theme decides what exists in your markup, not only how your store looks, so a theme update can remove an agent’s ability to select a variant or add to cart while changing nothing a person would notice. Nearly all of the mechanical failures live in two components, which makes the check after an update short and worth automating.

Most Shopify stores already generate a product feed for advertising, and reusing it is the fastest way to become cheap to enumerate. Two things usually need fixing first: advertising feeds are often deliberately partial, covering only promoted products, and they refresh on a schedule set for ad platforms rather than one that keeps pace with price and stock changes.

A Shopify store is agent ready when an agent can read its catalogue without running scripts and reach the payment step from a cold session. The Shopify specific risks are app accumulation, which adds overlays and checkout steps nobody decided on, and theme behaviour, which changes what exists in the markup rather than only how it looks.

Shopify introduced an agentic plan at no monthly cost, aimed at making it cheap for a catalogue to be present on agentic surfaces. Being present and being chosen are different things: a plan removes a commercial barrier to participating and changes nothing about whether your product data answers the constraints an agent checks, which is what actually decides comparisons.

An agentic storefront is the surface Shopify exposes so AI channels can read a store’s catalogue and transact against it. Shopify’s documentation says these are active by default for eligible stores, so for most merchants the question is not whether to switch it on but whether the store meets the requirements, and whether the data behind it is good enough to win a comparison.

A Shopify store can be selling under two agentic checkout patterns at once: an assistant sending a shopper to your own checkout in an in-app browser, and an assistant completing the purchase inside its own channel on Shopify-powered checkout. The two fail in different places, so a merchant needs both their storefront data and their checkout to hold up rather than choosing which one to care about.

Product copy helps an agent where it states a fact that can be checked against a shopper’s constraint, and does nothing where it makes a claim that cannot be verified. That does not mean writing for machines: it means making sure the specifics a buyer needs, materials, dimensions, compatibility, care, are present as plain statements somewhere, alongside whatever persuasion the page is doing.

Collections organised around how a business buys and merchandises stock rarely match how shoppers describe what they want, so a request for a kind of product resolves to a homepage rather than to a set of yours. Structuring for discovery means having a real page for the categories people actually ask for, and making sure those pages are listed, crawlable and readable without scripts.

A stale product feed is worse than no feed at all, because an absent feed sends an agent to your pages while a stale one gives it a fast, confident, incorrect answer it has no reason to double check. Freshness is therefore a property to monitor rather than a job to schedule, and the failure is silent: the URL still resolves and the file still parses.

When an assistant sends a shopper to your checkout, the purchase often completes inside an in-app browser rather than in the shopper’s usual browser. That environment is narrow, cold, and restricted in ways ordinary mobile testing does not reproduce, so a checkout that passes every device test you run can still fail the sessions an assistant actually sends you.

An add to cart that only works once scripts have run is unusable to any agent that stopped at your markup, and agents take the cheapest path to an answer rather than rendering every page. A form that posts to a server side endpoint is the fallback that makes the action expressible, and it costs nothing visible: the scripted version can still enhance it for everyone else.

An agent arrives with no cookies and no history, so every modal your store shows to a first time visitor fires on every visit. A newsletter overlay, a consent wall, a region selector or a cart upsell that a person dismisses without thinking is an unanswerable obstacle to an agent, and it usually appears at exactly the point where a purchase was about to complete.

An agent will not create an account, so a checkout that requires one converts a won sale into no sale at the last step. Most forced account creation exists for reasons that guest checkout can satisfy anyway: order lookup, marketing consent and repeat purchase are all achievable without making registration a precondition of paying.

Cloudflare separates bot traffic into categories, and the setting that governs shopping agents is usually one somebody accepted once rather than chose. That matters because this layer enforces where robots.txt only requests, so a store can publish a welcoming robots file and still block every agent that honours it.

Bot protection is the earliest and bluntest way a store disappears from agentic shopping: a challenge that asks the visitor to enable JavaScript and wait is unanswerable to an agent, so every other quality of the store stops mattering. The work is separating identifiable, well behaved agents from the abusive traffic the protection was bought for, which is a policy question rather than a technical one.

A variant picker fails an agent when the options only exist after a script attaches them, or when selecting one requires a hover. Both leave an agent at a product it wants and unable to say which version it wants, which is the most expensive place to fail because everything before it succeeded. Most of the remedy is ordinary accessibility work you may already owe.

A policy set in a designed graphic is unreadable to an agent, which means an agent asked whether you offer free returns will answer that you do not say. That is a different and worse answer than no, because a store with a stated but restrictive policy beats a store whose policy cannot be read. Converting them is a template change, not a design sacrifice.

An agent comparing stores needs the delivered total, not the item price, and it will not guess generously when your shipping cost only appears at checkout. Publishing shipping as data before checkout is what turns you from an unknown into a comparable offer, and the common objection, that shipping is too complicated to state, is usually about edge cases rather than the ordinary case.

Availability is only useful to an agent when it is stated per variant and when it is accurate in the negative. Stores routinely publish availability that is correct while a product is in stock and silently wrong once it is not, or that describes a product rather than the size a shopper asked for, and neither error is visible to anyone testing with a product that happens to be available.

A GTIN is a global identifier that lets an agent recognise your product as the same item it has seen on another store, which is what makes a price comparison possible at all. Without one you can still be found, but you are compared as an unknown rather than as a competing offer on a known product, and unknowns lose.

A product feed lets an agent read your whole catalogue in one request instead of fetching and parsing every product page. That matters because an agent answering a question does not survey your store, it takes the cheapest path to an answer, and a store that is expensive to enumerate gets skipped rather than ranked lower.

Search crawling, training data collection and agentic shopping are three different uses with three different consequences, and most robots.txt rules about AI were written with only the second in mind. The result is stores that intended to keep their content out of a training set and also removed themselves from assistant driven purchases, without ever making that decision.

An llms.txt file is a short, machine readable map of what a site contains and where the authoritative version of each thing lives. For a store it is most useful pointing at your policies, your feed and your reference pages, not at your catalogue, which belongs in a feed. It grants no permission and replaces nothing: robots rules still decide access, and structured data still decides whether a product is legible.

Product schema is how you state your price, availability, identifier and terms as data rather than as layout, so an agent reading your page does not have to infer them. Adding it is usually a template change rather than a redesign, and the test of success is not that the markup validates but that the specific facts an agent needs are present in it.

What a signal check can prove about a store, what only a purchase attempt can, and what lives in the gap between them.

Every stall an Ottom scan can report, grouped by journey stage, each with the mechanism behind it and the change that removes it.

Definitions for the vocabulary these pages use, one term per entry.