Your client runs a clinic, or a group of them, and wants an assistant on the website and WhatsApp that answers from their own service list and preparation rules. Every vendor and every framework you have looked at says the same thing: the answers are "grounded in your data", and you have to put your name to one of them.
The phrase covers at least three different builds, and only one of them behaves the way your client imagines. Grounded, in the sense that matters, means the assistant looks the fact up from a named record at the moment it answers, uses what that record says, and can tell you which record it was. If the fact changes in the source, the next answer changes with it, with nobody editing the assistant. Anything short of that is the model working from something it was given earlier, and it will keep sounding sure of itself long after that something has gone stale.
Three things that all get called grounding
The first is putting the facts in the instructions: the price list, opening hours and preparation notes pasted into the prompt the model reads before every conversation. It demos perfectly, because on the day of the demo the facts are right. Then a price moves, the list lives in two places, and only one of them gets updated. The assistant has no way of knowing its copy is old.
The second is retrieval over documents. The client's brochures and FAQ pages are cut into passages, and the passages that read most like the question are handed to the model to answer from. The term most people use for this, retrieval-augmented generation, comes from a 2020 research paper by Lewis and colleagues, and it is a real improvement on a model answering from memory. But "reads most like" is a similarity judgement, so a question about one package can pull back a passage about a similar one, or two brochures printed a year apart, and the model will blend them into one fluent answer.
The third is a lookup against structured records. Each service is a record with fields, the assistant searches those records, and it answers from what comes back. When nothing matches, it gets back nothing, which it can say. Most real systems mix the three, and that is fine. Anything with a number in it, or a yes-or-no about what a branch can do, belongs in the lookup. Tone and the limits of what the assistant may discuss belong in the instructions.
The lookup is the easy part
A competent developer can stand up the lookup without much trouble. What takes the time is the catalogue behind it, and it is never finished. Patients ask for things by names the price list has never used. The clinic changes a price in its own system and tells nobody. A branch stops offering a service. A package changes what it includes and the old brochure stays on the website. Each of those is a wrong answer waiting to happen, and none of them is a software fault.
When nobody owns this, the cost turns up at reception. A patient arrives at a branch that cannot do their test, or argues about a price the assistant quoted last week, and the clinic starts telling staff to double-check whatever the assistant said, which is the work it was bought to take off them.
So the question to settle before you quote is who keeps the catalogue right, every week, for as long as the assistant is live. It can be the clinic, it can be you, or it can be someone who does it for a living. It cannot be nobody, and whoever it is needs the time written into the plan, because it will not fit into the gaps of anyone's existing job.
What to do first, and what to leave until later
Before any model is involved, sit with the client and go through their ten most common questions. For each one, write down where the correct answer lives today and who changes it when it changes. You will usually find that prices live in the practice-management or billing system, that preparation rules live partly in a document and partly in a senior nurse's head, and that which branch does what is known at reception and written down nowhere. That list is the most useful thing you can hand your client early on, because it shows them which answers they cannot yet give reliably themselves, and it is the first honest conversation about who will own the catalogue.
Keep figures out of the prompt from day one, so that the first time a price changes there is only one place to change it. And do not start by indexing every PDF the client has. It is the fastest route to a demo, but the old brochure and the new one will both be in the index, and you will spend your support time explaining why the assistant quoted last year's package.
Questions to put to the vendor, or to your own build
- Change one price in the source system, then ask the assistant. Does the new price come back without anyone touching the assistant?
- Break the connection to the source on purpose. Does the assistant say it could not check, or does it answer anyway?
- For any answer, can you see which record it came from? If not, you cannot tell a lookup from a guess.
- Who keeps the catalogue right after go-live, and is that in the price or assumed?
- When the clinic changes something in its own system, how does the assistant find out?
- Show me a wrong answer from last month, and what changed in the source because of it.
The second question is the one most builds fail. When a lookup fails, the easy path for the model is to fill the silence with something plausible, and "that isn't available" is plausible. An assistant that treats "I couldn't check" as a different answer from "no" is worth more than one with a wider vocabulary. The last three questions are harder to fake: a vendor who really keeps a catalogue will answer them with a name, a routine and an example, and one who does not will talk about the model.
The honest limitation
A well-built lookup against a wrong catalogue gives a wrong answer with a citation attached, and that is more convincing to a patient than a wrong answer without one. A good lookup also does not stop a model from finding the right record and then misreading or ignoring it. That happens often enough that someone has to read what the assistant actually says, regularly, including the conversations nobody complained about. When you scope the work, put that reading into the plan as a named job with an owner, next to the catalogue upkeep, so it is costed at the start.
Keeping that catalogue right is the job I do, for clinics and for the agencies that build for them, so if you are scoping one of these and want to see what the job looks like for your client, write to me.