What an AI agent sees when it comes to buy in your store

An AI agent arriving to buy in your store usually receives this much: a product name, one amount, a word about availability and an image. To finish the order it also needs a stable identifier, a price carrying its currency and tax status, availability with a timestamp, and explicit delivery and return terms. This piece is about reading your own product the way a machine reads it, field by field, and about the standards decision that lands on your desk as a result. It assumes you know what an agent purchase is; if not, start with preparing your store for agentic commerce.

Input: a record, not a product page

Open your best selling product and cover everything except the text. Photography, layout, review stars, the discount banner, the buy button: none of that is input for an agent. The input is a set of key and value pairs pulled from your feed, your structured data or your API, plus whatever survives being scraped from HTML. When the price in that set reads "from 39", the selling unit is absent and availability says "only a few left", the agent holds a description of mood and no transaction parameters.

Test it on your own catalog rather than taking my word for it.

Field by field: where the purchase breaks

Seven fields, ordered by when an agent actually needs them. For each one: what the agent does with it, and what stops being possible when it is missing. Walk the table with one real product open beside you, ideally one with variants and a minimum order quantity.

The order of fields follows the four steps Shopify documents for agents: negotiate and authenticate, discover products, build carts and convert to checkout, monitor orders (shopify.dev/docs/agents, checked 2026-08-19). The field list itself is our operational checklist and is not a requirement of any protocol.

Two rows look like housekeeping and decide the most. Selling unit and multiple determine whether an agent order flows into your normal process or into the exceptions queue that somebody clears by hand. Return terms decide something even less visible: an agent holding a condition from its customer drops the offers where it cannot confirm that condition. Silence in your data functions as a refusal, even when your actual returns policy is more generous than your competitors offer. For the schema.org side of these facts, see our piece on structured data for AI.

Three silent failures, worse than an empty field

A missing field announces itself. The three cases below never reach a report, because the data is formally present and quietly wrong.

The feed says one thing, the page says another

An agent rarely reads a single source. Price comes from the feed pulled overnight, attributes from structured data, shipping from an API, the rest from HTML. When those sources drift apart, the agent sees no conflict, because nothing tells it to distrust itself. It simply keeps the value it received first and presents that to the customer as your offer. The mismatch surfaces at payment, at the worst possible moment, and looks to the buyer like your mistake, which is what it is.

A measurement you can run today: take 200 random SKUs, pull price, availability, selling unit and delivery cost in parallel from the feed and from the page, then count the rows where all four agree across both sources. That share is your practical ceiling on orders an agent can close without a surprise. I know of no public benchmark for this ratio and will not pretend otherwise; the number earns its value inside your own monthly time series.

Stock levels from last night

Availability ages faster than any other field in a catalog. A feed refreshed once a day means that during your busiest hours an agent decides on data from many hours earlier, and on thin-stock items that gap separates a sale from a cancellation. Check two things: how often the stock number refreshes in the source agents actually read, and whether your checkout revalidates stock at the moment the order is placed.

When the second answer is no, the first one stops mattering.

A price that exists only in context

This is the interesting one, because it mostly bites well run stores. Contract pricing behind a login, cart-level discounts, free shipping thresholds, bundle promotions, a tax rate that depends on the destination country: an agent working without a customer session holds none of that context.

It sees your list price and builds its comparison on that alone. In wholesale the effect inverts your intent, because the real offer for a returning buyer beats the one the agent quoted, and you lose the comparison to your own shelf price. Exposing a price list behind agent authentication fixes it, once you decide who that agent is allowed to be.

Protocol contest, read from the merchant seat

There is an open argument about how an agent talks to a store, and the companies on each side want different things. Below is what I could confirm at source on 19 August 2026, with no adoption figures, because nobody publishes them.

Sources for columns 2 to 4: agenticcommerce.dev, developers.google.com/merchant/ucp with the developers.googleblog.com post on UCP internals, and shopify.dev/docs/agents. All checked 2026-08-19. I do not name Shopify trust tiers here, because the documentation I read does not list their names.

One difference worth carrying into a legal review: ACP names its licence outright, while the UCP pages I checked describe an open, community-driven standard without naming a licence. A second difference shows up when you read them side by side. ACP concentrates on the transaction layer and deliberately leaves product data alone, whereas UCP reaches straight for the Merchant Center feed you already maintain. That combination works in your favour, since the shared part of the job is your data and the divergent part is a checkout adapter.

Some of this decision already belongs to your platform

Honestly, you have less room here than the word decision suggests. On closed SaaS your vendor picks the protocol and you learn about it from a changelog. Shopify has documented an agent flow on top of UCP, and that is the answer for every store on Shopify whether the merchant likes it or not. The trust tier that decides whether an agent only browses or completes a checkout is assigned by the platform to the agent, with no merchant in the loop.

Your leverage sits one layer down: in the quality of the data your platform exposes, and in whether your prices and stock can be read programmatically. That makes the arithmetic simpler than it looks. A platform choice turns out to be a protocol choice, so keep the question on the list when you choose the platform, rather than discovering it a year later.

Standard-agnostic work, which is why it goes first

The three items below pay off under ACP, under UCP and under whatever wins next. You do them once and they stop being strategy, becoming instead the foundation any adapter can sit on.

• One record per product. Identifier, selling unit, multiple and variant attributes live in one place, and feeds, pages and APIs read from it instead of keeping private copies with their own life cycles.
• One source of truth for price and stock. The amount in the feed, the amount on the page and the amount in the cart come from the same query. Customer, agent and warehouse then see the same number at the same hour.
• Return rules stored as data. Window in days, who pays for the parcel, exceptions per category. A policy page settles a legal dispute; a field settles the condition a customer gave an agent.

The cheapest home for all three is the layer that already generates your feeds, which is why we treat feed automation as work one level deeper than mapping columns per channel. We build platforms on the BEAM framework, where this data has a single home and keeping it fresh belongs to the Maintenance and Growth stage.

Small catalog and marketplace-only sales: the choice is not yours

A section for readers this article should not put to work. With a few dozen products, no variants, one tax rate, one shipping country and sales running entirely through Amazon, Allegro or Kaufland, your product data already lives in a format the marketplace dictates and the operator owns the checkout. The protocol decision is theirs, and your best investment stays the quality of the listings themselves.

If you run a store and channels together, first check whether your marketplace feed and your product page quote the same price and the same stock today, because that test costs an hour and settles whether protocols deserve any of your attention.

The threshold where this stops being theory is fairly concrete: direct sales large enough that a cancelled order hurts, plus variants, order minimums or contract pricing in play. At that point your data layer has become a sales layer.

One afternoon of diagnosis

The order I recommend: pull the feed and the page for two hundred SKUs, count agreement across the four fields, measure how old your availability data is, check whether checkout revalidates stock, and read the protocol specifications last. The first four steps run on your own data, and their result tells you whether the standards decision is even your most urgent problem this quarter. For the wider view of what happens to traffic when buying decisions move off your site, see our piece on GEO for eCommerce.

You can swap a protocol in a quarter. Messy product data outlives several of them.

Sources and date checked

All four addresses checked on 19 August 2026. Claims I could not find there are flagged in the text as unconfirmed.

• Agentic Commerce Protocol: agenticcommerce.dev (authorship by Stripe and OpenAI, Apache 2.0 licence, REST and MCP compatibility, Shared Payment Token, discovery mechanism in progress).
• Universal Commerce Protocol: developers.google.com/merchant/ucp (Merchant Center feed, native or embedded checkout, interoperability with AP2, A2A and MCP, expansion into new industries).
• UCP under the hood: developers.googleblog.com, post dated 11 January 2026 (announcement, partners, manifest at /.well-known/ucp, capability profiles).
• Shopify agent flow: shopify.dev/docs/agents (the four flow steps, trust tiers and access scope, catalogs, MCP tools for cart, checkout and orders).