The context gold rush: why everyone is building the same thing

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 (Slack, Notion, GitHub) 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. It is also a narrative that is sellable to executives: develop your own context layer now, or your competitors will and you will 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 built on moats and monopoly power, much of it driven by high switching costs: once you are embedded in a company, it is extremely hard for them to switch off. Managing a company’s context has all the same properties. For some business models — Harvey, for instance — you can develop a context moat by servicing customers. This is Nadella’s reverse information paradox.
• Model capability saturation (tech edge and competition). There’s a growing belief that models can do anything we want as long as they have the right context. As frontier models have started to discover new math, there is a sense that we have saturated the intelligence needed for most tasks. The bottleneck, then, is context. That makes it one of the few big areas of opportunity left that will not be commoditized by better models, and it sits largely outside the labs’ main strike zone.

All roads lead to Rome

It’s clear that something like a company brain is needed. What’s striking is how similar the products can seem, even when they started from vastly different places. Part of this is agents collapsing product into a singularity: a coding agent is fundamentally not that different from a marketing agent or an email agent. And so it goes across the stack. Another big part is that the space is still early, with lots of players trying to lay claim to a fuzzy field.

A dozen companies, one claim. The marketing copy converged faster than the products did.

• Personal knowledge base. A GitHub repo, gbrain, Claude Code plusObsidian. A folder of markdown files that serves 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, Honcho, Engram Lab. Per-agent memory layers that scale vertically in time. These companies tend to be research focused on building super long-horizon agents, split between those who believe in token space and those who believe in weight space.
• Observability tools. Braintrust, Raindrop. They capture the traces your external, production agents emit. The outputs tend to be dashboards and evals rather than an accumulating data store for future agents. Not directly playing here, but a natural place where the data accumulates.
• Agent dev tools. Entire, Mintlify. A similar service to observability tools, except for your internal coding agents. The output is a set of docs so that your coding agents produce less slop and run for longer.
• Data moat builders. Applied Compute, Prime Intellect. They sell enterprises on a vision of custom models and a context layer hyper-specific to their workflows. Part research lab, part AI context consulting firm, part GPU provider: own the customer relationship end to end and be a one-stop shop.
• Companies reinventing themselves. Notion, ClickUp, Airbyte, Glean,PromptQL. Established in related areas, and now joining the context gold rush.
• AI employee. Viktor, Lindy. Starting at the level of individual users, on the premise that they are well positioned to capture context and build a PLG motion that maps context across entire orgs.
• Vertical AI-native service companies.Too many to count. By building custom end-to-end workflows, they too build up an accumulating context layer, solving their customers’ pain points better than any horizontal player.
• Company brain. Stash (full disclosure — this is us), Sentra,Hyperspell, Supermemory. All relatively early start-ups, started to natively solve the org-level context layer problem. The bet is that attacking this problem from day one, rather than moving into it laterally, is how the category gets won.

And this doesn’t count the frontier labs doing similar work across their FDE and product teams, or related players like Hydra and Pinecone expanding vertically up from infrastructure, Exa moving from web search to enterprise search, agent orchestration companies building memory into their products, or integration companies like Composio that connect to existing context and sources of truth. All of them could move laterally into context management if the opportunity appears. An open question: 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 — they go after different customers with different use cases at different parts of the stack.

What has converged

A few patterns show up almost everywhere:

• Markdown files and a filesystem. Agents are post-trained on them, so they need no translation layer.
• Hybrid retrieval. Semantic search combined with keyword search for the best results.
• Dreaming and sleep-time compute. Separate the agent doing the work — a Claude Code session, a workflow agent — from the agent acting as custodian over the knowledge base. The sleep-time agent indexes, de-dups, and updates.
• External connections. Pull from as many external sources as possible: Granola, email, calendar, Slack, CRM. Treat these as raw data sources that your sleep-time agents read but do not edit over, and inherit the sharing scopes of those connections so isolation and permissioning stay simple.

An important note: the current implementation of these patterns will go 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, and several key components of mass adoption are missing.

• Combining structured and unstructured data. A clean ontology between all the different data types. Should data be structured as database tables or as a filesystem? How do you deal with unstructured data such as Slack channels? What happens when some of the memory is stored in weights rather than pure text? Each type has different permission models, shapes, and update cadences. Humans blend these seamlessly; agents need more guidance.
• Data ingestion everywhere. Company brains only become useful past a tipping point of information inside them. Otherwise it is more efficient to go to each source directly. That requires ingesting every format from PDFs to database tables, which makes sales cycles long through security reviews and heavy integration work.
• Data access and controls. Making sure the right people access the right information and the wrong people cannot. Each architecture has its own trade-offs. Do you provision each agent a user? What is shared between teams versus private? Can you build guard rails that actually prevent leakage?
• Good evals.Does a company brain actually make your team more productive, or is it a productivity nerd’s dream? What makes one implementation measurably better than another? Memory is inherently a long-horizon problem, so rollouts on evals get expensive and hard to run.
• Stability over long timeframes. Put another way, we need to solve continual learning. We need to trust that adding another skill or data source will not dilute the performance of the existing ones, and that knowledge bases will not slopify over time. Context rot is still a very real problem.
• Blast radius. Our internal name for how retrieved information is bounded by scope: time, context, prioritization. It is becoming clear that pure retrieval is not sufficient for good memory, and we will need better ways to instil common sense about which pieces of information matter more.

The killer use case

This is the big one. For all the hype around context graphs and company brains, the clear business case and ROI are still being developed. The metrics have not caught up to the technology and the vision. A few emerging hypotheses are working okay so far:

• Retrieve information. The original Glean use case: find information across scattered datasets and sources of truth.
• Automate workflows. Have agents do the repetitive, boring tasks — and more of them as time goes on.
• Cost and latency savings. Memory and context layers have been shown to decrease token costs substantially.
• Better agent performance. Have your agents complete tasks they could not have completed otherwise.

These are the questions we spend our time on. If you are building or thinking about your own brain, we would love to chat — see internal agents for the agents your team runs, external agents for the ones your customers use, or book a call.