Most advice on "preparing your product catalog for AI agents" stops at the same place: add schema markup, publish a feed, make sure your prices, categories and inventory are current. That's necessary, but it treats the catalog as a formatting problem - as if the data was already good, and just needed the right wrapper.
It isn't, and it doesn't.
Anyone who has worked with real merchant catalogs knows what the data actually looks like: a product titled "The Aria Dress," a description that's mostly brand story, and a handful of inconsistent tags that mean something different in every store. That's fine when a human is looking at a photo and filling in the gaps themselves. It's not fine when the thing making sense of the product is an AI agent - the kind now driving agentic commerce - that has to search, filter, and recommend based on what's actually written down.
So what does it actually take? Not one transformation - a sequence of four, each solving the failure mode the one before it leaves behind: generating visual descriptions from product imagery, normalizing free-text attributes into canonical structure, embedding images so appearance becomes searchable, and embedding the combined text so meaning does too. The order matters. Here's each step in turn - with the Aria Dress carried all the way through.
Step 1 · Visual descriptions: how do you make a product's appearance searchable?
Visual descriptions close the first gap: most of what's true about a product - silhouette, fabric, neckline, fit - was never typed anywhere. A vision model looks at the product images and writes those attributes down as plain text, so a query like "flowy floral midi with puff sleeves" can match a product whose title never contained those words.
A shopper works these facts out by looking at the photos. Take the Aria Dress: the photos show a flowy floral midi with puff sleeves and a square neckline, but the title is a name, the description is a mood, and none of those visual facts exist as text. Text search can't fill the gap the way a shopper does, because the words don't exist yet.
The fix is to have a model look at the product images and write down what it sees: a plain-language description of the actual visual attributes, not the marketing copy. The Aria Dress gains a description that finally states the obvious - a flowy floral midi dress with puff sleeves and a square neckline. Once that text exists, a query like "flowy floral midi with puff sleeves" can match a product whose title never contained any of those words, because now something does.
There's a second, quieter piece of this step that matters just as much. Nearly every listing ships with a jumble of photos - on-model shots, flat lays, close-ups, size charts - and different downstream jobs need different ones. A similarity search wants the on-model shot; a virtual try-on feature needs a clean garment-only image; a display crop wants something else again. Sorting out which photo does which job is unglamorous, but skip it and every visual feature built on top inherits the confusion.
Step 2 · Canonical attributes: how do agents filter when every merchant uses different words?
Canonical attributes turn inconsistent, merchant-specific text into a controlled set of facts - category, color, material, length, style - that an agent can filter on exactly. "Navy," "dark blue," and a color buried in a paragraph all collapse to one value, so the same query behaves the same way across one merchant's inventory or a hundred.
One merchant tags a color "navy," another "dark blue," a third buries it in a paragraph. In the catalogs we ingest, it's routine to see the same attribute spelled a half-dozen ways within a single store. That's tolerable for a person browsing - they'll figure it out - but an agent trying to apply a hard filter can't reconcile five spellings of the same color, and it can't turn "show me red cotton summer dresses" into an exact query if "red" and "cotton" aren't represented consistently anywhere.
This step takes the messy, merchant-specific text - titles, descriptions, the visual description from the previous step, whatever tags exist - and maps it onto a controlled, canonical set of attributes. The Aria Dress's prose collapses into facts: category: dress; length: midi; pattern: floral; sleeves: puff; neckline: square. The output isn't prose anymore; it's structured data an agent can filter on directly.
It's worth being explicit about what this does and doesn't override. Most of what a merchant already provides - collections, product type, vendor metadata, related products - is worth preserving as-is; that's structure the merchant already invested in. What gets normalized is specifically the loose, free-text stuff - tags, ad hoc categories - that was never consistent to begin with. The goal isn't to erase merchant intent, it's to make the parts of the data that were never standardized behave consistently across the catalog.
Step 3 · Image embeddings: how do agents find products that look alike?
Image embeddings represent each product image as a vector, positioned so visually similar products sit close together and dissimilar ones sit far apart. That turns "does this look like that?" into a fast distance calculation - the thing that powers "more like this," visual search, and pairing products that belong together. Without it, resemblance can't be expressed at all.
A lot of shopping isn't exact. A shopper who loves the Aria Dress and wants "something like this" isn't expressing a filter - they're expressing a resemblance, and resemblance is hard to write rules for. No combination of category, color, and length quite captures why two dresses feel like siblings and a third doesn't.
Representing each image as a list of numbers positioned in space makes visually similar products land close together. Skip this step and those experiences don't degrade - they simply don't exist, because neither structured filters nor plain-text search can express resemblance.
Step 4 · Semantic embeddings: how does an agent match a product to natural language?
Semantic embeddings fuse the title, merchant description, generated visual description, and canonical attributes into a single vector that captures what the product is, not just how it looks. That's what lets a shopper or an agent type "an elegant dress for a summer wedding" and surface the Aria Dress - even though none of those words appear in the listing.
By this point the Aria Dress has a title, a merchant description, a generated visual description, and a set of canonical attributes. Combine all of that into one block of text, generate a single embedding from it, and the query means something close to what the product's combined description means - something you can compute directly, rather than something you hope a keyword match stumbles onto.
The four representations of an agent-ready product
Step | Representation |
1 · Visual descriptions | A language description an agent can reason over |
2 · Canonical attributes | A set of facts it can filter on exactly |
3 · Image embeddings | A vector for how the product looks |
4 · Semantic embeddings | A vector for what the product means |
Why does the order matter more than any single step?
Because each step feeds the next. The visual description feeds the attribute normalization; both feed the semantic embedding; the image embedding runs in parallel as its own path. Get the order wrong or skip a step, and everything downstream inherits the gap - an agent extracting attributes from a bare title and a marketing blurb is working with a fraction of the signal it would have if a visual description existed first.
This is why "prepare your catalog for AI agents" is a bigger job than it sounds. It's not a metadata cleanup task or a schema-markup checkbox. It's a small pipeline that takes whatever a merchant happened to upload - thin, inconsistent, marketing-voiced - and produces four complementary representations of the same product: a description an agent can reason over, a set of facts it can filter on exactly, a vector for how the product looks, and a vector for what it means.
An agent making a recommendation is only as good as the weakest of those four. The Aria Dress arrived as a name, a mood, and a folder of photographs; it leaves as all four at once - something an agent can find, filter, compare, and recommend, with each verb depending on a different step of the pipeline.
The teams that get this right won't be the ones with the best-formatted feed. They'll be the ones who treated their catalog as something to genuinely understand, one transformation at a time, before ever worrying about how to publish it.
This four-step pipeline is exactly what runs behind Swap's Agentic Commerce Universal Catalog - it takes any merchant catalog and makes it agent-ready. Book a demo to see it run on your own catalog.
- agent-ready product catalog
- agentic commerce
- product data for AI
- embeddings
- catalog normalization


































