Knowledge Bases
How Knowably organizes documents into scoped knowledge bases so each AI agent searches only the content it should, avoiding irrelevant noise.
The first agent I built searched everything. Every SharePoint folder, every Confluence space, every Jira project, every uploaded PDF. One big pile.
A user asked about parental leave. The agent pulled in a Jira ticket about authentication refactoring, a Confluence page about server uptime, and - buried at the bottom - one relevant paragraph from the actual HR handbook. The answer was a confident, well-formatted mess that mixed policy language with sprint planning notes.
I tried fixing it with prompt engineering. "Only answer from HR documents." "Ignore technical content." The agent still retrieved everything. It just got better at pretending irrelevant results were relevant.
The problem was never the language model. The problem was search scope. If the retrieval step returns noise, nothing downstream can fix it.
That is why I built knowledge bases.
Search Everything Is Not a Strategy
Most organizations I talk to have the same starting point. Knowledge lives in six, eight, ten systems. Every system has its own search. None of them talk to each other.
The first instinct is always the same. Connect everything. Let the AI figure it out.
I tried this. It fails in predictable ways.
An HR agent retrieves engineering tickets. A sales agent surfaces internal audit reports when a customer asks about pricing. A support agent quotes an executive's draft memo instead of the product documentation.
You need boundaries. Not rigid ones. Flexible boundaries you can adjust in seconds.
The Model Is Simple
Data sources hold documents. Knowledge bases group them. Agents search them.
That is it. Three layers. I kept it simple on purpose.
A data source is a connection to where documents live - SharePoint, Confluence, Jira, email, GitHub, a folder of uploaded PDFs. It handles authentication and syncing. A pipe to your content.
A knowledge base groups data sources into a focused collection. Give it a name. Pick the data sources that belong. Done.
An agent is assigned to one or more knowledge bases. When a user asks a question, the agent searches only the documents inside those knowledge bases. Nothing else. It cannot see documents outside its scope.
Crossing Sources Is Where It Gets Interesting
One knowledge base can combine data sources from completely different systems.
I built a "Product" knowledge base for a client. Confluence space with product specs. Jira project with feature requests and bug reports. SharePoint folder with release notes. Uploaded architecture diagrams. Four systems. Four content formats. One searchable domain.
A product manager asked: "What was the rationale for the authentication redesign?"
The agent pulled context from a Confluence design doc, a Jira epic with the original requirements, and a release note summarizing the shipped feature. One answer. Three sources. Each one cited so you can click through and verify.
You cannot get this by searching each system separately. Each system only has a piece of the story. The synthesis across sources is the point.
One Source, Many Knowledge Bases
Knowledge bases and data sources have a many-to-many relationship. This matters more than it sounds.
Your "Company Policies" SharePoint folder might belong to both the HR knowledge base and the Legal knowledge base. The documents are not duplicated. Both knowledge bases reference the same indexed content. You are just changing which agents can see it.
An agent can also search multiple knowledge bases. A general-purpose company assistant might search "HR Policies" and "IT Documentation" simultaneously. The search runs across both as a single unified query - results surface by relevance, regardless of which knowledge base they came from.
This is where the architecture pays off. Start specific. One knowledge base per team. Then widen the scope later if a use case calls for it. Add or remove a data source from a knowledge base and every agent using it is immediately affected. No reindexing. No reprocessing. The next query uses the new scope.
Why I Chose Simplicity
I could have built a rules engine. Conditional filters. Document-level access control lists. Tags and metadata queries.
I did not.
A knowledge base is a name and a list of data sources. No rules. No filters. No configuration beyond picking what goes in.
Complex setups emerge from composition, not configuration. Need different agents to see different subsets of documents? Create different knowledge bases. Need one source visible to three agents? Put it in a shared knowledge base. The building blocks are simple. What you build with them does not have to be.
I have seen what happens when scoping systems get clever. They become a second problem to manage on top of the first one. Filters that nobody remembers setting. Rules that silently exclude documents. Access policies that drift out of sync with reality.
Grouping is enough. It is the simplest thing that works, and simple things stay working.
How Scoping Actually Works
This is not application-level filtering. Scoping happens at the database query level.
When documents are ingested, they are chunked into passages and embedded as vectors in PostgreSQL. Each chunk belongs to a document. Each document belongs to a data source. Each data source belongs to one or more knowledge bases.
At query time, the retrieval pipeline filters chunks to only those from data sources within the agent's assigned knowledge bases. This filter is part of the query itself. The search never touches documents outside the agent's scope.
I made that decision early. Post-processing filters are a liability - you retrieve everything and then throw most of it away. Filtering at the query level means irrelevant documents never enter the pipeline at all.
Common Patterns
Department-specific agents. The most common pattern. An HR knowledge base with employee handbooks and policy documents. An engineering knowledge base with Jira, Confluence, and GitHub repos. A sales knowledge base with product docs and pricing sheets. Each department gets an agent scoped to its own domain.
Shared sources across domains. A "Company Policies" data source added to both the HR and Legal knowledge bases. The documents exist once. The groupings differ.
Progressive disclosure. Start narrow. One agent, one knowledge base, one team. Prove the value. Then expand. The architecture supports growing without rearchitecting anything.
Get Started
Connect a data source. Create a knowledge base. Assign it to an agent. Ask a question. The scoping means you get focused answers from the start - not a firehose of everything.