Why we built FluentBot
Most chatbots hallucinate because they were never trained on your content. We took a different path.
When we started the project, every support team we talked to had the same complaint: generic chatbots sound confident, then send customers to pages that do not exist. The underlying model is fine — the training data is not theirs.
So we flipped the problem. Instead of shipping one more wrapper around a large model, we built the ingestion pipeline first: URLs, sitemaps, PDFs, and crawls, chunked and embedded against a single source of truth you control.
The three hard parts
- Freshness. Documentation moves. Our retrainer diffs the source and re-embeds only what changed, so the bot answers today’s docs — not last quarter’s.
- Citations. Every answer points back to the paragraph it came from. Hover, click, verify. If the citation is weak, the answer is weak, and the content-gap report tells you where to write next.
- Handoff. When the bot hits its limit, the visitor hits a human — with the full transcript, read receipts, and internal notes. No one is forced to watch a spinning loader while an LLM searches its feelings.
What we shipped first
- A retrieval layer that actually cites.
- A widget that respects the host page (Shadow DOM, theme-isolated).
- A team model that works for three-person shops and three-hundred-person orgs.
The rest — analytics, the API, the webhook graph — fell out of those three decisions.
If you are evaluating chat vendors, ask two questions: where does the answer come from, and what happens when it gets stuck. Those two answers tell you almost everything.