← Back to Blog

AI Knowledge Base That Learns From Conversations, Explained

An AI knowledge base that learns from conversations, the way Total Chat builds one, works through drafts and human review. It turns the questions your assistant couldn’t answer into draft help articles, a person approves, edits or rejects each draft, and the approved article becomes something the assistant can find the next time anyone asks. The loop runs on Starter and up: when a conversation exposes a gap in the knowledge base, the assistant drafts an article, you get an email, and nothing drafted from a conversation goes live until you approve it. The “learning” is the knowledge base growing, one approved article at a time.

Last updated: October 2026

That sounds like a technicality. It isn’t. It decides what you can inspect, what you can undo, and where the work lands on your team. It also changes where help content comes from: the questions users actually type, not the ones your team guessed at before launch. If your help docs went stale within a quarter, that’s not because you were careless. No team can predict every question. Our broader guide to conversational AI chatbot knowledge management covers all the sources that feed the knowledge base. This post follows a single unanswered question through the loop, start to finish, and spends most of its time on the step that decides whether the loop helps you: the review.

Why “learning” here means a content change

Total Chat’s assistant is instructed to search the knowledge base before it answers and to base its answers on what it finds, not to make things up. Search is semantic (PostgreSQL with pgvector), so a question doesn’t have to match an article’s wording word for word to find it.

Follow that through. If the answers can only be as good as the articles the assistant finds, improving the answers means improving the articles. The mechanism is drafts and approvals, and what changes is a set of documents you can read, edit and delete.

I think that’s the version you want. A model that quietly absorbed every chat would also absorb every confused user’s wrong guess about how your product works, and you’d have no line item to correct. A draft article is a line item.

One question, start to finish

Here’s the path a single gap takes.

1. A user asks something the knowledge base doesn’t cover. Say a logged-in user asks how to export last month’s data, and no article explains it. The assistant has nothing to ground an answer in. It’s instructed to say so plainly, that it doesn’t have that information and the user should contact support, rather than guess. If you’ve set an escalation email, the assistant can also hand the conversation to a person by email with the full transcript attached.
2. The assistant drafts an article from that conversation. This is the gap-drafting step, on Starter and up. The draft is a proposal, not a published answer.
3. You get an email, and the draft waits in the dashboard. It sits with your other pending drafts. Drafts don’t count toward your plan’s published-article cap, so a backlog doesn’t cost you room.
4. You approve it, edit it or reject it. Approving publishes it. Publishing needs room under the cap: 100 published articles on Starter, 500 on Pro, unlimited on Business.
5. The next person who asks gets the answer. The article is now in what the assistant searches. If you gave it a page route, search ranks it higher for users on that page.

Only step four needs you, and it’s where the value is won or lost.

What a good review actually checks

The draft is weakest exactly where you needed it. It exists because the knowledge base had nothing on the topic, so any product specifics in it (menu names, which plan includes what, how many steps) are the part to check hardest. Treat it as a well-phrased question with a first guess attached.

A review that takes the loop seriously asks five things.

Is it true? Check every step against the product as it ships today. If you can’t confirm a detail, cut it before you approve. An approved article gets repeated with full confidence to everyone who asks.

Is it general? The draft started from one user’s situation. Strip anything specific to that person or their account. The article will be shown to every user who asks something similar, not just the one who asked first.

Does it already exist? Sometimes the article was there all along and search didn’t connect it to the user’s phrasing. Then reject the draft and improve the existing article. Articles can carry a list of the common questions they answer and a set of keywords, and both can be updated through the knowledge base API. Adding the user’s own wording there fixes the miss without a near-duplicate eating into your cap.

Who should see it? Every article has a public visibility flag. Leave it on and the article can surface in pre-login chat on your marketing site too. Turn it off and it only surfaces for logged-in users, enforced on the server. Anything about cancellation, billing disputes or admin workflows belongs in the second group.

Is this a documentation problem at all? If the conversation was really “this button does nothing,” it’s a bug. The assistant files those as structured bug reports with the page address, browser and recent JavaScript errors, on every plan. If ten people a week ask where a setting lives, an article helps, but the real fix may be in your UI.

My strong opinion here: edit more drafts than you approve as-is. A draft approved untouched is the assistant’s first guess, now published with your name on it.

What improves over time, and what doesn’t

Some things get better as the loop runs. Others don’t move at all, and it’s worth knowing which before you promise your team anything.

Gets better as you approve drafts	Doesn’t change on its own
Coverage of questions real users actually ask	Drafts nobody reviews
Matching on users’ wording, if you add their phrasing to articles	Topics nobody has asked about yet
Page-specific answers, if articles carry a page route	Facts in a draft you approved without checking
Fewer repeats of the same unanswered question	Answers in pre-login chat that depend on which page the visitor is on

The left column is all downstream of review. The right column is why the loop doesn’t replace seeding. Questions nobody has asked yet still need articles you write through the KB API, drafts from the URL crawler (3 to 8 per crawl, also waiting for your approval), or the feature articles the codebase scanner publishes for Next.js apps. The scanner’s articles publish right away while you’re under the cap, because they come from your code rather than from a conversation.

The last row matters for marketing-site chat. The pre-login widget doesn’t use the visitor’s current page in its answers, so there, the article’s wording and its visibility flag carry the whole load.

Where the loop breaks down

The honest limitation: this is a queue, and queues only help if someone clears them. A team that lets drafts pile up has a knowledge base that grows at the same rate as one with no drafting at all. It just has more email. There’s a ceiling, too: once 20 conversation drafts are waiting, the assistant stops drafting new ones until you clear some, and it skips a question that closely matches a draft already in the queue. I’d put draft review on someone’s calendar by name, even if the slot is short.

Two more caveats. Gap drafting isn’t on Free, so on Free you’re finding gaps yourself through the dashboard’s conversation analytics and top questions. And the loop can only learn from conversations that happen, so a low-traffic app will see drafts trickle in slowly. That’s fine. Seed the obvious articles first and let conversations fill in what you didn’t predict.

Setup details for the API fields, visibility flag and plan limits are in the docs. If you want the wider picture of how these assistants work before you set any of this up, start with What Is a Conversational AI Chatbot? (And How Total Chat Compares).

Frequently Asked Questions

Does Total Chat’s knowledge base actually learn from conversations?

It grows from them, through drafts you review. On Starter and up, when a conversation shows the knowledge base doesn’t cover something, the assistant drafts a new article from it and emails you. You approve, edit or reject the draft in the dashboard. Once approved, it’s published to the knowledge base the assistant searches before answering, so the next user who asks can get that answer.

Can a draft written from a conversation go live without my approval?

No. Drafts the assistant writes from conversations wait in the dashboard until you approve, edit or reject them, and URL crawler drafts wait the same way. The one exception is the codebase scanner, which publishes short feature articles built from your code straight away while you have room under your plan’s published-article cap.

Do pending drafts count toward the article cap?

No. Only published articles count. The caps are 20 published articles on Free, 100 on Starter, 500 on Pro, and unlimited on Business and Enterprise. A backlog of drafts doesn’t use any of that room, but approving a draft does, and publishing past the cap is refused until you free up space or move to a larger plan.

What should I check before approving a conversation draft?

Check that every product detail is correct today, because the draft was written about a topic the knowledge base had nothing on. Remove anything specific to the user who asked. Look for an existing article that already covers it, set the public visibility flag for sensitive topics, and file real bugs as bug reports instead of documenting around them.

---