How retailers win AI shopping: making your catalog agent-readable

A shopper asking ChatGPT or Google's AI Mode to find "a quiet dishwasher that fits a 24-inch opening" isn't reading your product page. An agent is parsing your feed, and if the fields it needs aren't there in a structured, unambiguous form, your product simply doesn't surface. That's the new gate retailers are being run through, and most catalogs were built for a search box, not a reasoning model.

What "agent-readable" actually means

Agent-readable is not the same as SEO-friendly. A page can rank well in Google Search and still be useless to an AI shopping agent, because agents don't skim prose, they extract fields. OpenAI's Agentic Commerce Protocol spells this out directly: a product needs a stable item_id, a plain-text title under 150 characters, a description up to 5,000 characters, brand, price with an ISO 4217 currency code, an availability enum (in_stock, out_of_stock, pre_order, backorder, unknown), and seller identity fields before it's even eligible to appear in ChatGPT search, per OpenAI's product feed spec. Google's parallel push, its Universal Commerce Protocol reaching AI Mode and Gemini, runs on the same logic: structured, current, unambiguous data or you're invisible, as detailed in this rundown of Google Merchant Center setup for AI Mode.

The mechanism is straightforward. An agent doesn't "read" your catalog the way a shopper skims a page. It maps a query to structured attributes, then ranks candidates by how confidently it can match those attributes. Incomplete data doesn't get partial credit, it gets excluded, because rewarx's analysis of structured data for AI shopping agents notes that AI engines weigh dimensions, materials, compatibility, and variant accuracy together, and a gap in any one weakens the match enough to drop the product out of consideration.

Two different gaps, one outcome

Retailers tend to conflate two distinct problems:

The attribute gap. Missing or inconsistent structured fields: no material spec, no compatibility list, size expressed as "M" in one system and "Medium" in another, no GTIN to disambiguate variants. OpenAI's spec recommends 25+ structured attributes beyond the required minimum specifically because sparse feeds can't support conversational filtering the way a shopper actually asks ("compatible with a 2019 F-150," "BPA-free," "under 15 lbs").

The context gap. Even complete attributes don't answer "why would I buy this." Use cases, care instructions, comparative framing, the kind of narrative context a human sales associate would supply. Agents increasingly weigh this alongside raw specs, per Optidan's guide to how AI search engines interpret product feeds, which points out that products missing use-case and situational detail get statistically discounted even when their core specs are technically present.

Both gaps compound. A product with full dimensions but no stated use case reads as generic. A product with rich marketing copy but no structured material or compatibility field reads as unverifiable. Agents need both, and most PIMs were populated for humans skimming a page, not for a model extracting fields.

Before and after: a real gap, closed

Here's a raw supplier feed line for a cordless drill, next to what an agent actually needs:

Raw feed description: "DeWalt 20V drill, great for home projects, powerful motor, comes with battery."

Enriched attribute table:

The raw line is fine for a human skimming a shelf tag. It fails an agent trying to answer "will this drill work with the batteries I already own" or "is this heavy enough for a pro but light enough for my spouse to use," because neither compatibility nor weight is stated as a discrete, extractable value.

Ask an answer engine

Try this: ask ChatGPT or Google AI Mode "what's a lightweight cordless drill under $150 that's compatible with DeWalt 20V batteries." A model can only answer with a specific SKU if weight, price, and battery compatibility exist as clean fields somewhere in the feed it's reading. If your catalog only has "powerful motor, great for home projects" sitting in a description blob, the agent has nothing to extract, and it recommends a competitor's listing instead, one that happens to state 20V MAX battery platform explicitly.

Why this is a maintenance problem, not a one-time project

Feeds for agentic commerce are expected to refresh often, Lengow's ChatGPT product feed guide cites update cycles as frequent as every 15 minutes for price and stock accuracy. That cadence rules out a one-time cleanup. New SKUs arrive without full spec sheets, suppliers change fields without notice, and "in stock" drifts from reality within days if nothing is monitoring it. Static enrichment projects solve the catalog you have today, not the one you'll have next quarter.

Where this connects back to enrichment

This is the actual reason attribute-level enrichment has become a distinct discipline instead of a one-time data cleanup: agent-readability isn't a launch checklist, it's a maintenance condition. Anglera continuously scores catalogs against exactly these gaps, structured attributes and situational context, extracting values from supplier and source documents (never inventing them) and gap-filling what's missing so a product is legible to a buyer and to the model standing between that buyer and your storefront. Your PIM stores the data; Anglera does the work of keeping it agent-ready, plugging into Akeneo, Salsify, inriver, or a flat file without touching how your systems are architected today.