What Is a Company Brain for AI?
A company brain is one governed, evidence-backed, time-aware graph of your information that every AI product reads.
A company brain for AI is one governed place that holds an organisation's sources of information as an evidence-backed, time-aware graph, which every AI product the organisation uses reads from. It records who people are, how the organisation is structured, which systems exist, who owns what and how all of that has changed, and it attaches evidence to each fact. Access follows the identity of the person asking, sensitive content is cleaned before it reaches a model, and an audit trail records what changed and when.
That is the short answer. The rest of this post explains what problem it solves, what goes into one, what it is not, and how to tell whether your organisation needs one yet. Swfte's version is described on the company brain platform page.
What problem does a company brain solve?
Look at how most organisations adopt AI. A team buys a chat assistant and uploads a folder of documents. Another team builds an agent in a workflow tool and gives it a service account with broad read access. A third team pays for a coding assistant that indexes the repositories. Finance pilots a forecasting tool that pulls from the warehouse.
Each of these tools now holds its own copy of the organisation's context. Each copy is partial, each goes stale on its own schedule, and each applies its own idea of who may see what. When someone leaves, four systems still think they own something. When a team is renamed, three assistants keep routing questions to the old name. When an auditor asks which tools could read the salary review folder, nobody can answer without a week of digging.
Duplicated effort is the smaller cost. The larger one is that the answers disagree. Ask two assistants who owns the payments service and you may get two names, with no way to tell which one is current or why either was chosen.
A company brain replaces the many private copies with one shared, governed model of the organisation. Tools read from it instead of building their own. When the organisation changes, it changes in one place.
What goes into a company brain?
Think of the inputs as nine source families. Each family answers a different kind of question about the organisation.
- Directory and identity. People, accounts, groups, reporting lines and org units.
- Cloud accounts and resources. What runs where, and under whose account.
- Code repositories. What has been built, by whom, and who maintains it.
- CI/CD pipelines. How code becomes running software, and who can ship it.
- Kubernetes clusters. Which workloads run, in which namespaces, owned by which teams.
- Databases. Where data lives and which services depend on it.
- SaaS and business systems. The applications the business runs on.
- Tickets. What broke, what was asked for, and who handled it.
- Documents and email. What the organisation has written down and agreed.
Directory comes first for a reason. Every other family refers to people and groups, so a brain that cannot say who a person is cannot say who owns anything. We cover the order of connection in more depth on the sources page.
What is a company brain not?
It helps to rule out a few things it is often confused with.
It is not a wiki or a knowledge base. A knowledge base is content people write for other people to read. A brain may hold that content as one input, but its main job is to model the organisation itself. We compare the three ideas directly in company brain vs RAG vs knowledge base.
It is not a vector index. Embedding documents and retrieving similar passages is a useful technique, and a brain can use it, but similarity search on its own cannot tell you who was in a group last March or whether a fact is disputed.
It is not a data lake. A lake collects raw data for analysts. A brain resolves that data into entities and relationships with evidence and access rules attached, so a model can use it without seeing more than the person asking.
And it is not a model. The brain holds what the organisation knows. Models read from it, and the model can change without the knowledge being lost.
What are the pieces of a company brain?
Six parts make the difference between a pile of synced data and something an AI product can be trusted to read.
Entities and relationships. People, accounts, groups, teams, systems and services, and the links between them: member of, reports to, owns, depends on. One human with three accounts becomes one person, and the evidence for each link is kept. The knowledge graph page goes into how that resolution works.
History. Facts are added, never overwritten. You can read the graph as it stood on a given date, which is what lets you answer questions about the past and evaluate decisions against the organisation as it was when they were made.
Evidence statuses. Each fact carries one of seven statuses: observed, corroborated, verified, inferred, stale, disputed or unknown. A reader can decide how much weight to put on a fact, and an agent can stop and ask a person when the status is weak.
Identity-aware access. Every read is made on behalf of someone, and the answer never includes more than that person could see in the source system. An assistant answering a junior analyst sees what the junior analyst sees.
Sanitisation. Before content reaches a model, values that must not leave are removed or masked. Secrets are stripped before storage in the first place.
Audit. Changes are written to a hash-chained log with signed checkpoints, so tampering can be detected and you can show afterwards what the brain held and when it changed. The access and governance page covers this layer.
Who reads from a company brain?
The idea is that every AI product in the organisation reads from the same place. In Swfte's case the design is for these to read from it, and none of that wiring is built yet:
- Cortex, the desktop assistant, answering questions about the organisation for the person using it.
- Nexus, which governs and traces agents, checking an agent's planned action against who owns the thing it wants to touch.
- Studio, where agents and workflows are built, using the brain for routing and approvals rather than hard-coded names.
- Connect, the model gateway, carrying context to whichever model serves the request.
- Agents of every kind, reading context within their own limits, as described on agents on the brain.
- Custom models, adapted on data selected from the brain, covered on the custom models pages.
- Analytics: coverage, ownership and change over time.
People ask questions too. The ask your company page describes the question-and-answer experience over the brain.
What is built today, and what is designed?
An honest short answer. The graph store is built: insert-only history, as-of reads, tenant isolation, the seven evidence statuses and a hash-chained audit log with signed checkpoints. Directory sync from Active Directory and LDAP, Microsoft Entra ID, Okta and Google Workspace is built, with identity resolution, groups, reporting lines and org units, and a local API that serves graph, people, groups, coverage and audit data. It runs in your environment in connected, private or air-gapped mode.
Search over documents with per-object access lists, and the sanitisation gateway, are in progress: the libraries exist but the endpoints are not finished. Collectors for the other source families, document and email connectors, and the wiring into Cortex, Nexus, Studio and Connect are on the roadmap. The list of readers above describes the design. Today, the brain is read through its own API.
What does a company brain look like in practice?
Three plain examples, none of them exotic.
Routing a request. Someone asks an assistant to get access to a reporting dashboard. Without a brain, the assistant guesses or sends the person to a generic queue. With one, it can see who owns the dashboard's data, who that person reports to, and whether the requester's team already has a group that grants access. It drafts the request to the right approver. Whether the approval goes ahead stays with a human.
A leaver. A team lead leaves. The directory shows the account disabled. The brain shows the groups they were in, the people who reported to them and, once the collectors for systems arrive, the services they were recorded as owning. The handover list is a query rather than a week of asking around, and the history shows what the organisation looked like the day before they left.
An access question from audit. An auditor asks who was in the group that approves supplier payments at the end of the last quarter, including people who were members through a nested group. Because the brain keeps history and resolves transitive membership, the answer is a read of the graph as of that date, with the evidence for each membership attached. Once document sources arrive, the same kind of question can be asked about who could read a particular folder.
How do you know if you need a company brain?
You probably need one when two or more of these are true:
- More than one AI tool in the organisation keeps its own index of company content.
- Assistants give different answers to the same ownership or routing question.
- You cannot say, for a given AI tool, which data it can read and on whose behalf.
- Agents run with service accounts that see more than any single user would.
- Reorganisations break automations because names are hard-coded.
- You have obligations about where data is held and need to keep the context for AI inside your own environment.
You probably do not need one yet if a single team uses a single assistant over a small, shared folder, and nothing it does acts on the organisation. A knowledge base is enough for that, and it is a reasonable first step towards a brain later.
The case gets stronger as agents start to act. An agent that only answers questions can be wrong and someone notices. An agent that files tickets, changes access or messages people needs to know who owns what, and it needs that answer to be the same one every other tool gets.
Where should you go from here?
Start with the company brain overview, then read the five deep pages in order: sources, knowledge graph, access and governance, ask your company and agents on the brain. If control over where it runs matters to you, the guide to building a company brain without losing control of your data covers the decisions to make before connecting anything.
For the wider category this sits in, see sovereign intelligence explained.
Further reading: From Company Brain to Custom Model: A Practical Path.