# 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 工具都想要拥有记忆。会议记录工具记录对话，搜索产品记录文档，代理记录任务，工作流系统记录操作。这听起来像是进步，但实际上可能会让真正的问题变得更糟。如果每个工具都单独记忆，公司整体仍然会遗忘。
公司大脑需要一种不同的架构：记忆作为共享状态，而非记忆作为一种服务。
人类总是通过对话、直觉、非正式渠道和例会来修补碎片化的公司记忆。我们记得哪位客户发过火，产品经理（PM）承诺过什么，为什么某笔交易有风险，路线图项目为何变动，以及哪些决策是因为文档中未曾记录的原因而做出的。代理没有这种便利。它们只能根据所能访问的状态行事。如果该状态是陈旧的、局部的，或者是某个工具私有的，它们的推理就会继承这种碎片化。AI 的采用让这一点变得更加危险。每一个局部记忆都变成了一个局部真理。
我在本系列中描述的三种记忆，只有在它们是同一个状态的三个视图时才有效。事实记忆不能被困在企业搜索中。交互记忆不能只存在于会议记录里。行动记忆不能消失在工作流工具或代理追踪中。如果这三层变成了三个独立的产品，那么底层基质已经分裂，而在其上构建的一切都会继承这种分裂。
这就是公司大脑的架构核心。记忆不应位于某个应用的 API、某个向量索引、某个数据库、某个代理的草稿板或某个会议记录器中。公司必须能够对其进行检查、更正、版本控制、权限管理和迁移。否则，每个工具都记得一点，但公司本身依然在遗忘。
底层基质必须包含显而易见的实体：人员、团队、客户、项目、文档、工单、邮件、会议、仪表板和行动。但是，有用的公司记忆很少仅仅包含实体本身。它还必须包含关系、事件、事实、决策、承诺、假设、结果、出处、权限和历史。数据库存储的是记录。底层基质定义的是记录转化为共享操作状态所依据的规则。
存储不再是难题。难题在于数据如何转化为上下文，而这正是本体论变得至关重要的地方。本体论是一种透镜，它告诉系统存在哪些类型的事物，它们如何关联，以及它们意味着什么。根据应用的本体论不同，同一个实体可能意味着截然不同的事物。
以一封客户邮件为例。对于所有人来说，原始实体都是一样的：发件人、收件人、时间戳、主题、正文、附件。对于销售，这封邮件意味着续约风险。对于产品，这是路线图的信号。对于支持，这是升级事件。对于法务，这是一种义务。对于财务，这是营收敞口。对于 CEO，这是战略账户风险。对于代理，这是一个行动触发器。数据没有变，变的是透镜。人类自然而然且时刻都在做这件事。他们根据客户、项目、发言者、账户历史以及解读错误的后果，对同一句话有不同的理解。公司大脑不能把上下文视为附加在实体上的单一固定标签。根据角色、问题、时刻和正在考虑的行动，同一个实体必须能够通过不同的本体论被读取。
这也是上下文图谱有用的原因。上下文图谱不应该是万物互联的，因为那只会产生一团乱麻。有用的上下文图谱是由本体论塑造的：哪些实体存在，哪些关系重要，哪些事件应该被记住，以及实体的哪些部分应该成为持久的记忆。本体论是透镜。上下文图谱是透镜使其可见的内容。
单个客户投诉的生命周期，展示了底层基质必须承载的内容形态。投诉通过邮件到达，在 Slack 中被讨论，出现在 PM 的会议上，更新了支持工单，被链接到工程问题，并导致销售将账户标记为续约风险。有人承诺在周五之前跟进。后来，风险要么得到解决，要么升级，要么悄无声息地成为下一次路线图讨论的一部分。
记忆不是那封邮件、那个工单、那条会议记录、那个 Slack 话题或那个工程问题。记忆是投诉引发的状态变化：什么变成了事实，现在由谁负责，为什么它很重要，创建了哪些承诺，采取了什么行动，以及公司后来是否从结果中吸取了教训。状态变化必须成为一等公民。公司大脑必须记住某些东西发生了变化：出现了风险，分配了负责人，做出了承诺，假设变得不再成立，决策依赖于某项主张，或者行动完成了闭环。
我一直把我们正在构建的抽象称为语义记忆文件系统。文件系统的比喻之所以有用，是因为文件具有人们能理解的属性：路径、所有权、检查、版本历史和可移植性。发生变化的是语义部分。在我们的模型中，原语不仅仅是文件。它们是实体（人员、团队、客户、项目）、事实（具有出处的原子主张）、状态变化（推动公司状态前进的事件）和关系（承载意义的类型化边，而不仅仅是邻接关系）。本体论位于这一层之上作为透镜，而不是位于其下作为模式，这能让销售、产品、法务和代理以不同的方式读取同一底层记忆，而无需将记忆本身分裂成多个副本。
这就是抽象概念。实现层面必须做得更多。它必须支持精确检索，例如当有人在合同中寻找某个条款时。它必须支持语义检索，例如当问题使用的措辞在当时无人提及过时。它必须支持图遍历，当答案存在于关系、时间或权限中时。而且它必须支持将状态变化作为查询，因为最有用的问题往往不是“这是什么”，而是“什么改变了，为什么”。
人与代理的二重性是该架构至关重要的另一个原因。人类需要检查记忆、更正记忆并查看发生了什么变化。代理需要查询记忆、更新记忆、遵循权限并据此行动。如果它们不共享同一个底层基质，系统就会再次分裂：人类拥有文档，代理拥有草稿板，而公司依然没有记忆。
信任成为了真正的考验。底层基质必须回答那些看似无聊实则不然的问题。这段记忆来自哪里？谁能看到它？谁修改了它？它是否仍然最新？什么与之相矛盾？基于它采取了什么行动？人类可以更正它吗？没有这些答案，记忆就会变成另一个黑盒。
当底层基质正常工作时，它可以为不同的人呈现不同的样子，而不会变成不同的记忆。一名个人贡献者（IC）可能体验到的是眼前任务的上下文。一名经理可能看到的是承诺、阻碍、交接和未解决的决策。一名 CEO 可能看到的是公司在哪些地方正基于不一致的假设行事。一个代理可能看到的是操作状态：什么是真的，为什么重要，可以做什么，以及应该写回什么。同样的记忆，不同的界面。
语义记忆基质并不能消除判断、政治、模糊性或决定什么是重要的工作。公司仍然是人类系统。底层基质的作用是让它们的记忆变得足够清晰，从而使人类的工作不必不断重复。
有一个我尚未知道答案的真正开放性问题：是一个底层基质能泛化适用于所有垂直领域，还是每个垂直领域都需要自己的？我押注的是底层基质可以泛化，而其之上的本体论则不行。销售、产品、支持、法务和财务需要它们自己的透镜，但它们应该查看的是同一个记忆。这一押注是否成立，将留待下一年的构建来回答。本系列的下一部分将关于透镜层，这是采用要么复合要么碎片化的地方。
—-
第一部分：为什么大多数公司有数据但没有记忆
第二部分：事实记忆
第三部分：交互记忆
第四部分：行动记忆
在 Sentra，我们正在构建企业通用智能：一个位于所有沟通渠道、知识库和代理追踪之上的共享智能/记忆层，以了解组织中的每个人实际上是如何工作的，以及工作实际上是如何完成的，从而在近乎实时的时间内构建整个公司的鲜活世界模型。