Most chatbot designs start from the answer. What documents do we have, how do we index them, how do we get the model to summarise them well. The ones that people keep using start from the question, and from the person asking it.
A metaphor I keep coming back to: every user message is a seed, the context is the soil, intent recognition decides what needs to grow, and retrieval supplies the nourishment. The chatbot's job is to grow a response that earns curiosity, trust and accountability.
Metaphors are cheap. This one is useful only when it turns into concrete system behaviour, so here is the translation, section by section. It comes out of building a document chatbot for a regulated financial client, the one whose evaluation I wrote about earlier.
1. Treat each message as a seed of intention
A chatbot should work out what the user is trying to accomplish, not match keywords. Take one message from a workplace assistant:
"Why does our team keep missing deadlines?"
That sentence can carry several intentions at once:
- Understand the causes of the delays.
- Get practical advice.
- Find the company's escalation process.
- Express frustration and look for support.
The intent stage should therefore produce more than a label. It should record the likely goal, the entities involved (which team, which project), what context is missing, and how confident it is. Emotional tone can shape how the reply is worded, but it stays a tentative signal, never a fact about the person.
When the intention is unclear, ask exactly one useful question. "Are you looking to diagnose the delays, or to find the escalation process?" One question, with the options named, is faster for the user than a long answer to the wrong question.
2. Use context as soil
The same message needs different answers in different soil. A question about deadlines from a project manager in a live incident is not the same question from a new hire reading the handbook.
Useful context, in the order it usually matters:
- The current conversation, including what has already been ruled out.
- The project or record being discussed.
- Preferences the user has stated explicitly.
- The information this user is authorised to see. Authorisation is part of the context, not a filter applied afterwards.
Separate temporary conversation context from lasting memory. A passing frustration should never become a permanent judgement about someone. Save durable preferences or facts only under explicit consent and retention rules, and make it possible to show the user what has been kept.
3. Make retrieval the nourishment
Retrieval-augmented generation supplies evidence before the model writes. The intention decides what to retrieve and how the answer should be shaped:
| User intention | Knowledge to retrieve | Response approach |
|---|---|---|
| Explore an idea | Relevant examples, research, previous experiments | Offer possibilities and useful questions |
| Find a policy | The current approved policy and its exceptions | A direct, cited answer |
| Resolve a problem | Troubleshooting guides and similar resolved cases | The next practical steps |
| Understand responsibility | Ownership records, commitments, escalation rules | Who owns what, based on evidence |
The retrieval step itself should:
- Apply access permissions before retrieving, so nothing the user may not see ever reaches the model.
- Search with the user's goal and context, not the raw sentence.
- Rank results for relevance, authority and freshness, in that order.
- Keep source references attached so the answer can cite them.
- Say plainly when the available knowledge does not support an answer.
Retrieval should also go looking for exceptions and conflicting evidence. A garden that only feeds existing beliefs becomes an echo chamber, and a chatbot that only retrieves what agrees with the question becomes one too.
4. Turn the values into response rules
Curiosity, trust, accountability and care are values. Values belong in the system's instructions and, more importantly, in its evaluation criteria. Retrieving documents about values does not reliably produce the behaviour. Rules and tests do.
| Value | Chatbot behaviour | Safeguard |
|---|---|---|
| Curiosity | Ask useful questions, explore alternatives, explain uncertainty | Do not question when the request is already clear |
| Trust | Cite evidence, separate facts from suggestions, respect privacy | Never invent policies, sources or certainty |
| Accountability | Name practical next steps and documented ownership | Never claim an action was completed without confirmation |
| Care | Respond respectfully and recognise the user's situation | Do not diagnose emotions or assign blame |
These values govern how the chatbot communicates. They must never change what the evidence says.
5. Implement the complete flow
Not every message needs retrieval, and that is the first routing decision. The flow, end to end:
- Receive the user message.
- Identify the intention and the uncertainty around it.
- Add the conversation context the user is permitted to have.
- Choose a route: answer directly, ask one clarifying question, retrieve knowledge, or call an authorised tool.
- For retrieval: fetch and rank the supporting evidence.
- Generate the answer with curiosity, trust and accountability.
- Check the evidence, the permissions, and any claim that an action was taken.
- Respond with sources and a practical next step.
A greeting takes the direct route. A company-policy question needs authoritative knowledge. A request to update a record needs an authorised tool, with confirmation. Retrieval provides knowledge; tools perform actions. Keeping those two apart is what stops a chatbot from saying "done" about something it never did.
6. Tend the system through evaluation
"Nurturing each day" is not a sentiment. It is a maintenance schedule for the knowledge base and a review loop for the chatbot's behaviour:
- Remove or mark outdated and duplicate documents. Stale policy is the most common source of confident wrong answers.
- Test whether intentions are recognised correctly, on real phrasing collected from users.
- Check whether retrieval finds the right evidence, and whether it finds the exceptions.
- Measure whether answers are supported by what was retrieved and useful to the person.
- Review mistakes and user corrections before changing anything.
Do not treat every user statement, or every thumbs-up, as verified knowledge. Improvement comes from reviewed evidence and controlled updates, not from the system learning whatever it is told. The 21-case evaluation is one concrete way to run this loop.
What it sounds like
For the deadline question, a well-designed chatbot might say:
Repeated delays sound frustrating. The project records show two tasks waiting on approval, and the delivery guide names an approval owner. Those records suggest a possible bottleneck, but they do not establish the full cause. A useful next step is to confirm those dependencies with the owner. I can help draft that conversation.
In production each factual claim there carries a citation to the actual record. The reply shows curiosity by investigating, trust by limiting what it claims, and accountability by naming a concrete next step and offering to help with it, without pretending to have done it already.
That is the whole pattern. Seed, soil, nourishment, and a gardener who checks the evidence before promising a harvest.