What an Agent-Ready Catalog Actually Requires (And What It Doesn't)
In the last piece, Brand B lost a sale it never knew it was competing for.
Same shoe, same price, same availability as Brand A — but one missing size field meant an AI shopping agent never considered it. Not a bad product. An invisible one. Here's that same record, fixed:
Brand B — product record, after
Nothing about the shoe changed. What changed is that the data describing it became something an agent could actually parse. That's the whole problem, and it's a solvable one — but "agent-ready" gets thrown around loosely, so it's worth being precise about what it actually takes, and just as important, what it doesn't.
The four things that have to happen
Strip away the vendor-specific detail and every credible approach to this does the same four things, in the same order.
Start from what you have
PIM export, product images, ERP price and inventory. Not a replatform — you're pulling from systems you already run.
Make it agree with itself
Category rules, naming conventions, and attribute standards that drifted apart across systems get reconciled into one source of truth.
Fill gaps, carefully
Missing attributes get enriched and confidence-scored. Anything uncertain routes to a person before it ships — never auto-published.
Publish how agents read
Schema.org markup, structured for protocols like UCP and ACP — visible to ChatGPT, Google's AI Mode, and your own shopping agent.
The pattern behind every credible agent-readiness build.
To make stage three concrete: if a system can't find an explicit size field but infers one from a near-identical sibling SKU, that's a low-confidence guess — worth flagging for a person, not shipping live. A size pulled directly from the ERP inventory feed is a different case: directly sourced, high confidence, safe to publish. The job of this layer is knowing the difference and acting on it consistently, not guessing with false confidence and hoping nobody checks.
Propose, not auto-publish. No system should quietly rewrite your product data and push it live unsupervised.
Retail leaders are, correctly, wary of AI systems that "fix" data without a person checking the fix. The right architecture treats AI-generated enrichment as a draft, not a publish button.
We typically run Data Cloud to unify the data, Agentforce to run the decide-and-act layer, and Commerce Cloud to publish the resulting feed. The pattern holds regardless of stack — this is just the tooling we reach for most often.
The attributes agents actually check
Not every field matters equally. In practice, a small set of attributes accounts for most qualify/disqualify decisions:
- GTIN / UPC — the identifier that lets an agent match your product to a search intent at all
- Variant attributes — size, color, fit, material, sold separately from the parent product
- Category taxonomy — mapped to how shoppers actually search, not just your internal merchandising hierarchy
- Real-time availability — in stock, out of stock, expected restock date
- Price, including current promotions — agents compare this first
- Shipping and delivery window — a stated "ships in 2 days" beats an unstated default every time
- Return policy terms — increasingly used as a trust signal in agent comparisons
- Certifications or claims relevant to the category — sustainability, safety, materials, where they apply
Aim for complete, structured values across this set before worrying about anything else. It's a shorter list than most teams expect — you don't need to fix everything, you need to fix the right things first.
What the output actually looks like
Abstractions aside, here's the fixed Brand B record from earlier, expressed the way an agent actually reads it — standard schema.org markup, nothing proprietary about the format itself:
{
"@context": "https://schema.org/",
"@type": "Product",
"name": "TrailGuard Stability Runner",
"sku": "BB-1084-10",
"gtin13": "0012345678905",
"size": "10",
"category": "Running Shoes > Stability",
"offers": {
"@type": "Offer",
"price": "108.00",
"priceCurrency": "USD",
"availability": "https://schema.org/InStock",
"shippingDetails": {
"@type": "OfferShippingDetails",
"transitTime": "2 days"
}
}
}
This is the difference between a product existing in your PIM and a product existing for an agent. The format is public and well documented. What most brands are missing isn't knowledge of the standard — it's the operational discipline to get every SKU into it consistently, at scale, without a person hand-authoring each one.
What this doesn't require
The bigger objection usually isn't "does this work" — it's "how much does this cost me to find out." Worth being direct about what's not on the list:
- You don't need to replatform your commerce stack. This sits on top of what you have.
- You don't need to abandon your PIM. Your internal catalog probably isn't the problem — internal cleanliness and external, agent-readable structure are two different things, and only one has been a priority until now.
- You don't need to hand checkout to a third party. Given how unsettled full agentic checkout still is, the defensible win right now is discoverability, not rebuilding payments around a protocol that's still stabilizing.
- You don't need a multi-year program to start. An audit of your highest-traffic categories shows, within days, how much of your catalog is agent-readable today and where the gaps concentrate.
A five-minute self-check
Before booking anything, you can get a rough read on where you stand:
- 1Can you say, right now, what percentage of your SKUs have complete GTIN, size, and availability data in your public feed — not just your internal PIM?
- 2If a system inferred a missing attribute today, would it publish automatically, or would a person see it first?
- 3Is your product data marked up in schema.org today, and has anyone actually validated that it works?
- 4Does your analytics separate AI-assistant referral traffic from search traffic, or is it still bucketed together?
- 5If a competitor's product got recommended over yours by ChatGPT tomorrow, would you know why?
Three or more honest "no"s means the gap is real and worth quantifying properly — which is exactly what an audit does.
Where this actually starts — or where it seems to
Everything above is real, and it's worth doing regardless of what comes next. But there's a quiet assumption sitting underneath the whole framework, and it's worth naming before going any further: this chapter has been describing how to get through one door — the ChatGPT/Google gateway door, the one built on feeds and schema.org and UCP.
It turns out there isn't just one door.
While this series was being written, Amazon rolled out a shopping agent that explicitly skips every open standard described above. Anthropic released an entirely different model — not a gateway to get chosen by, but an agent you build and own yourself, embedded in your own site. Walmart is running both a first-party agent and a presence in ChatGPT and Gemini, on purpose, at the same time.
Fix your feed, and you've made yourself eligible for one house's rules. You haven't yet asked whose house is actually worth building in.
REFERENCES