Compatibility Data: The Attributes AI Agents Rely On Most

Every catalog audit we run finds the same hole. Materials are half-covered, dimensions live in prose — but compatibility, the record of what a product works with, fits, or is built for, is usually not thin. It's absent. And it's the attribute family AI shopping agents lean on hardest, because it's the one shoppers ask about most the moment they hand a purchase to an agent.

This article goes deep on the gap we flagged in the catalog enrichment playbook: what compatibility data is, why constraint queries dominate agent conversations, where the data already exists inside your business, and how to model it so agents can actually use it.

What is compatibility data in ecommerce?

Compatibility data is the structured record of relationships between your product and things outside it: other products, device models, standards, sizes, environments, and use cases. "Works with Sony E-mount bodies." "Fits iPhone 16 Pro." "Suitable for induction cooktops." "Pairs with the matching desk shelf." Each is a fact a shopper can act on — and a fact an agent can only use if it exists as a field.

Compatibility data

Structured attributes that assert a relationship between a product and something outside it — another product, a device model, a standard, a size system, or a use case. Typical fields: works_with, fits, compatible_with, suitable_for, pairs_with, replaces.

The defining property is that compatibility is relational. Material and weight describe the product alone. Compatibility describes the product against the shopper's existing world — the phone she already owns, the machine he needs a filter for. That's what makes it simultaneously the hardest attribute data to assemble and the most valuable: it answers the question the shopper actually has, not the question your spec sheet happens to cover.

It's also why it gets skipped. A merchandiser can fill in color and material from a spec sheet in minutes. Compatibility requires knowing about other companies' products and keeping that knowledge current as new models ship. Most teams quietly defer it. That deferral was survivable when humans browsed pages and drew their own conclusions. It isn't survivable when agents filter on fields.

Why constraint queries dominate agent conversations

Watch how the same shopper uses a search box versus an agent. Into a search box they type nouns: "phone case", "water filter". To an agent — Rufus on Amazon, a Shopify Brand Agent on your own store, or ChatGPT and Perplexity off-site — they state conditions: "a case for my son's iPhone 16e that will survive a skate park", "a filter that fits the fridge in my rental", "a charger that works with both my laptop and my camera batteries".

Constraint query

A shopping request framed by conditions the answer must satisfy — a device it must fit, a system it must work with, a situation it must handle — rather than by a product category alone.

The shift isn't cosmetic. Conversation invites constraints — nobody talks to an assistant in keywords. And constraints are the whole reason to use an agent: the shopper is delegating the tedious part, which is checking whether each candidate actually fits their situation. An agent that can't check constraints is pointless, so every serious agent is built to check them — against structured data.

The upside: traffic arriving through agents is disproportionately constraint-shaped, and constraint-shaped traffic is the best traffic there is. A shopper who states "must fit a 2019 Weber Genesis II" is not browsing. They're buying — from whichever merchant's data can confirm the fit.

How AI agents use works-with data

Mechanically, an agent handles a constraint query in a recognizable sequence: extract the entities from the request, normalize them, filter candidate products against structured fields, then answer — or decline.

Two details in that pipeline decide your fate. First, the filter runs on fields, not descriptions. Assistants do read prose, but for a purchase-blocking constraint they want a verifiable fact — "fits most standard pitchers" buried in a paragraph is not something a careful agent will stake a recommendation on. Second, when the field is empty the agent has two options: skip you, or guess. On-site agents are tuned to decline rather than fabricate, so you simply become invisible. Off-site assistants sometimes guess — and a wrong guess becomes your return, your one-star review, and your support ticket.

This dependency holds across every surface. Rufus reads Amazon's structured attributes, including the backend attributes shoppers never see. ChatGPT, Gemini, and Perplexity read your PDPs and schema markup. A Brand Agent reads your Shopify catalog directly. Different surfaces, same requirement: the relationship must exist as data.

The four relationships worth modeling

Compatibility isn't one field. In enrichment work we model four distinct relationship families, because they answer different shopper questions and fail differently when missing.

A fifth relationship, replaces, matters enormously if you sell consumables — filters, blades, ink, pods, batteries. "The filter that replaces the one in my Brita OB03" is nearly pure repurchase intent, and agents handle repurchase constantly. If your refill SKUs don't declare what they replace, that revenue routes to whichever competitor's do.

Notice that pairs_with is the odd one out: it's not a constraint the shopper states but a suggestion the agent makes, powering basket-building and post-purchase recommendations. It's also the one family you fully control, since both ends of the relationship are your own SKUs. Start there for an early win — the other three require the sourcing work below.

Where compatibility data hides in your business

Merchants stall on compatibility because they picture building it from scratch. You almost never have to. The facts exist — scattered across documents and systems nobody thinks of as catalog inputs. We run four mining passes, in this order:

1. 1

   Manuals and spec sheets

   Product manuals, engineering drawings, and manufacturer spec sheets state compatibility explicitly — model lists, thread sizes, voltage ranges, standards. This is your highest-accuracy source. If you buy wholesale or manufacture, ask your supplier for the compatibility matrix they already maintain; most have one and nobody ever requests it.

2. 2

   Support tickets

   Search a year of tickets for "will this work with", "does this fit", and "compatible with". Every question is a compatibility fact a shopper needed and couldn't find — and the answer your team gave is pre-verified data waiting to be structured.

3. 3

   Return reasons

   Returns tagged "didn't fit" or "not compatible" are compatibility data written in your most expensive ink. Each one names a relationship your catalog got wrong or never stated. Mine them for negative facts too — knowing what a product does not fit prevents both repeat returns and bad agent guesses.

4. 4

   Reviews and PDP Q&A

   Question sections and review text are full of owner-confirmed pairings: "works perfectly with my 2021 model." Treat these as leads, not facts — verify against the manual before promoting anything to the catalog, because owners misremember model numbers.

How to add fits and works-with attributes to your catalog

Sourcing gives you facts. Modeling decides whether agents can use them. Four rules keep compatibility data machine-usable:

• Store relationships as list-type fields, not sentences. On Shopify that means metafields with list types, or metaobjects for model lists shared across many SKUs; in a PIM, a proper relationship attribute. Shopify metafields vs a PIM covers where each approach breaks.
• Use canonical entity names. "iPhone 16 Pro" — not "iphone16pro", "IP16P", or "the newest iPhone". Agents match on names, and three spellings of one device is three chances to miss. Keep one reference list of model names and reuse it everywhere.
• State the direction. "Fits" runs from accessory to host: the case fits the phone, the filter fits the pitcher. Decide the direction per field, document it in the schema, and never mix directions inside one field.
• Record negatives where returns prove the confusion. A not_compatible_with field on your most-confused SKUs stops agents and shoppers alike from making the expensive mistake twice.

Where the fields live follows your stack. On Shopify, metafields handle compatibility at mid-market scale provided you enforce a per-category schema — the full argument is in attribute schema design. On Amazon, fitment and compatibility live in backend attribute sets with their own quirks per category. The modeling rules stay constant in every system: list-typed, canonical, directional, governed.

Then govern it like inventory, because compatibility decays. Manufacturers release new models every year, and "fits all current iPhones" is wrong twelve months after you write it — which is exactly why you never write it. List models explicitly, and put a recurring task on the calendar: when a major platform ships new hardware, update the affected model lists that week. Maintenance is the unglamorous half of this work, and it's the half that keeps the data trustworthy.

Mistakes that poison compatibility data

• Vague values. "Fits most models" is prose wearing a field's clothes. If you can't name the model, you don't have the data yet.
• Copying competitor claims. Their fitment errors become yours, with none of their context. Verify against manufacturer documentation.
• One mega-field. Cramming works-with, fits, and suitable-for into a single "compatibility" text blob destroys the distinctions agents filter on.
• Set-and-forget. Model lists go stale annually. Unmaintained compatibility data quietly converts from asset to liability.

Compatibility is the tedious half of catalog work, which is exactly why it's a moat. Any competitor can fill in color and material in an afternoon. Assembling verified works-with data for a thousand SKUs takes real effort — and once it's in your catalog, agents on every surface can do something with your products they can't do with anyone else's: say yes with confidence. Our Catalog Enrichment for AI service builds exactly this — sourcing, verification, modeling, and the governance schema that keeps it alive.