# The context gold rush: Why everyone is building the same thing.
**作者**: Sam Z Liu
**日期**: 2026-07-23T08:37:57.000Z
**来源**: [https://x.com/samzliu/status/2080210797465379147](https://x.com/samzliu/status/2080210797465379147)
---
You either die building product or live long enough to do context management. Whether you call it a context graph, company brain, or LLM wiki, it seems that many start-ups and larger companies alike are building the same thing: a place to store data and context for tomorrow's agentic workforce. This is one of the four main ideas apparently left in AI: research lab, RL environment, infrastructure, or context management.
From an ecosystem perspective, a context management product checks all the boxes for a high growth start-up or internal innovation team:
- Jevon's paradox (timing) - Lowering the cost (time, friction, labour) of producing code and writing will cause an explosion of text-based data that our current tools (e.g. Slack, Notion, Github, etc.) are not designed to handle. We are still on the early part of that curve as agent adoption penetrates the wider economy.
- Self-improvement (vision) - There's an enticing vision of an autonomous self improving system where agents become better and better over time without human intervention. Capturing and managing context is a big part of what we believe will enable that capability. Moreover, it's a narrative that's sellable to executives: you better develop your own context layer now before your competitors do so or you'll never catch-up.
- Data sovereignty (tailwinds) - Companies and governments are becoming increasingly worried about the frontier labs training on their internal data. An external, trusted party to store and manage that data will become increasingly important.
- Context moat (business model) - The previous generation of SaaS was build on moats and the monopoly power. A lot of what drove this was high switching costs: once you become embedded into a company, it's extremely hard for them to switch off. Managing a company's context seems to have all the similar properties of yesteryear's glory days. Moreover, for some types of business models (e.g. Harvey), you can develop your own context moat by servicing customers. This is Nadella's reverse information paradox.
- Model capability saturation (tech edge and competition) - There's this growing belief that models can do anything we want them to as long as they have the right context. As frontier models have started to discover new math, there's a sense that we have saturated the intelligence needed for most tasks. The bottleneck, then, is context. This suggests that context is one of the few big areas of opportunity left that will not become commoditized by better models. Moreover, this also seems largely out of the main strike zone for the labs, making it a compelling focus area lest Anthropic kill your company.
All Roads Lead to Rome
Try to guess what company or category each screenshot belongs to
It's clear that something like a company brain is needed. But what's striking is how similar products can seem, even if they started from vastly difference places. Part of this is agents collapsing product into a singularity: a coding agent is fundamentally not that different from a marketing agent or email agent. And so it goes across the stack. But another big part of it is that the space is still early with lots of players trying to lay claim to a fuzzy field.
– Personal knowledge base — Github repo, Gbrain, Claude Code + @obsdmd. This is a folder of markdown files that serve as skills and memory for your agents. Where people start when experimenting. They fail when trying to expand to an entire team.
– Agent memory — @Letta_AI. @honchodotdev. @EngramLab. These are per-agent memory layers that scale vertically in time. The companies tend to be research focused on a goal of building super long horizon agents. There's a split between companies that believe in token spaces vs weight space.
– Observability tools — @braintrust, @raindrop_ai. They capture the traces your external, production agents emit. The outputs here tend to be dashboards and evals rather than an accumulating data store for future agents. Not directly playing here but they are a natural place where the data accumulates.
– Agent Dev tools — @EntireHQ, @mintlify. They provide a similar service to observability tools except these are for your internal coding agents. The outputs here are a set of docs so that your coding agents produce less slops and run for longer.
- Data moat builders — @appliedcompute. @PrimeIntellect. They sell enterprises on a vision of custom models and context layer that are hyper-specific to their workflows. Part research lab, part AI context consulting firm, part GPU provider, the strategy here is to own the customer relationship E2E and be a one-stop shop.
– Companies Reinventing Themselves — @NotionHQ, @clickup, @AirbyteHQ, @Glean, @PromptQL. These are companies that were established in related areas which joined in on the context gold rush.
- AI Employee — @viktor__com, @getlindy. Starting at the level of individual users, they are presumably that they are well positioned to capture context and build up a PLG notion that maps context across entire orgs. While Claude Tag was criticized as a trojan horse for doing this very thing, these smaller companies will face less resistance.
- Vertical AI-Native Service Companies — Too many to count. By building custom E2E workflows, they too build up an accumulating context layer. By going vertical, the strategy is to solve their customer's pain points better than any horizontal player.
- Company Brain — @joinstashAI (full disclosure - this is us!), @sentra_app, @hyperspell, @supermemory. All relatively early start-ups, these companies were started to natively solve the org-level context layer problem. The bet is that directly focusing on this problem from day 1 rather than laterally moving into it from the side will enable this category to win out.
And this doesn't even count the frontier labs which are doing similar work across their FDE & product teams or the related players such as @hydra_db, @pinecone (expanding vertically up from infrastructure), @ExaAILabs (seem to be moving from web search to enterprise search), agent orchestration companies that are building memory into their product, agent workflow companies, or integration companies like @composio that connect to existing context and sources of truth. These all could laterally move into context management if there's an opportunity. For instance, an open question is as models get smarter, are integrations all you need?
There is likely space for many of these companies to thrive. Despite the similar marketing copy, they are probably not competitors: going after different customers with different use-cases at different parts of the stack. Context management is a problem that anyone using agents in the future will need to solve. And if the hype is to believed, that "anyone" will become "everyone" shortly enough. We will likely see a stratification as the temperature around context management dies down and it moves from a buzz word to a disciplined business. But it is a strange new world where a company selling to a 4 person design agency has the same essential product as a company selling cutting edge research to billion dollar tech companies.
The current patterns
Even across these very different starting points, a few patterns are becoming clear:
– Multiplayer and version control — Ensure that team members and their agents can collaborate. Version control is already critical for single player agents since not every multi-thousand line PR your coding agent puts up is desired. It's even more critical for multi-player as different team members modify and fork each other's work.
– Accumulating skills — An agent's token spend should not only benefit the direct task at hand but also the entire organization. The context layer becomes this "reasoning cache" which makes future agents perform better. Overtime, more and more workflows can be automated in this way.
– Hybrid retrieval layer — No single retrieval method wins. Combine vector search, knowledge graphs, and agentic search with keyword search for best results.
– Dreaming and sleep-time Compute — Separate out the agent that is doing the work (e.g. Claude Code session, workflow agent) from the agent that is a custodian over the knowledge base. The sleep-time agent indexes, de-dups, and updates.
– External connections — Pull from as many external sources as possible (e.g. Granola, email, calendar, slack, CRM, etc.). Treat these as raw data sources that your sleep-time agents read but don't edit over. To keep data isolation and permissioning simple, inherent the sharing scopes of these external connections.
An important note is that the current implementation of these patterns will become out of date as the industry evolves. We hosted a company brain and memory event a few weeks ago and found that most people believe the current paradigms will not stick around.
What's missing
We are still very early however and missing several key components to mass adoption:
– Combining structured and unstructured data — A clean ontology or mental model between all the different data types. Should the data be structured as database tables or file systems? How to deal with unstructured data such as Slack channels? What happens if some of the memory becomes stored in weights rather than pure text? Each type of data has different permission models, shapes, and update cadences. While humans can blend these seamlessly for different contexts (sorry overloaded term!), agents need a bit more guidance.
– Data ingestion everywhere — Company brains only become useful once you reach a tipping point of information that is inside of them. Otherwise, it's typically more efficient to go to each source directly. This requires ingesting data in all different formats from PDFs to database tables and integrating with all the tools at an organization. This makes sales cycles long due to security reviews and hefty integration FDE work.
– Data access and controls — Making sure the right people access the right information and the wrong people cannot access it. This is tricky to get right because each architecture has its own trade offs. Do you provision each agent a user? What information is shared between teams vs private? Can you build effective guard rails to prevent data leakage?
– Good evals — Does a company brain actually help your team become more productive? Or is it just a productivity nerd's dream? What makes one implementation measurably better from another? And since memory is inherently a long-horizon problem, rollouts on evals will becoming increasingly expensive and hard to do.
– Stability over long timeframes — Put it another way, we need to solve continual learning. We need to trust adding another skill or data source won't dilute the performance of the existing ones or that the knowledge bases will not slopify over time. Context rot is still a very real problem with LLMs today.
- Blast radius — Our internal name for how retrieved information is bounded by scope (time, context, prioritization). It's becoming clear that pure retrieval is not sufficient for good memory and we will need to develop better ways to instill common sense about which pieces of information matter more.
- Killer use-case — This is the big one. For all the hype around context graphs and company brains, the clear business case and ROI for these products are still being developed. The metrics have not caught up to the technology and vision. A few emerging hypotheses that are working okay so far:
- Retrieve information - this is the original Glean killer-use case. Find information across scattered datasets and sources of truth.
- Automate workflows - have agents do the repetitive, boring tasks. And have them do more and more of them as time goes on.
- Cost and latency savings - memory and context layers have been shown to decrease token costs by ~60-90%
- Better agent performance - have your agents complete tasks they would not have been able to otherwise.
These are the questions we're spending our time solving. If you're building or thinking about your own brain, we'd love to chat!
## 相关链接
- [Sam Z Liu](https://x.com/samzliu)
- [@samzliu](https://x.com/samzliu)
- [3.5K](https://x.com/samzliu/status/2080210797465379147/analytics)
- [reverse information paradox](https://x.com/satyanadella/article/2076323181154230284)
- [right context](https://alexzhang13.github.io/blog/2026/harness/)
- [Gbrain](https://github.com/garrytan/gbrain)
- [@obsdmd](https://x.com/@obsdmd)
- [@Letta_AI](https://x.com/@Letta_AI)
- [@honchodotdev](https://x.com/@honchodotdev)
- [@EngramLab](https://x.com/@EngramLab)
- [@braintrust](https://x.com/@braintrust)
- [@raindrop_ai](https://x.com/@raindrop_ai)
- [@EntireHQ](https://x.com/@EntireHQ)
- [@mintlify](https://x.com/@mintlify)
- [@appliedcompute](https://x.com/@appliedcompute)
- [@PrimeIntellect](https://x.com/@PrimeIntellect)
- [@NotionHQ](https://x.com/@NotionHQ)
- [@clickup](https://x.com/@clickup)
- [@AirbyteHQ](https://x.com/@AirbyteHQ)
- [@Glean](https://x.com/@Glean)
- [@PromptQL](https://x.com/@PromptQL)
- [@viktor__com](https://x.com/@viktor__com)
- [@getlindy](https://x.com/@getlindy)
- [Claude Tag](https://x.com/ashwingop/status/2069814177624121469)
- [@joinstashAI](https://x.com/@joinstashAI)
- [@sentra_app](https://x.com/@sentra_app)
- [@hyperspell](https://x.com/@hyperspell)
- [@supermemory](https://x.com/@supermemory)
- [@hydra_db](https://x.com/@hydra_db)
- [@pinecone](https://x.com/@pinecone)
- [@ExaAILabs](https://x.com/@ExaAILabs)
- [@composio](https://x.com/@composio)
- [hosted a company brain and memory](https://x.com/samzliu/status/2077482285960733068?s=20)
- [Context rot](https://www.trychroma.com/research/context-rot)
- [retrieval is not sufficient](https://plasticlabs.ai/blog/posts/Memory-as-Reasoning)
- [decrease token costs by ~60-90%](https://www.pinecone.io/blog/inside-askdata/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [4:37 PM · Jul 23, 2026](https://x.com/samzliu/status/2080210797465379147)
- [3,531 Views](https://x.com/samzliu/status/2080210797465379147/analytics)
- [View quotes](https://x.com/samzliu/status/2080210797465379147/quotes)
---
*导出时间: 2026/7/24 00:25:26*
---
## 中文翻译
# 上下文淘金热：为什么大家都在造同一个东西
**作者**：Sam Z Liu
**日期**：2026-07-23T08:37:57.000Z
**来源**：[https://x.com/samzliu/status/2080210797465379147](https://x.com/samzliu/status/2080210797465379147)
---
要么在做产品的过程中消亡，要么活得足够久去做上下文管理。无论你称之为上下文图谱、公司大脑，还是 LLM 维基，似乎许多初创公司和大型企业都在构建同一个东西：一个为未来的智能体劳动力存储数据和上下文的地方。这显然是 AI 领域目前仅存的四个主要方向之一：研究实验室、强化学习环境、基础设施，或上下文管理。
从生态系统的角度来看，上下文管理产品完全符合高增长初创公司或内部创新团队的所有标准：
- 杰文斯悖论（时机）—— 降低生产代码和写作的成本（时间、摩擦、劳动力）将导致基于文本的数据爆炸，而我们目前的工具（如 Slack、Notion、Github 等）并非为处理这些数据而设计。随着智能体在经济领域的广泛普及，我们仍处于这一曲线的早期阶段。
- 自我改进（愿景）—— 有一个令人向往的愿景，即建立一个自主自我改进的系统，智能体可以在没有人类干预的情况下随着时间的推移变得越来越好。捕获和管理上下文是我们认为将实现这一能力的重要组成部分。此外，这也是一个向高管推销的好故事：你最好在竞争对手之前开发你自己的上下文层，否则你将永远无法追赶。
- 数据主权（顺风）—— 公司和政府越来越担心前沿实验室利用其内部数据进行训练。一个外部的、可信的第三方来存储和管理这些数据将变得越来越重要。
- 上下文护城河（商业模式）—— 上一代 SaaS 建立在护城河和垄断力量之上。推动这一点的很大一部分原因是高昂的转换成本：一旦你嵌入到一家公司中，他们很难切换出去。管理公司的上下文似乎拥有过去辉煌时代的所有相似属性。此外，对于某些类型的商业模式（例如 Harvey），你可以通过服务客户建立自己的上下文护城河。这就是纳德拉的反向信息悖论。
- 模型能力饱和（技术优势和竞争）—— 人们越来越相信，只要拥有正确的上下文，模型就能做我们想做的任何事。随着前沿模型开始发现新的数学，有一种感觉认为我们已经饱和了大多数任务所需的智能。那么，瓶颈就是上下文。这表明上下文是仅存的几个不会被更好的模型商品化的大机会领域之一。此外，这似乎也主要不在实验室的主要打击范围内，这使得它成为一个引人注目的关注领域，以免 Anthropic 搞垮你的公司。
条条大路通罗马
试着猜猜每个截图属于哪家公司或哪个类别
很明显，需要类似公司大脑这样的东西。但令人震惊的是，尽管产品起步的地方截然不同，但它们看起来是多么相似。部分原因是智能体将产品坍缩成了一个奇点：编码智能体与营销智能体或电子邮件智能体并没有本质上的不同。这种情况在整个技术栈中都是如此。但另一个主要原因是，该领域仍处于早期阶段，许多参与者试图在一个模糊的领域中占据一席之地。
– 个人知识库 — Github 代码库、Gbrain、Claude Code + @obsdmd。这是一个 Markdown 文件夹，作为智能体的技能和记忆。这是人们实验时的起点。在尝试扩展到整个团队时，他们会失败。
– 智能体记忆 — @Letta_AI、@honchodotdev、@EngramLab。这些是每个智能体的记忆层，在时间维度上垂直扩展。这些公司往往以研究为导向，目标是构建超长视界的智能体。在相信 Token 空间和权重空间的公司之间存在分歧。
– 可观测性工具 — @braintrust、@raindrop_ai。它们捕获你的外部、生产环境智能体发出的踪迹。这里的输出往往是仪表板和评估，而不是为未来的智能体服务的积累数据存储。虽然不直接在这个领域，但它们是数据自然积累的地方。
– 智能体开发工具 — @EntireHQ、@mintlify。它们提供与可观测性工具类似的服务，只是这些服务是针对你的内部编码智能体的。这里的输出是一组文档，以便你的编码智能体产生更少的垃圾内容并运行更长时间。
– 数据护城河构建者 — @appliedcompute、@PrimeIntellect。它们向企业推销定制模型和上下文层的愿景，这些模型和层针对其工作流程超级特定。部分是研究实验室，部分是 AI 上下文咨询公司，部分是 GPU 提供商，这里的策略是端到端地拥有客户关系，并成为一站式商店。
– 自我重塑的公司 — @NotionHQ、@clickup、@AirbyteHQ、@Glean、@PromptQL。这些是在相关领域已立足的公司，加入了上下文淘金热。
– AI 员工 — @viktor__com、@getlindy。从个人用户级别开始，据推测它们能够很好地捕获上下文并建立 PLG 概念，将上下文映射到整个组织。虽然 Claude Tag 因做这种事而被批评为特洛伊木马，但这些较小的公司面临的阻力会较小。
– 垂直 AI 原生服务公司 — 多到数不清。通过构建定制的端到端工作流程，它们也建立了一个积累的上下文层。通过走垂直路线，其策略是比任何水平玩家更好地解决客户的痛点。
– 公司大脑 — @joinstashAI（完全披露——这是我们要做的！）、@sentra_app、@hyperspell、@supermemory。这些都是相对早期的初创公司，这些公司成立是为了原生地解决组织级别的上下文层问题。赌注在于，从第一天起就直接专注于这个问题，而不是从侧面横向切入，将使这一类别获胜。
这甚至还没有包括前沿实验室，它们在其 FDE 和产品团队中进行类似的工作，或者相关的参与者，如 @hydra_db、@pinecone（从基础设施垂直向上扩展）、@ExaAILabs（似乎正在从网络搜索转向企业搜索）、将记忆构建到产品中的智能体编排公司、智能体工作流公司，或者像 @composio 这样连接现有上下文和真相来源的集成公司。如果有机会，所有这些公司都可能横向进入上下文管理领域。例如，一个悬而未决的问题是，随着模型变得更聪明，集成是否就是你所需要的？
这些公司中很可能有许多都有空间蓬勃发展。尽管营销文案相似，但它们可能不是竞争对手：在不同的堆栈部分，以不同的用例针对不同的客户。上下文管理是任何未来使用智能体的人都必须解决的问题。如果相信炒作的话，那个“任何人”很快就会变成“每个人”。随着围绕上下文管理的热度降温，它从一个流行词变成一个规范的业务，我们很可能会看到分层。但这是一个奇怪的新世界，一家向 4 人的设计机构销售的公司，其核心产品与一家向价值十亿美元的科技公司销售前沿研究的公司相同。
目前的模式
即使在截然不同的起点之间，一些模式也变得清晰起来：
– 多人协作和版本控制 — 确保团队成员及其智能体可以协作。版本控制对于单人智能体来说已经至关重要，因为你的编码智能体提出的每个数千行的 PR 并不都是你想要的。对于多人协作来说更为关键，因为不同的团队成员会修改和派生彼此的工作。
– 技能积累 — 智能体的 Token 开支不应仅使眼前的直接任务受益，还应使整个组织受益。上下文层成为这个“推理缓存”，使未来的智能体表现得更好。随着时间的推移，越来越多的工作流可以通过这种方式自动化。
– 混合检索层 — 没有单一的检索方法能胜出。结合向量搜索、知识图谱和智能体搜索与关键词搜索以获得最佳结果。
– 梦想和睡眠时间计算 — 将进行工作的智能体（例如 Claude Code 会话、工作流智能体）与作为知识库管理员的智能体分开。睡眠时间智能体进行索引、去重和更新。
– 外部连接 — 尽可能地从更多外部来源提取数据（例如 Granola、电子邮件、日历、slack、CRM 等）。将这些视为你的睡眠时间智能体读取但不编辑的原始数据源。为了保持数据隔离和权限控制简单，继承这些外部连接的共享范围。
重要的一点是，随着行业的发展，这些模式的当前实现将会过时。几周前我们举办了一个公司大脑和记忆活动，发现大多数人认为当前的范式不会持续太久。
缺失了什么
然而，我们仍处于非常早期的阶段，缺乏大规模采用的几个关键组件：
– 结合结构化和非结构化数据 —— 在所有不同的数据类型之间有一个清晰的本体或心智模型。数据应该构造成数据库表还是文件系统？如何处理非结构化数据，例如 Slack 频道？如果部分记忆存储在权重中而不是纯文本中会发生什么？每种数据类型都有不同的权限模型、形状和更新节奏。虽然人类可以针对不同的上下文（抱歉，术语重载了！）无缝融合这些，但智能体需要更多的指导。
– 到处进行数据摄取 — 只有当公司大脑达到其中包含的信息的临界点时，它们才会变得有用。否则，直接去每个来源通常更有效率。这需要摄取所有不同格式的数据，从 PDF 到数据库表，并与组织的所有工具集成。由于安全审查和繁重的集成 FDE 工作，这使得销售周期变长。
– 数据访问和控制 — 确保合适的人访问合适的信息，而不合适的人无法访问它。要正确做到这一点是很棘手的，因为每种架构都有自己的权衡。你要为每个智能体配置一个用户吗？哪些信息在团队之间共享，哪些是私有的？你能建立有效的护栏来防止数据泄露吗？
– 良好的评估 — 公司大脑真的能帮助你的团队提高生产力吗？还是这只是生产力极客的梦想？是什么让一种实现比另一种实现明显更好？而且由于记忆本质上是一个长视界问题，基于评估的发布将变得越来越昂贵和困难。
– 长时间框架内的稳定性 — 换句话说，我们需要解决持续学习的问题。我们需要相信添加另一个技能或数据源不会稀释现有技能的性能，或者知识库不会随着时间的推移而变得混乱。上下文腐烂对于当今的 LLM 来说仍然是一个非常真实的问题。
- 爆炸半径 — 我们的内部名称，用于描述检索到的信息如何受范围（时间、上下文、优先级）限制。很明显，单纯的检索对于良好的记忆是不够的，我们需要开发更好的方法来灌输关于哪些信息更重要的常识。
- 杀手级用例 — 这是最重要的一点。尽管围绕上下文图谱和公司大脑有很多炒作，但这些产品明确的商业案例和投资回报率仍在开发中。指标尚未赶上技术和愿景。一些到目前为止运作尚可的早期假设：
- 检索信息 —— 这是原始的 Glean 杀手级用例。在分散的数据集和真相来源中查找信息。
- 自动化工作流 —— 让智能体做重复的、无聊的任务。并让它们随着时间的推移做越来越多的事情。
- 成本和延迟节省 —— 记忆和上下文层已被证明能将 Token 成本降低约 60-90%。
- 更好的智能体性能 —— 让你的智能体完成它们原本无法完成的任务。
这就是我们要花时间解决的问题。如果你正在构建或思考你自己的大脑，我们很乐意聊天！