This page walks through how that grounding works technically (retrieval-augmented generation, in the terms you'll see referenced elsewhere), what happens when the bot genuinely doesn't know something, and how to keep answer quality high as your product changes.
Scripted bots vs. an agent grounded in your content
An older generation of chatbots worked off decision trees: match the visitor's exact phrasing to a pre-written branch, or fail. Ask the same question five different ways and you'd get five different outcomes, because the bot wasn't understanding the question — it was pattern-matching against a script.
A retrieval-augmented agent works differently. When a visitor asks something, the system searches your knowledge base for the most relevant passages — from crawled pages, uploaded documents, or Q&A pairs you've written — and hands those to the language model as context for its answer. The model handles the variation in how people phrase things; your content stays the source of truth for what the answer actually says.
Training it on what you already have
There's no separate authoring step. Point a bot at a URL and it crawls the page; upload a PDF, DOCX, TXT, MD, or CSV and it's chunked and indexed; or write short Q&A pairs directly for the questions you already know come up. All three source types can be mixed on a single bot, and any of them can be added or removed at any time from the Knowledge tab.
When you update the underlying content — a docs page changes, a new FAQ gets added — re-embedding refreshes what the bot can retrieve, so answers stay current without rebuilding the bot from scratch.
Setting the tone
Beyond the knowledge base, the system prompt and personality/tone settings control how the agent talks — formal or casual, terse or thorough, and what it should never do (quote a price it isn't sure of, for instance). These settings apply on top of retrieval; they shape delivery, not the facts being retrieved.
What happens when it doesn't know the answer
Grounded answers also mean grounded limits — if the knowledge base doesn't cover something, a well-configured agent should say so rather than guess. That's a system-prompt instruction worth being explicit about: tell the bot to say it isn't sure and offer to connect the visitor with your team, rather than filling the gap with something plausible-sounding but wrong.
This is also where lead capture and support meet: an instruction like "if you can't answer, ask for their email so the team can follow up" turns a dead end into a handoff instead of a dropped conversation. The visitor gets acknowledged, and you get a record of exactly what the agent couldn't cover — useful signal for what to add to the knowledge base next.
See it running on your own content
First month free — no credit card required.
Keeping quality up as you scale
Every conversation can be closed and reviewed from the Conversations tab, and visitors can rate a conversation, giving you a running signal for where answers are landing and where they aren't. The bot's usage and analytics views show message volume and trends over time, so a spike in unanswered or poorly rated conversations about a particular topic is visible before it becomes a pattern of support tickets.
Treat the knowledge base as something that keeps growing, not a one-time upload — the most common reason a support agent underperforms months in is that the product moved on and the training content didn't.
Setting it up
Create a bot, write a system prompt describing its role and what it should do when it's unsure, then add your help docs, key product pages, and any Q&A pairs for questions your team answers often. Set the welcome message and tone, then embed the widget — as a floating bubble via script tag, or as a standalone page for a dedicated support link. See the embedding guide for the exact steps on your platform.