Something changed in commerce over the last eighteen months, and the way it changed made it easy to miss. There was no migration to run and no upgrade to approve. Shopify enabled agentic storefronts for eligible merchants in March 2026, and in May 2026 began shipping llms.txt, agents.md and UCP support natively. For a large number of merchants, the rail that lets an agent transact with their store was switched on by the platform, on their behalf, without any of them doing anything.
Meanwhile the demand side moved. AI-referred traffic and AI-attributed orders grew sharply through 2025 and 2026. People stopped typing queries into a search box and started stating intents to an assistant: something for a seven year old who has outgrown their first bike, under two hundred pounds, delivered before Saturday. The assistant does the shortlisting. The merchant never gets the impression it used to get, because there is no impression. A program read something, or failed to read something, and moved on.
The result is a gap that very few store owners can see from inside their own business. The platform says agentic commerce is enabled. The analytics show traffic that looks broadly normal. And yet the store is not appearing in the answers, because being enrolled in agentic commerce and being legible to an agent are two entirely different things.
What an agent actually reads
It helps to be concrete about what happens when an AI shopping agent evaluates a store, because the mental model most people carry over from search is wrong in a specific and expensive way.
A search engine crawler was, at heart, reading a document for a human. It indexed text so that a person could later be handed a link. The page was the product being sold and the human did the interpreting. Design mattered. Persuasion mattered. Ambiguity was survivable, because a person resolves ambiguity effortlessly.
An agent is not reading a document. It is trying to fill in a record. It arrives with a set of fields it needs values for, and every field it cannot fill is a gap it must either guess at or route around. Guessing is expensive and route-around is cheap, so it routes around. That is the whole mechanism. It reads in roughly this order.
First, can it get in at all. The agent's crawler requests robots.txt and obeys what it finds. Five crawlers matter most in shopping contexts today: GPTBot and OAI-SearchBot from OpenAI, ClaudeBot from Anthropic, PerplexityBot from Perplexity, and Google-Extended. These are separate user agents with separate purposes. Some fetch to answer a shopper's question right now, and some fetch to train a model for later. A rule that blocks the retrieval crawlers removes the store from consideration before any other quality of the store has been assessed. Nothing about this failure is visible from inside the business. No error is raised, no alert fires, and traffic does not drop in a way that points at the cause.
Second, can it find the catalogue. The agent looks for the conventional orientation files: a sitemap that actually exposes product URLs, an llms.txt describing what the site is and where the useful pages are, its longer llms-full.txt variant, an agents.md, and a UCP manifest at /.well-known/ucp. None of these are ratified standards, and it is worth being honest about that rather than overselling them. They are conventions that have converged quickly because they solve an obvious problem. Their absence is not fatal, but their presence is cheap, and cheap wins are the right place to start.
Third, can it parse the product. This is where most stores lose, and where the loss is least visible. A product page that looks complete to a person can be empty to a parser. What the agent wants is a Product node in JSON-LD with an Offer carrying a price and a currency, an availability value expressed as a schema.org enumeration rather than the words "in stock" in a paragraph, and identity fields: SKU, and GTIN or MPN. Those identity fields are what let the agent recognise that your listing and another merchant's listing are the same physical object. Without them you are not a competing offer. You are an unmatched item, which is a polite way of saying you are not in the comparison.
WooCommerce core emits no Product schema at all without a plugin. A store can run for years on that stack, sell well, look immaculate, and be structurally unreadable to every agent that has ever visited it.
Fourth, can it price the risk. This is the part that surprises people. An agent recommending a purchase, and increasingly completing one, has to reason about what happens after the money moves. Agents select merchants partly on structured data completeness, and specifically on AggregateRating, MerchantReturnPolicy, OfferShippingDetails and FAQPage. Each of those maps to a question a careful buyer would ask. Is it any good. What happens if I need to send it back, and who pays. When does it arrive and what does delivery cost. And then the long tail of specifics that only an FAQ answers.
A returns page written in warm, clear English is worth nothing here. Not because the agent cannot read English, but because prose does not give it a value it can compare against another merchant's value. Thirty days, free return shipping, returns by post: those are fields. "We want you to love your purchase" is not.
Enrolled and invisible
Once you see the order of operations, the failure mode explains itself.
Platform enrolment turns on the transaction rail. It makes the store capable of completing an agent-initiated purchase. What it does not do is make the store worth selecting, because selection happens earlier and depends on data the platform does not own. Your theme decides what JSON-LD the product page emits. Your apps decide what gets injected or stripped. Your policy pages were written by a person for people. Your robots.txt may have been edited during a scraping scare two years ago by someone who has since left.
So the store is enrolled, and the store is invisible. Worse, it can be enrolled and downgraded, which is subtler: the agent can read you, but it can fill in six fields for a competitor and three for you, and completeness is part of how it chooses. Missing data is not neutral. In a comparison, absence reads as a reason to prefer the merchant whose data is present. You do not get told you lost on incompleteness. You simply do not appear in the answer, and the counterfactual is invisible to you forever.
Agent readiness as a discipline
This is why the useful unit of work here is not a growth tactic but an audit.
Agent readiness is the measurable state of a store being findable, readable, comparable and transactable by an AI shopping agent. The reason to define it that precisely is that every clause corresponds to something that either passes or fails when you go and look. Crawl access passes or fails. A Product node has a GTIN or it does not. A MerchantReturnPolicy exists with a returnPolicyCategory and a merchantReturnDays, or it does not. There is no interpretation in the middle, which means there is no room for the comforting vagueness that surrounds most marketing advice.
That measurability is the point. It makes the work finite. A store has a current state, that state has specific defects, each defect has a fix, and after the fix you can re-measure and see it change. This is closer to accessibility auditing or performance budgets than it is to SEO strategy. Nobody argues about whether an image has alt text.
It also means the work is unglamorous and mostly one-off. Emit the structured data. Express the policies as fields. Stop blocking the crawlers you did not mean to block. Publish the orientation files. Then check that a theme update has not quietly undone any of it, because that is the one part that recurs: these fixes live in templates, and templates get redeployed.
What to do about it
In order, cheapest and most gating first.
Read your own robots.txt, top to bottom, and confirm that the retrieval crawlers are not blocked. Decide deliberately about the training crawlers, which is a legitimate business judgement rather than a technical error, but know that blocking the retrieval ones costs you sales.
Fetch your own product page and read the JSON-LD, rather than trusting the theme or the plugin to have done it. Look for the Offer, the price and currency, the availability enumeration, and the identity fields.
Add MerchantReturnPolicy and OfferShippingDetails as structured data, not as a link to a policy page. Add FAQPage where you genuinely answer questions. Emit AggregateRating only if you actually have ratings, because inventing them is both detectable and a policy problem.
Publish llms.txt, agents.md and, if your platform supports it, a UCP manifest. If you are on Shopify some of this may already be generated for you, which is worth checking rather than assuming, because "eligible merchants" and "native support" are not the same as "every store, covered".
None of this is difficult. It is simply invisible work with a delayed and unobservable payoff, which is exactly the category of work that does not get done until someone measures it. The stores that sort this out in the next year will not experience it as a dramatic win. They will just quietly remain in the consideration set as more of the buying moves to agents, while the stores that did not will watch a slow, unattributable decline and blame it on the market.
The switch has already been flipped. The only open question is whether anything useful happens on your side of it.
If you want to see which of these your store currently passes, run a free scan. It reads only public pages, takes about twenty seconds, and tells you what an agent finds when it looks at you.