Context Graphs Are a Trillion-Dollar Opportunity. But Who Actually Captures It?
Jaya Gupta’s thesis is right about context graphs, and wrong about who wins. In a world of heterogeneity, the integrator always wins, not the application.
If you’re in the data world, you probably saw systems of record and context graphs go viral in recent weeks.
Jamin Ball’s “Long Live Systems of Record” argued that, despite the discourse, AI agents won’t kill systems of record like data warehouses, CRMs, ERPs, HRISes, etc. Instead, “truth” will live in systems of record with a semantic layer on top that tells agents how to use that truth.
Jaya Gupta and Ashu Garg responded in the now-viral “AI’s trillion-dollar opportunity: Context graphs”, arguing that adding AI to systems of record with some semantic layer isn’t enough. Instead the next trillion-dollar opportunity is in what this misses: decision traces, or the “why” behind past decisions. All of these will form a context graph, which they called the next trillion-dollar opportunity.
Who gets to own this? Jaya and Ashu think it’s not the systems of records but instead the agents that work in the “execution path” and can see the full context when a decision is made. In other words, vertical agent startups will own the context graph for their domain. The sales agent company will capture context around renewals, the support agent company will capture context around escalations, and so on.
This prompted a lot of debate and discussion: how to actually build a context graph, the two-layer context architecture, the importance of operational context and execution intelligence, and what this means for agent reliability, governance, observability, AppSec, financial recovery, and more.
No wonder this article went viral, it’s an elegant thesis. And I think they’re right about the importance and opportunity of context graphs. But they’re wrong about who gets to capture that trillion dollars.
That’s because this idea of the context graph runs headfirst into a messy reality in enterprises: heterogeneity.
I’ve been wrestling with the context problem for the past 18–24 months — in conversations with customers, in our product strategy at Atlan, and in essays I’ve written about the enterprise context layer and the AI context gap. This post is my attempt to pull those threads together, connect them with the “systems of intelligence” stack, and share where I think the world is really going.
The end of one heterogeneity, and the start of another
For the last decade, “heterogeneity” in data meant a mess of point tools orbiting a few closed warehouses, followed by a wave of consolidation as platforms tried to pull everything into their gravity well. Iceberg and open table formats are ending that era, with storage becoming open, compute becoming fungible, and lock-in moving downhill.
But fragmentation isn’t going away. Heterogeneity is just moving up the stack.
Instead of five warehouses, we’re moving toward hundreds of agents, copilots, and AI applications. Each with its own partial view of the world, its own embedded definitions, its own “private” context window. Instead of arguing about where data lives, we’ll be arguing about whose semantics are right, whose AI we can trust, and how to keep dozens of autonomous systems aligned with a single version of reality.
Unfortunately, this isn’t a guess for the future. We’re already seeing this happen.
One customer told us: “We have 1,000+ Databricks Genie rooms and no way to govern them all. It’s like BI sprawl all over again.”
Another said: “We have all kinds of agentic tools (Sierra, Writer, Google Agentspace, Snowflake Cortex) and none of them talk to each other. I want a common layer of context so I don’t need to context-engineer every single one of them.”
Why vertical agents can’t solve this
Execution paths are local, context is global
Let’s go back to Jaya and Ashu’s core argument for agents owning the context graph:
“Systems of agents startups have a structural advantage. They sit in the execution path.”
This is true for capturing decision traces within a single workflow. But for most decisions, context comes from everywhere.
When a renewal agent proposes a 20% discount, it doesn’t just pull from the CRM. It pulls from:
PagerDuty for incident history
Zendesk for escalation threads
Slack for the VP approval from last quarter
Salesforce for the deal record
Snowflake for usage data
The semantic layer for the definition of “healthy customer”
And here’s the kicker: every enterprise has a different combination of these systems. One customer runs Salesforce + Zendesk + Snowflake. Another runs HubSpot + Intercom + Databricks. A third runs a homegrown CRM + ServiceNow + BigQuery.
I think this is the heterogeneity problem that Jaya and Ashu’s thesis doesn’t address. The vertical agent startup sees the execution path and captures context within their workflow. But enterprises have dozens of agents, across dozens of vendors, each building their own context silo. The vertical agent can’t see this full context web.
To truly capture the context graph, a vertical agent would need to integrate with 50-100+ systems just to cover the common cases. Now multiply that across every vertical agent company — the sales agent, the support agent, the finance agent, the HR agent — each building the same integrations.
The two halves of context
System heterogeneity is just the start of the problem. Though we think of “context” as a single concept, context itself is heterogeneous.
Tomasz Tunguz gave a great explanation of the two emerging types of context databases:
Operational context databases store standard operating procedures and institutional knowledge: when a customer calls about resetting a password, when legal reviews an NDA, when HR answers questions about options vesting. These processes represent trade secrets and intellectual property.
Analytical context databases are the evolution of semantic layers: definitions and calculations for metrics like revenue or customer acquisition cost. Semantic layers told AI what data meant, while analytical context databases teach AI how to reason about it.
These two forms of context are deeply intertwined and yet distinct, both in what they look like and where they live, a fact that the context graph discourse has yet to account for.
A renewal decision doesn’t just pull from operational context (”here’s our exception policy for discounts”). It also pulls from analytical context (”here’s how we calculate customer health score, here’s what ‘at-risk’ means”). And that analytical context is defined in your semantic layer, which sits on top of your data warehouse, which contains data from your CRM, support system, product analytics, and billing platform.
The vertical agent sees the workflow, not the analytical context that feeds it. The data warehouse sees the metrics, not the operational decisions that use them. The context graph needs to bridge both of these perspectives.
From execution paths to compounding systems
In practice, context turns out to be cross-system and multi-layered. And that changes the question. It’s no longer just who captures a decision trace at the moment it’s made, but what kind of system can capture, refine, and deliver context across dozens of agents over time.
In a world with hundreds of agents operating simultaneously, the hard problem isn’t initial context capture. It’s coordination and improvement. How does context get better? How does it stay consistent? How do we ensure that what one agent learns can benefit another?
That’s where two ideas become foundational: feedback loops and context platforms.
Context compounds through feedback loops
Tomasz made another point that’s relevant here: “The key to both operational & analytical context databases isn’t the databases themselves. It’s the feedback loops within them.”
The system that wins isn’t the one that captures the most context on day one. It’s the one that gets better at capturing and delivering context over time.
This creates a flywheel:
Accuracy creates trust: When the context is right, agents make better decisions.
Trust creates adoption: Teams use the system more.
Adoption creates feedback: More usage generates more corrections and refinements.
Feedback creates accuracy: The context gets better.
The vertical agent can run this flywheel within their domain, but they can only improve context for their workflow. They can’t improve the shared building blocks for all workflows: the underlying definitions of key terms, entity resolution across systems, semantic understanding of metrics, and precedents from one domain that affect others.
The universal context layer runs this flywheel once, at the platform level, and every agent benefits. Every interaction — across sales, support, finance, and operations — improves the shared context. The semantic definition of “customer health” gets refined. The entity resolution between Salesforce contacts and Zendesk users gets better. The understanding of which exceptions create precedents gets sharper.
That’s where compounding lives: at the platform layer, not the application layer.
From context engineering to context platforms
Today, making AI work in enterprises requires enormous amounts of manual context engineering.
They rely on armies of forward-deployed AI engineers and agent product managers, who gather context from customers and manually update system prompts and evals. This approach works, but it’s slow and labor-intensive. And crucially, it means every vertical agent vendor is doing the same context engineering, over and over, for each customer.
Instead, there’s been a shift from “ad-hoc context engineering” to productized context platforms.
A critical piece here is in the last row: customer-owned.
Tomasz made this point recently: “Enterprises learned a lesson from cloud data warehouses. They handed over both data & compute, then watched as the most strategic asset in their business, how they operate, became someone else’s leverage…” This is why Iceberg exists and open table formats are winning. Enterprises realized that ceding control of their data to a single vendor created lock-in that hurt them strategically, and the data itself became leverage against them.
Now imagine doing that with something even more valuable than data: the accumulated institutional knowledge of how your company makes decisions. The tribal knowledge. The exception logic. The “we always do X because of Y” reasoning that lives in people’s heads. That’s what context graphs capture.
Enterprises are not going to hand that over to a dozen vertical agent startups, each owning a slice of their operational DNA. Their strategic asset is context, not agents. Enterprises will want to own their own context with open, federated context platforms that any agent can read from, humans can govern, and the organization can improve over time.
Who will capture the trillion-dollar opportunity?
Context is a trillion-dollar opportunity, but I think the winner won’t be the company that sees one workflow deeply. It will be the company that stitches context across workflows, across systems, across the heterogeneous mess of enterprise technology.
Here’s what that actually requires:
Cross-system connectivity: Integrations with hundreds of data sources, from warehouses to CRMs to BI tools to communication platforms
Operational context synthesis: Extracting SOPs and institutional knowledge from logs, tickets, chats, and human behavior
Analytical context management: Governing metric definitions, business entities, and semantic relationships
Context delivery at inference time: Serving the right context to any agent, at the moment of decision
Feedback loops at scale: Improving context continuously across every interaction
Governance and trust: Ensuring all agents operate on a shared version of reality
This is a platform problem, not an application problem.
The companies that have already built #1 and #3 — the ones that connect to Snowflake and Databricks and BigQuery and Salesforce and dbt and Looker — have a structural advantage here. They’ve already solved the heterogeneity problem, understand how data flows through an organization, and have the relationship graph that ties systems together.
This is the real trillion-dollar opportunity: creating a universal context layer that helps all of the enterprise data and AI systems work together.
In a world of heterogeneity, the integrator always wins. And in a world where enterprises learned the Iceberg lesson, the platform that lets customers own their context will beat the platforms that try to own it for them.
We’re exploring this at The Great Data Debate with thought leaders who are shaping the space from some of the world’s leading organizations. Join Jaya Gupta (Foundation Capital), Karthik Ravindran (Microsoft), Bob Muglia (Snowflake), and Tony Gentilcore (Glean) as they unpack where we are today and debate who’s best positioned to win the trillion-dollar opportunity ahead.
I’d love to hear what you think. Share your thoughts in the comments!
That’s all for this edition. Stay curious, keep exploring, and see you all in the next one!
About Metadata Weekly
Metadata Weekly isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: trust, governance, context, discovery, and the human side of doing meaningful work.
Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.
Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Metadata Weekly is your place to learn, reflect, and connect.
Got something on your mind? We’d love to hear from you. Hit Reply!
Aside from the wild response to the context graph concept, how can an agent manifest tacit knowledge, that humans have in their heads?
For agent decisions are already captured in trace logs. For human decisions though?
It’s illogical. The only system or innovation that makes sense is process knowledge management.
This looks like new jargon for the agent concept actually applied rather than a genuinely new take on agent deployment. What makes it exciting is the possibility of removing agent actions from the workflows once they replace humans in the workflows.
Obviously, any agent will need to work with a large set of tools as part of doing their work when substituting for a human being (for example, a sales agent). The information transferred between the human and the tools will allow for decisions made by the agent.
If the plan is to capture those agent decisions in a separate layer (the context layer) when the decisions are actually made, don't you think you should be able to implement that for the human worker first? But you don't. If you did, that would let you automate the human work, but it would require special tooling and cooperation from the humans involved. Agents will cooperate with business process management when humans cant or wont.
An agent could provide a decision trace that you could then capture in a database, thereby tracking its actions over time and the reasons for them. The obvious value of the metadata is to BPM (and KYC when that information isn't captured already), not data interchange or metadata management. Maybe for businesses that don't know what their workers actually do, it would useful to see their actions and reasons for action. Everybody will be thinking about how to reduce the cost of agent use.
You could ask a properly skilled software agent to provide information about additional automation that it could create to remove its actions (or another agent's actions) from some decisions. The more repeatable its sequences of actions, the simpler automation of what the agent does would be for the agent. This is true now for the humans working the jobs that agents replace, it's not a new idea.
Someone was bound to come up with agents automating their own work once agent actions cost money. Context graphs are headed that direction. Their allure seems to be that they are captured decision data. It is ironic that humans know why their work is valuable while supposedly agents wont.
Copying a trace of agent actions and their reasons (the decision trace) to an external database will provide a means to transfer tasks between agents and automate tasks currently performed by agents because the information and control flows involved will be available to agents that manage or automate other agent work.
It's the dream of BPM realized among software agents, to streamline work and reduce costs. The "market opportunity' is in the additional tooling that enables interoperability and automation of tools used by agents. The rest of it will be the traditional software development meant to reduce costs and remove paid decision-making (and action-taking) from work in general.
If this next trillion-dollar irony comes to fruition, the agent providers will find their product less employable over time and all those data centers ready for deploying all those agents will sit unused.
Or I suppose if agents are good enough at modeling and automating human decisions, we could skip a lot of the agent deployment.
This brings to mind the original vision for XML use by industry, back in the early 2000's...