The Storefront Your Customer's AI Agent Actually Reads

Two chief executives sat on a stage in San Francisco on 15 October and talked about customers who are not people. Practical Ecommerce reported the announcement on 20 October: Shopify's Tobi Lutke and Vercel's Guillermo Rauch, a rebuilt Hydrogen software development kit, and an open source storefront template called Vercel Shop that treats an AI agent as a visitor with its own needs rather than a scraper to be blocked.

If you run a shop alone, the temptation is to file this under conference news and move on. Do not. Strip away the two brand names and what was demonstrated is a short list of files and fields that any shop can publish, on any platform, including one you built yourself. The list is the useful part, and it has been sitting in a public specification since January.

What did Shopify and Vercel actually announce?

A storefront that answers twice. The template looks like an ordinary ecommerce site to a person, with product pages, search and a cart. The same product URL, asked politely by a machine, returns Markdown instead: the description, the price, the available options and the availability of each specific variant. According to Practical Ecommerce, that means an agent does not have to parse your HTML or take screenshots of your page to work out whether the blue one in medium is in stock.

The second half is a set of tools exposed at the merchant's own domain over the Model Context Protocol. Those tools cover catalogue search, live availability for a named variant, cart operations and a checkout link. The cart is shared, so an item an agent adds shows up in the human session and the other way round. There is also an optional assistant that sits on the storefront itself, switched off by default.

Lutke's line about the underlying work was blunt: checkouts are ridiculously hard to get right. That is the honest reason this arrives as a platform feature rather than a weekend project. The agent reads your catalogue; the platform still owns the money.

What does a shopping agent need that a web page does not give it?

Six things, and five of them are data rather than code. An agent needs to know your shop exists, what protocol you speak, what a product costs in a form it cannot misread, which variant is actually available right now, what your policies say, and where to hand the shopper back to you. A rendered page gives a machine the first and the last of those, badly. Everything in the middle it has to guess.

That is why this is a catalogue problem. The fields an agent wants are the same fields a feed wants, which is why the product feed is where a shop gets judged long before any protocol is involved. If your variants are encoded in the title string, no amount of Markdown will save you.

Read the right hand column again. Four of the six rows are yours, and none of them require a developer. They require a catalogue where the price is a number, the stock is per variant and the policy page says what you actually do.

Where does an agent look for your shop?

At a single path. The Universal Commerce Protocol specification overview is explicit: businesses publish their profile at /.well-known/ucp, served over HTTPS with no redirects, and that file is the discovery entry point. An agent reads it to determine protocol support, locate your endpoints and negotiate which capabilities you both understand. Agents identify themselves the other way, advertising their own profile URL in a UCP-Agent request header.

The specification is tidier than most protocol documents a merchant will meet. Services are named by reverse domain, so the shopping surface is dev.ucp.shopping. Versions are plain calendar dates in YYYY-MM-DD form, with examples running from 2026-01-11 through 2026-08-25, which means you can look at a profile and tell at a glance how old it is. Capability negotiation works by intersecting what the business supports with what the platform supports, so an unsupported version degrades rather than breaking.

Google's engineering write up from 11 January 2026 walks the checkout path end to end. A session is created with a POST to /checkout-sessions and comes back with an identifier and a status of ready_for_complete. The discount example in that post applies a code called 10OFF to a $35.00 item and the total lands at 3150 minor units. It also names the partners: the protocol was developed with Shopify, Etsy, Wayfair, Target and Walmart, and endorsed by more than twenty others.

Four transports for one capability set is a lot of optionality, and it exists because nobody yet knows which one wins. The protocol README on GitHub lists the initial capabilities as checkout, identity linking through OAuth 2.0, order lifecycle webhooks for events such as shipped or delivered, plus payment token exchange between payment service providers and credential providers. Discounts and fulfilment are extensions rather than core. The licence is Apache 2.0.

Is any of this real traffic yet?

Yes, and it converts better than the rest of your traffic. Adobe's July 2026 figures, reported by Digital Commerce 360, put AI referral traffic to US retail sites up 62% year over year and up 1,219% against October 2024. Those visits convert at a rate 60% higher than non AI traffic, the eleventh consecutive month of outperformance, and they generate 53% more revenue per visit. Visitors arriving this way spend 59% more time on site, bounce 33% less and add to cart 28% more often. The base is more than 1 trillion visits to US retail sites.

Two cautions before you redraw your forecast. The first is that this is Adobe measuring its own analytics cohort, which skews towards large retailers; more than 200 of the Top 2000 online retailers use it. The second is that a referral from an assistant is not the same thing as an agent transacting on your domain, and the two get blurred constantly. Our own look at four shops that measured their AI traffic and got four different answers is a useful corrective: the measurement question is unsettled even where the traffic is real.

The number worth acting on is a different one. Adobe found that in April, retailers had not optimised about 25% of the content on their homepages for language models, and by July its expanded cohort was at 61% visibility, leaving 39% of those homepages unreadable by a machine. Large retailers are slow here because changing a homepage requires a committee. You are not slow.

What should a small shop do before the agents arrive?

Four jobs, in this order, none of them requiring you to adopt a protocol this quarter.

1. Make the price a number and the stock a variant. If your price lives in a text field with a currency symbol glued to it, or your stock is one count across six sizes, every machine reading your shop will get it wrong. This is the single highest leverage hour in the list.
2. Give a machine something to read. Structured data on product pages, a current sitemap and a plain text summary of your catalogue are what the Vercel Shop announcement calls discovery aids. None of them are new. They are simply now load bearing.
3. Decide what an agent may touch. Reading your catalogue is one permission. Adding to a cart is another. Holding a logged in session on a customer's behalf is a third. These are separate decisions and what a seller still controls once a browser agent reaches the checkout is worth settling before someone else settles it for you.
4. Measure the channel on its own. If assistant referrals land in your analytics as direct traffic, you will conclude the channel does not exist. Tag it, then watch the conversion rate rather than the volume.

Doing those four leaves you ready for whichever protocol wins, because all of them need the same underlying catalogue. The shop that cannot say which variant is in stock cannot be helped by any amount of specification.

What can the agent still not do?

Pay, mostly. In the Vercel Shop configuration described by Practical Ecommerce, the storefront assistant cannot place an order or process a payment, and the shopper finishes through the normal checkout. Shopify remains the authority on prices, availability and which cart changes are permitted. The agent proposes; the platform disposes.

That boundary is deliberate, and it is the thing most commentary gets wrong. Google's reference implementation lets people buy from eligible businesses inside AI Mode in Search and the Gemini app, but only where the business has an active Merchant Center account with eligible products, and the protocol separates payment instruments from payment handlers so a shopper's card is never the same object as the processor touching it. Every authorisation carries cryptographic proof of user consent. The machinery is being built to keep a human decision inside the loop, not to remove it.

Which leaves the familiar question of who is answerable when an agent gets it wrong. We wrote about who agreed to what when a machine buys from you and the answer has not improved: your terms, your policy pages and your consent records are the evidence, and they are worth reading again now that a non human party is reading them too.

Three questions worth asking your platform this month

Ask them by email so you have the answer in writing.

• Do you publish a profile at /.well-known/ucp on my domain, and can I see it? If the answer is yes, open the URL. If it 404s, the feature is on a roadmap rather than on your shop.
• Which capabilities are declared, and what version date do they carry? A profile declaring checkout at 2026-01-11 while agents negotiate 2026-08-25 will still work by intersection, but you should know you are a year behind.
• Can an agent change a cart without a logged in session? This is the question with a commercial answer rather than a technical one, and the person who sells you the platform may not have thought about it.

A shop running on code it owns can answer all three by reading its own repository, which is the quiet argument for building on something you control. If you are weighing that choice, our AI ecommerce store builder page sets out what owning the storefront code actually changes when a new protocol shows up.

What is actually inside that profile file?

Four kinds of declaration, and it is worth knowing them because the file is the only part of this a merchant can inspect without a developer. The specification overview says a business profile carries its supported capabilities, its payment handlers and its verification keys, while the platform publishes signing keys for any capability that requires cryptographic verification. Google's walkthrough shows the shape of a real one: a service block for dev.ucp.shopping with a REST schema and endpoint, capability entries for checkout plus the discount and fulfilment extensions that hang off it, and a payment handler list. The sample in that post names three handlers, one of them called mock_payment_handler, which tells you how early this still is.

The version mechanics matter more than they look. Because every entity carries a plain date, a profile is self dating, and because negotiation works by intersection rather than by exact match, a shop running an older capability version keeps working with a newer agent instead of failing closed. The specification includes an unsupported version example dated 2026-01-12, so the failure path is written down rather than left to each implementer. For a merchant that is the useful property: you are not forced to upgrade on someone else's schedule, you are only forced to publish honestly.

What the file does not contain is anything about your business beyond the mechanics. There is no quality signal, no ranking input, no place to argue that your returns policy is generous. An agent that wants to know whether you are worth buying from reads the same public pages a person would, which is why a shop's visibility inside an assistant still rests on the ordinary work of being findable and consistent rather than on registering with a protocol.

The part that will not change

Protocols will. There are already several competing for the same job, and the transport list in the specification is itself an admission that the question is open. What survives every version of this is the catalogue: a price a machine cannot misread, a stock figure attached to the thing being sold, a policy page written in sentences. The shops that were already careful about how their product data holds up now that AI product discovery went daily will find the protocol work is a weekend. The shops that were not will find it is a rebuild.

The conference is over and the template is public. The useful response is not to adopt anything. It is to open your own product feed, pick your worst selling variant, and see whether a stranger could tell from the data alone what it costs and whether it exists.