Is your store ready for agentic commerce?

Classic search returns a list of links. A person opens several stores, compares prices, hunts for shipping costs, checks the return window and decides. Every one of those steps is a page view, and every page view is a chance to convince through design, copy and trust.

Agentic commerce moves those intermediate steps into an assistant. The user describes what they need and receives a short, already filtered selection. In the fuller version, the assistant builds the cart or completes the purchase without a store page ever appearing in a browser.

For a store this changes the entry condition. Design is no longer what gets judged first; what matters is whether software can pull the relevant facts cleanly and without contradictions from the page or from a feed. A store that does not supply those facts never enters the shortlist.

As of early 2026 two lines are taking shape. One is the Agentic Commerce Protocol, or ACP, documented by OpenAI and developed in the OpenAI and Stripe orbit. It describes a checkout inside ChatGPT, a delegated payment path for payment service providers, and a feed format for product data.

The second line is the Universal Commerce Protocol, or UCP. It presents itself as an open standard, is carried by a broad group — including Google, Shopify, Etsy, Stripe and several large retailers — and defines shared building blocks for checkout, identity linking via OAuth 2.0 and order management.

The honest answer is that committing today would be premature. Stripe appears in both camps, UCP still lists further verticals as forthcoming, and neither specification has established itself as the single standard. What you can usefully build right now is the layer both of them assume.

Both protocol lines assume the same foundation: a data set that describes a product completely without anyone looking at a page. As long as that is missing, no protocol changes anything. Product data work is therefore the investment that pays off regardless of how the standards question resolves.

The ACP feed specification makes this concrete. Required are a stable item identifier, an availability status, a price with an ISO 4217 currency code, and at least one image. Common identifiers such as GTIN and manufacturer part number are optional, but they make matching a listing to a real product far more reliable.

What goes beyond that is more interesting. Merchants who also want to sell through the feed have to supply a privacy policy and terms of service as fields. Returns are expressed through dedicated fields: whether returns are accepted, within what deadline, and where the full policy can be read.

The Model Context Protocol is an open standard for connecting AI applications to external systems. It follows a client-server pattern: a server exposes tools and data, an assistant connects to it and calls them, so no bespoke integration is needed for every combination of assistant and system.

For commerce this already exists in finished form. Shopify runs a Storefront MCP server through which an assistant can search the catalogue, request recommendations, create and modify a cart, read shipping and return policies, and check order status. The answers come from the store itself rather than from an index.

The difference to a feed is when the truth is established. A feed is a snapshot and ages between runs; an MCP endpoint answers at the moment of the question. In exchange, the assistant has to establish that connection at all, whereas a feed is read passively by more surfaces.

The first point is delivery. If product copy, price and availability sit in the HTML as served, any client can read them. If they only appear through client-side JavaScript, everything depends on whether the particular crawler renders — and many do not, or only with a delay.

The second point is access itself. robots.txt, bot protection and WAF rules decide who gets an answer at all. Blanket blocks against anything without a browser fingerprint reliably exclude the same clients that would otherwise put your products into an answer. That is a deliberate decision, not a detail.

The third point is stability and status codes. Product URLs that survive every range reshuffle are worth more than perfect titles. Discontinued items should answer with 404 or 410 rather than an empty 200 page. And response times matter directly here: anything too slow simply gets skipped.

An assistant rarely reproduces a whole page. It looks for the passage that answers one concrete question completely and takes that. Paragraphs that only make sense together with the preceding sentence drop out along the way. A paragraph that stands on its own gets used — that is the whole mechanism.

Contradictions cost more than gaps. If structured data states a different price than the visible page, or claims availability the store does not confirm, both sources lose credibility. Consistency between markup, feed and visible page matters more than the number of fields you have filled in.

On product pages this means fit, material, delivery time, care and returns belong on the page as readable text. If those details live only in lazily loaded tabs or inside an image, they do not exist for the retrieving client — and the answer then gets built from a different source.

A useful assessment is not a score but a list of blockers. Either a client reaches the facts or it does not. Values in between help nobody decide what to do next.

In practice you check every point twice: once the way a person sees the page, and once the way software without JavaScript receives it. The gap between those two views is the actual work list. Everything else follows from it.

The most common misinvestment is committing early to a protocol that is still moving. Building a full checkout in early 2026 against a specification whose surroundings may shift within months ties development time to a bet. Feed and data work, by contrast, pays off in every version of the future.

Rebuilding the store into a pure machine interface is equally unwise. The bulk of revenue still comes from people who look at a page. Agentic readiness is an additional requirement on that same page, not a replacement for design, argument and conversion work.

Finally, spend nothing on metrics that do not exist yet. Visibility inside assistants cannot be measured cleanly in early 2026 the way search positions can. Reporting built on that rests on estimates. Check the prerequisites instead — those can be established unambiguously.