Blog · Agents and commerce

Agentic commerce: what an agent needs from your catalogue

Published 24 August 2026 · Updated 12 October 2026 · 8 min read

Agentic commerce: what an agent needs from your catalogue
Photograph: Lance Chang / unsplash

The short answer: OpenAI's Agentic Commerce product feed specification asks for one machine-readable record per sellable variant, carrying a stable id, title, description, link, brand, seller name, image, price and a stock state. Under that specification the product page is secondary. A row with a missing or unrecognised required value is rejected by the spec's own rules, and where the row and the page disagree, the spec says neither representation reconciles the conflict for you. What a surface then does with that merchant is not documented anywhere we can read, and we cannot observe it from outside.

That is the whole shift, and it is smaller and more mechanical than the word agentic suggests.

The catalogue stopped being a page and became a contract

Until recently, a shopping assistant had one route into your inventory. It read your HTML, or it read somebody else's copy of your HTML, and it guessed. Price drifted. Stock was fiction. A filter like "under 500 dollars, in stock, delivered by Friday" could not be satisfied honestly, so the assistant satisfied it dishonestly.

The protocols now being published close that route by opening a better one. OpenAI's Agentic Commerce Protocol has three separable parts: a product feed, a checkout specification merchants implement, and a delegated payment specification that payment providers implement. Only the first part is about your catalogue. It is also the part you can finish without touching your payment stack, which is why it is the sensible place to start.

Treat the feed as a contract rather than a marketing asset. Everything in it is a claim an agent will act on, at a moment when no human is looking at your site. What an agent-readable page looks like covers the page side of this. The feed side has its own rules.

Nine required fields, and the two that actually decide

The Agentic Commerce product feed spec marks nine fields as required for every row: item_id, title, description, url, brand, seller_name, image_url, availability and price. Most of these already sit in a merchant database somewhere, so the work is usually export rather than authoring.

Two carry disproportionate weight.

availability is an enumeration, not free text. The permitted values are in_stock, out_of_stock, pre_order, backorder and unknown, and the spec says an omitted, empty or unrecognised value rejects the row. That last value is the interesting one. It exists so you can be honest when your stock service is down, and the spec states plainly that unknown does not assert the item is in stock. Mapping every ambiguous SKU to unknown because it is safest in a code review is therefore a weaker claim than it looks. Whether a surface skips those rows when someone asks to buy today is not documented, and we have no way to measure it.

item_id has to be stable and unique per variant. The spec asks for an ID that is stable, unique per item or variant, and never reused for a different item. Stable means it survives a replatform, a re-export and a merchandiser renaming a colour. Shops that key the id on a row number, a slug or a title hash regenerate the entire catalogue as new items every time anything upstream shifts. What a surface loses when the ids churn is not something the spec describes or that we can see.

Identifiers deserve a word too. gtin is optional, but the spec is strict about its shape: exactly 8, 12, 13 or 14 digits, with a valid check digit. The spec asks you to preserve leading zeros and send no spaces or dashes, so a GTIN carried as a spreadsheet number loses its leading zero and fails the shape rule. Export the column as text, then verify the check digit before you ship.

The variant problem is where most catalogues break

A human reads one page for a shoe and picks a size from a dropdown. An agent cannot do that, because the price, the stock state and sometimes the image differ per size, and it is buying one of them.

The spec is explicit. Send a separate row for each selection, each with its own item_id, all sharing a group_id, with listing_has_variations set true and a variant_dict describing the chosen options. Keep the top-level attributes consistent with the matching entries inside variant_dict, because, in the spec's own framing, neither representation reconciles a conflict for you.

In the export files we have opened during audits, the failures take one of two shapes. Either a single parent row carries a "from" price, in which case the only price in the feed is one nobody can buy at, or child rows carry a top-level price copied from the parent while variant_dict holds the real one. We have not counted how often each shape occurs, and the spec does not say what a surface does with either.

Variant hygiene is unglamorous and it is the cheapest win in this entire area. Product feeds for AI shopping surfaces goes further into the export mechanics.

Two flags you may not have set

Eligibility is controlled separately from content. In the feed spec, is_eligible_search and is_eligible_checkout are distinct flags: search defaults to enabled, checkout defaults to disabled, and setting search to false overrides the checkout flag. The spec also notes that checkout needs a separately enabled integration, so setting the flag does not by itself complete checkout onboarding.

Read that twice if you own a catalogue. A perfectly valid feed, delivered on schedule, can be discoverable while being unbuyable, because the checkout flag was never flipped and nobody noticed. It is a one-line default, not a bug, and it is invisible from the outside.

The flags also give you a legitimate suppression tool. Restricted goods, made-to-order items, products whose claims need legal sign-off before an agent can repeat them: all of these are better excluded explicitly than left to be discovered awkwardly. If your category lives under that kind of review, AEO when every claim needs approval sets out how to keep the approved wording and the feed in step.

Honest limits

Almost everything above is read off one engine's published specification, OpenAI's, checked on 12 October 2026. Other shopping surfaces may want different fields or different defaults, and we have not found comparable public specs for them, so do not read any of this as an industry rule.

We cannot tell you how these surfaces weight merchant quality against price, because none of the published specifications describe ranking at all. Claims that reviews, return rates or fulfilment history drive agent selection, including any you may read from us, are guesses rather than documented behaviour.

We also cannot tell you how often a feed must be refreshed. The spec asks for the current price and tells you to update the feed when a sale starts or ends, without naming an interval or a staleness limit. Nightly exports are the common default in the platforms we have worked on, which is plainly insufficient for flash pricing, but we have no measurement of what a surface tolerates.

The mismatch pattern described above, and the two variant failure shapes, come from catalogues we happened to audit. They are a small, self-selected sample with no recorded counts, not a census of ecommerce. Attribution is the last gap: an agent-mediated purchase arrives with thin referrer data, and the merchants we have worked with have not been able to separate it from direct traffic with confidence.

FAQ

Do I need a feed if my structured data is already correct? For visibility in general answers, good markup goes a long way. For a surface that executes a purchase, a feed is how price and stock arrive with enough freshness to be acted on. The two are complementary, and keeping them consistent is the real job.

Which catalogue mistakes come up most in our own audits? Unstable item_id values, and variant rows whose top-level price contradicts the options inside them. That is what we have run into, across a small number of catalogues, rather than a ranked industry statistic. Both are export problems rather than content problems, which may be why marketing teams rarely catch them.

Should I block shopping agents instead? That is a commercial decision, and it removes you from whatever purchases those systems make. Exclude specific items with the eligibility flags if the concern is a category rather than the channel.

How do I know my products are eligible to be bought? Check the two eligibility flags in your own export rather than assuming the defaults. Search is on by default, checkout is not, and nothing external will tell you which state you are in.

Sources

All four were opened and checked against the sentences that cite them on 12 October 2026.

Structured data

``json { "@context": "https://schema.org", "@graph": [ { "@type": "Article", "@id": "https://citrel.ai/blog/agentic-commerce-and-your-catalogue.html#article", "headline": "Agentic commerce: what an agent needs from your catalogue", "description": "OpenAI's agentic commerce feed spec has a shopping agent buy from a structured record, not from your product page. The fields it requires, the variant and eligibility mistakes it warns about, and a mismatch check you can run.", "datePublished": "2026-08-24", "dateModified": "2026-10-12", "inLanguage": "en", "author": { "@type": "Organization", "name": "Citrel AI", "url": "https://citrel.ai" }, "publisher": { "@type": "Organization", "name": "Citrel AI", "url": "https://citrel.ai" }, "mainEntityOfPage": "https://citrel.ai/blog/agentic-commerce-and-your-catalogue.html" }, { "@type": "FAQPage", "@id": "https://citrel.ai/blog/agentic-commerce-and-your-catalogue.html#faq", "mainEntity": [ { "@type": "Question", "name": "Do I need a feed if my structured data is already correct?", "acceptedAnswer": { "@type": "Answer", "text": "For visibility in general answers, good markup goes a long way. For a surface that executes a purchase, a feed is how price and stock arrive with enough freshness to be acted on. The two are complementary, and keeping them consistent is the real job." } }, { "@type": "Question", "name": "Which catalogue mistakes come up most in our own audits?", "acceptedAnswer": { "@type": "Answer", "text": "Unstable item_id values, and variant rows whose top-level price contradicts the options inside them. That is what we have run into, across a small number of catalogues, rather than a ranked industry statistic. Both are export problems rather than content problems, which may be why marketing teams rarely catch them." } }, { "@type": "Question", "name": "Should I block shopping agents instead?", "acceptedAnswer": { "@type": "Answer", "text": "That is a commercial decision, and it removes you from whatever purchases those systems make. Exclude specific items with the eligibility flags if the concern is a category rather than the channel." } }, { "@type": "Question", "name": "How do I know my products are eligible to be bought?", "acceptedAnswer": { "@type": "Answer", "text": "Check the two eligibility flags in your own export rather than assuming the defaults. Search is on by default, checkout is not, and nothing external will tell you which state you are in." } } ] } ] } ``

Related reading

Product feeds for AI shopping surfacesCan an agent book, buy or fill your formWhat an agent-readable page looks likeAEO when every claim needs approvalShopping inside ChatGPT, and what it readsStock, availability and answers that go stale