Your AI agent's knowledge base: what to give it to read and how to keep it alive

The agent replies in two seconds, with an impeccable tone and total confidence: "Quotes are valid for 30 days." The customer hangs up satisfied. The problem is that this policy changed in March — it's 15 now — and the document the agent read is the PDF of the previous terms, which someone uploaded on day one and nobody ever looked at again. The model didn't fail, nor did the script or the escalation rules: the library failed.

When a first agent is being prepared, almost all the attention goes to the visible parts: the script and the tone, the limits and the escalation, the introduction to the team. The knowledge base — the documents the agent reads in order to answer — usually gets sorted in one afternoon: gather whatever exists, upload it, move on. And yet it's the piece that decides, every day and in every conversation, whether the agent tells the truth.

This article is about that piece: what to give an operational agent to read, what never to give it, how to organise the information so it doesn't contradict itself and — the part almost nobody plans — how to keep it alive when the business changes, which is always.

The agent answers only as well as what it has read

An operational agent doesn't invent your company's opening hours or your return periods: it reads them from the documentation you've given it. That's the good news — you control what it knows — and also the responsibility: the quality of its answers has a ceiling, and that ceiling is your documentation.

It's worth understanding the two distinct ways this fails. The first is noisy and benign: the agent can't find the answer, says it doesn't know and escalates to a person. Annoying, but it deceives nobody, and it even leaves a trail: every escalation caused by missing information is a notice of which document is lacking. The second is silent and expensive: the agent finds an answer — the one in the old document, the one in the PDF that contradicts the website — and delivers it with total conviction. The customer has no way to suspect it, the team doesn't see it because the case was resolved "fine", and the error only surfaces when someone complains.

From that asymmetry comes the principle that orders everything else: an agent that knows less and escalates more beats one that knows a lot from dubious sources. A small, correct, maintained base always wins over a large one nobody watches.

What to give it to read (and what not to)

The day-one temptation is to dump everything in: the onboarding manual, the full catalogue, the exported website, three years of internal memos. It's a mistake shaped like a shortcut. What an operational agent needs fits in four categories:

• The real questions with their correct answer. Not the FAQ somebody imagined in a meeting: the questions that actually arrive by phone and email. The best source is your own shared inbox: the twenty or thirty most repeated queries of the last quarter, with the answer that is correct today, are worth more than any manual.
• The stable operational facts. Opening hours, addresses, payment and contact methods, standard deadlines, terms of service. They change little, get asked a lot, and are the ground where the agent shines from day one.
• The policies applied as written. Returns, cancellations, warranties, the requirements of a procedure. If a policy has exceptions that depend on a person's judgement, the policy goes into the base and the exception goes into the escalation rules — not the other way round.
• The phrases that cannot be paraphrased. The legal notice, the recording disclosure, the agent's introduction. They're marked as literal, just as when fixing the voice script.

Just as important is the list of what does not go in:

• Duplicate or obsolete documents. If the 2025 price list and the 2026 one coexist, the agent may quote either. Clean before uploading: one version per document, the current one.
• Internal criteria that must never reach the customer. Margins, maximum discounts, notes like "large accounts get it granted". The agent talks to customers; whatever you wouldn't say out loud in front of one, you don't give it to read.
• Personal data it doesn't need. The knowledge base is general documentation, not a case archive. Each customer's data travels with each specific case, under its own access logic, not in the shared library.
• Anything nobody is going to maintain. This is the hardest filter and the most useful one. Every document is a commitment: someone will have to update it when reality changes. If the honest answer is "nobody", it's better to leave that question out of scope and let the agent escalate it.

A single source of truth for every fact

The most common failure of knowledge bases isn't missing information: it's contradiction. The opening hours appear on the website, in the email footers and in a terms PDF, and all three versions were true at some point — but only one is true today. A person resolves the ambiguity with context ("the PDF is old, trust the website"); an agent has no reason to choose the same way, and the serious part is that it will choose confidently.

The rule is one of hygiene, not technology: every fact lives in exactly one place. One price list, one pricing document. One schedule, one opening-hours sheet. When it changes, it changes there, and only there. If the same fact must appear in several documents for context reasons, one of them is the master and the others point to it instead of repeating the figure.

And there's a second rule for data that changes daily: what gets copied ages; what gets looked up doesn't. An order's status, an account balance, the free slots in the diary are never written into any document: the agent looks them up in the relevant system at the moment of the conversation, as it does when handling after-hours calls and checking the status of a case. The knowledge base holds what stays true for weeks; what stays true for hours gets looked up live.

Information with an expiry date

Between the stable and the live there's a treacherous strip: information that is true until a date. The September promotion, the August opening hours, the special deadline of the tax-season campaign. It produces the most visible errors, because it expires in silence: nobody remembers the document until the agent offers, in October, the discount that ended on 30 September.

The treatment has three parts. First, label the expiry when the document is created, don't trust it to memory: every temporary piece carries its end date visibly. Second, review on expiry: the expiry date is an appointment in the owner's calendar, and on that day the document is updated or retired — not left in "just in case". Third, prefer removal over accumulation: a base where five past promotions coexist "for context" is a contradiction factory.

The operational version of this idea is simple and resembles what you already do with your website: every business change that affects what the agent says must include "update the agent" in its checklist. If prices go up, the day the new price list is published, the agent's document is updated. If summer hours start in July, the document goes in during June with its expiry set. The agent stops being a separate project and becomes one more channel you maintain, exactly like the website or the phone system.

Keeping it alive: the correction cycle

A knowledge base is never finished: it's cultivated. And the raw material is the agent's own conversations, which point every week to where the next gap is. The cycle has three sources and a single person in charge.

The first source is escalations due to missing information. When the agent transfers a case because it didn't know the answer, it leaves behind a valuable fact: a real question the base doesn't cover. Reviewing those cases weekly turns gaps into documents, starting with the ones that repeat most.

The second is the team's corrections. When someone reviews one of the agent's drafts and corrects it, or spots a wrong answer in a transcript, that correction has to reach the base — not stay in the individual case. This is the circuit we described when discussing team adoption: a team that sees its corrections applied within days feeds the agent; one that sees them die in a suggestion box stops proposing them.

The third is business changes, which arrive through the checklist of the previous section instead of by surprise.

The person in charge is the agent owner: one specific person from operations who decides what goes in, retires what expires and applies the corrections. It's not a technical role or a full-time job: once the flow has stabilised, the weekly review — flagged conversations, escalations due to missing information, documents about to expire — usually fits in an hour. What doesn't work is spreading it across everyone: a library everyone is responsible for ends up exactly like a shared drive everyone is responsible for.

Signals that the base has gone stale

No knowledge base announces that it has expired; you have to read the indirect signals, and it pays to know them before you need them:

• Confidence without truth. The agent states with total conviction things that are no longer true. It's the most dangerous signal because it doesn't look like an error: you detect it by reading random transcripts or checking answers against current reality, not by waiting for complaints.
• Escalations rising for one specific intent. If a question the agent used to resolve on its own starts escalating more, something changed in reality that its document doesn't reflect.
• Customers correcting the agent. "Well, the website says something else", "that's not what I was told last month". Every appearance of that phrase in a transcript is a contradictory or expired document with a first and last name.
• The team going back to answering by hand. When reviewers stop trusting the agent's drafts and rewrite from scratch, the distrust almost always points to stale information — and it's the first step of the silent veto you already know.

The answer to any of the four is the same: go to that intent's documents, compare them against today's reality, and correct or retire. It's library work, not technology work.

The next level: real-time integration

Everything above works with a documentary base: the library that holds what stays true for weeks. The next level is connecting the agent to the systems where the rest lives: the CRM, the management software, the diary, the ticketing tool. An integrated agent doesn't answer from a copy: it looks up the customer's record at the moment of the call, sees whether the invoice is paid or the order shipped, checks the diary's real free slots before proposing a time. And it works in both directions: besides reading, it writes — it logs the call on the customer's record, updates the case status, creates the follow-up task for the sales rep.

The effect on the knowledge base is twofold. First, it shrinks: every fact the agent looks up live is a document that disappears from the maintenance list, and the risk of answering from an expired copy disappears with it. Second, the answers move up a category: from "the usual delivery time is five days" to "your order left yesterday and arrives tomorrow". Any website can give the first one; the second is what makes the customer stop asking for a person.

There's no need to integrate everything on day one: the healthy pattern is to start with the documentary base and connect the first system once the flow already works, beginning with the one that concentrates the most questions — the CRM if what comes in is commercial, the diary if it's appointments, the case management system if it's status enquiries. And since every operation uses different tools, this part doesn't come out of a box: if you're thinking about a specific flow with your CRM or your management software, write to us and we'll build it with you — we adapt to the systems you already use, not the other way round.

How BeeAgent fits in

In BeeAgent, the knowledge base is managed by the same person who manages the rest of the agent: the operations team, no-code and with no tickets to development. Uploading a new document, replacing a price list or retiring an expired promotion are matters of minutes, which is what makes the weekly correction cycle viable — the difference between keeping the base alive and promising it will be kept alive.

Traceability closes the loop: every conversation is logged, so the agent owner can read the week's transcripts, locate the escalations caused by missing information and see exactly what the agent answered and where the answer came from. And for live data, the agent queries the connected systems at the moment of the conversation — a case's status, free diary slots — so the library holds only what it should hold: the information that stays true for weeks, not the kind that changes every hour.

Start with the library this week

If you're preparing your first agent — or if the one you have has already given an outdated answer — this is the order that works. First, the thirty real questions: pull them from last quarter's emails and calls, with the answer that is correct as of today. Second, the filter of what stays out: duplicates out, old versions out, internal criteria out, and out too with anything nobody will maintain. Third, one place per fact: if an opening schedule or a price list lives in three documents, pick the master and retire the rest. Fourth, expiry dates: every temporary piece, labelled and with its review in the calendar. And fifth, the owner and their weekly hour: one person, a short cycle, corrections applied within days.

With that, the agent has what it needs to tell the truth today and a mechanism to keep telling it when the business changes tomorrow.

Conclusion

The conversation about AI agents usually revolves around the model: which one understands better, which one sounds more natural. But in daily operations, the difference between a reliable agent and one you have to watch is almost never in the model: it's in the library it reads. Which documents it has, whether they contradict each other, who maintains them and how long they take to reflect a business change. That library isn't built once: it's cultivated every week, and the cost of cultivating it is a fraction of the cost of the wrong answers it prevents.

If you want to see how this translates into a concrete flow, the use cases show real examples — from customer service to email triage — or write to us and we'll build that first thirty-question base with you.