In the first piece, I argued that a real Company Brain needs three kinds of memory: factual memory, interaction memory, and action memory. Factual memory is the first layer. It is the part that answers the basic questions every company asks all day: what is this, what happened, where is the source, who owns it, when did it change, and how does this thing work?
That sounds simple, but it is not. Most companies have data. Some have knowledge bases. Few have real memory or a context graph. Almost none preserve the facts in a way that is personalized, permissioned, connected across tools, and useful in the moment work is happening.
Factual memory is not a shared drive. It is not a wiki. It is not enterprise search with a chat box attached. Factual memory is the company’s ability to answer questions about what exists and what happened across all the places where work leaves a trace: documents, tickets, CRM notes, support threads, product specs, incidents, dashboards, emails, meetings, code, customer calls, roadmap documents, and decisions once they become artifacts.
The mistake is to think this can be built as a central repository. That is how knowledge bases die. People do not work in repositories. They work in docs, Slack, meetings, tickets, local notes, spreadsheets, CRM systems, design tools, GitHub, and email. If the Company Brain asks people to stop working naturally and start feeding a central archive, it will fail.
Company memory has to be built from the individual outward. There is an individual brain, and there is a company brain. They overlap, but they are not the same thing. An individual has drafts, private notes, half-formed opinions, local context, and working memory. A company has official documents, shared decisions, customer commitments, policies, projects, and operating knowledge. A good Company Brain has to respect the boundary between the two while still allowing useful memory to emerge.
The useful word here is emergence. Company memory can be imposed from the top down, but it comes with real challenges. Drop-in memory tends to look like another repository: connect every tool, index every document, answer every query. That may be useful, but it misses the true power of company memory. The better version grows with the people using it. It emerges as individual work becomes shared work, and shared work becomes institutional memory.
A personal note may become a team doc. A team doc may become a roadmap decision. A roadmap decision may become a customer commitment. Over time, the memory of the company forms through these transitions. If I were drawing this, I would not draw a giant database at the center with arrows pointing into it. I would draw small individual workspaces at the edge, with notes, meetings, docs, tickets, conversations, drafts, and decisions in progress. Some artifacts stay personal. Some become shared team memory. A smaller set becomes company memory.
When it works, the Company Brain is not separate from the individual brain. It works with it. It helps people remember, contribute, and retrieve without pretending that every private thought is a company record. That also means factual memory needs attribution: who created this, who modified it, who owns it now, and which person or team made it official? Is it still current? Is it contradicted by something newer? Can this person see the underlying source? Can this answer be trusted for a customer conversation, or is it only a working hypothesis?
This is why I do not think the durable version of factual memory is just RAG across enterprise data. RAG can retrieve fragments. A well-built demo can feel magical. But a company does not only need plausible snippets. It needs durable structure: provenance, permissions, ownership, freshness, source-of-truth boundaries, and relationships between artifacts. This is not the same as saying every embedding-based retrieval system is useless. It is saying that retrieval alone will fail when meaning has to persist. The Company Brain version needs something closer to a semantic file system.
By semantic file system, I mean a memory layer where artifacts are not just blobs of text. The relationships around the artifact matter as much as the artifact itself. A customer call connects to an account, the account connects to open issues, the issues connect to tickets, the tickets connect to product areas, the product areas connect to owners, and the owners connect to decisions. This is more than a knowledge graph pasted on top of documents, and more than markdown with metadata. The quality of the relationships determines the quality of the memory.
This changes what the interface should feel like. It may include a chat window, because chat is the simplest way to ask natural-language questions. But the interface cannot only be chat. It should be mutable. It should show up inside the work itself, bring facts forward based on what someone is doing, and respect the boundary between assistance and surveillance. The goal is not to watch people. The goal is to help the company remember without making people feel watched.
If an IC asks, “I’m picking up the billing integration. What should I know?” the answer should not be a list of ten links. It should synthesize the relevant specs, prior tickets, known risks, owners, customer commitments, recent incidents, and open decisions. It should explain what is current, what is stale, and where the evidence comes from.
If a manager asks, “What is actually blocking onboarding?” the system should not return every document that contains the word onboarding. It should pull together tickets, status updates, ownership, customer escalations, meeting artifacts, and unresolved dependencies. It should separate facts from interpretation. It should say, “Here is what appears to be blocked, here is who owns each part, here is the latest evidence, and here is what I am uncertain about.”
If a CEO asks, “What do we know about enterprise churn?” the answer should combine CRM data, support tickets, renewal notes, call summaries, account history, product issues, and dashboard metrics. It should not pretend all of those sources have the same weight. A dashboard may tell you churn increased. A customer call may tell you what hurt. A support thread may tell you when the problem started. Factual memory should bring those sources together without erasing their differences.
The same question should not produce the same answer for everyone. An IC may need implementation details and owners. A manager may need blockers, risk, and scope. A CEO may need the shape of the issue across customers and strategy. Personalization is not decoration here. It is part of memory. The system has to understand the person asking, what they are allowed to know, and what they are trying to do.
This is where the experience has to be better than enterprise search. Glean and others showed that finding knowledge across company tools is a real wedge. But a Company Brain has to go further: synthesize across sources, personalize the answer, respect permissions, show provenance, notice stale information, admit uncertainty, and bring the right fact to you before you ask.
That last part matters. Factual memory cannot just sit in a search box waiting for a query. A good Company Brain should be proactive. Before a customer call, it should surface open commitments, recent issues, and prior conversations. When someone edits a roadmap doc, it should surface related customer asks and duplicate work. When a ticket is assigned, it should show prior incidents and owners. When a pricing exception is requested, it should surface precedent. When a new employee joins, it should build a personalized map of what they need to know.
This is the difference between a knowledge base and memory. A knowledge base waits. Memory participates. It shows up when context changes, helps the person orient faster, and reduces the number of people who have to be interrupted just to reconstruct what the company already knows.
At Sentra, this is one of the places we have spent a lot of time: not just making company knowledge searchable, but making it usable in the moment where work is happening. The hard part is not connecting to tools. The hard part is preserving the shape of the company’s knowledge as it moves across people, teams, artifacts, and systems.
Factual memory is the first layer of a Company Brain because without it, the company cannot know what it knows. But factual memory is still not enough. It can tell you what exists, what happened, where the sources are, who was involved, when something changed, and how a workflow works. It can make the company searchable, explainable, and proactive.
What it cannot fully preserve is why a decision was made. That lives in interactions: meetings, messages, disagreement, judgment, escalation, and tradeoff. That is the next layer of the Company Brain: interaction memory.
At Sentra , where we are building enterprise general intelligence: a shared intelligence/memory layer that sits on all communication channels, knowledge bases and agent traces to understand how everyone in an organization actually works as well as how work actually gets done, constructing a living world model of the entire company in near real time.