Semantic Layers Failed. Context Graphs Are Next… Unless We Get It Right
Context graphs are a hot new conversation these days. And yet I feel like I’ve seen this story before.
Context graphs are a hot new conversation these days. And yet I feel like I’ve seen this story before…
Think back to the semantic layer hype just a couple years ago. Conferences, blogs, and Twitter threads declared it the missing piece of the modern data stack. People argued about whether semantics should live in a central layer or remain embedded in tools. I was there as a launch partner when dbt launched their semantic layer, and when dbt and Transform duked it out in our Great Data Debate. And just as quickly as the data world sprinted up the peak of inflated expectations, we quietly slid down into the trough of disillusionment.
Fast forward to today and there’s an eerily similar feeling. The context graph hype kicked off in December with Jaya Gupta and Ashu Garg’s elegant article arguing that context graphs are the next trillion-dollar opportunity. Since then, people debating what a context graph should look like, how to build it, and how it will affect the larger data ecosystem — including responses from Glean’s CEO Arvind Jain and, well, me. CIOs are publishing excited takes on LinkedIn, and startups everywhere are framing their product as the “context layer for X”.
I’m completely onboard — the context graph conversation echoes what I’ve been hearing from data leaders for the last couple of years. Context is everything, and context graphs have the potential to solve it. But I’ve also seen what happens when an elegant thesis meets messy enterprise reality.
So here’s my question:
How can we make sure that context graphs avoid the semantic layer’s fate?
Why the semantic layer failed
Once-popular ideas often seem so obviously wrong in hindsight. We rewrite the story as if the flaws were always apparent, the outcome always inevitable.
But that’s not the case here. The semantic layer wasn’t a case of a bad idea or immature technology. On paper, in fact, it had everything going for it.
The core promise of the semantic layer was simple and powerful:
One common place to define metrics everyone understands
No lock-in—customers can move freely across tools
Define once, use everywhere
The problem-value fit was dead on. Everyone agreed this was needed, and data people were ready to jump out a window rather than argue yet again over contradictory metrics or what an “active user” actually meant. And the problem-solution fit was also a lock — the technology worked, as demonstrated by tools like dbt’s MetricFlow, Transform, and Cube.
Here’s the issue: the product-market fit never materialized. The semantic layer never broke through as a standalone category. Not because people didn’t want it, but because it ran into three structural problems.
1. Incentives were misaligned
For companies like Power BI, Tableau, and Looker, semantics weren’t a commodity — they were the moat. Metrics, limited as they were, already lived in BI. Letting them go to an independent semantic layer meant that customers could easily churn and switch from one BI tool to another.
Business intelligence had no incentive to support an independent semantic layer. As Benn Stancil put it, “They’ve [BI tools] been reluctant to outsource semantic layers to a third party that they can’t control, and that everyone else can use.”
In theory, everyone said they wanted openness. In practice, every major BI tool wanted to be the place semantics lived.
2. The migration math didn’t work
The time when semantic layers were all the rage was rough for most data budgets.
At that point, most enterprises had already built their first generation of BI. They had sunk years of time and money into building V1 of their Power BI dashboards, Tableau workbooks, or Looker explores.
Migrating to a standalone semantic layer meant rebuilding large parts of that stack for essentially the same business outcome. No new insights or answers, just the promise of more clarity in the future.
When data budgets tightened in 2023, that math became a hard sell for enterprises. The semantic layer just didn’t seem to make business sense.
3. It wasn’t in the execution path
The semantic layer was always framed more as a governance layer than an execution layer.
Before you could use the semantic layer, you had to build it and define all the metrics first. The value came after the investment, not during the work. Even after setup, the semantic layer wasn’t something analysts touched every day to answer every data question. It lived off on its own, working in the background as needed.
Contrast that with Fivetran, which succeeded because ingestion was the work. dbt succeeded because transformation was the execution path. These tools weren’t a layer on top of daily work — they were the work, providing value on Day 1.
The first core use case of a metric store was a BI dashboard or a visualization, and building the semantic layer as a part of that daily workflow was core for making it stick. As George Fraser predicted, “They [Looker] weren’t able to sell their metric store without a built-in viz/dashboard/users/permissions layer, and that’s not going to change.”
Why context graphs might, and might not, be different
At first glance, context graphs seem fundamentally different from semantic layers.
Anyone who’s spent worked with AI knows that context isn’t a “nice to have.” It’s everything. Without the right context, agents hallucinate, stall, or make confidently wrong decisions. As Anthropic put it, “context is a critical but finite resource for AI agents”.
Making AI work is a matter of context engineering. Andrej Karpathy defined this as “the delicate art and science of filling the context window with just the right information for the next step.” Or as Tobi Lütke put it more, it’s the “art of providing all the context for the task to be plausibly solvable by the LLM”.
This problem is why the context graph thesis resonated so strongly. Jaya and Ashu articulated something many teams were already feeling: systems of record capture what happened but they lose the why, i.e. all of the institutional memory that determines how decisions actually get made at an enterprise. Context graphs promise to change this by tracking how decisions get made and turning that logic into searchable precedent. Over time, this becomes “the real source of truth for autonomy” for AI agents.
The case that context graphs are different
It would be easy to equate the context graph with semantic layer or knowledge graphs. The principles are the same: creating shared sources of truths. A semantic layer is about creating a single source of truth for analytics, and as we start thinking about context graphs, it’s about creating a single source of context for AI.
In fact, there’s been a lot of confusion about the difference between semantic layers, knowledge graphs, and context graphs and ontologies. Jessica Talisman even published a whole article about it on Metadata Weekly last week. But I think this misses something very important: in the AI world, context is not an abstraction or best case practice. Instead, context is to AI what data was to BI, the raw input that allows the system to function.
Making an AI agent work is all about giving it the right context. Without it, agents don’t just work inefficiently or give iffy answers. They fail outright. And unlike semantics, you can’t add context to AI later. It’s a critical part of daily work, both for determining what inputs an agent receives and guiding its output.
In short, context engineering is the work, and context lies squarely in the execution path.
The fatal flaw in this case
Jaya and Ashu argued that vertical agents will own context because they “sit in the execution path”. The sales agent will capture renewals context, the support agent will capture escalations context, and so on.
This quietly assumes there’s a single execution path where context naturally accumulates. It’s true for simple workflows, but not beyond that. Most decisions happen across workflows and systems, and context comes from everywhere.
For example, when a renewal agent proposes a 20% discount, it doesn’t just pull from the CRM. It needs to pull 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”
While context absolutely sits in the execution path, there is no one execution path for most decisions.
This is the crux of the issue, and it’s something I explored in my earlier piece on the enterprise context layer. Heterogeneity is moving up the stack today, from a mess of data tools to an ever growing mess of AI agents, copilots, and applications. This means that while execution paths may be local, context is global.
A sales agent can capture sales context, and a support agent can capture support context. But neither can see, let alone own, the full web of reasoning behind a decision without rebuilding the same integrations, definitions, and assumptions across dozens of systems.
Instead of eliminating fragmentation, this approach risks recreating it one layer up: many agents, each capturing partial context, embedded private definitions, conflicting decision logic, and their own private versions of “why.”
The context layer is fundamentally different from the semantic layer… but if we build it as fragmented, vendor-owned silos with misaligned incentives, we’ll repeat the same failure in a new form.
The principles that will determine the context layer’s survival
Fivetran and dbt didn’t win in an increasingly chaotic, fragmented data stack because they promised better architecture. They won because they embedded themselves directly in the everyday work building data warehouses, as a place for work rather than a layer on top of it. They provided value on Day 1 and just kept improving over time — no preliminary two-year tagging project needed.
If context graphs are going to live up to their incredible promise, they have to follow the same playbook. Ontology can’t be a three-year-long IT project or something that stops work. It has to be built thoughtfully and naturally, emerging as agents are deployed and decisions are made over time.
Here are four principles that will make the context layer a reality beyond the hype:
1. Built for human collaboration, not just machines
Context can’t be a black box. If an agent proposes a 20% renewal discount, humans need to see why. Not just the outcome, but the reasoning: which signals mattered, which precedents were used, and which assumptions were made.
Humans will need to be able to review and, more importantly, correct these processes based on their organizational context. For example, imagine that an agent looked at a renewal decision and decided not to give a discount, based on the fact that the customer was an enterprise customer with sufficient budget. What if the agent missed that this customer was not only at risk of churning but was also a key reference logo in a new industry for the company? This is an entirely different situation that requires a different approach, one that couldn’t be fully mapped out within an agent.
This feedback from humans, from not only AI engineers but all frontline teams, will create institutional knowledge and make the system smarter over time.
2. Machine-native and built for change
The context layer can’t be designed around today’s protocols alone. We’re still in the early innings of agent infrastructure, and change is guaranteed.
When we first started using AI, humans were doing most of the work and asking AI for help along the way (i.e. AI-assisted workflows). More recently, though, we’re in the early days of AI-augmented workflows. This flips the script, where AI is taking over most of the work and then asking humans for help.
The last month is a great example of this, where people across tech have been losing their minds over the massive step forward for AI-augmented coding. As Simon Willison put it, “It genuinely feels to me like GPT-5.2 and Opus 4.5 in November represent an inflection point - one of those moments where the models get incrementally better in a way that tips across an invisible capability line where suddenly a whole bunch of much harder coding problems open up.” (Here’s a great video from The AI Daily Brief on why people are obsessed with Claude Code.)
I don’t know what’s next, but I can guarantee that MCP, A2A, and today’s agent frameworks won’t be the last ones we build. The context layer needs to be built for consumption by AI first, which will take up the heavy lifting and ask humans for help as needed, not the other way around. More than that, it has to be built for resilience to change. The context layer can’t be built for today’s world when we don’t know what tomorrow will bring.
3. Open, portable, and bigger than any single vendor
Enterprises already learned the Iceberg lesson: handing your most strategic asset to a single vendor creates permanent lock-in.
Context, the accumulated reasoning behind how your company makes decisions, is even more valuable than raw data. No enterprise will hand that over to a dozen vertical agent startups, each owning a slice of their operational DNA.
This is even more true now, as the world is moving so fast and we’re entering a cycle of massive innovation. The worst thing that any enterprise can do right now is commit to a single vendor, a single LLM, and get locked in. What if you make the wrong choice?
The winning context layer has to be open and portable. Context needs to move with you across agents, LLMs, clouds, and tools, rather than being held hostage to a single execution environment.
4. One shared brain, many agents
Vertical agents can run flywheels for individual workflows. But a shared context layer runs the flywheel once, at the platform level, and every agent benefits.
Here’s an example: Say that a company’s top-of-funnel sales qualification agent or inbound BDR agent learns that there are more inquiries for a certain new category or search term. That context needs to flow into the marketing agents, informing the company’s ICP (ideal customer profile) and upcoming marketing campaigns. It should also flow into the content marketing agent for a new blog post on this emerging term.
This is where compounding happens. Every agent learns from the same living source of truth, so every piece of context improves the whole system, every use case makes the whole enterprise smarter.
The real trillion-dollar question
I want content graphs to succeed. The problem they’re solving is real, urgent, and unavoidable for every enterprise using AI today.
But I’ve seen what happens when elegant ideas turn into standalone infrastructure that doesn’t plug into daily work and takes too long to prove its value. That’s how the semantic layer lost its promise.
Context graphs will meet the same fate if they follow the semantic layer playbook: massive upfront investment, vendor lock-in, and vertical fragmentation.
There’s another path: where context is built at the same time as AI agents are deployed, emerging from people’s work rather than blocking it. Something open, federated, enterprise-owned, and improved over time.
The trillion-dollar opportunity, as Jaya and Ashu put it, is real. But the path to capturing it isn’t through vertical agents building siloed context graphs. 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.
Context graphs are valuable — that’s not up for debate. What is up for debate is how we’ll build them. Will it be as vertical silos that accidentally recreate the fragmentation problem, or as a universal, open layer that solves it once and for all?
I’ve seen this story before. This time, I’m hoping for a different ending.
We’re exploring these architectural choices and their strategic implications 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 debate the paths forward: Can semantic layers evolve? Do enterprises need ontologies? And who’s positioned to capture the trillion-dollar context graph opportunity?
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!