In March, Gartner boldly declared that 2026 is the year of context. But fast forward to now, and there's still confusion across the industry about what that really means.
In episode two of WTF Is the Context Layer?, Sanjeev Mohan, principal at SanjMo and former Gartner Research VP, revealed that he's still fielding questions from enterprise buyers and vendors who are conflating context with semantics. It's come up so frequently that he even published an FAQs blog.
Sanjeev joined Austin Kronz to cut through the noise: untangling six terms the industry treats as synonyms, pushing back on overcomplicated context engineering approaches, and giving an honest view of where enterprise teams stall when taking AI into production. Here are the highlights.
Q: What's the difference between semantics and context?
In short, semantics defines things. It systematically tells you that MRR means monthly recurring revenue or that a customer is someone with an active subscription. Sanjeev described semantics as being built for the BI world, where business users needed consistent definitions they could trust without having to understand or write SQL. If there was a question about rules, formulas, or shared meanings, semantics was designed to answer it.
Context is everything semantics leaves out; the "why" behind a definition or event. By way of example, Sanjeev described his recent purchase of a MacBook Air M5. Semantics, he said, can tell you the transaction happened, but not why he chose the M5 over the Pro, or which sites he visited to research it, or what influenced the final decision. Those are the "why" questions.
"All the 'why' questions that help complete a transaction have got nothing to do with semantics. That's context."
The semantics versus context distinction matters more now because software is shifting from being built for humans to being built for agents. A human customer support rep can patch together disparate signals on the fly, but an AI agent can't. Agents working on behalf of humans need scattered context assembled and delivered explicitly, which is why context engineering has emerged as a real job title.
Q: What is ECL and why does it matter?
ECL stands for Extract, Context, Link, a term Sanjeev framed as a riff on ETL (Extract, Transform, Load).
Extracting and moving data in an ETL process introduces latency, compliance overhead, and cost, but it was also never meant for unstructured data. That's the core problem today: the context enterprises actually need lives mostly in unstructured sources, like PDFs, parts manuals, support tickets, and internal wikis.
ECL proposes a different approach. Instead of extracting and moving the data, extract the context from it. That way, agents can traverse it without the underlying data ever needing to move.
"Instead of extracting and moving data, let's extract context. If it's a parts manual in a PDF, I extract the entities, I create vector embeddings, I do similarity search. I now know what's related to what. Then I link it so an agent can use it."
A specific set of converging infrastructure shifts has made this feasible: cloud separation of compute and storage, the Apache Iceberg standard, cheaper compute and object storage, faster networks, and less egress costs between major cloud providers.
Q: How much context do organizations need to start building agents?
Sanjeev proposed a six-layer context architecture stack: metadata, semantics, taxonomy, ontology, knowledge graph, and context. But it came with a caveat: taxonomy, ontology, and knowledge graphs should not block you from starting.
For most organizations, the other three layers are sufficient for a proof of concept: metadata as the foundation, semantics for consistent definitions, and context for situational awareness. Sanjeev recommended picking a single use case, connecting those three layers, and starting to build.
"Pick a business use case. Collect your metadata, create the semantic layer, and then do context engineering on top. Ontology, knowledge graph, taxonomy — those are important, but if they slow you down, get started without them."
Complexity does justify more layers, and organizations with large, frequently changing datasets and user populations may eventually need the full stack. But the "all six or nothing" framing causes hesitation. A working proof of concept built on three layers beats a stalled architecture debate about nine.
Sanjeev's take? The more complex the framework, the higher the chance enterprises decide they don't have the budget or expertise, and it simply never happens.
Q: Where do teams actually hit the first blocker?
The first blocker is messaging: context is framed as something you must build, not buy. This may be technically accurate, but it's practically damaging. When teams hear "build," they think of a new project, new team, new budget, and new timeline. Most stop before they start.
Sanjeev countered that notion, saying context isn't a new project but an extension of work teams are already doing.
"You're not embarking on a different project. You're upskilling. You've done the metadata, you've got the glossary, the lineage. Now you're asking: how do I expand my semantics to bring in context from other sources? When you do that, you get the context."
The on-ramp is what makes adoption stick. Teams need a path that starts where they are today, and follows a smooth curve from metadata to semantics to taxonomy to context.
Generative AI has removed the excuse that starting is too hard. The hard part now is finishing: taking a working agent and building toward an enterprise-scale context layer. The way through is to start building and run headfirst into the real problems.
In episode 3, Dave Mariani, co-founder and CTO of AtScale, will join Austin to examine how semantic layers and context layers actually relate. Same vocabulary with different architectures, or the same thing described twice? Register here.
