打造公司大脑的一年经验总结

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

本文分享了作者构建“公司大脑”系统的经验。核心观点包括：企业智能将从单纯的知识库转向基于本体的记忆系统；公司记忆应自发于日常工作流而非简单的转录；系统需支持基于角色的多种本体视角，以解决不同部门对同一信息不同理解的问题；最终目标是建立企业的世界模型，通过强化学习机制，降低信息传递延迟，实现上下文实时感知与智能响应。

企业智能本体论组织记忆 Agent 知识管理 RL 产品设计公司大脑 LLM

# What Building a Company Brain over the last Year Taught Me **作者**: Ashwin Gopinath **日期**: 2026-05-06T15:41:06.000Z **来源**: [https://x.com/ashwingop/status/2052051032566530216](https://x.com/ashwingop/status/2052051032566530216) --- ![Image](/doc/1732/image/img_7a386f651768.jpg) We did not start by calling it Company Brain. Our first name for what we were building was Enterprise General Intelligence. The thesis was that some version of AGI would become real over the next few years, and that intelligence itself would start to get commoditized. If every enterprise eventually has access to similar intelligence, what makes one company better than another? My answer was: the way the company works. That was what the name was trying to capture, even if it sounded too much like a research agenda. Company Brain became the simpler and more accurate name. The project did not start as category theory. It started with founder pain. I wanted to understand what was actually happening inside the company without relying on status updates, secondhand summaries, and my own ability to chase context across meetings, messages, documents, and people. Every founder knows some version of this problem. You have a sense of what is going on, but the detailed reality is always scattered. Our first instinct was naive: what if an agent could check in with everyone, call around, ask what was happening, and give me a live picture of the organization? In the strange peak of Elon/DOGE discourse, we even half-joked about naming the thing Elon. It was a terrible name, but the impulse was honest. A founder wants to know what is happening everywhere without slowing everyone down. That idea broke quickly because people do not want to report to an agent every day. More than that, company truth is not created by polling people. The truth is already being produced in the work itself: in the meeting where a customer risk becomes real, the Slack thread where a workaround gets accepted, the email where a commitment is made, the call where a product decision changes, and the ticket where all of that gets reduced into a few fields. The first lesson was simple, though it took a while to internalize: company memory has to emerge from the work itself. Meetings, messages, emails, and calls are the undistilled version of company reality. Documents, tickets, dashboards, and workflows matter, but they are usually downstream. The decisions, objections, tradeoffs, commitments, complaints, and handoffs happen before the artifact is cleaned up. I have started to think of these interactions as the chain of thought of the organization. Not in the literal model sense, but in the human sense. They are where the company reasons before it writes down what it decided. That changed the problem from transcription to memory. We were not trying to record more words; we were trying to understand what should be remembered. A transcript tells you what was said, but memory has to understand why it mattered, who it mattered to, what changed because of it, and what should happen next. That is how ontology became central for us. We did not get there by wanting a cleaner data model. We got there because the same conversation kept meaning different things to different parts of the company. A customer call is a good example. A salesperson may hear renewal risk, a PM may hear a roadmap signal, a support lead may hear an escalation, and a lawyer may hear an obligation. The artifact is the same, but the useful memory depends on the perspective. LLMs can help understand what was said; ontology determines what it means inside the company. Organizational memory is different. It is still complex, but it is more tractable. Companies have roles, functions, customers, products, risks, commitments, owners, workflows, and decisions. A CEO, PM, lawyer, support lead, salesperson, manager, and IC may see the same artifact differently, but the set of meaningful perspectives is not infinite. That boundedness is one reason company memory is buildable. The second lesson was that you cannot solve this by dumping everything into one store. That only moves fragmentation down a layer. If the memory substrate cannot support different ontologies over the same underlying data, the company ends up with separate memories for sales, product, legal, support, leadership, and agents. The interface may look unified while the memory has already split. The substrate has to be universal without forcing one universal interpretation. That sentence took us a long time to arrive at. A useful Company Brain needs a single memory substrate that can hold the same underlying artifacts while allowing different valid perspectives on them. The CEO looking at a customer email should not see the same thing as the support lead, the PM, or the account owner. They should all be looking at the same memory, but through different ontological lenses. This is also why context graphs are not static objects. The graph depends on the ontology. The same email may create a risk trace, a commitment trace, a decision trace, an action trace, or several of those at once. The ontology determines which relationships matter, which state changes should be remembered, and which future actions the memory should inform. Memory traces matter because they let the system begin to build a world model of the company. By world model, I do not mean anything mystical. I mean a learned representation of how work tends to move: which signals precede risks, which commitments usually slip, which handoffs fail, which decisions create downstream work, and which actions resolve problems. This is the deeper reason memory matters for enterprise AI. Without memory, agents can act only from the context they are given in the moment. With memory traces, decision traces, and action traces, the system can begin to learn from outcomes over time. If a certain escalation pattern repeatedly leads to churn, if a handoff keeps failing, or if a type of customer request usually predicts a roadmap change, the system should learn. In plain terms, this is learning from outcomes. If you want the technical analogy, it is the beginning of reinforcement learning inside the company: traces, actions, outcomes, and feedback loops. The practical version is grounded. The organization leaves traces, actions produce outcomes, and the memory substrate makes those outcomes usable. That realization changed how we thought about the product. The interface cannot stop at “go ask AI.” That is useful, but it is not the end state. The better experience is that the right context, memory, or action shows up when the work needs it. Testing this with customers made the idea less theoretical. In one organization, a customer success person was speaking with a customer when something that looked like churn risk surfaced in the conversation. The system did not wait for a weekly account review or a cleaned-up CRM note. It flagged the CTO while the conversation was still fresh, and the CTO started investigating immediately. The interesting part was not that the CTO learned something they never would have learned otherwise. They probably would have found out eventually. The interesting part was latency. A signal that normally would have moved through a chain of summaries, meetings, and escalations showed up almost as it happened. That creates a different kind of friction. When information moves that quickly, the question becomes who should see it, how it should be framed, and what the system should ask a human to do next. We saw a related version of this in project work. People working on the same initiative can have different understandings of the goal, the timeline, or what has already been decided. That has always happened inside companies. Usually it is discovered later, when the project slips, someone escalates, or the meeting turns into a painful reconstruction of how everyone got misaligned. A Company Brain can notice some of that earlier. But then the product question becomes more delicate. Should it tell everyone they disagree? Should it ask a manager to intervene? Should it simply show the conflicting traces and let the humans work it out? These are not technical questions alone. They are human questions that become visible earlier because memory compresses the time between a signal appearing and someone noticing it. For a founder or CEO, this means answering the question almost nobody can answer well: what is actually happening inside the company? Not the sanitized version or the dashboard version, but the operational reality. For leadership, it means seeing whether strategy is turning into work. For managers, it means understanding blockers, commitments, and handoffs without constantly asking for updates. For ICs, it means context comes with the task, and work that used to disappear into meetings and messages can become visible without turning the company into a surveillance machine. That boundary matters. Company memory has to be explicit about ontology, provenance, permissions, and scope. The goal is not to make everyone feel watched. The goal is to make work legible, creditable, and easier to act on. In the examples above, the issue was not surveillance. The issue was that information passed from one part of the company to another much faster than the organization was used to. Culture will always matter here, but architecture matters too. Over the last year, testing these ideas with teams and design partners has made one thing clearer: memory is useful almost everywhere, but it should not show up everywhere in the same way. Sometimes it should summarize, sometimes it should warn, sometimes it should connect two things nobody realized were related, and sometimes it should stay quiet until the right condition is met. One of the harder questions from a large enterprise pilot was how to show the value of memory at all. The default visual answer is a knowledge graph. There is a place for that, especially when explaining the architecture. But I do not think a graph is how most people should experience company memory day to day. The right experience is closer to the system helping you notice what matters and make the next good decision. TikTok is a strange but useful analogy. TikTok does not show you a giant map of all your interests. It understands enough about what you care about to surface the next thing you are likely to engage with. Company memory should not work like consumer recommendations, but the product lesson is real. The value of memory is often experienced through surfacing, not browsing. The system should know enough about the company, the role, the work, and the current moment to bring the right thing forward. That is especially true for a CEO. A CEO wants to know everything that is happening inside the company, but no human can process everything directly. The product cannot simply become a firehose with a better search box. It has to become a tool for interacting with the company’s live memory: what changed, what is drifting, what is misunderstood, what requires judgment, and what can safely wait. That is what makes the substrate so important. If the memory layer is flexible, the surfaces can be different. A CEO surface, manager surface, IC surface, and agent surface can all use the same underlying company memory without becoming the same product. The interface question matters more than I expected. I do not think Company Brain should feel like another person inside the company. If it behaves too much like a copilot or an employee, it can quietly take agency away from the humans who still own the decision. It should feel more like a tool, a cockpit, or a memory instrument. It can surface reality, show disagreement, and prepare the work, but humans need to remain responsible for judgment. That may be the strangest lesson from building this for a year. When AI starts to understand enough of the company collectively, the dynamics change in ways that are not obvious from the outside. The obvious concern is task automation, but the larger change is pace. Signals move faster, misunderstandings appear earlier, and collaboration starts to feel different because the company can notice more of itself in motion. We started with the ambition of Enterprise General Intelligence. A year later, I think the clearer primitive is Company Brain. The ambition did not get smaller. The path became clearer: the memory substrate has to come first. The version of enterprise AI I believe in is not built around tool-local memory. It is built around shared semantic company state: interactions becoming memory, memory becoming a world model, and the world model helping humans and agents act with context. That is what we have been building at Sentra. —- Part 1: Why most companies have date but no memory Part 2: Factual Memory Part 3: Interaction Memory Part 4: Action Memory Part 5: Memory Is State, Not a Service At Sentra, where we are building what can be only described as a "company brain", a shared intelligence/memory layer that sits on all communication channels, knowledge bases, action 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) - [10K](https://x.com/ashwingop/status/2052051032566530216/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) - [Memory Is State, Not a Service](https://x.com/ashwingop/status/2051691477831745907) - [Sentra](https://www.sentra.app/) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [11:41 PM · May 6, 2026](https://x.com/ashwingop/status/2052051032566530216) - [10.4K Views](https://x.com/ashwingop/status/2052051032566530216/analytics) - [View quotes](https://x.com/ashwingop/status/2052051032566530216/quotes) --- *导出时间: 2026/5/7 09:01:52* --- ## 中文翻译 # 过去一年构建“公司大脑”带给我的启示 **作者**: Ashwin Gopinath **日期**: 2026-05-06T15:41:06.000Z **来源**: [https://x.com/ashwingop/status/2052051032566530216](https://x.com/ashwingop/status/2052051032566530216) --- ![Image](/doc/1732/image/img_7a386f651768.jpg) 我们一开始并没有叫它“公司大脑”。我们最初给正在构建的东西起名叫“企业通用智能”。当时的论点是，某种形式的通用人工智能（AGI）会在未来几年内成为现实，而且智能本身将开始变得商品化。如果每家企业最终都能获得相似的智能，那么是什么让一家公司比另一家公司更优秀呢？我的答案是：公司运作的方式。这就是这个名字想要捕捉的含义，尽管它听起来太像是一个研究议程了。“公司大脑”后来成了一个更简单、更准确的名字。这个项目并非始于范畴论。它始于创始人的痛点。我希望了解公司内部实际发生了什么，而不依赖状态更新、二手总结，也不依赖我自己在会议、消息、文档和人员之间追逐上下文的能力。每位创始人都知道这种问题的某种版本。你对正在发生的事情有种感觉，但详细的事实总是零散的。我们的第一个直觉是幼稚的：如果一个代理能跟每个人签到，四处打电话，询问发生了什么，然后给我一张组织架构的实时图景会怎样？在埃隆/DOGE（政府效率部）讨论的奇怪巅峰期，我们甚至半开玩笑地想把这东西命名为埃隆。这是一个糟糕的名字，但这种冲动是诚实的。创始人希望知道各地正在发生什么，而不想让所有人慢下来。这个想法很快就破灭了，因为人们不想每天向一个代理汇报。更重要的是，公司的真相不是通过民调创造的。真相已经在工作中产生：在客户风险变得真实的会议上，在变通方案被接受的 Slack 线程中，在做出承诺的电子邮件中，在产品决策发生变化的通话中，以及在所有这些被缩减为几个字段的工单中。第一个教训很简单，尽管我们花了一段时间才真正内化：公司记忆必须从工作本身中涌现。会议、消息、电子邮件和通话是公司现实未经过滤的版本。文档、工单、仪表盘和工作流程很重要，但它们通常处于下游。决策、反对意见、权衡、承诺、投诉和交接发生在文档清理干净之前。我开始将这些互动视为组织的思维链。不是字面上的模型意义上的，而是人类意义上的。它们是公司在写下决定之前进行推理的地方。这将问题从转录变成了记忆。我们不是试图记录更多的词；我们是试图理解应该记住什么。转录告诉你说了什么，但记忆必须理解为什么它很重要，对谁重要，因为它改变了什么，以及接下来应该发生什么。这就是本体论对我们变得中心的原因。我们并不是因为想要更清洁的数据模型才走到这一步的。我们走到这一步是因为同样的对话对公司的不同部分意味着不同的事情。客户通话就是一个很好的例子。销售人员可能会听到续约风险，产品经理（PM）可能会听到路线图信号，支持负责人可能会听到升级，而律师可能会听到义务。工件是一样的，但有用的记忆取决于视角。大语言模型（LLM）可以帮助理解说了什么；本体论决定了它在公司内部意味着什么。组织记忆是不同的。它仍然复杂，但更易于处理。公司有角色、职能、客户、产品、风险、承诺、所有者、工作流程和决策。CEO、产品经理、律师、支持负责人、销售人员、经理和个体贡献者（IC）可能会以不同的方式看待同一个工件，但有意义的视角集合并不是无限的。这种有界性就是公司记忆可构建的原因之一。第二个教训是，你不能通过把所有东西倾倒到一个存储中来解决这个问题。那只是把碎片化向下移动了一层。如果记忆基底不能在同一底层数据上支持不同的本体论，公司最终将为销售、产品、法律、支持、领导和代理分别拥有独立的记忆。界面可能看起来是统一的，但记忆已经分裂了。基底必须是通用的，而不强加一种通用的解释。这句话我们花了很长时间才得出。一个有用的公司大脑需要一个单一的内存基底，它能够容纳相同的底层数据，同时允许对它们进行不同的有效视角解读。查看客户邮件的 CEO 不应该看到与支持负责人、产品经理或客户所有者相同的东西。他们都应该查看同一个记忆，但通过不同的本体论视角。这也是为什么上下文图不是静态对象。图取决于本体论。同一封邮件可能会创建风险追踪、承诺追踪、决策追踪、行动追踪，或同时创建其中的几个。本体论决定了哪些关系很重要，哪些状态变化应该被记住，以及哪些未来的行动应该由记忆来提供信息。记忆追踪很重要，因为它们让系统开始构建公司的世界模型。我所说的世界模型，并不是指任何神秘的东西。我指的是关于工作倾向于如何移动的学习表示：哪些信号先于风险，哪些承诺通常会延迟，哪些交接会失败，哪些决策会产生下游工作，以及哪些行动能解决问题。这就是内存对企业 AI 更深层的原因。没有内存，代理只能根据当下给出的上下文采取行动。有了记忆追踪、决策追踪和行动追踪，系统就可以开始随着时间的推移从结果中学习。如果某种升级模式反复导致客户流失，如果某个交接一直失败，或者如果某种类型的客户请求通常预示着路线图的变更，系统应该学习这些。通俗地说，这就是从结果中学习。如果你想要技术类比，这就是公司内部强化学习的开始：追踪、行动、结果和反馈循环。实际版本是落地的。组织留下追踪，行动产生结果，内存基底使这些结果可用。这一认识改变了我们对产品的思考。界面不能止步于“去问 AI”。这很有用，但并不是最终状态。更好的体验是，当工作需要时，正确的上下文、记忆或行动就会出现。与客户一起测试使这个想法不再那么理论化。在一个组织中，一位客户成功人员正在与客户交谈，当时谈话中出现了看起来像流失风险的情况。系统没有等待每周的客户审查或清理过的 CRM 记录。它在对话还很新鲜时就标记了 CTO，CTO 立即开始调查。有趣的部分不是 CTO 得知了他们永远不会知道的事情。他们最终可能还是会发现的。有趣的部分是延迟。通常需要通过一系列总结、会议和升级传递的信号，几乎在发生时就会出现。这产生了一种不同的摩擦。当信息移动得如此之快时，问题就变成了谁应该看到它，应该如何构建它，以及系统应该要求人类下一步做什么。我们在项目工作中看到了这种的相关版本。从事同一倡议的人可能对目标、时间表或已经决定的事情有不同的理解。这种情况一直发生在公司内部。通常在后来才发现，那时项目延迟了，有人升级了，或者会议变成了痛苦的重建，以解释每个人是如何变得不一致的。公司大脑可以更早地注意到其中的一些事情。但随后产品问题变得更加微妙。它应该告诉每个人他们有分歧吗？它应该要求经理干预吗？它应该只是显示相互矛盾的追踪并让人类解决吗？这些不仅仅是技术问题。这些是人类问题，由于记忆压缩了信号出现和某人注意到它之间的时间，这些问题变得更早可见。对于创始人或 CEO 来说，这意味着回答几乎没有人能很好回答的问题：公司内部实际发生了什么？不是经过净化或仪表盘版本，而是运营现实。对于领导层来说，这意味着看到战略是否正在转化为工作。对于经理来说，这意味着理解阻碍、承诺和交接，而无需不断询问更新。对于 IC 来说，这意味着上下文随任务而来，并且曾经消失在会议和消息中的工作可以在不把公司变成监视机器的情况下变得可见。这种边界很重要。公司记忆必须明确本体论、出处、权限和范围。目标不是让每个人都觉得被监视。目标是让工作变得清晰、可信赖且更容易执行。在上面的例子中，问题不在于监视。问题在于信息从公司的一个部分传递到另一个部分的速度比组织习惯的要快得多。文化在这里总是很重要，但架构也很重要。在过去的一年里，与团队和设计合作伙伴测试这些想法使一件事变得更清楚：记忆几乎在任何地方都有用，但它不应该以同样的方式出现在任何地方。有时它应该总结，有时它应该警告，有时它应该连接两个没人意识到相关的事情，有时它应该保持安静，直到满足正确的条件。来自一家大型企业试点的一个更难的问题是如何显示内存的价值。默认的视觉答案是知识图谱。这有一席之地，特别是在解释架构时。但我认为图谱不是大多数人日常体验公司记忆的方式。正确的体验更接近于系统帮助你注意到重要的事情并做出下一个好的决定。 TikTok 是一个奇怪但有用的类比。TikTok 不会向你展示你所有兴趣的巨大地图。它对你关心的内容有足够的了解，可以展示你可能参与的下一件事。公司记忆不应该像消费者推荐那样工作，但产品教训是真实的。记忆的价值通常是通过呈现而不是浏览来体验的。系统应该对公司、角色、工作和当前时刻有足够的了解，以将正确的事情带向前台。对于 CEO 来说尤其如此。CEO 想要知道公司内部发生的所有事情，但没有人类能直接处理所有事情。产品不能简单地变成一个带有更好搜索框的消防水管。它必须成为一个与公司实时记忆交互的工具：什么改变了，什么正在偏离，什么被误解了，什么需要判断，什么可以安全地等待。这就是基底如此重要的原因。如果内存层是灵活的，表面可以是不同的。CEO 表面、经理表面、IC 表面和代理表面都可以使用相同的底层数据库内存，而不会成为相同的产品。界面问题比我想象的更重要。我不认为公司大脑应该感觉像公司内部的另一个人。如果它的行为太像副驾驶或员工，它可能会悄悄地夺走仍然拥有决策权的人类的主观能动性。它应该感觉更像是一个工具、驾驶舱或记忆仪器。它可以呈现现实，显示分歧，并准备工作，但人类需要对判断负责。这可能是构建这个一年后最奇怪的教训。当 AI 开始集体理解公司的足够多的部分时，动态会以外部不明显的方式发生变化。明显的担忧是任务自动化，但更大的变化是步伐。信号移动得更快，误解出现得更早，协作开始感觉不同，因为公司可以注意到更多的运动。我们带着企业通用智能的雄心开始了。一年后，我认为更清晰的原语是公司大脑。雄心并没有变小。道路变得更清晰了：记忆基底必须先行。我相信的企业 AI 版本不是围绕工具本地内存构建的。它是围绕共享语义公司状态构建的：交互变成记忆，记忆变成世界模型，世界模型帮助人类和代理在上下文中行动。这就是我们在 Sentra 一直在构建的东西。 —- 第 1 部分：为什么大多数公司有数据但没有记忆第 2 部分：事实记忆第 3 部分：交互记忆第 4 部分：行动记忆第 5 部分：内存是状态，不是服务在 Sentra，我们正在构建的东西只能被描述为一个“公司大脑”，这是一个共享的智能/记忆层，位于所有通信渠道、知识库、行动和代理追踪之上，以了解组织中的每个人实际上如何工作以及工作实际上是如何完成的，在近乎实时地构建整个公司的生动世界模型。

🔗 相关文档