# Company Brain, Part 3: Interaction Memory
**作者**: Ashwin Gopinath
**日期**: 2026-05-03T15:39:30.000Z
**来源**: [https://x.com/ashwingop/status/2050963469898506342](https://x.com/ashwingop/status/2050963469898506342)
---
Almost everything important in a company happens in meetings, messages, or emails.
That sounds exaggerated until you start listing the actual places where decisions are made. A customer complains on a call. A sales rep promises a workaround. A manager says a project is blocked, but only after someone asks twice. A founder changes the priority in a five-minute Slack exchange. Legal approves something with conditions. Engineering agrees to ship, but only if one assumption holds.
Later, some artifacts appeared. A ticket. A CRM update. A roadmap note. A line in a launch doc. By then, the real context has already been compressed.
The last post was about factual memory: what happened, where the source is, who owns it, when it changed, and how things connect. Interaction memory is different. It is not the memory of artifacts. It is the memory of what happened between people before the artifact existed.
Its goal is to preserve the parts factual memory usually drops: why something happened, how people expected the work to be done, what constraint mattered, which assumption was fragile, and what was left unsaid. Interaction is the chain of thought of the organization. It is the trace of how a group moved from partial information to judgment.
That difference matters because companies do not make most decisions inside databases. They make them in conversation. The database records the aftermath. A CRM field may say an account is at risk, but the customer call explains the real objection. A roadmap document may say launch moved by two weeks, but the meeting explains the tradeoff. A ticket may say SSO is needed, but the sales conversation explains why it mattered and who made the promise.
Human-human interaction is still upstream of human-agent interaction. Agents matter, and agent traces will matter more over time. But today, most agent work inherits its purpose from human conversations. The agent may draft the email, update the ticket, summarize the thread, or execute the workflow. The reason the work exists usually came from people talking to each other.
If factual memory is the company remembering its artifacts, interaction memory is the company remembering how meaning was created.
A transcript is not enough. A summary is not enough. Even a good meeting note is only a surface representation of the interaction. The hard problem is interpretation. What was actually decided? What was implied but not said? What did people disagree about? Which objection was real? Which commitment was made casually but will later matter?
Ontology is the word for this problem. An ontology is the set of concepts and relationships a system uses to make sense of a domain. In a company, the ontology decides whether something in a conversation is a decision, commitment, objection, escalation, dependency, assumption, customer pain, owner, precedent, or open question. Those labels are not just metadata. They decide what gets remembered.
Take a boring sentence from a meeting: “We can ship this Friday if legal signs off and Acme is okay with the beta limitation.”
A transcript stores the sentence. A meeting summary might say the team discussed the Friday launch. Interaction memory has to see the structure underneath. From a product lens, this is a launch plan with a constraint. From a legal lens, it is an approval dependency. From a customer lens, it is a conditional commitment to Acme. From a sales lens, it may be a deal risk. From an action lens, it contains follow-ups. From an executive lens, it is not actually a closed decision.
Humans do this naturally. We 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. Existing systems usually do not. They store the sentence once, attach a summary, and hope retrieval will recover the meaning later.
Interaction memory cannot be a static note archive. The meaning of an interaction depends on the ontology used to interpret it. Change the ontology, and the same interaction can mean something different. A casual objection from a customer can later become evidence of churn risk. A technical concern in an architecture meeting can later explain why a launch slipped. A one-line approval in an email can later become precedent.
The company has to be able to reread its own past.
Humans do this all the time. Something that seemed like a minor complaint becomes important after three more customers repeat it. A vague concern becomes the thing everyone should have listened to. A decision that looked settled becomes obviously conditional once the missing assumption shows up. A real Company Brain should be able to do some version of that.
Here the context graph matters. A context graph is the structure connecting people, teams, customers, projects, commitments, decisions, risks, assumptions, dependencies, and time. Interaction memory should update that graph. A meeting should not only produce a note. It should change the map of what the company believes, what it has promised, what remains unresolved, and what should happen next.
The diagram version of this is clean. The real version is messy. People hedge. They disagree politely. They imply ownership without assigning it. They make decisions without announcing that a decision has been made. They refer to prior context with phrases like “same issue as last time” or “the enterprise thing.” They move between strategy, emotion, execution, and politics in the same ten minutes.
A useful system has to know what to remember and what to ignore. Too little memory, and the company keeps forgetting why things happened. Too much memory, and the system becomes noisy or creepy. Interaction memory sits very close to how people think, negotiate, disagree, and change their minds. If you get the product wrong, it feels like surveillance. If you get it right, it feels like the company finally stopped losing the thread.
That means permissions and boundaries are not a detail. Some interactions are personal. Some are team context. Some are company records. Some can be summarized but not quoted. Some should contribute to aggregate memory without exposing the raw conversation broadly. A Company Brain has to understand those differences, or people will not trust it with the most important context.
It also means the interface cannot just be a meeting recorder. Recording, transcription, and action items are useful, but they are not the category. The interface should help before, during, and after an interaction. Before a customer call, it should surface prior commitments, open issues, decision history, and unresolved questions. After a meeting, it should identify decisions, assumptions, risks, and follow-ups. Weeks later, it should notice patterns across interactions that no one person is holding in their head.
For an IC, interaction memory might answer: “What did we decide in the last architecture discussion, and what assumptions still need validation?” The answer should not be a transcript. It should say what changed, what stayed open, who owned the next step, and which prior discussions matter.
For a manager, the question might be: “Which commitments did my team make across customer calls and internal meetings this week?” The answer should connect human promises to tickets, owners, deadlines, and risks. It should also notice the awkward cases: commitments that were implied but never assigned, or decisions that different people understood differently.
For a CEO, the question is often broader: “Where are teams making decisions from different assumptions?” This is where interaction memory becomes much more than note-taking. It can show that sales believes a feature is committed, product believes it is exploratory, engineering believes it is blocked, and support believes it is already late. No dashboard will show that cleanly. The truth lives in interactions.
The proactive version is the interesting one. A Company Brain should notice when the same objection appears in three customer calls. It should notice when two teams use conflicting definitions of the same metric. It should notice when a decision keeps getting reopened because the original tradeoff was never recorded clearly. It should notice when an owner is implied but never named. It should notice when an escalation has quietly become a product signal.
Here is the bridge between memory and action. Factual memory can tell you what exists. Interaction memory tells you what people meant, debated, promised, and left unresolved. It preserves the organizational reasoning that rarely makes it into the artifact. Without it, agents will keep operating downstream of incomplete context. They may retrieve the ticket, draft the email, or update the CRM, but they will not know the human reason the work matters.
That is why I think the Company Brain problem starts with human communication. Not because documents and data are unimportant. They are obviously important. But the company’s meaning is created in interaction before it is formalized anywhere else.
Interaction memory is the second layer of a Company Brain. It turns meetings, messages, emails, calls, complaints, and debates into structured memory. But it still does not complete the loop. Once the company remembers what happened and understands what the interaction meant, it has to coordinate what happens next.
That is the third layer: action memory.
Part 1: Why most companies have date but no memory
Part 2: Factual 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)
- [29K](https://x.com/ashwingop/status/2050963469898506342/analytics)
- [factual memory: what happened](https://x.com/ashwingop/status/2049885545288077720)
- [Why most companies have date but no memory](https://x.com/ashwingop/status/2049641901410955694)
- [Factual Memory](https://x.com/ashwingop/status/2049885545288077720)
- [Sentra](https://www.sentra.app/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:39 PM · May 3, 2026](https://x.com/ashwingop/status/2050963469898506342)
- [29.9K Views](https://x.com/ashwingop/status/2050963469898506342/analytics)
- [View quotes](https://x.com/ashwingop/status/2050963469898506342/quotes)
---
*导出时间: 2026/5/4 09:15:11*
---
## 中文翻译
# 公司大脑，第三部分：交互记忆
**作者**: Ashwin Gopinath
**日期**: 2026-05-03T15:39:30.000Z
**来源**: [https://x.com/ashwingop/status/2050963469898506342](https://x.com/ashwingop/status/2050963469898506342)
---
公司里几乎所有重要的事情都发生在会议、消息或邮件中。
这话听起来有些夸张，直到你开始列举做出决策的实际场所。客户在电话中投诉。销售人员承诺了一个变通方案。经理说项目被阻塞了，但这只是在有人追问了两次之后。创始人在一次五分钟的 Slack 交流中改变了优先级。法务在有条件的情况下批准了某事。工程团队同意发布，但前提是一个假设成立。
后来，出现了一些产物。一张工单。一次 CRM 更新。一条路线图备注。一篇发布文档中的一行文字。到了那时，真正的语境已经被压缩了。
上一篇文章讨论的是事实记忆：发生了什么、来源在哪里、谁负责、何时变更以及事物如何关联。交互记忆则不同。它不是对产物的记忆。它是对产物产生之前人与人之间发生了什么的记忆。
它的目标是保留那些通常被事实记忆丢弃的部分：为什么发生某事、人们期望工作如何完成、什么约束很重要、哪个假设是脆弱的，以及哪些话没明说。交互是组织的思维链。它是一个群体如何从部分信息走向判断的轨迹。
这种差异之所以重要，是因为公司并不是在数据库内部做出大多数决策的。他们在对话中做出决策。数据库记录的是后果。一个 CRM 字段可能会显示某个账户有风险，但客户通话记录解释了真正的异议。路线图文档可能会说发布推迟了两周，但会议记录解释了其中的权衡。一张工单可能会说需要 SSO，但销售对话解释了为什么它很重要以及是谁做出的承诺。
人与人之间的交互仍然是人与代理交互的上游。代理很重要，而且随着时间的推移，代理轨迹将变得更加重要。但在今天，大多数代理工作的目的都继承自人类对话。代理可以起草邮件、更新工单、总结话题或执行工作流。工作存在的理由通常源于人与人之间的交谈。
如果说事实记忆是公司记住其产物，那么交互记忆就是公司记住意义是如何被创造的。
仅仅有逐字稿是不够。仅仅有摘要是不够。即使是一份好的会议记录也只是交互的表层表征。难题在于解释。实际做出了什么决定？暗示了什么但没明说？人们在哪些方面有分歧？哪个异议是真实的？哪个承诺是随口一说但后来变得重要？
本体是描述这个问题的词汇。本体是一组概念和关系，系统利用它来理解某个领域。在公司中，本体决定了对话中的某物是决策、承诺、异议、升级、依赖、假设、客户痛点、负责人、先例还是未解之谜。这些标签不仅仅是元数据。它们决定了什么会被记住。
从会议中拿一个无聊的句子：“如果法务签字批准，且 Acme 对 Beta 版的限制没问题，我们可以在本周五发布。”
逐字稿存储了这句话。会议摘要可能会说团队讨论了周五的发布。交互记忆必须看到底层的结构。从产品的角度来看，这是一个带有约束的发布计划。从法律的角度来看，这是一个批准依赖。从客户的角度来看，这是对 Acme 的有条件承诺。从销售的角度来看，这可能是一个交易风险。从行动的角度来看，它包含了后续跟进。从高管的角度来看，这实际上并不是一个已确定的决策。
人类天生就会这样做。根据客户、项目、发言人、账户历史以及解释错误会发生什么情况的不同，我们对同一句话的理解也不同。现有的系统通常做不到这一点。它们存储一次句子，附上摘要，并寄希望于检索能在以后恢复意义。
交互记忆不能是一个静态的笔记档案。交互的意义取决于用来解释它的本体。改变本体，同样的交互可能意味着完全不同的东西。客户随口提出的一个异议后来可能成为流失风险的证据。架构会议上的一个技术顾虑后来可能解释了为什么发布延期。邮件中一行批准的文字后来可能成为先例。
公司必须能够重读它自己的过去。
人类一直在这样做。起初看似微不足道的投诉，在又有三个客户重复之后变得重要。一个模糊的顾虑变成了每个人都应该倾听的事情。一个看起来已成定局的决定，一旦缺失的假设出现，就明显变成了有条件的决定。一个真正的公司大脑应该能够做到某种程度的这种能力。
在这里，上下文图谱很重要。上下文图谱是连接人员、团队、客户、项目、承诺、决策、风险、假设、依赖和时间的结构。交互记忆应该更新这个图谱。会议不应仅仅产生一条笔记。它应该改变公司的信念地图、它的承诺地图、未解决的问题地图以及下一步应该发生什么的地图。
图表版本看起来很干净。现实版本则是一团糟。人们会闪烁其词。他们客气地表示异议。他们暗示责任归属但不明确指派。他们在没有宣布做出决定的情况下做出了决定。他们用“和上次一样的问题”或“企业级那档子事”这样的短语来指代之前的语境。他们在同样的十分钟内从战略、情绪、执行和政治之间来回切换。
一个有用的系统必须知道该记住什么，该忽略什么。记忆太少，公司就会不断忘记事情发生的原因。记忆太多，系统就会变得充满噪音或令人毛骨悚然。交互记忆非常贴近人们的思考、谈判、争论和改变主意的方式。如果你把产品做错了，它感觉就像监控。如果你做对了，它感觉就像公司终于没有丢失线索。
这意味着权限和边界不是一个细节。有些交互是私人的。有些是团队语境。有些是公司记录。有些可以总结但不能引用。有些应该有助于聚合记忆，而不是广泛暴露原始对话。公司大脑必须理解这些差异，否则人们不会信任它来处理最重要的上下文。
这也意味着界面不能仅仅是一个会议记录器。录制、转录和行动项目很有用，但它们不是这个品类。界面应该在交互之前、期间和之后提供帮助。在客户通话之前，它应该展示之前的承诺、未解决的问题、决策历史和未回答的问题。会议结束后，它应该识别决策、假设、风险和后续行动。几周后，它应该注意到没有人能完全记住的跨交互模式。
对于一名个人贡献者（IC）来说，交互记忆可能会回答：“我们在上一次架构讨论中决定了什么，以及哪些假设仍然需要验证？”答案不应该是逐字稿。它应该说明什么改变了，什么仍然悬而未决，谁负责下一步，以及之前的哪些讨论很重要。
对于经理来说，问题可能是：“本周我的团队在客户通话和内部会议中做出了哪些承诺？”答案应该将人类的承诺与工单、负责人、截止日期和风险联系起来。它还应该注意到那些尴尬的情况：暗示了但从未分配的承诺，或者不同的人理解不同的决定。
对于 CEO 来说，问题通常更宽泛：“团队在哪里基于不同的假设做出决策？”这正是交互记忆远超笔记记录的地方。它可以显示销售认为某个功能已承诺，产品认为它是探索性的，工程认为它被阻塞，而支持认为它已经延期。没有仪表盘能清晰地展示这一点。真相存在于交互之中。
主动版本才是有趣的。公司大脑应该注意到当同样的异议出现在三次客户通话中。它应该注意到当两个团队对同一指标使用冲突的定义。它应该注意到当一个决定不断被重新打开，因为最初的权衡从未被清晰地记录下来。它应该注意到当一个负责人被暗示但从未被点名。它应该注意到当一个升级悄悄地变成了产品信号。
这就是记忆和行动之间的桥梁。事实记忆可以告诉你存在什么。交互记忆告诉你人们的意思、辩论了什么、承诺了什么以及留下了什么未解决。它保留了很少进入产物中的组织推理。没有它，代理将继续在不完整的上下文下游运作。它们可以检索工单、起草邮件或更新 CRM，但它们不会知道工作之所以重要的人类原因。
这就是为什么我认为公司大脑的问题始于人类沟通。并不是因为文档和数据不重要。它们显然很重要。但是公司的意义是在交互中创造的，然后才在其他地方正式化。
交互记忆是公司大脑的第二层。它将会议、消息、邮件、通话、投诉和辩论转化为结构化记忆。但这仍然没有完成闭环。一旦公司记住了发生了什么并理解了交互意味着什么，它就必须协调接下来发生的事情。
这就是第三层：行动记忆。
第 1 部分：为什么大多数公司有数据但没有记忆
第 2 部分：事实记忆
在 Sentra，我们正在构建企业级通用智能：一个共享的智能/记忆层，位于所有通信渠道、知识库和代理轨迹之上，以了解组织中的每个人实际上是如何工作的，以及工作实际上是如何完成的，从而在近乎实时的情况下构建整个公司的生动世界模型。
## 相关链接
- [Ashwin Gopinath](https://x.com/ashwingop)
- [@ashwingop](https://x.com/ashwingop)
- [29K](https://x.com/ashwingop/status/2050963469898506342/analytics)
- [factual memory: what happened](https://x.com/ashwingop/status/2049885545288077720)
- [Why most companies have date but no memory](https://x.com/ashwingop/status/2049641901410955694)
- [Factual Memory](https://x.com/ashwingop/status/2049885545288077720)
- [Sentra](https://www.sentra.app/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:39 PM · May 3, 2026](https://x.com/ashwingop/status/2050963469898506342)
- [29.9K Views](https://x.com/ashwingop/status/2050963469898506342/analytics)
- [View quotes](https://x.com/ashwingop/status/2050963469898506342/quotes)
---
*导出时间: 2026/5/4 09:15:11*