The Catalogue Enrichment Agent

Bad product data is a silent revenue leak — items that cannot be found, filtered, or trusted. An agent that fills the gaps at catalogue scale without inventing attributes.

Every retailer with a large catalogue has the same quiet problem. A meaningful share of products have thin titles, missing attributes, empty or duplicated descriptions, inconsistent categorisation, and images with no alt text. Nobody planned it that way; it accumulated. Suppliers send what they send, categories get restructured, and nobody has the headcount to go back and fix eighty thousand SKUs.

The cost does not show up as a line item, which is why it persists. It shows up as products that do not surface in search, filters that return incomplete result sets, comparison pages that look broken, higher return rates on items whose description did not set expectations, and paid traffic sent to pages that do not convert.

The one rule that matters

There is exactly one way this build goes wrong, and it is worth stating before the architecture: the agent must never invent an attribute.

If a model is asked to fill in "material" for a product and the source data does not say, it will produce something plausible. Plausible is catastrophic here. A jacket described as waterproof when it is water-resistant is a returns problem and, depending on the claim and the jurisdiction, a regulatory one. Product data is a representation to a customer, and a confidently fabricated specification is a false one.

So the agent is built to distinguish three states, and to never collapse them:

Known — the value is present in a source, and the source is cited.
Derived — the value follows from something known by an explicit, reviewable rule.
Unknown — no source supports a value. This stays empty and goes on a supplier data-request list.

Most enrichment tools have two states. The third is the whole point.

How it works

Attributes are Known, Derived or Unknown — never guessed. Unknown stays empty and becomes a supplier data request, which is how the underlying data actually improves.

Gather sources. Supplier feeds, spec sheets and PDFs, existing catalogue data, manufacturer references, images, and — often the richest source — customer reviews and returns commentary, which frequently describe fit, sizing and material behaviour that the official data never captured.

Extract with provenance. Attributes are pulled from those sources, each tagged with where it came from and how confident the extraction was. Conflicts between sources are surfaced rather than silently resolved; a supplier feed and a spec sheet disagreeing about a dimension is information, not noise.

Normalise to the taxonomy. "Navy", "Dark Blue" and "NVY" become one value. Units are converted. Sizes map to the client's own size system. This runs against the client's taxonomy, which is a real artefact we work with rather than something the model improvises.

Generate copy from facts only. Titles and descriptions are composed from the validated attribute set, in the client's voice and structure, with the merchandising rules applied. Because generation is constrained to known attributes, the copy cannot claim something the data does not support.

Score and route. Complete, high-confidence items flow to review in bulk. Items with conflicts, low-confidence extractions or gaps in commercially important attributes go to a merchandiser individually, with the conflict laid out.

Report the gaps. Everything that came back Unknown becomes a structured request to the supplier. Over time this is how the underlying data quality actually improves, rather than being papered over.

Merchandisers stay in the loop — at a sane altitude

Reviewing eighty thousand items one at a time is not a workflow anyone will sustain, so review is designed around batches and exceptions. A merchandiser approves a category's worth of normalised colour values in one action, and spends their individual attention on the two hundred items where sources disagreed.

Changes are staged, diffable and reversible. A bad enrichment run that cannot be rolled back is an outage of your entire catalogue, so we treat publication like a deploy: staged, reviewed, promoted, revertible.

Where it plugs in

PIM or catalogue system as the system of record, supplier feeds and portals as inputs, the search and merchandising platform downstream, and the storefront as the eventual surface. The agent writes to the PIM, not to the storefront, so the client's existing publication path and approvals continue to apply.

What we measure

Attribute coverage on commercially important fields, split by known versus derived. Extraction precision against a merchandiser-labelled sample — and precision is the metric to watch, not recall, because a missing attribute is a gap while a wrong one is a liability. Merchandiser override rate. Then the downstream signals: search result coverage, filter completeness, conversion on enriched pages, and return rate on items whose descriptions changed.

That last one is the honest test. If returns rise on enriched products, the copy is overselling, and the agent's constraints need tightening.

What it is not

It is not a content farm. The goal is not more words per product; it is accurate, complete, findable product data with the gaps identified rather than filled with plausible fiction.

Handled that way, it is one of the highest-return builds available in retail, precisely because the problem is so widespread and so rarely staffed.

Retail and e-commerce is one of the domains we build agentic workflows in — discovery, catalogue, order support, forecasting, store ops. Describe yours in the console or run /estimate.