# Company Brain, Part 2: Factual Memory
**作者**: Ashwin Gopinath
**日期**: 2026-04-30T16:16:13.000Z
**来源**: [https://x.com/ashwingop/status/2049885545288077720](https://x.com/ashwingop/status/2049885545288077720)
---
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.
## 相关链接
- [Ashwin Gopinath](https://x.com/ashwingop)
- [@ashwingop](https://x.com/ashwingop)
- [21K](https://x.com/ashwingop/status/2049885545288077720/analytics)
- [first piece](https://x.com/ashwingop/status/2049641901410955694)
- [Sentra](https://www.sentra.app/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:16 AM · May 1, 2026](https://x.com/ashwingop/status/2049885545288077720)
- [21.6K Views](https://x.com/ashwingop/status/2049885545288077720/analytics)
- [View quotes](https://x.com/ashwingop/status/2049885545288077720/quotes)
---
*导出时间: 2026/5/1 10:29:34*
---
## 中文翻译
# 公司大脑，第二部分：事实记忆
**作者**: Ashwin Gopinath
**日期**: 2026-04-30T16:16:13.000Z
**来源**: [https://x.com/ashwingop/status/2049885545288077720](https://x.com/ashwingop/status/2049885545288077720)
---
在第一篇文章中，我提出一个真正的公司大脑需要三种记忆：事实记忆、交互记忆和行动记忆。事实记忆是第一层。它负责回答每家公司整天都在问的基本问题：这是什么、发生了什么、源头在哪里、谁负责、什么时候发生了变化，以及这个东西是如何运作的？
这听起来简单，其实不然。大多数公司都有数据。有些有知识库。很少有真正的记忆或上下文图谱。几乎没有公司能以一种个性化的、有权限控制的、跨工具互联的、并且在工作发生当下就能发挥作用的方式来保存事实。
事实记忆不是一个共享网盘。它不是维基。它也不是附带聊天框的企业搜索。事实记忆是公司回答“存在什么”和“发生了什么”的能力，涵盖工作留下痕迹的所有地方：文档、工单、CRM 备注、支持对话、产品规格、事故记录、仪表盘、邮件、会议、代码、客户通话、路线图文档，以及一旦成为正式产物后的各项决策。
错误的想法是把它建成一个中央知识库。知识库就是这样死掉的。人们不在知识库里工作。他们在文档、Slack、会议、工单、本地笔记、电子表格、CRM 系统、设计工具、GitHub 和邮件中工作。如果公司大脑要求人们停止自然的工作方式，转而去喂养一个中央档案库，它注定会失败。
公司记忆必须从个体向外构建。有一个个体大脑，也有一个公司大脑。它们有重叠，但并不是同一个东西。个体拥有草稿、私人笔记、尚未成形的观点、本地上下文和工作记忆。公司拥有官方文档、共享决策、客户承诺、政策、项目和运营知识。一个好的公司大脑必须尊重两者之间的边界，同时仍然允许有用的记忆涌现出来。
这里的关键词是“涌现”。公司记忆可以自上而下强制推行，但这会带来真正的挑战。这种外部接入的记忆往往看起来又是一个知识库：连接每个工具，索引每份文档，回答每个查询。这也许有用，但它错失了公司记忆的真正力量。更好的版本是随着使用者一起成长的。它涌现于个人工作变成共享工作、共享工作变成机构记忆的过程之中。
一条个人笔记可能变成一份团队文档。一份团队文档可能变成一个路线图决策。一个路线图决策可能变成一项客户承诺。随着时间的推移，公司的记忆通过这些转变逐渐形成。如果我画这幅图，我不会画一个居于中心的巨大数据库，四周是射向它的箭头。我会画边缘上的一个个小型个人工作区，里面有待办笔记、会议、文档、工单、对话、草稿和进行中的决策。一些产物保持个人属性。一些变成共享的团队记忆。更小的一部分变成公司记忆。
当它有效运转时，公司大脑并不独立于个体大脑，而是与之协同工作。它帮助人们记忆、贡献和检索，而不假装每一个私人想法都是公司记录。这也意味着事实记忆需要归属信息：这是谁创建的，谁修改过它，现在谁负责，以及是哪个人或团队将其确立为正式版本？它是否仍然有效？是否被更新的内容所推翻？这个人能否查看底层来源？这个答案可以用于客户对话吗，还是仅仅是一个工作假设？
这就是为什么我不认为持久可用的事实记忆只是在企业数据上跑 RAG。RAG 可以检索片段。一个精心构建的演示可以让人感觉神奇。但公司需要的不仅仅是看似合理的片段。它需要持久的结构：出处、权限、所有权、新鲜度、事实来源边界，以及产物之间的关系。这并不是说所有基于嵌入的检索系统都没用。而是说当含义必须持续存在时，仅靠检索是会失败的。公司大脑版本需要一个更接近语义文件系统的东西。
我所说的语义文件系统，是指一个记忆层，其中产物不仅仅是文本块。围绕产物的关系与产物本身同等重要。一次客户通话连接到一个客户账户，账户连接到未解决的问题，问题连接到工单，工单连接到产品领域，产品领域连接到负责人，负责人连接到决策。这不仅仅是贴在文档之上的知识图谱，也不仅仅是带元数据的 markdown。关系的质量决定了记忆的质量。
这改变了界面的应有形态。它可能包括一个聊天窗口，因为聊天是提出自然语言问题最简单的方式。但界面不能只有聊天。它应该是可变的。它应该出现在工作本身之中，根据某人正在做的事情主动呈现相关事实，并尊重辅助与监视之间的边界。目标不是监视人们。目标是帮助公司记住，而不让人们感到被监视。
当一个工程师问：“我要接手计费集成的工作了。我应该了解什么？”答案不应该是十个链接的列表。它应该综合相关的规格说明、过往工单、已知风险、负责人、客户承诺、近期事故和悬而未决的决策。它应该说明哪些信息是当前的、哪些已过时，以及证据来自哪里。
如果一位经理问：“到底是什么在阻碍新客户接入？”系统不应该返回所有包含“接入”这个词的文档。它应该汇总工单、状态更新、责任人、客户升级事件、会议产物以及未解决的依赖关系。它应该把事实和解读区分开。它应该说：“这是看起来被阻塞的部分，这是每个部分的负责人，这是最新的证据，以及这是我不确定的地方。”
如果一位 CEO 问：“关于企业客户流失，我们了解什么？”答案应该结合 CRM 数据、支持工单、续约记录、通话摘要、账户历史、产品问题和仪表盘指标。它不应该假装所有这些来源具有相同的权重。仪表盘可能告诉你流失增加了。一通客户电话可能告诉你造成伤害的原因。一个支持线程可能告诉你问题是什么时候开始的。事实记忆应该把这些来源汇集在一起，同时不抹去它们之间的差异。
同一个问题不应该为每个人产生相同的答案。一名一线员工可能需要实现细节和负责人。一位经理可能需要阻碍因素、风险和范围。一位 CEO 可能需要问题在客户和战略层面的整体形态。个性化在这里不是装饰。它是记忆的一部分。系统必须理解提问的人、他们被允许知道什么，以及他们想要做什么。
这正是体验必须优于企业搜索的地方。Glean 和其他公司证明了跨公司工具查找知识是一个真实的市场切入点。但一个公司大脑必须走得更远：跨来源进行综合、个性化答案、尊重权限、展示来源、发现过时的信息、承认不确定性，并在你提问之前就把正确的事实带到你面前。
最后一点很重要。事实记忆不能只是待在搜索框里等待查询。一个好的公司大脑应该是主动的。在客户通话之前，它应该呈现未兑现的承诺、近期问题和此前的对话。当有人编辑路线图文档时，它应该呈现相关的客户需求和重复的工作。当一个工单被分配时，它应该显示此前的事件和负责人。当有人申请价格例外时，它应该呈现先例。当一名新员工入职时，它应该构建一张个性化的地图，展示他们需要了解什么。
这就是知识库和记忆之间的区别。知识库等待。记忆参与。它在情境变化时出现，帮助人们更快地理清方向，并减少那些仅仅为了重建公司已知信息而不得不被打扰的人数。
在 Sentra，这是我们投入大量时间的地方之一：不仅仅是让公司知识可以被搜索，而是让它在工作正在发生的那一刻就能被使用。困难的部分不在于连接工具。困难的部分在于在公司知识跨越人员、团队、产物和系统流动时，保持它的形态。
事实记忆是公司大脑的第一层，因为没有它，公司就无法知道自己知道什么。但仅有事实记忆仍然不够。它可以告诉你什么存在、发生了什么、来源在哪里、谁参与了、什么时候发生了变化，以及一个工作流程是如何运作的。它可以让公司变得可搜索、可解释、可主动。
它无法完全保留的，是一个决策为什么会被做出。这存在于互动之中：会议、消息、分歧、判断、升级和权衡。这就是公司大脑的下一层：互动记忆。
在 Sentra，我们正在构建企业级通用智能：一个共享的智能/记忆层，它覆盖所有沟通渠道、知识库和智能体轨迹，以理解一个组织中的每个人实际上是如何工作的，以及工作实际上是如何完成的，从而以近乎实时的方式构建整个公司的活的世界模型。
## 相关链接
- [Ashwin Gopinath](https://x.com/ashwingop)
- [@ashwingop](https://x.com/ashwingop)
- [21K](https://x.com/ashwingop/status/2049885545288077720/analytics)
- [第一篇文章](https://x.com/ashwingop/status/2049641901410955694)
- [Sentra](https://www.sentra.app/)
- [升级到 Premium](https://x.com/i/premium_sign_up)
- [2026年5月1日 凌晨12:16](https://x.com/ashwingop/status/2049885545288077720)
- [2.16万次浏览](https://x.com/ashwingop/status/2049885545288077720/analytics)
- [查看引用](https://x.com/ashwingop/status/2049885545288077720/quotes)
---
*导出时间: 2026/5/1 10:29:34*
