# Memory Is State, Not a Service
**作者**: Ashwin Gopinath
**日期**: 2026-05-05T15:52:21.000Z
**来源**: [https://x.com/ashwingop/status/2051691477831745907](https://x.com/ashwingop/status/2051691477831745907)
---
Part 5 of Company Brain Series!
Every AI tool now wants to remember. Meeting recorders remember conversations, search products remember documents, agents remember tasks, and workflow systems remember actions. That sounds like progress, but it may be making the real problem worse. If every tool remembers separately, the company still forgets.
A Company Brain needs a different architecture: memory as shared state, not memory as a service.
Humans have always patched over fragmented company memory through conversations, intuition, backchannels, and recurring meetings. We remember which customer was angry, what a PM promised, why a deal was risky, why a roadmap item moved, and which decision was made for reasons that never made it into the document. Agents do not have that luxury. They act from whatever state they can access. If that state is stale, partial, or private to one tool, their reasoning inherits the fragmentation. AI adoption makes this more dangerous. Every local memory becomes a local truth.
The three memories I have described in this series only work if they are three views of one state. Factual memory cannot be trapped in enterprise search. Interaction memory cannot live only in meeting notes. Action memory cannot disappear inside workflow tools or agent traces. If those three layers become three separate products, the substrate has already split, and everything built on top of it inherits that split.
This is the architectural center of Company Brain. Memory should not sit inside one app's API, one vector index, one database, one agent scratchpad, or one meeting recorder. The company has to be able to inspect it, correct it, version it, permission it, and move it. Otherwise every tool remembers a little, but the company itself still forgets.
The substrate has to include the obvious artifacts: people, teams, customers, projects, documents, tickets, emails, meetings, dashboards, and actions. But useful company memory is rarely the artifact alone. It also has to include relationships, events, facts, decisions, commitments, assumptions, outcomes, provenance, permissions, and history. A database stores records. A substrate defines the rules by which records become shared operating state.
Storage is no longer the hard question. The hard question is how a piece of data becomes context, and that is where ontology becomes central. An ontology is the lens that tells a system what kinds of things exist, how they relate, and what they can mean. The same artifact can mean very different things depending on the ontology applied to it.
Take a customer email. The raw artifact is the same for everyone: sender, recipients, timestamp, subject, body, attachments. To sales, that email is renewal risk. To product, it is a roadmap signal. To support, it is an escalation. To legal, it is an obligation. To finance, it is revenue exposure. To a CEO, it is strategic account risk. To an agent, it is an action trigger. The data did not change. The lens did. Humans do this naturally and constantly. They hear the same sentence differently depending on the customer, the project, the speaker, the history of the account, and what happens if the interpretation is wrong. A Company Brain cannot treat context as a single fixed label attached to an artifact. The same artifact has to be readable through different ontologies depending on the role, the question, the moment, and the action being considered.
This is also what makes context graphs useful. A context graph should not be everything connected to everything else, because that produces a hairball. A useful context graph is shaped by ontology: which entities exist, which relationships matter, which events should be remembered, and which parts of an artifact become durable memory. The ontology is the lens. The context graph is what the lens makes visible.
The lifecycle of a single customer complaint is the shape of what the substrate has to hold. The complaint arrives in email, gets discussed in Slack, shows up in a PM meeting, updates a support ticket, gets linked to an engineering issue, and causes sales to mark the account as a renewal risk. Someone promises a follow-up by Friday. Later the risk either resolves, escalates, or quietly becomes part of the next roadmap discussion.
The memory is not the email, the ticket, the meeting note, the Slack thread, or the engineering issue. The memory is the state change the complaint caused: what became true, who now owns it, why it mattered, which commitments were created, what action followed, and whether the company later learned from the outcome. State changes have to be first-class. A Company Brain has to remember that something changed: a risk appeared, an owner was assigned, a commitment was made, an assumption became false, a decision depended on a claim, or an action closed the loop.
I have been calling the abstraction we are building toward a semantic memory filesystem. The filesystem metaphor is useful because files have properties people understand: paths, ownership, inspection, version history, and portability. The semantic part is what changes. In our model, the primitives are not just files. They are entities (people, teams, customers, projects), facts (atomic claims with provenance), state changes (the events that move company state forward), and relationships (typed edges that carry meaning, not just adjacency). Ontologies sit above this layer as lenses, not below it as schemas, which is what lets the same underlying memory be read differently by sales, product, legal, and an agent without the memory itself splitting into copies.
That is the abstraction. The implementation has to do more than this. It has to support exact retrieval when someone is looking for a clause in a contract. It has to support semantic retrieval when the question is asked in words nobody used at the time. It has to support graph traversal when the answer lives in relationships, time, or permissions. And it has to support state change as a query, because the most useful question is often not "what is this" but "what changed and why."
The human and agent duality is the other reason this architecture matters. Humans need to inspect memory, correct it, and see what changed. Agents need to query it, update it, follow permissions, and act from it. If they do not share the same substrate, the system splits again: humans have docs, agents have scratchpads, and the company still does not have memory.
Trust becomes the real test. The substrate has to answer boring questions that are not actually boring. Where did this memory come from? Who can see it? Who changed it? Is it still current? What contradicts it? What action was taken from it? Can a human correct it? Without those answers, memory becomes another black box.
When the substrate works, it can show up differently for different people without becoming different memory. An IC may experience it as context for the task in front of them. A manager may see commitments, blockers, handoffs, and unresolved decisions. A CEO may see where the company is acting from inconsistent assumptions. An agent may see operating state: what is true, why it matters, what can be done, and what should be written back. Same memory, different interfaces.
A semantic memory substrate does not remove judgment, politics, ambiguity, or the work of deciding what matters. Companies are still human systems. The substrate is what makes their memory legible enough that the human work is not constantly being repeated.
There is a real open question I do not yet know the answer to: does one substrate generalize across verticals, or does each vertical need its own? The bet I am making is that the substrate generalizes and the ontologies on top of it do not. Sales, product, support, legal, and finance need their own lenses, but they should be looking at the same memory. Whether that bet holds is something the next year of building will answer. The next part of this series is about the lens layer, which is where adoption either compounds or fragments.
—-
Part 1: Why most companies have date but no memory
Part 2: Factual Memory
Part 3: Interaction Memory
Part 4: Action 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)
- [20K](https://x.com/ashwingop/status/2051691477831745907/analytics)
- [Why most companies have date but no memory](https://x.com/ashwingop/status/2049641901410955694)
- [Factual Memory](https://x.com/ashwingop/status/2049885545288077720)
- [Interaction Memory](https://x.com/ashwingop/status/2050963469898506342)
- [Action Memory](https://x.com/ashwingop/status/2051317871750558077?s=20)
- [Sentra](https://www.sentra.app/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:52 PM · May 5, 2026](https://x.com/ashwingop/status/2051691477831745907)
- [20.9K Views](https://x.com/ashwingop/status/2051691477831745907/analytics)
- [View quotes](https://x.com/ashwingop/status/2051691477831745907/quotes)
---
*导出时间: 2026/5/6 09:59:29*
---
## 中文翻译
# 记忆是状态，而非服务
**作者**：Ashwin Gopinath
**日期**：2026-05-05T15:52:21.000Z
**来源**：[https://x.com/ashwingop/status/2051691477831745907](https://x.com/ashwingop/status/2051691477831745907)
---
《公司大脑》系列第五部分！
如今每个 AI 工具都想拥有记忆。会议记录工具记住对话，搜索产品记住文档，智能体记住任务，工作流系统记住操作。这听起来像是进步，但可能正在让真正的问题变得更糟。如果每个工具各自记忆，公司整体仍然在遗忘。
公司大脑需要一种不同的架构：记忆作为共享状态，而非记忆即服务。
人类一直在通过对话、直觉、私下沟通和例行会议来弥补公司记忆的碎片化。我们记得哪位客户生气了，产品经理承诺了什么，为什么某笔交易有风险，为什么路线图上的某项被移动了，以及某个决定背后的原因——而这些原因从未写进文档。智能体没有这种奢侈的条件。它们只能基于能够访问的状态来行动。如果那些状态是过时的、不完整的，或是某个工具私有的，它们的推理就会继承这种碎片化。AI 的普及使这更加危险。每一个局部记忆都变成了局部真相。
我在本系列中描述的三种记忆，只有当它们是同一状态的三种视图时才能发挥作用。事实记忆不能被困在企业搜索里。交互记忆不能只存在于会议记录中。行动记忆不能消失在工作流工具或智能体轨迹里。如果这三层变成了三个独立的产品，基底就已经分裂了，构建在其上的一切都会继承这种分裂。
这就是公司大脑的架构核心。记忆不应位于某一个应用的 API、某一个向量索引、某一个数据库、某一个智能体的暂存区，或某一个会议记录工具之中。公司必须能够审查它、修正它、对它进行版本管理、为它设置权限，并迁移它。否则，每个工具都记住一点东西，但公司本身仍然在遗忘。
基底必须包含那些显而易见的实体：人员、团队、客户、项目、文档、工单、邮件、会议、仪表盘和操作。但有用的公司记忆很少只是实体本身。它还必须包含关系、事件、事实、决策、承诺、假设、结果、来源、权限和历史。数据库存储记录。基底则定义了记录如何成为共享运营状态的规则。
存储已不再是难题。真正的难题是，一条数据如何成为上下文，而这正是本体论成为核心所在。本体是告诉一个系统存在哪些类型的事物、它们如何关联、以及它们可能意味着什么的透镜。同一个实体，取决于应用其上的本体，可以有截然不同的含义。
以一封客户邮件为例。原始实体对所有人都是一样的：发件人、收件人、时间戳、主题、正文、附件。对销售来说，这封邮件是续约风险。对产品团队来说，它是路线图信号。对支持团队来说，它是一次升级处理。对法务来说，它是一项义务。对财务来说，它是收入风险敞口。对 CEO 来说，它是战略客户风险。对智能体来说，它是一个行动触发器。数据没有变，变的是透镜。人类自然而然且时刻在做这件事。他们会根据客户、项目、说话的人、该客户的历史，以及解读错误会带来什么后果，对同一句话产生不同的理解。公司大脑不能把上下文当作附着在实体上的单一固定标签。同一个实体必须能够根据角色、问题、时刻和正在考虑的行动，通过不同的本体来解读。
这也是上下文图有用的原因。上下文图不应该是万物互联，因为那会产生一团乱麻。有用的上下文图由本体塑造：哪些实体存在，哪些关系重要，哪些事件应被记住，以及实体的哪些部分成为持久记忆。本体是透镜，上下文图是透镜让肉眼可见的东西。
一次客户投诉的完整生命周期，正是基底必须承载内容的形态。投诉通过邮件到达，在 Slack 中被讨论，出现在产品经理会议上，更新了一张支持工单，被关联到一个工程问题，并导致销售将该客户标记为续约风险。有人承诺周五前跟进。之后，这个风险要么得到解决，要么升级，要么悄无声息地成为下一次路线图讨论的一部分。
记忆不是那封邮件、那张工单、那份会议记录、那条 Slack 消息串，或那个工程问题。记忆是投诉引发的状态变更：什么成为了事实，现在由谁负责，为什么它重要，产生了哪些承诺，随后采取了什么行动，以及公司后来是否从结果中学到了东西。状态变更必须是一等公民。公司大脑必须记住某个东西发生了变化：出现了一个风险，分配了一位负责人，做出了一项承诺，一个假设被证伪，一项决策依赖于某个主张，或者一个行动完成了闭环。
我一直把我们要构建的抽象称为语义记忆文件系统。文件系统的比喻很有用，因为文件具有人们理解的属性：路径、所有权、可审查性、版本历史和可移植性。而“语义”部分才是关键的变化。在我们的模型中，原语不仅仅是文件。它们是实体（人员、团队、客户、项目）、事实（带有来源的原子性主张）、状态变更（推动公司状态向前发展的事件）和关系（承载含义的类型化边，而不仅仅是相邻关系）。本体作为透镜位于这一层之上，而不是作为模式位于其下，这正是让销售、产品、法务和智能体能够以不同方式读取同一份底层记忆、而记忆本身不会分裂成多个副本的原因。
这就是那个抽象。而实现要做的事情远不止于此。它必须支持精确检索，当有人在合同中寻找某项条款时；必须支持语义检索，当问题用当时没人使用过的措辞提出时；必须支持图遍历，当答案存在于关系、时间或权限之中时；还必须支持将状态变更作为查询，因为最有用的问题往往不是“这是什么”，而是“发生了什么变化以及为什么”。
人与智能体的双重性是这个架构如此重要的另一个原因。人类需要检视记忆、修正它、看到发生了什么变化。智能体需要查询它、更新它、遵循权限，并基于它采取行动。如果二者不共享同一个基座，系统就会再次分裂：人类有文档，智能体有暂存区，而公司依然没有记忆。
信任成为真正的考验。这个基座必须能够回答那些看似无聊实则不然的问题。这条记忆从何而来？谁能看到它？谁修改了它？它是否仍然有效？什么与它相矛盾？基于它采取了什么行动？人类能否修正它？没有这些答案，记忆就会变成又一个黑箱。
当基座正常运作时，它可以对不同的人呈现不同的形态，而不会变成不同的记忆。一线员工可能将其视为手头任务的上下文。管理者可能看到承诺、阻碍、交接和未决的决策。CEO 可能看到公司在哪些方面基于相互矛盾的假设行动。智能体可能看到运行状态：什么是真的，为什么重要，能做什么，以及应该写回什么。同一份记忆，不同的界面。
语义记忆基座并不能消除判断、政治、模糊性，以及决定什么才重要这项工作。公司仍然是人的系统。基座的作用是让公司的记忆足够清晰可读，从而使人的工作不必不断地被重复。
还有一个真正的开放性问题，我还不知道答案：一个基座能否跨垂直领域通用，还是每个垂直领域都需要自己的基座？我所下的赌注是：基座是通用的，而其上的本体则不是。销售、产品、支持、法和财务需要各自不同的视角，但他们看到的应该是同一份记忆。这个赌注能否成立，将由接下来一年的构建来回答。本系列的下一部分将讨论视角层，那是采用率要么复利增长、要么碎片化的地方。
—-
第 1 部分：为什么大多数公司有数据却没有记忆
第 2 部分：事实记忆
第 3 部分：交互记忆
第 4 部分：行动记忆
在 Sentra，我们正在构建企业通用智能：一个共享的智能/记忆层，它建立在所有通信渠道、知识库和智能体轨迹之上，以理解组织中每个人实际如何工作以及工作实际如何完成，从而近乎实时地构建整个公司的活态世界模型。
## 相关链接
- [Ashwin Gopinath](https://x.com/ashwingop)
- [@ashwingop](https://x.com/ashwingop)
- [20K](https://x.com/ashwingop/status/2051691477831745907/analytics)
- [为什么大多数公司有数据却没有记忆](https://x.com/ashwingop/status/2049641901410955694)
- [事实记忆](https://x.com/ashwingop/status/2049885545288077720)
- [交互记忆](https://x.com/ashwingop/status/2050963469898506342)
- [行动记忆](https://x.com/ashwingop/status/2051317871750558077?s=20)
- [Sentra](https://www.sentra.app/)
- [升级到 Premium](https://x.com/i/premium_sign_up)
- [2026年5月5日 23:52](https://x.com/ashwingop/status/2051691477831745907)
- [20.9K 次浏览](https://x.com/ashwingop/status/2051691477831745907/analytics)
- [查看引用](https://x.com/ashwingop/status/2051691477831745907/quotes)
---
*导出时间: 2026/5/6 09:59:29*
