What is a knowledge base for an AI agent?
The documents an agent may answer from. agent4.io keeps two kinds — your company's vetted material, and each customer's own files — retrieved together but never confused for one another.
The knowledge base is what makes an agent yours rather than generic. It is the answer to "where did that come from" — and if the answer isn't in there, the agent should say so.
Two knowledge bases, not one
Most platforms give you a single pile of documents. That is enough for a support bot answering FAQs and nowhere near enough for real business, because the two questions a customer actually asks are different in kind:
"What are your terms, and do I qualify?" — that is your material. Fee schedules, eligibility rules, current regulations, product sheets. It is the same for everyone who asks, it is vetted by you, and it is authoritative.
"Here's my diploma and my employment letter — where does that leave me?" — that is their material. It belongs to one customer, it is often sensitive, and it is meaningless to anyone else.
agent4.io keeps these as two separate systems, deliberately not sharing an implementation:
| Tenant knowledge base | Customer knowledge base | |
|---|---|---|
| Owned by | You, the business | One end customer |
| Contains | Regulations, pricing, policy, product terms | Their documents, certificates, correspondence |
| Isolation | Filtered by tenant at the API | Enforced by the database, per customer and space |
| At rest | Not encrypted — it is your published material | Encrypted with that customer's own key |
| Curated by | Your admins, reviewed before publishing | Uploaded by the customer as they go |
Why real answers need both at once
Take an immigration enquiry. "Do I meet the salary threshold for this route?"
The threshold is in your tenant knowledge base — the current rule, as vetted by your firm. Their salary is in their own — the employment letter they uploaded last week. Neither half answers the question. An agent with only your documents can recite the rule and then ask the customer to do the comparison; an agent with only their documents knows their salary and nothing about what it needs to clear.
Both are retrieved on the same question, and the answer is the comparison.
The part that stops them being confused
Retrieved passages are not poured into one bucket. Each source arrives as its own block with its own framing:
- Your material is introduced as authoritative — to be followed, and each knowledge base carries its own instructions to the model, written by you. A regulations base can say: this is the vetted current rule; answer from it, do not fall back on prior knowledge, and if it is not covered here, say so.
- The customer's material is introduced as for reference — theirs, useful, and not a source of policy.
That distinction is the difference between "your firm's fee is X" and "the customer believes the fee is X because it says so in a document they uploaded". An agent that cannot tell those apart will eventually quote a customer their own mistake back to them as your policy.
A knowledge base with no relevant passages contributes nothing at all — not even a header. Relevance is decided by vector distance before the model sees anything, so an unrelated base does not sit there consuming its attention.
Tuning strictness per knowledge base
Each knowledge base has its own relevance floor, because the right level of caution is not the same everywhere. A regulations base should be strict — below the floor, returning nothing and answering "I don't have that" is correct, and far better than a near-miss paragraph about a different route. A general FAQ can be looser, where a roughly related answer is still helpful.
A knowledge base is not a training set. Nothing you upload changes the model; it changes what the model is allowed to read at the moment it answers. Which is also why correcting a document corrects every future answer immediately — no retraining, no redeploy.