Agent-Ready Ecommerce: What I Shipped, and What Blocked Me

What agent-ready ecommerce actually means

An AI shopping agent has to clear three separate layers before it can hand you an order. Most stores are strong on the first, patchy on the second, and have never thought about the third.

The word "ready" only means something at the layer you are targeting. A store that is discoverable and parseable gets recommended. Only a transactable store gets checked out. Decide which one you are actually going for before you write a line of code — they cost wildly different amounts of work.

ACP and UCP: the two agentic commerce protocols that matter

There are two live standards, one per ecosystem. OpenAI's Agentic Commerce Protocol (ACP) powers Instant Checkout in ChatGPT. Google's Universal Commerce Protocol (UCP) landed in early 2026 and powers buying inside AI Mode and Gemini. They solve the same problem with opposite philosophies: ACP asks the merchant to expose a checkout API; UCP leans on the Merchant Center feed you probably already have.

Read that table as a build-versus-configure decision, not a loyalty test. UCP is mostly a data-quality and onboarding exercise if you already run Shopping feeds. ACP is a software project: signed headers, idempotency keys, order state machine, webhook delivery guarantees. Pick one, ship it properly, then port — the catalog work is shared, the checkout work is not.

Neither protocol asks you to abandon your own storefront. Both keep you as merchant of record, which also means both leave you holding the refund, the chargeback and the angry customer. Treat an agent as a new sales channel with the same operational obligations as a marketplace, because that is what it is.

How to get your products into ChatGPT: the feed is the gate

Everything in ChatGPT shopping starts with a product feed, and feed onboarding is currently open to approved partners rather than self-serve. The mechanics are worth knowing before you apply, because they decide how you build the export job.

• Full snapshot, at least daily. File upload over SFTP, pushed as a complete snapshot — not a delta. Keep filenames stable and overwrite them.
• Format. Parquet is preferred, ideally zstd-compressed; jsonl.gz, csv.gz and tsv.gz are also accepted. UTF-8 only.
• Sharding. Target roughly 500k items per shard and keep files under about 500MB.
• Intraday changes go through the API. The feed API handles updates between snapshots, and promotions can only be sent through the API.
• Deletion is not instant. A product you simply omit from the feed is retained for up to 14 days. To pull it faster, set is_eligible_search=false and it becomes ineligible at the next processing run.
• Validate small. Start with a sample of about 100 items that covers every required field. The common rejections are missing required fields, outdated or non-spec field names, and malformed values.
• Schema shape. Only id and variants are marked required on the product, with title, URL, description, media, availability and price carried at variant level wherever they differ.

The 14-day retention is the line I would underline. It means a sold-out or discontinued product can keep being recommended for two weeks after you delete it from your database, and the first you hear about it is a cancelled agent order. Build the export from the same source of truth as your product pages, run it on a schedule you actually monitor, and treat availability as the one field you never let drift.

The deeper point: a feed is an operational commitment, not a one-off export. If nobody on the team owns the daily job, do not apply yet.

Full field-level detail lives in OpenAI's commerce documentation for merchants, and the Google side is documented in the Universal Commerce Protocol merchant guide.

Letting agents in: robots.txt, llms.txt, markdown and Cloudflare

This is the layer everyone means when they say "agent-ready", and it is the cheapest one. Here is exactly what I implemented on a Ford parts store we build and run, and what each piece is actually for.

• Markdown content negotiation. A mixin on the product and blog detail views returns clean markdown at the same URL when the client asks for it, instead of a page wrapped in navigation, filters and scripts. Same URL, same canonical, far less noise for the parser.
• llms.txt at the root. A map of what the site contains and where the useful endpoints are. It is orientation for a model, not a catalog — more on that distinction below.
• robots.txt with explicit AI crawler rules and Content-Signal directives. Separate the agent fetching a page on behalf of a shopper from the crawler collecting training data, and answer them differently.
• A /.well-known/api-catalog Linkset endpoint. It advertises the store's APIs in a discoverable place. Every one of those APIs sits behind token auth.
• Cloudflare in front, on the free plan, with AI crawl controls on. Bot policy belongs at the edge, not in application code, and the free tier is enough to start.

Two things I would tell anyone before they copy this. First, the biggest ranking lever on that store was never markup — organic traffic comes almost entirely from people typing a part number, and the one change that moved the numbers was content quality in the wrong direction: when AI-generated product copy went up, rank and clicks fell by roughly 90%. Machine-readable formatting does not rescue thin content, in classic search or in an answer engine.

Second, llms.txt does not sell anything. It helps a model understand your site; it is not a catalog, not a feed, and no agent buys from it. It is worth having because it costs an afternoon — if you want one generated against your real sitemap, our free llms.txt generator will build it from your domain — but do not confuse shipping it with being agent-ready.

The real blocker: your store has no machine-readable stock or price

Here is where the project stopped on that parts store, and I think it stops in the same place for most small merchants.

To complete an order, an agent needs four answers programmatically, in under a second, with no human in the loop:

1. Is this exact variant in stock right now?
2. What is the final total to this address, including shipping and tax?
3. Can you accept this order payload and return an order id?
4. What happens when it is cancelled, returned or refunded, and how do you tell me?

That store answers questions one and two over chat, by a human, during business hours. It sells on something close to a drop-ship model, so stock is whatever the supplier has today. There is no stock-availability field anywhere in the system because there is no stock. The supplier catalog account has no API, so prices cannot be synced programmatically either. The site is beautifully discoverable and completely non-transactable, and no amount of llms.txt changes that.

That is not a markup problem. It is an inventory-systems problem wearing an AI costume. The honest sequence for most SMB stores is:

Saying "we are not ready for agentic checkout, we are ready for agentic discovery" is a perfectly good strategy. Pretending otherwise just produces cancelled orders and chargebacks you are the merchant of record for.

Who owns which work, by platform

Protocol support changes month to month, so check your platform's current status before building anything yourself. What does not change is the division of labour — this is the part worth planning around.

If you are on the custom row and tempted by direct ACP integration, cost it like a payments project rather than an SEO project, because that is what the certification checklist describes: sandbox logs, idempotency behaviour, error codes, rate limits, webhook delivery, IP allowlisting.

What I would do first with one week

In this order, because each step is a prerequisite for the next:

1. Fix the catalog source of truth. One queryable place where every variant has an availability state, a current price, a stable identifier (GTIN, MPN or part number) and a canonical URL. Everything else is downstream of this.
2. Get the feed right on a surface you already have. Merchant Center is the route into Google's agent surfaces anyway, so feed quality pays twice.
3. Set your crawler policy deliberately. robots.txt rules that distinguish shopping agents from training crawlers, bot controls at the edge, and llms.txt for orientation.
4. Make the transactable decision honestly. If you cannot answer stock and final price by API, do not chase checkout certification. Ship lead capture that works while you sleep instead, and revisit in a quarter.
5. Only then pick a protocol and scope it as the engineering project it is.

Steps one and four are the ones that decide whether any of this earns money. Steps two, three and five are the ones everyone starts with.

If you want the crawler, feed and markup layer handled rather than researched, that is what our AI search visibility and agent-readiness service covers — audit first, implementation priced to scope, so you find out which layer you are actually on before committing to a build.