"RAG" usually conjures an embedding index: chunk your documents, store vectors, retrieve the nearest, stuff them into the prompt. For product data that is the wrong default. A catalog's most important facts — is it in stock, what does it cost, when does it ship — change constantly and must be exact, and a vector snapshot is stale the moment you build it. The grounding architecture that works for commerce is tools as truth: the model calls live functions against your systems and reasons over the results. Embeddings still have a role, but a supporting one.
Tools as truth, not an embedding index
The cardinal rule of a grounded assistant is that it may only reference facts returned by a tool call this turn. Search, product detail, price, stock, delivery — each is a named function the model can call, and its return value is the only thing the model is allowed to state. This is different from embedding-only RAG in kind, not degree: an embedding index answers "what documents are similar to this query", while a live tool answers "what is true right now". For a shopper asking whether something is in stock, only the second question has a correct answer. We built our assistant this way and describe the whole loop in the assistant architecture.
| Dimension | Embedding-only RAG | Tools-as-truth |
|---|---|---|
| Freshness | As stale as the last index build | Live at query time |
| Stock / price accuracy | Risky — snapshots drift | Exact — read from source |
| Best for | Prose, guides, evidence text | Structured facts, availability, actions |
| Failure mode | Confidently cites old data | Empty result (an honest answer) |
Freshness: stock and price can't be stale
The single biggest reason to prefer live tools is that the facts a shopper cares most about are the ones that move fastest. An assistant that recommends a sold-out product, or quotes yesterday's price, does more damage than one that says less. Live tool calls read the same source of truth the storefront reads, so the assistant and the product page can never disagree. If you must cache tool results for latency, cache them for seconds and scope the cache per fact — never let a price or a stock flag ride a long TTL. Search relevance can tolerate slight staleness; availability cannot. The retrieval and fusion mechanics behind those tools are the same ones in marketplace search and semantic search for ecommerce.
Evidence corpora for claims you can't make up
Some answers aren't about products at all — they're claims. "Does this help with X?" needs a citation, not a vibe. This is the one place a retrieval index over vetted text is exactly right: a curated evidence corpus the model can query, where each claim it makes must resolve to a source, and a claim that can't cite gets softened or dropped. It is RAG in the classic sense, but fenced — the corpus is whitelisted, and the output validator refuses uncited claims. That fail-closed posture mirrors the guardrail chain: silence beats invention. The same evidence-first discipline governs our published content, described in does AI content rank.
The empty result is an answer
The most under-appreciated grounding principle: when a tool returns nothing, "we don't carry that" is the correct, complete answer — not a prompt to improvise a substitute. An assistant that treats emptiness as a failure to be papered over will invent products, and the moment it does, every other answer becomes suspect. Treat the empty result as first-class: render it honestly, optionally offer a real category fallback, and never let the model fill the void from memory. Shoppers trust a store that admits its limits far more than one that always has an answer.
There's a design consequence: your tools must be able to express emptiness unambiguously. A search tool that returns nothing and a search tool that errored look identical if you're careless, and the model will guess. Return a structured "no matches" that is distinct from a failure, and distinct again from "brand not carried" — each deserves a different, honest response, and the same brand-not-carried empty state we describe in marketplace search is exactly this principle rendered in the storefront rather than the chat.
Data contracts: RAG is only as real as its pipeline
Grounding moves the risk rather than removing it: the assistant is now exactly as reliable as the tools feeding it, which means the pipeline behind those tools needs a contract you actually test.
Our worst assistant incident was not a hallucination — it was a data contract. A candidate filter referenced a field that belonged to a different schema and did not exist on the catalog documents, so the filter silently matched nothing and the builder had zero products to work with. The model reasoned perfectly over an empty list and produced a confident, useless answer. The fix wasn't a better prompt; it was testing the data contract with production-shaped documents instead of fixtures. Grounding cuts both ways: garbage-in is now garbage-grounded.
Practically: version the shape your tools return, validate it against real documents in CI, and fail loudly when a field goes missing — the same typed-contract mindset in structured LLM outputs.
When embeddings still earn their place
None of this means vectors are useless — it means they're a component, not the architecture. Embeddings shine for semantic recall (finding the product a shopper described without the right keyword), for the evidence corpus above, and for clustering near-duplicate content. The right mental model is a hybrid: live tools for facts and actions, vectors for similarity and recall, fused by ranking. The same selective-triggering logic that keeps semantic search from harming precise queries applies here. And once your commerce facts live behind clean tools, exposing them to third-party AI assistants — agentic commerce — is nearly free, because the hard part was always the grounding, not the surface.
Key takeaways
- Prefer tools as truth over an embedding index for product facts — live calls answer "what is true now", vectors only answer "what is similar".
- Never let stock or price ride a cache — the facts shoppers care about most move fastest, so read them live.
- Use a fenced evidence corpus for claims, where every claim must cite or be dropped — classic RAG, but fail-closed.
- An empty tool result is a complete answer — "we don't carry that" beats an invented substitute and protects trust in every other answer.
- Test the data contract with production-shaped documents — a grounded assistant is only as real as the pipeline behind its tools.
- Keep embeddings as a supporting component for recall and evidence, fused with live tools rather than replacing them.
Frequently asked questions
Is embedding-based RAG the right way to build a product assistant?
How do you keep an AI assistant's stock and price accurate?
What should an assistant do when a search returns no products?
Does grounding eliminate hallucination risk?
Answers grounded in a live catalog.
The tool-grounding architecture here powers the AI assistant on the managed marketplace we operate for content brands.
Request early access See the live marketplace →