A Shopping Assistant That Never Invents a Deal: Grounding the Model in the Real Catalog

1 day ago
3 min read

The worst failure of a shopping assistant is not an awkward answer. It's an invented offer: a price that doesn't exist, an expired discount, a merchant that no longer sells the product. Prototyping a shopping assistant plugged into a real deals catalog, we set one rule before writing the first line: the model never quotes a price it hasn't just read.

That rule structured everything — the number of tools, the split between memory and data, even the definition of success. Here is what a prototype teaches when you forbid it to lie.

Key takeaways

On commercial content, factual error is binary: an invented price is unforgivable. The model writes; the catalog alone supplies the facts.
Four narrow, typed tools beat twenty broad ones: search offers, read an offer's details, browse categories, check validity. Nothing else.
Refusal is a feature: when the catalog has no answer, the assistant says so and shows what exists — it never fills the gap with its memory.

Commerce's fatal error: the invented offer

Approximate prose can be fixed; an invented price destroys trust in a single interaction — and, depending on the market, creates regulatory exposure. That's the difference between an error of style and an error of fact: on a transactional assistant, the second is fatal. The architectural consequence is immediate: the model's memory, however vast, is a forbidden source for any commercial fact. Price, discount, validity dates, availability, merchant name — each of these fields comes from a query executed right now, or doesn't appear in the answer.

Four narrow tools instead of twenty broad ones

The prototype temptation is to expose many tools "just in case." We took the opposite path: a handful of narrow tools with typed responses — search offers by criteria, read one offer in full, browse categories, check that an offer is still valid. That's all.

The tightening has two measurable effects. First, less wandering: an agent picks its next move better when the menu is short — we've written it elsewhere: a goal without boundaries makes an agent roam; so does tooling without boundaries. Second, full traceability: every claim the assistant makes links back to a logged tool call, which makes acceptance (our five gates) applicable to the letter.

The model's memory is for language, not facts

So what is the model for, if facts come from the catalog? Everything else — and it's enormous. Understanding a vague request ("a gift for my mother, around fifty euros") and translating it into structured queries. Knowing that "sunscreen" in June doesn't mean what it means in December. Reshaping three raw offers into a readable recommendation, in the platform's voice. The split is the same as in our distribution pipelines: the deterministic layer supplies the facts, the model supplies the language. A shopping assistant is not a catalog that talks; it's a translator between human intent and real data.

Refusal is a feature

The moment of truth for a grounded assistant is the query with no answer. The catalog has nothing that matches; the model's memory, meanwhile, "knows" dozens of plausible products. That's where the rule pays: the assistant says it found nothing, shows the closest things that do exist in the catalog, and stops. We track the refusal rate as a quality metric, not a failure — an assistant that never refuses is an assistant that invents. User trust isn't built on omniscience; it's built on the certainty that what's displayed exists.

Prototype first, product second

What a phase-zero prototype must prove is not a seductive interface: it's that the grounding architecture holds end to end — intent understood, queries correct, facts exact, refusals clean. A demo that lies is worse than no demo: it commits the organization's confidence to foundations that don't exist. The investment order follows: grounding first, experience second. The rest — preference memory, personalization, channels — gets added on top of a foundation that doesn't know how to invent.

FAQ

Why not classic RAG over the catalog? Because a deals catalog is structured and perishable: typed tools querying the fresh source beat a vector layer for transactional data. RAG keeps its place for editorial content, not for prices.

Which model do you need? Any frontier model understands purchase intent. The difference isn't the model choice; it's the grounding architecture and tool discipline.

How many tools should you expose? Start under five. Every added tool widens the error space; add one when a class of real queries demands it, not before.

ECTIME AI Lab is the applied-AI research and deployment unit of ECTIME Group. We build, ship and stress-test agentic systems in production, from GEO/SEO automation to multi-step autonomous agents. We maintain open-source Claude Skills for GEO/SEO and advise European brands on deploying AI that is not just autonomous, but verifiable and authorized.