Product Feed vs Agent-Readable Catalog: What Merchants Should Publish Now
A product feed helps listing and search surfaces understand merchandise. An agent-readable catalog helps software buyers act on merchandise. Keep the shopping feed for discovery. Then publish a catalog that exposes action URLs, policy terms, checkout routes, provenance, and current commerce state so agents can evaluate an offer without scraping your theme.
Google Shopping feeds and Merchant Center data still matter for ads, product listings, and search-style ranking. Agent-readable catalogs add the operational layer: what an agent may do, which checkout route is official, which policy applies, who operates the merchant surface, and how order evidence returns to the buyer.
Product Feed vs Agent-Readable Catalog
| Merchant question | Product feed answer | Agent-readable catalog answer |
|---|---|---|
| Where should the item appear? | Search listings, ads, shopping tabs, marketplaces, and comparison surfaces. | Agent workflows, shopping assistants, checkout agents, support agents, and partner APIs. |
| What facts are published? | Title, image, price, category, availability, shipping hints, and product URL. | Stable product IDs, variants, compatibility, policy URLs, checkout routes, allowed agent actions, and support paths. |
| Can a software buyer act? | Usually by sending a human shopper to a product detail page or hosted checkout. | By building a cart, requesting a quote, starting a machine checkout, or routing a support request under merchant rules. |
| How are policies read? | Policies may sit on separate pages or appear as lightweight merchant attributes. | Return terms, refund policy, shipping rules, warranty limits, support contacts, and escalation paths are linked from the catalog. |
| How is trust checked? | The surface relies on merchant account metadata, listing status, and platform review. | The catalog points to a public .agent identity, operator proof, source record, version, and receipt route. |
What Product Feeds Still Do Well
Product feeds are still the cleanest way to push merchandised facts into listing systems. Channels compare titles, images, prices, availability, categories, and landing pages at scale. Keep feed quality high. Agents often start on the same discovery surfaces humans use.
That feed job is expanding, not disappearing. Google's Merchant Center guide for UCP tells participating merchants to keep product data current, then add agentic checkout signals through a supplemental feed so everyday listing data stays intact. Documented signals include a native commerce checkout eligibility flag (off unless you set it), consumer notice fields for required warnings, and a merchant item id map when the feed id and checkout API id differ. Help Center pages for native commerce and UCP-powered checkout describe the same pattern.
OpenAI's Agentic Commerce product feed and Stripe's agentic commerce product feed follow a similar discovery logic: structured rows for products, price, and availability that agents can index. Useful. Still a feed. Uploading one does not, by itself, publish policy links, allowed agent actions, provenance, or a public merchant identity.
What an Agent-Readable Catalog Adds
An agent-readable catalog is the action layer on top of merchandising facts. The UCP shopping catalog specification (2026-08-25 path) describes catalog search and lookup so agents can query products, variants, prices, availability, and media, with room for policy objects on responses. That is a different job from "rank this SKU in Shopping."
The Agentic Commerce Protocol path still needs clean product data for agent checkout. Checkout configuration belongs in the catalog story: human checkout URL, machine checkout URL, session rules, and receipt routes. Protocol scope differences live in ACP vs UCP vs BMOS. This page stays on the artifact you publish.
BMOS is the merchant-facing version of that pattern: a standardized catalog feed with schema.org plus ACP- and UCP-oriented extensions, current pricing, variants, images, availability, checkout links, refund policy, terms, and agent metadata. The public BMOS agentic commerce standard documents feed v0.1 as the legacy baseline and v0.2 as the accepted enrichment shape, with a draft proposal for additive checkout actions. Pin the feed version you publish. Do not invent fields the draft has not shipped.
Fields Merchants Should Publish Now
- Canonical product ID, SKU or GTIN, normalized title, brand, description, category, media, and product URL.
- Variant structure: size, color, bundle, subscription, replacement part, compatibility, and substitution guidance.
- Current price, currency, availability, fulfillment windows, shipping options, tax handling, and stock constraints.
- Human checkout URL, machine checkout URL, cart-building route, quote route, session expiry, and receipt route.
- Return policy, refund policy, warranty terms, shipping policy, privacy terms, support contact, and escalation path.
- Allowed agent actions, blocked actions, purchase limits, buyer confirmation rules, and handoff conditions.
- Catalog version, update timestamp, source system, publisher identity, proof links, and change log.
- Public .agent identity with agent.json, SKILL.md, llms.txt, endpoint list, policy links, and operator proof.
If you sell into Google AI shopping surfaces that use UCP, add the Merchant Center supplemental attributes and account-level return and support settings those guides require. Treat that as channel prep beside the merchant-owned catalog, not a replacement for it.
Example Agent-Readable Catalog Record
Illustrative only. Hosts and IDs are examples, not a live integration.
{
"merchant": "northstar-outfitters",
"identity": {
"headless_domain": "northstar.agent",
"agent_json": "https://northstar.agent/.well-known/agent.json",
"skill_md": "https://northstar.agent/SKILL.md",
"llms_txt": "https://northstar.agent/llms.txt"
},
"catalog": {
"feed_url": "https://catalog.northstar.example/agentic-commerce.json",
"schema": "schema.org Product plus ACP and UCP extensions",
"catalog_version": "2026-09-25",
"updated_at": "2026-09-25T09:00:00Z"
},
"product": {
"id": "sku-7421",
"name": "Trail Jacket",
"variants": ["small", "medium", "large"],
"availability": "in_stock",
"price": {"amount": "84.00", "currency": "USD"}
},
"checkout": {
"human": "https://northstar.example/checkout",
"machine": "https://machine.checkout.example/northstar",
"protocols": ["ACP", "UCP"]
},
"policies": {
"returns": "https://northstar.example/returns",
"terms": "https://northstar.example/terms",
"support": "mailto:support@northstar.example"
},
"agent_actions": {
"allowed": ["compare", "quote", "cart", "checkout_request", "order_status"],
"blocked": ["auto_substitute_without_confirmation"]
}
}Where a Headless Domain Fits
Headless Domains gives the commerce surface a public identity anchor. Attach the BMOS feed (or your own catalog URL), ACP or UCP checkout routes, policy pages, proof links, endpoint list, and support routes to a .agent identity that agents can inspect through command-line and API workflows.
Catalog data tells agents what can be bought. The identity record tells agents which commerce surface is official, who operates it, which manifests are authoritative, and where payment or support evidence should return. Pair this with How to Make Your Store Discoverable to AI Shopping Agents when the question is channel discovery rather than catalog shape.
A Practical Publishing Order
- Clean the existing product feed so titles, prices, images, availability, variants, and product URLs match the live store.
- Create the agent-readable catalog with policy, checkout, provenance, and action fields.
- Expose the catalog as JSON at a stable URL and document the update cadence.
- Add channel-specific feed extensions only where you are actually onboarding (for example Merchant Center supplemental attributes for UCP, or an ACP product feed for a partner that requires one).
- Connect ACP or UCP checkout routes where the store is ready for agentic purchase flows.
- Publish agent.json, SKILL.md, and llms.txt for the merchant surface.
- Attach the catalog, policies, endpoints, and proof links to a public .agent identity.
- Test shopping prompts against discovery, cart, checkout, return, and order-status flows before inviting partners.
Related Reading
- ACP vs UCP vs BMOS
- AI Shopping Readiness Checklist
- How to Make Your Store Discoverable to AI Shopping Agents
- Agent Payments Require Identity, Authorization, and Receipts
- The Agent Identity Stack
FAQ
Is a product feed still worth publishing?
Yes. Product feeds remain useful for listing surfaces, ads, search systems, marketplaces, and first-pass discovery. The agent-readable catalog extends that foundation into action, checkout, policy, and identity. Skip the feed and you make discovery harder. Publish only the feed and agents still guess at policies and checkout rules.
What is an agent-readable catalog?
An agent-readable catalog is a machine-readable product and commerce record that lets software buyers inspect products, policies, checkout options, provenance, and allowed actions without scraping a visual storefront.
How is this different from schema.org Product markup?
Product markup helps search and structured-data consumers understand a page. An agent-readable catalog can include the same product facts plus cart routes, checkout links, refund terms, support paths, identity records, and protocol metadata.
Is an ACP or OpenAI product feed the same thing?
No. Those feeds help agents discover and index merchandise for a given channel. They are still feeds. An agent-readable catalog is the merchant-owned action record: policies, allowed actions, checkout routes, provenance, and identity pointers you maintain for any agent that can fetch them.
Where do ACP and UCP fit?
ACP focuses on agent-ready checkout flows between buyers, agents, and businesses. UCP defines a broader commerce language across discovery, cart, checkout, identity linking, order management, and post-purchase support. Use the triad guide for protocol roles. Use this page to decide which catalog artifacts to publish.
How does a .agent identity help merchants?
A .agent identity gives agents one public place to inspect the merchant operator, catalog URL, policy URLs, checkout endpoints, manifests, proof links, and support routes before they recommend or buy.
What should merchants publish first?
Start with one publishable unit: clean the shopping feed, expose the agent-readable catalog as machine-readable JSON, link the checkout routes you actually support, and attach the commerce surface to a public .agent identity on HeadlessDomains.com. Then agents can inspect product facts, policy, checkout, and provenance before a recommendation or purchase.