Key takeaways
- An AI assistant in our team portal answers internal questions. Its knowledge base is generated from our real documents, not written for the bot.
- 204 entries, produced one for one from two master documents we already maintain. Nobody typed them.
- A hand-written bot knowledge base is wrong the first time a process changes, because nobody remembers the bot exists.
- The sync deletes entries whose source section is gone. People skip that half, and it is the half that stops a retired procedure being recommended forever.
- Access to the assistant is an honesty check, not a login. So nothing goes in it that would hurt if the wrong person read it.
Our team documentation lives in two long documents. One describes every automation we run and answers the same seven questions about each: where it runs, what triggers it, what it does, what a human still has to do, where its state lives, how you tell whether it ran, and what will bite you. The other is the written procedure for how the business operates.
Both are published as internal courses. Which is fine, except nobody reads a course at the moment they need one paragraph out of it. They ask instead. So we gave them something to ask: an AI assistant in the team portal chat, answering out of a knowledge base.
The obvious way to build it, and why we did not
The obvious way is to sit down and write the assistant a knowledge base. Take what you know, phrase it as questions, paste it in. It works immediately and feels productive.
It also starts dying the same afternoon.
Here is the failure. Two months later you change how something works. You update the real procedure, because that is the document people read. You do not update the bot, because it is a different system in a different tool and no line connects the two. Now you have an assistant confidently teaching a process you abandoned, and it keeps doing that for as long as anyone asks, because nothing about being wrong makes it stop answering.
A stale document is a small problem, because a human reading it can tell it is old. A stale assistant is a bigger one. It delivers the answer with the same confidence either way, in one sentence, with no date on it.
Generated, not written
So the knowledge base is generated. A script reads both masters, turns each entry and each section into one question and answer record, and pushes them up. That produced 204 records the first time. Nobody typed any of them.
When either document changes, you run the script again. That is the whole maintenance story, and what matters about it is that the update sits on a path people already walk. Nobody has to remember the assistant. They update the document they were going to update anyway, run the sync that ships it, and the assistant is current as a side effect.
The script is safe to run repeatedly. It keeps a small state file mapping each question to the record it created plus a hash of the content, so every run can tell what actually changed. Unchanged records are skipped. Edited ones are updated in place rather than duplicated.
The half everybody skips
The third case is deletion, the one people leave out.
If you remove a section from your procedure, the sync deletes the matching record. Not for tidiness. A sync that only adds and updates leaves every retired process in the knowledge base forever, and the assistant has no way to know that entry is dead. You end up with a helper that reliably recommends the thing you deliberately stopped doing, which is worse than no helper, because now somebody goes and does it.
Deleting is what makes the source document authoritative. Anything a sync will not remove is not generated from the source. It is a copy that happened to start there.
Who is allowed to ask
The portal is shared. Clients use it for their courses, so the chat is visible to people who are not on our team.
A client-facing assistant answers first and hands over to the internal one only when the person says they are on the team and asks an operational question. That handover is an honesty check. It is not a login, and it would not survive somebody deciding to lie.
We knew that going in, and it shaped the content rather than the gate. Nothing in there is a credential, a key, or a customer's information. It holds a description of how our own business runs, which already sat in a course any team member can open. If revealing something would be a problem, it does not belong in a system whose door is a question.
That is a cleaner way to think about internal AI generally. Do not start with how strong the gate is. Start with what happens if it fails, and only put things behind it that survive that.
One trap worth writing down
During the build, a push went out through an older scripting path that sends the request body as plain text. It stripped every non-standard character on the way, which quietly removed an emoji from a live assistant's personality.
No error. No warning. The write succeeded and the content was quietly different from what we sent. Every script here now sends raw bytes. If you push text into any platform through an API, send an emoji and an accented character through it and read them back. That is a five minute test for a bug you would otherwise find in front of a customer.
What this means for your business
If you are thinking about an AI assistant that answers questions for your team or your customers, the model is not the hard part. Keeping what it knows true is.
Three questions before you build one. Where does its knowledge come from, and is that a document somebody already maintains for their own reasons. What happens when that document changes, and does anyone have to remember the bot for it to stay right. And what happens to an answer you retire, because if nothing removes it, it is still being given.
Generated beats written. Not because writing is worse, but because generated cannot drift.
Want one built for you
We build AI assistants for small businesses that sit on your real documents and stay current as you update them. If you want Go High Level in San Jose set up so it runs itself, start at optechsol.llc.