A support bot that answers from your documents

Half of everything support is asked has already been written down: in the price list, in the delivery terms, in the manual. A human answers those ten times a day and the customer waits anyway. This scenario answers on its own, but only from your documents: what is not in them, it does not invent.

What is inside

1. Customer question — the entry.
2. Knowledge base tells the search where to look, wired with a data connection.
3. Search across documents pulls a few matching fragments out of the base.
4. Answer from what was found — the agent. What reaches it is not the customer’s question but the fragments, and its system prompt tells it to answer only from those.
5. Send to the customer — the exit.

The “does not invent” property lives in the agent’s prompt, not in advice on this page: the grounding rule ships with the template. Delete the prompt and the model starts filling gaps from what it knows, and the customer cannot tell the two apart.

What to set up for yourself

• The base id in the Knowledge base node: replace REPLACE_ME with your own.
• The agent’s system prompt. Keep the grounding rule; add the tone and the boundaries: how to address people, what to offer when there is no answer, when to hand over.
• How many fragments (top_k on the search). Start with four to six. Too many is noisy and expensive; too few makes the bot say “I don’t know” when the answer is right there.
• The failure text on the exit node: that is what the customer sees if something breaks.

What to connect

No connections; documents. Open Documents, create a base, upload the price list and the policies. One practical note: upload what a person would actually read. A forty-page contract in legal language makes answers worse, because the search finds formally similar paragraphs that nobody can answer from.

Publish on the Publish tab: to the chat page, to a widget on your site, or to Telegram. The graph does not change — it does not know which door the question came through.