Company Brain vs RAG vs Knowledge Base: What Is the Difference?
A company brain, RAG and a knowledge base differ: the brain is a governed model of the organisation that RAG reads.
A knowledge base is content that people write for other people to read. Retrieval-augmented generation, or RAG, is a technique that fetches relevant passages and hands them to a model so it can answer from them. A company brain is a governed model of the organisation itself: its people, systems, relationships, history, evidence and access rules. The three are different kinds of thing. A knowledge base is a source, RAG is a method, and a company brain is the shared place both can sit inside, with RAG as one of the ways it gets read.
People mix them up because all three show up when someone says "let the AI answer questions about our company". This post separates them, shows when each is enough, and suggests a path from the one you probably already have to the one you may need.
What exactly is each one?
A knowledge base is a curated collection of articles, how-to guides, policies and answers. Someone writes each page, someone owns it, and readers browse or search it. Its unit is the article. If you want the longer treatment, our guide to what a knowledge base is covers types, structure and upkeep.
RAG is a pattern for model applications. Documents are split into chunks, the chunks are indexed (usually with embeddings, often with keyword search alongside), and at question time the closest chunks are pulled out and placed in the model's prompt. Its unit is the passage. The RAG architecture and implementation guide goes through chunking, retrieval and evaluation in detail.
A company brain holds the organisation as entities and relationships: people, accounts, groups, reporting lines, systems, owners. Each fact carries evidence and a status, history is kept, and every read is filtered by who is asking. Its unit is the fact about the organisation, with the evidence for it. The company brain overview describes Swfte's design.
How do they compare side by side?
| Question | Knowledge base | RAG | Company brain |
|---|---|---|---|
| What is it | Written content | A retrieval technique | A governed model of the organisation |
| Main reader | People | A language model | People, models, agents and analytics |
| Unit of storage | Article | Text chunk and its embedding | Entity, relationship and evidence |
| Keeps history | Page revisions, if any | Usually only the latest index | Yes, readable as of a past date |
| Knows who owns what | Only if someone wrote it down | Only if a passage says so | Modelled directly from sources |
| Access control | Per space or page | Depends on how it was built | Filtered by the asker's identity on every read |
| Says how sure it is | No | Similarity score only | Evidence status on each fact |
| Effort to keep current | Writers and reviewers | Re-indexing pipelines | Connectors syncing from sources |
When is each one enough?
A knowledge base is enough when the audience is people, the content changes slowly, and the questions are about how to do things. Onboarding guides, expense policy, product documentation. A good search box on a well-kept knowledge base still beats a chatbot on a badly kept one.
RAG is enough when you want a model to answer in natural language from a body of documents, the documents can be read by everyone who will ask, and the questions are about what the documents say. A support assistant over public product docs is the classic case. So is a team assistant over a shared project folder.
A company brain becomes necessary when the questions are about the organisation rather than about a document, when different people are allowed to see different things, when answers have to be explainable later, or when agents are going to act on the answers. The jump usually happens the first time an agent needs to know who to ask for approval.
What can RAG alone not answer?
RAG finds passages that look like the question. That works when the answer is written down in one place. Many of the most useful questions about an organisation are not written anywhere as a sentence.
Who owns this? Ownership is a relationship between a team and a system, and it changes. A wiki page might say "Payments is owned by the Platform team", but it might be two reorganisations out of date, and RAG has no way to tell. A brain holds ownership as a fact with a source and a status, and can say when it was last observed.
Who was in the group last March? A RAG index usually holds the current state of documents, not the history of a directory. Questions about the past need data that was recorded as it happened and is never overwritten. A brain keeps that history and can be read as of a date.
Which of these facts is disputed? If two sources disagree about a person's manager, RAG will retrieve whichever passage scores higher and the model will state it with confidence. A brain records both, marks the fact as disputed, and lets the reader decide or ask a person.
How many people can approve this change? This needs transitive group membership: people in groups that are in groups. That is a graph question. Passages cannot answer it reliably, because no passage contains the answer.
The knowledge graph page shows how entities, relationships and history are stored to answer questions like these.
How does access control differ?
This is where many RAG projects get into trouble. The simplest build indexes every document with one service account and lets everyone query the index. The model then answers from documents the asker could never open in the source system. Nobody intended a leak, but the index flattened the permissions.
A safe design keeps the access list of each source object next to the object, and filters every retrieval by the principals of the person asking: their account, their groups, and the groups those groups belong to. If the access list is unknown or incomplete, the object should be treated as invisible rather than public. That rule sounds strict. It is the only one that holds up when someone checks.
Doing this well needs an accurate picture of who belongs to which group, which is exactly what a company brain's directory layer provides. In Swfte's design the rule is that a reader never gets more access than the asking user. Retrieval over documents with per-object access lists, filtered inside the database, exists as tested libraries and is in progress; the HTTP endpoints are not finished. The directory sync and group resolution it depends on are built.
Why do evidence statuses matter?
A knowledge base page is either published or not. A RAG result has a similarity score, which measures how close the passage is to the question, not how true it is. Neither tells a model how much to trust what it read.
A company brain attaches a status to each fact. Swfte uses seven: observed, corroborated, verified, inferred, stale, disputed and unknown. An agent deciding who to send an approval request to can treat a verified reporting line differently from an inferred one. An answer to a person can say "this is inferred from group membership and has not been confirmed". That honesty is what makes an answer usable for anything consequential.
How do freshness and upkeep compare?
Knowledge bases go stale through neglect. Keeping one current costs writer and reviewer time, every week, and the cost grows with the number of pages.
RAG indexes go stale when the pipeline stops running or when documents are deleted at the source but stay in the index. The cost is engineering: re-indexing, deduplication, and handling deletes and permission changes, which are easy to forget.
A company brain stays current through connectors that sync from the systems of record. Facts that are not seen again age into "stale" rather than silently remaining true. The cost is in running and monitoring those connectors and in deciding which sources to trust when they disagree. It moves the effort from writing to wiring, and the wiring is shared by every tool that reads from the brain instead of being repeated per tool.
How do you move from one to the next?
You do not have to replace anything. A sensible path looks like this.
- Start with the knowledge base you already have. Keep it. It is good content for people, and it will become one source among several.
- Add RAG over it for a single, low-risk use. A team assistant over content everyone in that team can read. Learn how retrieval behaves on your material.
- Add the directory. Connect your identity sources so the system knows who people are, which groups they are in and who they report to. In Swfte this is the built part: Active Directory and LDAP, Microsoft Entra ID, Okta and Google Workspace, read-only.
- Make retrieval respect identity. Filter every answer by the asker's principals, using the directory you just connected.
- Add sources one family at a time. Documents with their access lists, then systems such as code, cloud and tickets as collectors become available. These are on Swfte's roadmap, and the sources page lists what is built and what is not.
- Point every AI tool at the same place. Assistants such as Cortex, agents and analytics read from the brain instead of keeping their own copies. In Swfte this wiring is designed for and on the roadmap; today Cortex runs RAG over knowledge bases on the device.
At the end of that path the knowledge base still exists, RAG still runs, and both sit inside something that knows who is asking and how sure it is.
Where can you read more?
For the plain-language definition, read what is a company brain for AI. For the question-and-answer experience on top of a brain, see ask your company. For the data model, see the knowledge graph page.
Further reading: From Company Brain to Custom Model: A Practical Path; Using Internal Company Knowledge to Build Focused AI Systems.