What makes a product feed readable to an AI shopping agent?
A human shopper forgives a lot. They read a price rendered as an image, infer that "2 left in stock" means low availability, and guess that the small grey text under the button is the shipping estimate. An autonomous shopping agent forgives nothing. It does not see your layout. It parses data, and it acts only on values it can locate, type, and trust.
So an agent-readable feed is not a prettier product page. It is the same catalogue expressed as structured, machine-verifiable data. Each product carries a stable identifier, a typed price with an explicit currency, a machine-readable availability state, variant identifiers, and shipping terms that resolve to values rather than prose. The agent can then answer three questions without guessing: what is this exactly, can I buy it right now, and at what total cost.
If any of those answers lives only in rendered HTML, marketing copy, or an image, it does not exist for the agent. This is the practical gap most stores discover the moment an agent tries to transact. The store looks complete to a person and blank to a machine. We wrote about the symptoms in 12 signs your product data is invisible.
How is an agent feed different from a Google Shopping feed?
Many teams assume they already have this covered because they run a Google Shopping feed. A marketing feed and an agent feed overlap, but they are built for different readers and different jobs.
A marketing feed, such as the one defined by the Google Merchant Center product data specification, exists to place an ad or a listing in front of a human. Its job ends when the person clicks through to your site. Freshness tolerances are generous, a daily crawl is normal, and small gaps are absorbed by the human who lands on the page and finishes the decision themselves.
An agent feed exists to let software complete the decision. There is no human on the other end to reconcile a stale price or interpret an ambiguous variant. That changes the requirements in three concrete ways. Availability and price must be current at request time, not from last night's export. Every variant must be individually addressable, because the agent buys one specific SKU, not a product family. And the feed must be queryable, so the agent can ask about one product or filter a set, rather than downloading a whole catalogue file to find one row.
The table below sets the two readers side by side.
| Field or property | Human product page | Agent-ready feed |
|---|---|---|
| Price | Rendered text or image, sometimes assembled by script | Typed number plus explicit currency code (ISO 4217) |
| Availability | Words like "in stock" or "only a few left" | Enumerated state (InStock, OutOfStock, PreOrder) plus quantity |
| Product identity | Implied by URL and page title | Stable product ID plus GTIN or MPN where they exist |
| Variants | Selected by dropdown, one shared URL | Each variant its own ID, price, and stock |
| Shipping and tax | Estimated at checkout, often after login | Machine-readable cost, region, and delivery window |
| Access | HTML for a browser to render | Structured data plus an API an agent can query |
| Freshness | Whatever the page happens to show | Current at request time |
What does structured product data look like for an agent?
The shared vocabulary for this is schema.org Product paired with Offer. It is the same standard search engines already understand, which is why it is a low-risk place to start: you are not inventing a format, you are completing one you probably already emit partially.
The point of Offer is that it carries the commercial facts as typed fields rather than prose. Price is a number. The currency is a separate, explicit code. Availability is one of a fixed set of values, not free text. Here is a small, correct JSON-LD example for a single variant.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Merino Crew Sweater",
"sku": "SW-MER-CRW-NVY-M",
"gtin13": "0123456789012",
"brand": { "@type": "Brand", "name": "Northfell" },
"offers": {
"@type": "Offer",
"price": "89.00",
"priceCurrency": "EUR",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition",
"url": "https://store.example.com/p/merino-crew?variant=navy-m"
}
}Two things matter more than the syntax. First, emit this per purchasable variant, not once per product family, so the navy medium and the grey large are distinct offers with their own price and stock. Second, the availability value has to reflect real inventory at the moment it is read. A hard-coded InStock that never changes is worse than no data, because it invites an agent to attempt a purchase you cannot fulfil.
Why do stable product and variant identifiers matter?
An agent may see your product today, compare it tomorrow, and buy it next week. If the identifier it recorded no longer resolves to the same item, the transaction breaks or, worse, resolves to the wrong thing. Stable identity is what lets an agent build a reliable reference to something in your catalogue.
In practice that means a durable internal product and variant ID that does not change when you re-slug a URL or restructure a collection, plus a standard external identifier where one exists: a GTIN for manufactured goods, an MPN otherwise. The external identifier lets an agent recognise that your listing and another seller's listing are the same physical product, which is exactly the comparison an autonomous shopper is built to make. If your only identifier is a URL that changes with every merchandising tweak, you are invisible across time even when you are visible today.
How should stock and shipping be exposed?
Availability and total cost are where human-only stores fail an agent most often, because both are traditionally resolved late and behind interaction. A person clicks add to cart, proceeds to checkout, maybe logs in, and only then sees the shipping cost and the real delivery date. An agent needs those facts before it commits, expressed as values.
For stock, that means an enumerated state plus a quantity where you can share it, updated in near real time rather than cached from an overnight job. For shipping, it means the cost, the destination region, and a delivery window that an agent can read and factor into a total. The goal is that the agent can compute the full landed price and the expected arrival before it decides, without simulating a checkout or scraping a confirmation screen. When those numbers are only discoverable by walking your funnel, the agent either abandons or transacts on incomplete information, and neither outcome is one you want.
What is an MCP server for ecommerce, and how does it relate to ACP checkout?
Structured data on your pages makes your catalogue legible. An agent still needs a way to query it and to act. That is the job of a thin interface layer, and the emerging standard for it is the Model Context Protocol (MCP), an open standard for connecting AI models to external tools and data.
An MCP server for ecommerce is a small service that sits over your existing store API and exposes a defined set of operations an agent can call: search the catalogue, fetch a product with its live offer, check availability, start a cart. You are not rebuilding your store. You are publishing a machine-facing door onto the data and actions it already has, described in a way agents discover and use consistently.
Reading a catalogue is only half of a purchase. The other half is completing the transaction safely, and that is what the Agentic Commerce Protocol (ACP) addresses: a shared shape for how an agent proposes and confirms a checkout with a merchant. Aligning the MCP interface with the ACP checkout flow keeps the two halves consistent, so discovery and purchase speak the same language rather than being stitched together per integration.
None of this should mean handing an agent an open wallet. A production interface needs guardrails at the boundary: a spend cap so no single order or session can exceed a limit, an approval gate for actions above a threshold, and an audited mandate that records what the agent was authorised to do and what it actually did. Legibility and safety are the same project.
How does this map onto Shopify, Shopware, or a custom stack?
The reassuring part is that almost none of this requires rebuilding the store. The catalogue, the inventory, and the pricing logic already exist. What is usually missing is the clean expression of them and the machine-facing door.
On Shopify, product and variant identity and inventory already live in the platform, reachable through the Storefront API, and many themes emit partial Product JSON-LD already. The work is completing the structured data per variant, ensuring availability reflects live inventory, and placing an MCP layer over the API. On Shopware, the same pattern holds against its store API. On a custom stack, you already own an API; the feed and the MCP server are a thin adapter over it rather than a migration.
This is precisely the shape of work Saturnia Labs does. We expose your existing catalogue as a clean, agent-ready feed, put a thin MCP server over your store API aligned with ACP, and add the guardrails: spend cap, approval gate, and an audited mandate. It is built on Anthropic's open commerce-agents blueprint, and we are a member of the Claude Partner Network. The starting point is knowing where you stand today. You can see that in a few minutes with the free scan, and read more about the wider picture in our guide to agentic commerce readiness.
The stores that win the next phase of ecommerce will not be the ones with the prettiest product pages. They will be the ones a machine can read, verify, and trust enough to buy from.