Company Brain, Part 2: Factual Memory

✍ Ashwin Gopinath🕐 2026-05-01📦 10.0 KB 🟢 已读 𝕏 文章列表

文章探讨了构建“公司大脑”中的事实记忆层。作者指出，真正的企业记忆不是简单的知识库或带有聊天框的企业搜索，而是一种从个人工作向外涌现的语义文件系统。它必须具备追溯性、权限管理和个性化能力，能够综合多源数据（如文档、CRM、代码）并主动提供上下文，而非仅被动等待查询。

Company Brain 企业搜索知识管理 RAG Agent 语义层产品设计信息检索上下文感知

# 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) --- ![Image](/doc/1339/image/img_5976336660be.jpg) 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) --- ![Image](/doc/1339/image/img_5976336660be.jpg) 在第一篇文章中，我认为一个真正的“企业大脑”需要三种记忆：事实记忆、交互记忆和行动记忆。事实记忆是第一层。它负责回答每个公司每天都会问的基本问题：这是什么，发生了什么，来源在哪里，谁负责它，它何时变更的，以及这个东西是如何运作的？这听起来很简单，但事实并非如此。大多数公司都有数据。有些有知识库。很少有公司拥有真正的记忆或上下文图谱。几乎没有公司能以一种个性化、有权限控制、跨工具连接且在工作进行时立即可用的方式来保存事实。事实记忆不是共享驱动器。它不是维基（Wiki）。它也不是带聊天框的企业搜索。事实记忆是公司回答关于“存在什么”和“发生了什么”这些问题的能力，这些问题涉及所有留下工作痕迹的地方：文档、工单、CRM 备注、支持贴、产品规格、故障事件、仪表盘、电子邮件、会议、代码、客户通话、路线图文档以及一旦成为决策产物的决定。错误在于认为可以将其构建为一个中央存储库。这正是知识库消亡的原因。人们不在存储库里工作。他们在文档、Slack、会议、工单、本地笔记、电子表格、CRM 系统、设计工具、GitHub 和电子邮件中工作。如果企业大脑要求人们停止自然地工作并开始向中央归档系统输送内容，它就会失败。企业记忆必须从个体向外构建。有个体大脑，也有企业大脑。它们有重叠，但不是同一回事。个体有草稿、私人笔记、未成型的观点、本地上下文和工作记忆。公司有官方文档、共享决策、客户承诺、政策、项目和运营知识。一个好的企业大脑必须尊重两者之间的界限，同时仍然允许有用的记忆涌现。这里的关键词是“涌现”。企业记忆可以自上而下地强加，但这会带来真正的挑战。植入式的记忆往往看起来像另一个存储库：连接每个工具，索引每份文档，回答每个查询。这可能有用，但它错过了企业记忆的真正力量。更好的版本是随着使用它的人一起成长的。当个体工作变成共享工作，而共享工作变成机构记忆时，它就涌现出来了。一条个人笔记可能会变成团队文档。团队文档可能会变成路线图决策。路线图决策可能会变成客户承诺。随着时间的推移，企业的记忆通过这些转变形成。如果我要画一张图，我不会在中心画一个巨大的数据库，并用箭头指向它。我会在边缘画出许多小的个人工作空间，里面有笔记、会议、文档、工单、对话、草稿和进行中的决策。一些产物保持个人性质。一些变成共享的团队记忆。更少的一部分变成企业记忆。当它运作良好时，企业大脑不是独立于个体大脑之外的。它与个体大脑协作。它帮助人们记忆、贡献和检索，而不假装每个私人想法都是公司记录。这也意味着事实记忆需要归属：谁创建了这个，谁修改了它，谁现在拥有它，以及哪个人或团队使其正式化？它是否仍然是最新的？它是否被更新的内容所反驳？这个人能否查看底层来源？这个答案对于客户对话是否可信，还是仅仅是一个工作假设？这就是为什么我不认为事实记忆的持久版本仅仅是跨企业数据的 RAG（检索增强生成）。RAG 可以检索片段。一个构建良好的演示可能会让人感觉神奇。但公司不仅需要看似合理的片段。它需要持久的结构：出处、权限、所有权、新鲜度（时效性）、单一事实来源边界以及产物之间的关系。这不是说每个基于嵌入的检索系统都是无用的。而是说，当意义必须持久保存时，仅靠检索会失败。企业大脑版本需要更接近语义文件系统的东西。所谓语义文件系统，我指的是一个记忆层，其中的产物不仅仅是文本块。产物周围的关系与产物本身同样重要。一个客户通话连接到一个账户，账户连接到未解决的问题，问题连接到工单，工单连接到产品区域，产品区域连接到负责人，负责人连接到决策。这不仅仅是粘贴在文档之上的知识图谱，也不仅仅是带有元数据的 Markdown。关系的质量决定了记忆的质量。这改变了界面应有的感觉。它可能包含一个聊天窗口，因为聊天是提问自然语言问题的最简单方式。但界面不能仅仅是聊天。它应该是可变的。它应该出现在工作本身内部，根据某人的行为将事实推向前台，并尊重协助与监控之间的界限。目标不是为了监视人。目标是在不让人感到被监视的前提下帮助公司记忆。如果一名 IC（独立贡献者）问：“我要接手计费集成的工作。我需要知道什么？”答案不应该是十个链接的列表。它应该综合相关的规格说明、先前的工单、已知风险、负责人、客户承诺、最近的故障和未解决的决策。它应该解释什么是当前的，什么是过时的，以及证据来自哪里。如果一名经理问：“实际上是什么在阻碍入职流程？”系统不应该返回每个包含“入职”一词的文档。它应该汇集工单、状态更新、所有权、客户升级、会议产物和未解决的依赖关系。它应该将事实与解释区分开来。它应该说：“这里似乎是受阻的地方，这里是每部分的负责人，这是最新的证据，这也是我不确定的地方。” 如果一位 CEO 问：“我们对企业客户流失了解多少？”答案应该结合 CRM 数据、支持工单、续约备注、通话摘要、账户历史、产品问题和仪表盘指标。它不应该假装所有这些来源具有相同的权重。仪表盘可能会告诉你流失率增加了。客户通话可能会告诉你是什么造成了伤害。支持贴可能会告诉你问题是什么时候开始的。事实记忆应该将这些来源汇集在一起，而不抹去它们之间的差异。同样的问题不应该为每个人都产生相同的答案。IC 可能需要实施细节和负责人。经理可能需要阻碍因素、风险和范围。CEO 可能需要跨客户和战略层面的问题概览。个性化在这里不是装饰。它是记忆的一部分。系统必须理解提问者，他们被允许知道什么，以及他们试图做什么。这就是体验必须优于企业搜索的地方。Glean 和其他人表明，跨公司工具查找知识是一个真正的切入点。但企业大脑必须更进一步：跨来源综合、个性化答案、尊重权限、显示出处、注意过期信息、承认不确定性，并在你提问之前就为你提供正确的事实。最后一部分很重要。事实记忆不能只坐在搜索框里等待查询。一个好的企业大脑应该是主动的。在客户通话之前，它应该展示开放的承诺、最近的问题和先前的对话。当有人编辑路线图文档时，它应该展示相关的客户需求和重复的工作。当工单被分配时，它应该显示先前的故障和负责人。当请求定价例外时，它应该展示先例。当新员工加入时，它应该构建一张他们需要了解的内容的个性化地图。这就是知识库与记忆的区别。知识库是等待的。记忆是参与的。它会在上下文发生变化时出现，帮助个人更快地定位方向，并减少仅仅为了重建公司已知内容而必须被打扰的人数。在 Sentra，这是我们投入大量精力的领域之一：不仅是让公司知识可搜索，而且是让它在工作进行的那一刻变得可用。困难的部分不是连接工具。困难的部分是在知识跨越人员、团队、产物和系统移动时，保持公司知识的形态。事实记忆是企业大脑的第一层，因为没有它，公司就无法知道它知道什么。但事实记忆仍然是不够的。它可以告诉你存在什么，发生了什么，来源在哪里，谁参与了，什么时候发生了变化，以及工作流是如何工作的。它可以使公司变得可搜索、可解释和主动化。但它无法完全保留的是“为什么”做出某个决定。这存在于交互中：会议、消息、分歧、判断、升级和权衡。这是企业大脑的下一层：交互记忆。在 Sentra，我们正在构建企业通用智能：一个位于所有通信渠道、知识库和智能体痕迹之上的共享智能/记忆层，以了解组织中的每个人实际上是如何工作的，以及工作实际上是如何完成的，从而在近乎实时的时间范围内构建整个公司的鲜活世界模型。

🔗 相关文档