WHO OWNS THE FRONT DOOR? / 02

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

price: $108
size: 10, in stock
category: stability running
availability: ships in 2 days
Matched → shown to shopper

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.

01 — SOURCES

Start from what you have

PIM export, product images, ERP price and inventory. Not a replatform — you're pulling from systems you already run.

02 — UNIFY

Make it agree with itself

Category rules, naming conventions, and attribute standards that drifted apart across systems get reconciled into one source of truth.

03 — DECIDE & ACT

Fill gaps, carefully

Missing attributes get enriched and confidence-scored. Anything uncertain routes to a person before it ships — never auto-published.

04 — OUTPUT

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.

How we build this

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:

product-feed.json
{
  "@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:

  1. 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?
  2. 2If a system inferred a missing attribute today, would it publish automatically, or would a person see it first?
  3. 3Is your product data marked up in schema.org today, and has anyone actually validated that it works?
  4. 4Does your analytics separate AI-assistant referral traffic from search traffic, or is it still bucketed together?
  5. 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
Part 2 of 5 — Who Owns the Front Door? Next: the five different bets on who reaches your customer first