The obvious way to add an assistant to a product is to send the user's question to a language model and show the answer. For a venue discovery app, that would mean the model inventing an address, a price, or an opening time that sounds entirely plausible and is entirely wrong. A customer arriving at a restaurant that closed two years ago is a worse outcome than having no assistant at all.
We shipped an assistant for a product covering venues across 118 Moroccan cities, and the design principle was simple to state and load-bearing in every decision: the model is a translator, not a knower.
The model never touches the database
The assistant is given tools rather than data. Search venues by city and category. Search menu items. Fetch details for one venue. When a user asks for a cheap rooftop in Casablanca, the model does not answer. It decides which tool to call and with what arguments, our backend runs the real query, and the model is then asked to phrase the result.
The distinction matters because it moves the truth boundary. The model chooses the question. The database gives the answer. A model that has never been handed a price cannot hallucinate a price, and no amount of clever prompting achieves that guarantee, because prompts are requests and architecture is a constraint.
The tools enforce the rules, not the prompt
Every tool applies the same filters the rest of the product does. Unpublished venues are excluded at the query level. Personal information is stripped before results are returned, so an owner's phone number cannot leak through a conversational interface that nobody thought to audit.
Writing those rules into the system prompt instead would be a mistake. A prompt is a strong suggestion to a system that is fundamentally probabilistic. A WHERE clause is a rule. Anything that must always be true belongs in the query.
Empty results are a feature
When a tool returns nothing, the assistant has to say it found nothing. That sounds trivial and is where most implementations quietly fail, because a model with no results and a helpful disposition will reach for something adjacent and present it with total confidence.
The instruction has to be explicit and the behaviour has to be tested: no results means say so and suggest widening the search. We test this deliberately with queries we know return nothing, because it is the exact failure users will not report and will not forgive.
Cost and blast radius
Two controls ship with the feature, not after it. Rate limits per user and a global ceiling, so a loop or a curious user cannot run up an unbounded bill overnight. And a kill switch: a configuration flag, read live, that disables the assistant everywhere without a redeploy. If the model provider has an outage or starts behaving strangely, the feature goes dark in seconds.
The provider itself is swappable behind the same interface. Models change, pricing changes, and a provider you cannot leave is a dependency you do not control.
What we learned the hard way
Match user language to database reality before searching. People type city names with different spellings, accents and transliterations, and a naive exact match returns nothing for a query that should obviously work. Normalising the city name before the query fixed more "the assistant is broken" reports than any prompt change did.
Refund the user's rate-limit allowance when a call fails for our reasons. Otherwise a provider timeout costs the user one of their questions, which they experience as the product being broken twice.
Where this applies beyond one app
Any business considering an assistant over its own data faces the same fork. Let the model answer, and accept that it will occasionally be confidently wrong about your prices, your policies or your availability. Or make it a translator over real queries, and accept that it can only answer what your data actually supports.
For anything customer-facing with money or logistics attached, the second is the only defensible choice. We build assistants this way as part of localisation and AI work, and the constraint is the product, not a limitation of it.