How to Add an AI Shopping Assistant Powered by Product Catalog Content

Ask a generic AI shopping assistant whether a jacket is waterproof and in stock in medium, and it will confidently answer from a stale snapshot: the price is last quarter's, the "waterproof" claim was hallucinated from a similar product, and the size it recommends sold out an hour ago. For an ecommerce team, that is not a quirky demo failure. It is a returned order, a support ticket, and a customer who no longer trusts the assistant. The gap is almost never the model. It is what the model is grounded in.

Sanity Context is the retrieval layer that closes that gap, an intelligent backend that lets an AI shopping assistant answer from your live product catalog rather than a frozen copy of it. Built on Sanity, the Content Operating System for the AI era, it treats your catalog as structured, queryable content the assistant can read at request time, with governance kept inside the editorial loop where merchandisers already work.

This guide walks through the architecture of a catalog-grounded shopping assistant: how to model product content so an agent can reason over it, how hybrid retrieval finds the right variant, and how to keep answers fresh, governed, and safe to ship.

Why generic assistants hallucinate against product catalogs

The failure mode is specific. A shopping assistant that wraps a general-purpose model has no reliable connection to the exact SKU, price, inventory state, or attribute the shopper is asking about. When you ask a question the model can't ground, it does what language models do: it produces the most plausible-sounding answer, which for commerce means inventing specifications, conflating similar products, or quoting a price it half-remembers from training data or a cached page.

Bolting a vector database onto a product feed does not fix this on its own. Product catalogs are relational and fast-moving. A single product has variants, each variant has its own price and inventory, attributes differ by category, and merchandising copy changes daily. A flat pile of embedded text chunks flattens all of that structure into similarity soup, so the assistant retrieves "a jacket that sounds relevant" rather than "the waterproof variant in medium that is actually purchasable right now."

The deeper problem is architectural. Legacy content systems stop at publishing a page, then hand the hard part, keeping retrieval accurate and current, to whatever glue you assemble downstream. Every export, sync job, and re-embed step is another place freshness decays and structure is lost. The assistant is only ever as trustworthy as the least-current copy of the catalog in that chain, and in most stacks there are several copies. Grounding has to start where the catalog actually lives, not three hops away.

Model your catalog so an agent can reason over it

The first pillar is model your business, and for a shopping assistant it is where accuracy is won or lost. An agent can only answer precisely about attributes that exist as discrete, queryable fields. If "waterproof," "material," "care instructions," and "size availability" live as loose sentences inside a marketing blurb, the assistant has to guess at them. If they live as typed fields on a product document, the assistant can retrieve them exactly.

In Sanity, product content lives in the Content Lake as structured documents you define. You model a product with its variants as references, each variant carrying its own price, SKU, and inventory field, and you model shared attributes as typed fields rather than free text. Category-specific attributes become their own object shapes, so a footwear product and an outerwear product can differ in structure without breaking the assistant's ability to query either. Portable Text keeps rich merchandising copy structured rather than as an opaque HTML string, so the parts an agent should quote stay separable from the parts it should ignore.

The payoff is that a shopper question maps to a query, not a guess. "Is this waterproof and in medium?" resolves against a boolean attribute and a variant inventory field, and the assistant answers from data it can cite. Modeling this way up front is the difference between an assistant that reads your catalog and one that free-associates near it. It also means new attributes added by merchandisers are immediately reasonable-over, with no re-training and no schema migration in a separate retrieval system to keep in sync.

Hybrid retrieval: finding the right variant, not a similar one

Shoppers ask in two registers at once. Some queries are semantic ("something warm for a rainy commute") and some are lexical and exact ("Gore-Tex, size M, under $200"). Pure vector search nails the first and fumbles the second; pure keyword search does the reverse. A catalog assistant needs both in the same pass, which is exactly what hybrid retrieval provides.

Inside the Content Lake, this is native rather than assembled. A single GROQ query can blend `text::semanticSimilarity()` for the fuzzy intent with a BM25 `match()` for the exact tokens, then combine them with `score()` and `boost()` to rank results the way a merchandiser would. You can boost in-stock variants, weight the exact color the shopper named, and demote discontinued lines, all in one query against the live catalog, without a separate search cluster to provision or keep consistent.

This matters because retrieval quality is where most catalog assistants quietly fail. When semantic and lexical signals live in different systems, someone has to fuse the results, reconcile two ranking scales, and keep both indexes current as the catalog changes. Every one of those steps is latency, cost, and drift. Doing the blend in one query against the structured catalog collapses that stack. The assistant asks the catalog a real question and gets back the specific purchasable variant, with its attributes attached, ready to answer the shopper accurately rather than approximately.

Keeping answers fresh when prices and inventory change hourly

Ecommerce content is among the most volatile content there is. Prices change with promotions, inventory changes with every order, and merchandising copy is rewritten for seasons and campaigns. A shopping assistant that answers from yesterday's snapshot is worse than no assistant, because it is confidently wrong at the exact moment a shopper is deciding to buy.

Most retrieval architectures create a freshness tax. You export the catalog, chunk it, embed it, and load it into a vector store on a schedule, so every field the assistant knows is only as current as the last run of that pipeline. With Sanity, embeddings are dataset embeddings tied directly to the content, so when a product document changes, the embedding updates within minutes rather than waiting for a nightly re-index. There is no separate vector pipeline to babysit and no window where the assistant is grounded in a version of the catalog that no longer exists.

For the truly live signals, the Live Content API pushes changes as they happen, so an assistant can reflect a price drop or a sold-out variant without polling. The combination means the assistant's answer and the product page a shopper sees are grounded in the same source at the same moment. That is the whole promise of grounding: not "close to current" but current, so the assistant never recommends a size that sold out while the shopper was typing.

Governing the assistant: instructions editors can stage and control

A shopping assistant is not just a retrieval problem, it is a merchandising surface. What the assistant is allowed to recommend, how it describes sale items, whether it upsells, and what it must never claim about a product are business decisions that belong to the people who own the catalog, not buried in application code where only engineers can change them and no one can review them safely.

This maps to the automate everything pillar, but under editorial control. In Sanity, agent instructions and merchandising rules can live as governed content in the Studio, versioned and reviewed like any other content. Content Releases let a team stage a change to how the assistant behaves, a holiday tone, a new upsell rule, a corrected product claim, and preview it before it goes live, the same way they stage a change to the website. Roles & Permissions decide who can alter assistant behavior, and Audit logs record who changed what and when.

Production agents connect through the Sanity Context MCP endpoint, so the assistant that ships is grounded in the same governed catalog and instructions the editorial team controls. That closes the loop competitors leave open: instead of assistant behavior drifting in a config file outside anyone's review, it stays inside the editorial process, staged, permissioned, and auditable. On enterprise deployments this is backed by SOC 2 Type II, GDPR compliance, regional hosting for data residency, and a published sub-processor list, so the governance story holds up under procurement review.