If an assistant builds a product list for one customer at the moment they ask, the hard part is not the language model. The hard part is making sure every item on the list is real, in stock and priced right. This is a design sketch for that, written as a forecast of one pattern, not as a description of a shipped product.
Start with the rule: the model never creates inventory
Public examples show the right split. Zomato's MCP server exposes restaurant discovery, menu browsing with prices, cart creation and ordering. The AI tool calls those functions and reads real menus. It does not make up dishes.
Use the same rule in your own system. The assistant can choose, filter, rank and explain. It cannot add an item that is not in your product records.
The pipeline
- Intent in. Customer message arrives in chat, for example from a click-to-WhatsApp ad.
- Classify. A small classification step turns free text into a typed decision: category, budget band, urgency, confidence. TypeSafe describes its Jev model this way: unstructured input in, typed probabilistic decisions out, and no free text generation. A classifier is a good fit because the next code step needs a value from a fixed list, not a paragraph.
- Branch on confidence. Below a threshold, ask one clarifying question or hand over to a person.
- Retrieve. Query your own product store with the typed fields. Pull from approved documents for product facts.
- Check live state. Re-read price and stock right before showing the list.
- Rank and explain. The language model writes a one-line reason per item, using only fields it was given.
- Review. The customer confirms. Nothing is bought without that step.
A schema that keeps the model honest
{
"intent": {"category": "string (enum)", "budget_max": "number", "confidence": "0..1"},
"items": [
{"sku": "must exist in product store",
"price": "from live read",
"in_stock": "from live read",
"reason": "max 20 words, uses only retrieved fields",
"sponsored": "boolean"}
]
}
Reject the whole response if any sku is not found in the store. Do not try to repair it.
Guardrails worth writing as tests
- Unknown sku: response is dropped and logged.
- Stale price: if the live read differs from the retrieved value, show the live value.
- Sponsored items: always flagged, never hidden inside "recommended".
- Personal data: only use data the customer agreed to share. The FTC's January 2025 surveillance pricing study press release is a good reason to keep price rules the same for everyone unless you can explain a difference.
- Reorder and compare: keep a stable category view. People still want it.
Keep the feed clean
Everything above depends on clean records: title, plain description, price, availability. Google Search Central tells merchants to share product data through structured data and Merchant Center feeds, and says the Content API suits quick stock updates. If your data is wrong, a per-customer list only gets the wrong answer faster.
What I am not claiming
I am not claiming any vendor ships this whole flow today. Amazon's Interests and Rufus, and Spotify's Prompted Playlist beta, show pieces: prompt-driven lists, memory, refresh. The full pipeline above is a design I think is worth testing.
I'm Tej Pandya, founder of GrowEasy.ai.
Top comments (0)