How to build a company brain

Every company already has a brain. It just does not live anywhere you can query. It lives in the head of the engineer who knows why the billing service retries three times, in a Slack thread from fourteen months ago, in the support reply a teammate wrote at midnight and filed nowhere. A new hire spends their first months reassembling it by asking people. That reassembly, the slow transfer of how this particular company actually works, is the thing everyone means by a company brain, and almost every attempt to build one fails the same way: it assumes the problem is storage.

It is not storage. You already have more places to put knowledge than anyone will ever read. The problem is capture, and capture is hard for a specific reason: the most valuable knowledge in your company is precisely the part nobody had time to write down. This is a guide to building the thing that holds it, and to the places the naive version quietly breaks.

The knowledge isn't missing, it's unwritten

Pick any question a new hire actually asks. Not "what is our PTO policy," which is written down, but "who do I talk to before touching the pricing config," or "why did we move off the old queue," or "what did we promise Acme in that renewal." The answers exist. None of them are in the wiki. They are split across the people who were in the room, the pull request where the decision got made, the thread where it got argued, and a contract nobody reads twice.

Knowledge work runs on two kinds of knowledge. The explicit kind sits in documents, and it survives when someone leaves. The tacit kind, the judgment and the context and the reasons behind the decisions, lives in people, and it walks out the door with them. Every company brain project is an attempt to convert the second kind into the first. The catch is that tacit knowledge is expensive to write down, the people who hold it are the busiest people you have, and the moment they stop to document it they are no longer doing the work that generated it. So it does not get written. The famous statistic about knowledge workers losing nine hours a week to searching has been recycled since the early 2000s and was a soft guess when it was new, but you do not need a number to know the shape of it. You have asked someone where something is this week.

Why every wiki becomes a graveyard

The standard answer to all of this is a wiki, and the standard outcome is a wiki nobody trusts. The failure is structural, and four mechanics drive it.

Pages decay, because the gap between what a page says and what the system actually does widens with every deploy and every reorg, silently, since nothing ever tells the page it has gone wrong. Trust collapses on top of that, because a stale page sits in the search results next to a correct one, indistinguishable, and a person who gets burned twice learns that checking the wiki costs more than asking a human, so they ask a human. Ownership thins out until it disappears, because a page that belongs to everyone belongs to no one, and "someone should update this" resolves, reliably, to no one. The last mechanic is the one nobody likes to say out loud: the incentives point away from writing things down. A performance review rewards shipping, not documenting, and the person who is the only one who understands a system holds a quiet advantage that writing it all down would give away. Few people would put it that way. Plenty act on it.

None of this is a tooling problem, which is why buying a nicer wiki never fixes it. Wiki rot is a property of organizations, not of software, and any system that asks busy people to stop and feed it by hand will rot for the same four reasons.

Capture from the work, not next to it

If people will not stop to document, then the documenting has to happen inside the work rather than beside it. This is the whole game. Knowledge captured in the flow of the work keeps the context that desk-written documentation throws away. It remembers why the timeout is ninety seconds, because the incident that forced it is right there in the thread. Write the same fact down a week later, away from the work, and you get the number without the reason, which was the half that mattered.

For most of the history of work this was a nice idea with no mechanism behind it. You cannot ask people to narrate their reasoning into a system all day. What changed is that the work is no longer done only by people. Agents now sit inside the work, writing the code, drafting the reply, running the query, and an agent in the loop can record what got decided and why as a byproduct of doing it, with no human stopping to type.

The capture problem that sank every wiki becomes tractable the moment the thing doing the work can also record what it learned.

Build a stream with state, not a snapshot

A wiki is a snapshot. Someone writes down what is true on a Tuesday, and from that Tuesday on the document and reality drift apart. A company brain has to be the other thing: a stream written continuously by the work, with state that reflects the latest the company knows rather than the last time a person remembered to edit a page.

It helps to be exact about what this is, because three different things all get called memory. Retrieval over your documents answers "what does this page say." It is useful, and it is not a brain, because a pile of searchable pages is still a pile of pages. Per-user agent memory answers "what did this person tell me," which makes one assistant feel less forgetful and stays trapped in one person's thread. A company brain answers a third question, "how does this company work," and the thing that makes it a brain instead of a search index is that it is scoped to the organization. Every agent writes to it, every agent reads from it, and what one of them works out on Monday is there for all of them on Tuesday.

Where the naive version dies: retrieval and permissions

Say the brain exists and it is full. Now the hard parts start, and they are the parts a weekend prototype skips.

Retrieval is the first. The prototype embeds everything, matches on similarity, returns the top few chunks, and it works in the demo and fails on the real questions. Ask "where do we file feature requests for Acme," and the system has to know which Acme you mean, the enterprise customer and not the open-source library your team also uses, map "feature requests" to whatever the board is actually called, and remember that the answer changed when you switched trackers in March. Similarity search is good at finding things that sound alike and bad at exactly this: telling two entities apart, returning a complete set, and respecting time. Serious systems stop leaning on similarity alone and fold in keyword matching and entity resolution, then re-rank what comes back, because the question is rarely "what sounds like this" and usually "what is the one right answer right now."

Permissions are the second, and they are where a shared brain turns dangerous. The moment memory is organization-wide, every answer has to respect who is allowed to see what, or the brain becomes the fastest path for the compensation discussion to surface in an engineer's chat. The wrong way is to fetch everything and filter the results afterward, because by then the model has already read what it should not have. The bar is to enforce access where the lookup happens, as part of retrieval, and to have it change the instant someone's access does. It is unglamorous, and it is the whole difference between a system you can put in front of the company and a demo you can only show the founders.

The parts nobody has solved yet

A guide that stopped here would be lying by omission, because some of this is genuinely unsolved, and you should build knowing where the floor is missing.

Staleness is the deep one. Decaying obviously old, rarely touched memories is easy. The hard case is a fact the system is confident about that quietly stops being true: a person's role after a reorg, a process after it is replaced, a number after it is renegotiated. The brain gets no signal that the world moved, so a confidently held fact becomes confidently wrong, and most systems file a change as a brand new fact sitting next to the old one rather than a correction of it. Knowing that a new truth retires an old one is closer to a research problem than a finished feature.

Then there is a failure mode the wiki never had. When agents write to shared memory, a wrong write does not stay local. One agent records a mistaken fact, every other agent reads it and acts on it, and a bad memory propagates through the company at machine speed. Anything everyone writes to needs a way to weigh and check what gets written, or it becomes a single point through which one confident mistake reaches the whole org.

Which leaves the quiet requirement under all of it: attribution. A memory you cannot trace, with no source, no author, no date, is a memory people will not act on, and they are right not to. The wiki failed partly because you could not tell a live page from a rotted one at a glance. A company brain has to carry where each thing came from and when, so a person and an agent can both decide how far to trust it. Trust is not a tone the writing takes. It is a property you build in or leave out.

What a company brain has to be

Strip away the specifics and the thing has a short list of properties it cannot do without. It captures from the work, rather than waiting for anyone to write things down. The memory is the organization's, so what one agent learns compounds for all of them instead of pooling in a private thread. Questions get resolved instead of merely matched, so the answer is the one right thing and not ten plausible ones. Access is checked where the lookup happens, not bolted on after. And nothing is trusted without a source and a date attached, because a brain you cannot audit rots into the same graveyard as the wiki.

That list is why we are building Glen. Glen is shared memory for the AI agents an organization already runs, one place every agent reads from and writes to, reached as a single tool rather than a database each team wires up on its own. It captures from the work instead of asking anyone to document, and it belongs to the organization rather than to one user or one thread, which are the first two properties on the list and the ground the rest of them stand on. The harder items, the ranking and the permissions and the slow problem of knowing when a true thing has stopped being true, are exactly that, hard, and some of them are not finished anywhere yet. That is the point. A company brain is not a document you write once. It is a system you build, and then it gets sharper every time your company uses it.

If you want the longer argument for why a memory like this should belong to the organization and not to each agent on its own, that is our thesis.