Should your company brain be a curated wiki, or a memory your agents can query?

Ask ten companies what they mean by "a brain for the business" and you will get roughly the same wish: one place that knows everything, so nobody has to remember where anything is. What almost nobody has decided at that point is which of two very different machines they are describing. One of them is an encyclopedia that people trust. The other is a memory that machines can query. They look similar in a slide and they diverge on the first day of the build.

The pattern we looked at

A growth-stage company we observed had built exactly the first kind, and built it well. Their brain is a repository of curated pages: an AI writes each entry, and a person reviews every change before it is published, the way an engineering team reviews a code change before it ships. Sensitive material is filtered out at the moment of writing under layered rules covering compensation, fundraising figures, personal data, credentials, and negotiated terms, and the system keeps an auditable record of what it deliberately left out.

The result is a company memory where practically every fact has been read by a human who agreed with it. That is not a small achievement. If your problem is that people do not trust what the AI tells them, this design solves your problem directly.

The cost is on the other side of the ledger, and it is permanent. Once the write-up is approved, the meeting, the thread, and the call it came from are gone. If the write-up missed a nuance, that nuance is unrecoverable. Ask the system what a customer actually said on a call and, by design, the answer does not exist anywhere. The summary is now the ground truth, frozen at whatever quality the model and the reviewer produced on the day it was written. A better model next year cannot improve it, because there is nothing left to re-read.

The second shape: enterprise search

The other familiar answer is enterprise search, the category Glean sits in. It indexes the raw material, every document, message, and page, and retrieves the originals when you ask. Nothing is summarized in advance, so recall is essentially the whole product. It will find the thing. What it hands back is a document, not an answer, and it has no notion of how the thing you found connects to anything else.

Notice that the curated brain and enterprise search want the same outcome and make opposite storage decisions. One keeps only the approved paraphrase. The other keeps only the raw material. The interesting design is the one that refuses to choose.

What we build instead

A knowledge layer, the way we build it, keeps the source corpus and derives a structured index on top of it. Meetings, documents, records, and messages flow into one preserved corpus. A model reads them and pulls out the facts and the relationships between them. Those get merged into a single map, where one client mentioned across ten documents becomes one entity rather than ten. Every fact carries the date it was recorded and the document it came from, and the whole map is rebuilt from scratch every night.

Two properties fall out of that, and they are the reason we build it this way.

The first is that answers keep their receipts. You can ask a question in plain English, get a connected answer rather than a stack of documents, and then open the exact source line the answer came from. Nothing has to be taken on faith, because nothing was thrown away.

The second is that the memory compounds. Because the corpus is preserved, we can re-read all of it with a better model whenever one arrives, and the whole memory gets sharper without anyone rewriting a single page. A system built on stored summaries cannot do that at any price. Its quality is fixed at the moment each summary was written.

The three shapes, side by side

What the curated version does better than ours

We would be selling you something if we stopped at the table. Three things in that design are ahead of where we are, and we are borrowing all three.

Their sensitivity filter runs at the moment of extraction, with explicit rules for the categories that should never enter a shared memory, and it logs what it dropped so a human can audit the omissions. Ours is the weakest column in that table and we say so plainly. Their high-stakes facts get cross-checked against a second source before they are written, and single-source claims get flagged, which is a direct answer to the failure mode every automated extraction pipeline has, including ours: the same entity fragmenting into near-duplicates, and two documents quietly disagreeing. And their per-change review gives a human a clear view of what entered the memory and why. We publish a build stamp and a source citation on every fact, but we do not yet publish a readable diff of what changed in last night's rebuild. A nightly "here is what changed" digest gets most of that benefit without putting a person in front of every fact.

That last point is the real tension between the two designs. Per-change human review is what makes their memory trustworthy, and it is also the thing that caps how much memory a company can have. You can only remember as fast as someone can read.

The question to ask before anyone builds anything

When someone on your team says they want a company brain, the useful next question is not which vendor. It is this: do you want an encyclopedia that people trust, or a memory that your agents can query?

If the honest answer is the first, that a handful of people need a small set of settled answers they can rely on without checking, then a curated and reviewed library is the right build, and the discarded sources are a real cost you are choosing on purpose.

If the answer is the second, that you expect agents to work against this memory and follow the connections between things at a speed no reviewer can match, then you need the sources kept and the structure derived, and you need to accept that the reviewer moves from checking every fact to checking the system that produces them.

Most teams we talk to describe the first and need the second. That is a fine place to start, as long as you find out before the sources are gone. Everything else in this design can be revised later. That one cannot.