How to build a company brain
Most writing on this subject stops at the idea. The idea is not the hard part. A company brain is a current account of how a company operates, held so that people and AI can both work from it, and anyone who has watched an assistant confidently invent their own pricing already understands why one is worth having.
The hard part is that a document describing your company is out of date the week you finish it, and a document nobody trusts is a document nobody reads. So this is about mechanism: what writes the pages, what keeps them true, and how an assistant reaches them mid-task. Three mechanisms, in that order. Then the two decisions that no mechanism makes for you.
1. The pages are written from the tools
The first instinct is always to sit down and write it, usually in whatever wiki the company already pays for. It is the right instinct and the wrong method, for one reason: the account is only as true as the last person who felt like updating it.
The alternative is to derive it. Almost everything you would want to write down already exists somewhere as a trace of the work itself. How a deal actually progresses is in the CRM. How support really escalates is in the ticket history. What a process consists of is in the calendar invites, the threads and the documents that get attached to them. Reading across those and synthesizing them into a page is work a machine is genuinely good at, and it has one property that hand-authoring can never have: rerunning it is cheap.
That is the whole trick. Not that a machine writes better than your ops lead, because it does not. That a machine will do it again next month without being asked.
| Hand-authored | Derived from the tools | |
|---|---|---|
| Who writes it | Whoever has time | A process that reruns |
| What it covers | What someone remembered to write | What the systems actually record |
| Staying true | Discipline, indefinitely | Rerunning, which is cheap |
| Cost of an update | A person's afternoon | Near zero |
| Failure mode | Quietly goes stale and is still trusted | Inherits whatever the source systems get wrong |
The last row is the honest one. A derived brain is not free of failure; it moves the failure to somewhere you can see and fix, which is the source system, rather than leaving it in a document nobody has opened since March.
2. Every page carries a source and a date
A synthesized page has an obvious failure mode: it reads as authoritative whether or not it is right. The fix is not to make it more cautious. It is to make it checkable.
Two pieces of metadata do most of that work. Where this came from, so a disputed claim resolves in thirty seconds by opening the thing it was drawn from instead of becoming a meeting. And when it was last true, so a reader can weigh a page written this morning differently from one that has not moved since March.
Undated context is the single most expensive thing you can hand an assistant, because a model has no instinct for staleness. It will treat a sentence from last year exactly as it treats one from this morning. A person reading the same page at least pauses.
3. An assistant can reach it mid-task
A brain nobody can reach at the moment of work is a filing cabinet. The mechanism that closed this gap is the Model Context Protocol, an open standard published by Anthropic in November 2024 and since adopted well beyond it, which assistants use to talk to outside systems. Point one at your context and the assistant can pull what a question needs, at the time it needs it, without anyone pasting anything.
Two properties matter more than the protocol details. It is pull, not push: the assistant asks for what the task requires instead of being fed everything up front, which is what keeps a large body of context affordable to work with. And it is the same context everywhere — the same answers in Claude, in ChatGPT, in Slack — so the company stops maintaining a different unofficial memory per tool and per person.
Connecting a client to an MCP server is a five-minute job once the server exists, and the same shape whichever client you use: an address, a credential, and a permission decision about what it may reach. The protocol specification is the place to check what a server actually has to implement. The reference server collection is the fastest way to see what a server actually has to implement.
The two decisions that are yours
Mechanism gets you a brain that writes itself. It does not answer either of the questions that decide whether people trust it.
What belongs in it. The commonest failure is to point it at everything, on the theory that more context is better context. It is not. A brain should hold how the company operates: processes, decisions, definitions, the shape of the business. It should not hold raw records that are better queried where they live, and it should never hold credentials. Scope is what keeps the answers sharp.
Who sees what. A company brain that ignores the access rules of the systems it read from is a data incident with a nice interface. Whatever you build has to carry the boundaries the source systems already have, and the question "can this person's assistant see this" needs an answer before the first team is onboarded, not after.
Neither of those is a technical problem. Both are the reason a rollout succeeds or quietly gets abandoned.
What it looks like when it works, and where to start
Nobody announces it. What happens is that the briefing paragraph people used to paste at the top of every chat stops being written, because the answers are already right without it. New hires stop asking the question that has been asked forty times. Someone notices the assistant knew about a pricing change nobody told it about.
That is the honest version of the payoff. It is not a demo moment. It is the absence of a daily friction that everybody had stopped noticing they were paying.
If you are starting, start narrow. One team, two connected tools, and the process that team explains most often to other people. That is enough to find out whether the derived pages are actually true, which is the only question worth answering early, and it is small enough that being wrong costs a week rather than a quarter.
If you would rather assemble one from parts than buy it, the field is unusually good right now: the open-source projects worth knowing covers what each one actually does. If you are still deciding whether this is a build-versus-buy question at all, a company brain compared with what you already have puts it beside the wiki, the search bar and the agent platform. And if the premise itself is what you are unsure about, why your AI does not know your company is the argument underneath this one.
Common questions
- How long does it take to build one?
- The mechanism is not the long part. Connecting the first tools and getting readable pages out is days rather than months; what takes real time is deciding what belongs in it and who can see what, and then keeping the pages true after the first quarter turns. Teams that treat it as a one-off project rather than a loop end up with a snapshot.
- Does it need to hold everything the company has?
- No, and pointing it at everything is the commonest failure. A company brain should hold how the company operates: processes, decisions, definitions, the shape of the business. Raw records are better queried where they live, and credentials do not belong in it at all.
- What is MCP, and do we have to use it?
- The Model Context Protocol is an open standard, published by Anthropic in late 2024 and adopted well beyond it, that lets an assistant pull from an outside system at the moment of a question. You do not have to use it, but the alternative is a custom integration per assistant, which is the work it exists to remove.
- Can we build this on top of our existing wiki?
- Partly. A wiki is a good place to keep the things a person judged worth writing, and there is no reason to throw that away. What it cannot do on its own is stay current without someone maintaining it, so the derived pages have to come from the tools rather than from the wiki.