Skip to main content
or read the full transcript

Live demos

Want to watch a live demo?

Atlan engineers bootstrap, test and deploy enterprise context on real data.

About this session

44 min2 speakers

Episode 2 of WTF is the Context Layer?, hosted by Austin Kronz. Sanjeev Mohan explains why semantics tell you what a transaction was but not why it happened, why context may stay federated across vendors for now, and where taxonomy, ontology and knowledge graphs fit. His advice: pick one use case and build on the metadata and semantics you already have.

Full transcript6 chapters · searchable

Intro

0:00

Austin Kronz

0:00 All right, let's do this. Well, welcome everyone to WTF is the Context Layer? This is the second episode in our series where we are we, we are demystifying what even is a context layer. I think we have seen from whether it's your favorite social media influencer, your vendor someone within your organization, some ask of you coming internally, there's all this terminology and all this confusion. There's a lot of conflicting terminology. If you have a conversation with one person, they almost certainly will disagree with the next on what some of these mean.

0:34 And so we wanted to put together a series that assembles experts from the space, whether they're independent analysts like today's guest, whether they're vendors who have founded their— or founders who have built their own company around these terms and, and offerings, or just investors, experts, et cetera. To ground us on a couple fundamental questions that we've been talking about in the first episode, you know, Gartner declared this year the year of context. How are we as an industry, are we even ready for this to, to capitalize? Knowledge graphs, semantic layers, data catalogs, these are all things that have exi-existed for quite some time. So what is the missing ingredient?

1:12 And does context live on its own? Is it its own layer? Are we building the next thing that hopefully we won't spend the next decade unwinding? Just a quick recap of what we talked about in the first episode with Prukalpa, who's the co-founder of Atlan. She introduced this equation that I think is really powerful because if we want performance from our agents, this is a a factor of intelligence and context. Intelligence being the model or the LLM that you choose to use, and context being everything that gives it, you know, information about you, your organization, and things to ultimately get to a correct output. And you can see that this is a multiplying effect.

1:50 So context without intelligence doesn't get you any performance. Intelligence without any context also gets you zero performance. So the more context you add, the more of a multiplicative effect that you'll have. The other side of this was tacit knowledge is really hard. We always have talked about tribal knowledge, kind of in the BI era. And tacit knowledge, everything that lives in the heads of your individuals and what they know about your current processes and workflows can be quite challenging to capture.

2:15 However, what we've learned at Atlan in working with a lot of customers is that your systems already have a lot of this encoded into it, whether that's SQL, whether that's your semantics and your BI tool, whether that's the questions that people are actually asking via queries to your underlying databases. There's actually a lot of information that exists already. And so being able to reverse engineer some of what's been encoded already is actually quite a powerful way to bootstrap context and get started building this overall context layer. And the last thing, I love that it came from Prukalpa. I think it gives me off the hook.

2:47 I do work at Atlan, but even Prukalpa said, "Question every vendor in this category talking about this, including Atlan." So please grill us on anything that we're talking about. When we talk about building your ontology or building semantics or giving an agent context, I think these are questions that you should push on and learn more from anyone bringing them up. Let's get into. Well, actually, I want to tee up next episode too. So if you haven't subscribed to the entire series yet, I'm excited for what we'll do on July 15th.

3:16 We have Dave Mariani, who's the co-founder and CTO of AtScale, who's gonna come talk to us a bit more about semantic layers and context layer. How are they related? Different? Are they the same? So please join us on July 15th. You'll be asking, "Austin, it's May 27th. Why are we talking about July 15th?" Well, June is a jam-packed month with Snowflake Summit and Databricks Summit, and I'm sure all the announcements and new things that are released during the month of June, we needed some time to digest, decompress, and we'll talk about that all on the next episode. But today we're joined by Sanjiv Mohan. Sanjiv, thank you so much for joining.

3:51 I'm so excited to have you here. Sanjiv is the founder of Sanjiv Mohan Consulting, where he runs his own practice. He's a former VP of Gartner where he and I actually spent some time working with a lot of the data and AI leaders, helping them understand the space, navigate the vendor complexities, what's real and what isn't. I think Sanjiv and I have had many a conversations of trying to be the most practical analyst that we could possibly be. He has his own podcast called It Depends.

4:17 He has published books on data products, and hopefully I'm allowed to say I have a book coming out shortly, but Sanjiv, I'll let you talk about that a bit more. But Sanjiv, welcome to WTF is the Context Layer? So excited to have you.

Sanjeev Mohan

4:31 Thank you so much Austin. It's such a pleasure. You and I have stories in the past. I remember that one time when you were driving Lamborghinis in Barcelona and luckily you didn't crash it. But but it's so great to be to be with you and talk about such an important concept.

Austin Kronz

4:52 Yeah. I think hey, speaking of Lamborghinis in Europe, yeah, I think context is probably needed on that conversation. But, you know, if anyone wants to catch up with us at a conference, we'll happily tell you that story. I guess it's not a long story. I love sports cars. If I'm gonna go somewhere like on a beach, maybe Barcelona definitely gonna drive a Lamborghini along the beach. So happy to talk about that when I'm not talking about AI, too.

Sanjeev Mohan

5:17 I by the way, yeah, context is such an important thing that I, I just got reminded of a post I did. I last saw you at Gartner DNA Summit Orlando, and I was getting ready to leave my house taking a red-eye from West Coast US to Orlando, and I get a message on my cell phone from Uber, and it said, "Leave now to meet Jesus. He is arriving in a red Chevrolet." And first I did a double take. Oh my God, finally the day has arrived. But if you know the context, then you know that you don't need divine intervention to get to Gartner's conference. It was just the driver was named Jesus.

6:02 So that's why I found it very— And I, actually, my post basically turned it around and said, "Oh, look, this is why context is so important."

Austin Kronz

6:11 That's awesome. I, I love the, the real example and I remember the post. So let's talk about, you mentioned your article. So you just published this on Friday frequently asked questions that you're getting. So I love that I know you're having conversations every day, whether it be with customers and end users or vendors that are trying to piece together this as well. When you think of what kind of inspired this, this article, right I think you articulated the different layers of the stack very well. But just walk us through kind of what you were thinking as you put this together. What was the inspiration behind some of this?

6:45 And, you know, give us the general outline. We'll send a link in the chat to the actual article itself.

Sanjeev Mohan

6:52 Thank you. So Austin, what why I put this together was because two weeks ago, as I'd got another Gartner DNS summit, this time it was in London, and I was running into end users large corporations, as well as vendors, and they were asking me, "What the heck is context? Gartner's declared twenty twenty-six to be the year of context, but we don't even understand it." And, and when they tried to explain to me, these are experts, sometimes some of these were experts, I, I was telling them that, "No, what you're telling me is not context, it's semantic." And they're like, "Yeah, well, what's the difference? It's the same thing."

7:32 So then I would sit with them and start explaining, and I saw them drawing out the stack, which I then decided that instead of going around trying to explain verbally, let me just put my thoughts into a blog. And, and my focus was, was mainly on defining using examples, what are the different terms and how they all are, have their independent place. They're not overlapping, although we tend to use them interchangeably. That was it.

Austin Kronz

8:07 Yeah. And I, I think the visual that you included there, I think articulates very well, not just the layers, but how they are related to one another, how they may feed or influence the other. So I think that's really helpful. Maybe just a, a quick question on, like you mentioned semantics. I think if you come from the data and analytics space, the BI space, there's maybe a bias towards semantics, right?

Semantics vs. Context

8:25

Austin Kronz

8:28 Semantic layers go back, Prukalpa and I talked about this a little bit in the last episode, but I mean, well before the modern data stack even existed, it was a concept. And I think— Mm-hmm... Maybe there's just some bias, especially at a Gartner Data and Analytics Summit, right, where semantics might sound like context because, well, for an analyst, this is like the context. But there's so much more that isn't being captured. So maybe just tell us a little bit about— Yeah... You know, different perspectives.

Sanjeev Mohan

8:55 So, so let me, so, so let me see if I can help demystify this. So semantics, if you look at even the English word semantics, what, what it means definition, defining what Like when we say, you know, you and I have we're differing in semantics, is like the way we are explaining things is, is different. So semantics became extremely important in the world of BI because BI reports and dashboards were being built by business users, and business users should not have to understand that cust underscore addr underscore st is a state. How would they know? So if I'm writing a SQL statement, yeah, I, I know it.

9:40 But translating, so we were basically creating a business glossary. We were saying that businesses should be able to see terms or terminology that they are used to, and that is one of the semantics. So other semantic things are what are the rules? What are the formulas? So if you and I belong to two different parts of an organization, and we are both tasked with calculate our monthly recurring revenue, and you and I have different understanding of what that is, then we have inconsistency. So semantics helped solve by creating a consistent definitions, rules, meanings and that was it.

10:28 But it does not tell you why a transaction took place. It tells you everything about a, about a transaction. The example that I've used in my blog talks about how I recently bought my Apple MacBook Air M5 laptop. And but why did I choose an M5? Why did I choose on thirteen inch? Why not MacBook Pro? What sites did I visit? What's my level of satisfaction? What, what other influences came in, like warranty? Maybe I was interested in buying AirPods. So all of those whys that help complete that transaction become context. They've got nothing to do with semantics.

11:17 So now the question that begs is, okay, so I understand semantic, so context is not new. We've, we've kind of always wanted to know the why, but why is it such a big deal today? Why didn't we, we pay so much attention to context five years ago, ten years ago? Because what you're saying makes sense, but it's, it's not new. The reason for that is because we, our industry is, or software is moving from being developed for humans to being developed for agents.

11:52 So when it's humans, and I get an irate customer support call, I can quickly dig around, do my homework, I can patch things together, and I can understand, oh look, this guy is really mad because of these things. But if I'm now going to use an agent on my behalf, the agent cannot do that. The agent does not have this magical skill of understanding everything. Like, like, like an, an LLM can tell you what an apple is, but I can guarantee an LLM has never tasted an apple. Or you can ask, like, how it like, it can tell you how it tastes based on what it's been trained, but it's never tasted it, right?

12:39 So, so that's why context is also important, because agents are working on our behalf. That's one reason. And the second reason by the way there are four reasons I give there. But the second reason that is also important is that a lot of context does not sit in structured databases. They sit everywhere. Unstructured databases, PDF manual on SharePoint that will tell you that the reason this person is calling customer support is because it's a known defect, but it didn't make it into my database. It could be in tweets people are doing about the product.

13:21 So a context job is to assemble all of these signals that are separated in different places, and then feed it to an agent to provide the answer.

Austin Kronz

13:35 Yeah. So I, if I could just say that back to you a little bit, it sounds like context is disparate, much like data was disparate.

Sanjeev Mohan

13:42 Yeah.

Austin Kronz

13:42 And we've probably spent the last three decades trying to corral data from multiple sources. Context lives in multiple places as well. And so there has to be some mechanism to assemble context for a particular use case or a particular agent.

Extract. Context. Link.

13:52

Austin Kronz

13:57 I think that's one thing I heard.

Sanjeev Mohan

13:59 Yeah.

Austin Kronz

14:01 I think the other side of that you mentioned is almost what we talked about in the first episode a little bit around agent onboarding. Like—... All of that information that a human analyst or just any employee accumulates, oftentimes, yes, it's their experience that they bring with them to your organization, but you also onboard them. You tell them, like, "Here's where all of our standard operating procedures live. Here's what they are. Here's the ones that are relevant for your job. Here is our security onboarding. Here is our, you know, basic policies. You know, here is your mentor or mentee that you should be partnering with every day to sync up."

14:36 And, you know, all of this is in an effort to transfer context to a person. And so there has to be some level of effort to do this for our agents as well. Now, I think you get the benefit of scale with an agent that— Yeah... Like, yes, they can accept an infinite level of context, and probably you don't need a three-month onboarding or something like that. So there's obviously the benefit there. But that exercise of corralling context, I think is now, you know, commonly called just context engineering. You introduce maybe a, a level deeper of that in your article that you call ECL. Can you talk a little bit about what that is?

Sanjeev Mohan

15:11 Yeah.

Austin Kronz

15:11 And, like, what the outcomes of that would be?

Sanjeev Mohan

15:14 Yeah, absolutely. So what I'm, I'm proposing in, in my article and I haven't gone too detailed into ECL, but we, we are used to, and Austin, you alluded to this, that data originates in different places, different types of data. It could be customer service data, it could be point of sale data, it could be logs. So you've got different system of records. But then we go through this process of ETL or ELT, where we're extracting this data and we are moving into a lakehouse or a cloud data warehouse, and then we build reports on top of that.

15:55 Now, the problem with this is that first of all, we've never been successful in really, really building out a corporate data warehouse. It's, it's a huge task to move all of this data, and we are only talking about structured data. We haven't even talked about unstructured data. So what I'm proposing, where I think we should be going in the future, is instead of extracting and moving data, moving data will always involve some latency, security overhead compliance issues, all of... So there's there's a lot of cost skills that are needed. Let's not extract content. Let's extract context.

16:39 And so, and by context, what I mean is if it's a parts manual and it's it's a PDF document, then I extract the entities, I create vector embeddings, I do similarity search. I, I now know what's related to what. So I create the context, and then I create some sort of a link where I can then see all this context for my particular problem. Sometimes that linking may be in a knowledge graph but you don't always need a knowledge graph. But you need some sort of extraction of entities, creating the context graph, if you may, and then linking it to provide it to an agent.

17:24 So this ECL, I chose these terms as a take on ETL. So that was the whole idea.

Austin Kronz

17:33 Yeah, it makes sense. I think, yeah, the similar— There's so many parallels to the structured data world, I think. In unstructured, you know, your Google Drive, your Confluence— Yeah... Your SharePoint will still be a system of record for unstructured data.

Sanjeev Mohan

17:48 Yeah.

Austin Kronz

17:48 However, curating what's relevant out of the massive ocean that is your corporate G Drive your agent can't possibly intelligently or meaningfully or cost efficiently traverse all of that to figure out for you one question what that is. So this, this context engineering or this ECL process— Right... Is really a way to give the agent what's most meaningful for the particular questions. I mentioned, I was talking before the call about how then we, we talk about, like, bounding— Context.

Sanjeev Mohan

18:19 Yeah.

Austin Kronz

18:20 Which is essentially a way to say your agent is trying to serve this purpose. What are all the necessary pieces of context, both data, semantics, relationships like SOPs, skills, anything that might be related for that particular agent use case.

Sanjeev Mohan

18:36 Right. So, so can I I, I love to dive deep into technology. So if, if you humor me for just a minute, why is this even possible from a technology point of view? And we, we weren't talking about this a few years ago. A lot of things have happened lately that some, some of these may surprise the viewers. So with the cloud, we got a separation of compute and store. With Apache Iceberg, we got a standard way to access the storage. So that that's one reason. Compute became a lot cheaper. So storage also became cheaper, too, with object storage. Compute also became more widespread.

19:22 Networks have become really fast, so I can now build this context very easily. And the last thing that is very surprising and has not been talked about is that egress cost has gone away between AWS, Microsoft Azure, and Google Cloud. So if you have a lakehouse on Google Cloud and your data is in, let's say, ServiceNow, it's ITSM data, and it's on AWS, you can, you can pull the like the data or the context, and there's no egress fee. There is some fee for the high speed interconnect, but it's, it's very minuscule.

20:00 So, so now all of a sudden, the underlying technology has advanced to a point where I don't necessarily need to move data into one central place.

One Layer or Many?

20:07

Austin Kronz

20:13 Gotcha. Yeah. Speaking of just the, the different, whether it's a major cloud provider, an application, independent vendor, something like that, I, you know, I was trying to do my research on some of the things you were publishing throughout the year, and I think after the first Gartner summit, you weren't sure if context layer would be, you know, its own separate layer, right? And as things progress, I think based on the most recent FAQ doc that you published on Friday, it is its own layer. How do you view that with respect to, like, every, like GCP, AWS, Microsoft, OpenAI, Anthropic? I'm sure they all have some elephant, Yeah... Element of their own context layer.

20:52 So I guess, what's your current take on separate layer versus independent versus either but interoperable?

Sanjeev Mohan

21:00 So so Austin, great question. What I'm saying in my blog is that semantic layer, the the semantics are everywhere. You have it in the BI tool. You have it in your data integration tool. You have it at the database level. You have it as a universal, independent, standalone layer. So it's a, a semantic is spread across all of these. And then, by the way, there's so many others like Palantir, for example, is a, a platform with Foundry. So my point is that if semantic is in so many different places, I suspect that context will end up also in different places.

21:40 For example, there is some context that is associated with all the logs, all the firewall logs, so they have things like metrics, traces, events. So they may generate their own context, and it may sit with, for example, Datadog. Not that I have any information. OpenAI is heavily into context, so they're building context of how the agents are being used. That may actually sit in OpenAI. So, so the jury is still out on where exactly is this context going to materialize, or will it be federated?

22:22 I, I, I think I'm, I'm thinking it'll be federated, and I'm going with this whole idea of open semantic interchange, which allows semantics to be shared between a data catalog provider or a BI provider or a database. So I feel that the same thing may actually happen with context, but we're not there yet because we are still at the stage where we are still trying to parse and understand what is context and how is it different from ontology, for example, or knowledge graph. So we are still very early in this phase, and it's very hard to say how this will materialize.

Austin Kronz

23:05 Yeah. I, I think the jury's still out comment almost lends itself, though, to the need for an independent layer because I think organizations are also still experimenting— Yeah... Across platforms, right? Whether they're building agents in OpenAI, they're building in Google, they're building inside of, like, pick your agent harness of choice or your SDK, your— Yeah... Your framework, whatever it is you're building agents in.

Sanjeev Mohan

23:27 Yeah.

Austin Kronz

23:28 Like across LangChain, open source, anything like that. I think— Correct... All of the above are happening in a lot of organizations, including the application specific agents, including the data agents in Snowflake and Databricks. And so I think I agree with your point on standards. Like, something like an OSI is a good way to get the industry to focus on something that would work across solutions. But I also think in the agentic world, I mean, something as simple as markdown files, like both human and machine readable interfaces, I think are, are becoming the norm. So there are some standards forming, but I, I do think it lends itself to that.

24:03 It needs to be independent so you don't get tied into any one vendor ecosystem, but at the same time, it needs to be interoperable. So like at Atlan, if you want to use Atlan as your independent context layer today and switch tomorrow, like we want you to be able to pivot as quickly as possible, so.

Sanjeev Mohan

24:19 Yeah. That was actually one of the most memorable lines from your last episode, where the businesses should feel empowered to own their context. And semantics. And they shouldn't feel they're being locked in, because that that's what causes businesses to hold back on adopting. So if we want to enable adoption of context, then we have to give customers this feeling that they are the ones in control, they're the ones who own it, they're hosting it at a vendor's product, but they're not locked in. And so that's a work that needs to be done.

Austin Kronz

25:04 Yeah. I, I, I completely agree. Like again, I have to use Atlan examples. I'm in Atlan, so Yeah... We are, are trying to build the enterprise context layer. However, if you ever wanna access anything that we're generating, anything in the context files, context repos, it's all stored behind the scenes on an Iceberg native format. So if you wanna pivot, query it, if you wanna access it directly through Atlan, you wanna leave tomorrow and just transport it, it's all, it's all available and interoperable. So, A-and with MCP as the endpoint, right?

Sanjeev Mohan

25:35 The MCP is the endpoint.

Austin Kronz

25:35 Exactly. If you want MCP into it, if you want a SQL into it, whatever mechanism you want to access it, you have access to it. So your agents can come through the MCP if you have— Yeah... You know, just even questions, you can write a SQL query against it as well.

Sanjeev Mohan

25:48 Yeah.

Austin Kronz

25:51 I have to ask, you mentioned knowledge graph, ontology. I think two of the most common— Two of the layers that generate the most questions in, in conversations anytime we talk about either generating an ontology or reverse engineering an ontology and then also everyone wants to talk about what graph database are you using.

The 6-Layer Stack

26:08

Austin Kronz

26:12 And sometimes knowledge graph and graph database are conflated. Maybe help give your perspective on what is an ontology, how does it relate to knowledge graph? What does that mean for an enterprise buyer who is facing, you know, 50 emails a day from vendors saying, "Yeah, we do that. We do that."

Sanjeev Mohan

26:30 So the, so the three layers— So I, I, I, I propose six layers. So metadata is the basic foundational structure way of getting your information about your product. So metadata is, is a must-have because everything builds upon it. Semantic, I think is really important. Context is really important. But then there are three layers sort of in between, and they are taxonomy, ontology, and knowledge graph. Those three, I, I, I'm a bit ambivalent on these three because to do the right thing, you should have all three. You should have all six, including these three. But then I talk to customers, and customers, end users are lost.

27:18 They're like, "I don't have anything, and I'm under a lot of pressure from my CEO, the businesses, business heads are saying put in agents. But agents have to be able to give the right reliable insights. So I know I need these things, but do I need all, all six?" So I would, and I know purists would not like me saying this, but I think these three things, ontology, taxonomy, and knowledge graph are nice to have. But then if they slow you down, if you're a big company, by all means, do the right thing.

27:58 But if you are experimenting, pick a business use case and you say, "For this use case, I'm gonna define, I'm gonna collect my metadata, create the semantic layer, and then create the context, do context engineering on top." Ontology is where I'm defining relationships. Knowledge graphs, a lot of times you need some, a graph database, although not always, but I think graph databases are the natural home for a knowledge graph. But then that's a technology that somebody has to learn. And so I, so I, So it's a constant battle I have between what's practical and what's theory and is probably the right thing to do.

28:44 And sometimes we have to be more pragmatic and say, "You know, let's just build a proof of concept first before we get into some of these more technical nuances."

Austin Kronz

28:58 Yeah. I, we were working with a large retailer and their head of the AI office actually stood up in the room and basically said, "We can't let the perfect state vision get in the way of value now." And Oh, yeah... It was exactly what they were... They were trying to get agents into production. We were building the enterprise context layer. But you need to build the context layer for particular agents as you go, right? The enterprise version is how you scale and how you don't have to repeat effort across every single agent every time you build. But I mean, absolutely you have to get to value.

29:29 So, I mean, maybe a question back to you there is, like, which, might be rhetorical, but which, which fight would you rather have internally? Like, this is why we need all six layers, and don't do anything until you get all six. Or like, this is how we get something to production, right? You know what I mean?

Sanjeev Mohan

29:45 Yeah. So, so Austin, I'm gonna give you a very consultant answer, which is it depends. And and I say that in my blog too. It depends on the complexity of your data, how many users you have. I would say if, if, if a organization has their act together the data does not change very frequently, business people are really caught on, they're switched on, they know what to do, then they can follow the Atlan's point of view because, because they have that dedication. But like I said, it depends which is also the name of my podcast. So, Yeah.

Austin Kronz

30:28 Appropriately so. Yeah. Yeah, the one thing we, we were talking about, we talk about a lot with customers and whenever questions about whether it's ontologies, graph it's just that we, we can agree that relationships are very important for AI. AI understanding how one domain or entity relates to another is information that an AI agent should have. And I think there's a multitude of ways to convey to that agent, that's how this happens.

Sanjeev Mohan

30:58 Yeah.

Austin Kronz

30:58 And then there's different levels of scale as well. So to your point, that six-layer architecture, the taxonomy ontology knowledge graph might be the most efficient, scalable end state. But if you can fundamentally just focus on how can my agent reason across relationships more effectively, I think it should help the internal conversations too. I saw a question in the chat about, like, how do you have these conversations internally?

Sanjeev Mohan

31:21 Yeah.

Austin Kronz

31:21 And yeah, I think a lot of them are just how can you boil them down to simple concepts.

Sanjeev Mohan

31:26 Yeah. That's great. Yeah.

Austin Kronz

31:29 Yeah. So I wanna, I wanna... You know, you just published this blog. Things change very quickly in this space. What are you worried about, I don't, I don't want to say, like, aging poorly, but where can you see some of this changing? I know you don't have a crystal ball, but what are some of the things that if you're at Gartner twenty twenty-seven- Yeah. You know, are we having this conversation— Yeah... Or have we completely moved on?

Sanjeev Mohan

31:55 So I, I'll tell you what, what scares me the most. In fact, I, I, recently after having spoken to some end users at the last event, and then some of them I got to know, and they pinged me, and I got on a call. My biggest concern is that we overcomplicate this space. In fact on my LinkedIn post, somebody said, "Oh, by the way, you missed this layer seven, eight, and nine, because there's a policy layer, there's a governance layer." And, and my response was like, "Yes, all of those things are needed, but six itself is a big number, and you're saying it should be nine." Somebody will say, "No, why, why stop at nine?

32:34 Make it twelve." So because— and in theory, all of those things are needed. Without policy, what's the point? You know, so my biggest concern is that we overcomplicate it to a point where businesses hold back. If you look at data catalog space, data catalog I think a data catalog is a must-have because without data catalog, how in the world are you gonna discover what assets you have? And how will you see the lineage? But data catalogs have had a very tough journey because it gets out of date. People don't keep it in sync. So there's an initial euphoria, it comes in, and then it tapers, and then it just declines.

33:19 So I don't want context to fall in that space. And I think the more we overcomplicate it, there's a higher chance that businesses will be like, "I love the idea. You guys, analysts do a great job telling me how important it is. I don't have the budget for it. I don't have the expertise for it," and, and it just flops. So that's, that's my biggest concern.

Austin Kronz

33:46 Do you see certain types of organizations being more successful at this than others?

Sanjeev Mohan

33:53 Yeah. Actually, the funny thing happened. We used to make fun of regulated industries. "Oh, you're so regulated, like healthcare, so you're falling behind," because they cannot experiment. It has to be HIPAA compliant. Financial services actually did a great job of being innovative while being regulated. But like high tech for instance, fell way behind because there's so many rules. Those industries are now at the precipice of being more successful with agents because they have done the hard work of building out all this underlying understanding of the data. So, so they, they actually are benefiting from years and years of moving slow.

34:42 Retail doesn't have that, but I think retail I I, I see huge potential that retail would be able to build a context layer so.

Austin Kronz

34:55 Yeah, I think that's helpful. There's a question in the chat that was very similar, like what companies are actually making progress here and, and where do you get stuck? But I think the follow-up question to that was where teams actually hit the first blocker when they try to do this.

Sanjeev Mohan

35:12 So the, the very first blocker is in fact, there was a very popular theme that was going around. Context layer is not something you can buy, you have to build it.

Build vs. Buy & Begin

35:20

Sanjeev Mohan

35:22 So the moment I see this, I have alarm bells going on in my head, which is build versus buy. So and I think that's, that's a very important piece that... And I think we should be careful not to say you, you have to build it. Yes, obviously, you cannot buy a, a context layer that is specific to your domain's knowledge, but maybe you can buy the scaffolding, and then you can customize it. But the moment you start saying you have to build it, the people stop in their tracks. So I think semantics, using the right terminology, are very, very important. By the way, I say the same thing for governance.

36:09 When people say, "I, I have a data stack, and I need to move to governing AI stack." So this move to all these worlds, they sound like you are embarking on a totally different project. What I tell people is that, no, you're not embarking on a different project with context, you're upskilling it. So you've done the metadata, you've got the technical metadata, you've got the business metadata, you've got the glossary, the lineage. Now you are saying, "How do I expand my, my semantics to bring semantics from other sources?" And when you bring semantics from other sources, you get the context.

36:48 So, so this, th-this is to me is a, is such a big blocker where we are proposing something brand new which is a game changer, but the the, the jump to that is too wide, too far from b-for businesses. So we need to have an on-ramp for businesses and say, "You know what? It's a smooth curve." You've got metadata, semantic. You. If you want to put taxonomy, by the way, taxonomy sometimes is already there in the way hierarchies are, and then we'll take you to context. So that bridge is really important for it to be successful.

Austin Kronz

37:34 Yeah. That's really helpful. I would also say that you have to just start building to run headfirst into these problems, right? Maybe there's two types of conversations that happen. We kind of have the enterprise architects that are being tasked by senior leadership to say, "What are we doing with AI? Like, what is our AI technology landscape? What does our architecture look like going forward?" And so there's a bit of a top-down. I think that's where a lot of these conversations are coming from too, which is like, well, do we need that six-layer cake? Is it a nine-layer cake? You know, it's someone's job and responsibility to figure out what that is.

38:13 But then we talk to builders who have already just been doing it, right? I've, I've been building agents, and they come to us saying, "I built context for this one agent. Here's the MD file or series of MD files that I have for this one agent. But now when I go to build this other one, I spent months curating that one MD file." And so to your point, build versus buy is more of like, how do you first get something that helps you, helps you build— Yeah... That one agent in and of itself, or build context for that one agent.

38:47 And then, yes, at the architect level, you have to think if you're a large enterprise, at some point you're gonna wanna be able to scale beyond one agent at a time and have a universal layer. So yes, there's a, there's a bottoms-up approach that I think actually hits the problem head on, and you can iterate, and like I said, after a certain number of iterations, you're gonna end up more than likely with that full layer cake that you put in your post.

Sanjeev Mohan

39:10 100%, yes. So this, so we are in the era of builders. With generative AI, everything's gotten inverted. I used to when I grew up, everyone used to say the hardest problem in life is to show up. The hardest problem in life is to start the job. Once you start, then you are on the path to completion. I think with, with GenAI, it's reversed. The easiest thing is to start. It is finishing it taking it to conclusion because with, with things like Claude Code, Claude Cowork, I can say, "Build me this, build me that."

39:49 So there is no reason, there's no excuse left for enterprise employees to say, "Well, I don't know, like, how to get started." You can get started. You may get stuck later on, for which you would need some consultant to come and help you based on the maturity level. But get started, build the context for one use case, one business domain problem that you're trying to solve, and see how it pans out. That's the only way. In fact I've said this for years, and people say, "No, this is such a wrong thing to say." But I've said, "The best strategy is execution." I learned that decades ago in my MBA.

40:37 Like, the best laid strategy plans went nowhere, and somebody by mistake experimented with something and it took off, and then everybody said, "Oh, look, you had such a good strategy, such a good plan." Somebody even said, "Planning is a form of procrastination," when we do too much planning. Just build it and then see then, then seek help as you proceed.

Austin Kronz

41:05 Yeah. That's great. I, I fully agree. Running into the problems is gonna be the best way to get past them rather than, you know— Yeah... Sitting in a room talking to each other about how, where we might go wrong and, like, where this could be challenging and what we might need.

Sanjeev Mohan

41:20 Yeah.

Austin Kronz

41:20 So I think that's really helpful. Curious in, in your conversation, we have a couple minutes left. I mean, what are your types of questions that you're asking when you're going to either talk to a vendor that's talking about this, an end user organization that's trying to build something?

Sanjeev Mohan

41:36 Yeah.

Austin Kronz

41:36 Like, what are your conversations looking like?

Sanjeev Mohan

41:39 So I have two questions. First question I, I ask them is if they're talking about context, what is context for you? Define, like, educate me what is context? And that is usually the, the, the most eye-opening question you can ask because then you find out, oh wait, okay, they're all over the place. The second thing that I, I wanna ask I, I ask them is, where are you today? So I'm trying to understand what is the gap between where the aspiration is and what they have today.

42:13 And because where they are today will determine how quickly they can get to the aspiration and and if the gap is too wide, then we have to think about, like, intervening steps and help guide that journey.

Austin Kronz

42:30 Yeah. So this might be this might be counterintuitive based on that, that question, but if you had to elevator pitch or explain to a CEO-level persona in, you know, 60 seconds or something like this, like here is context and why it's important if they're not already on board. I'm sure they're on board that AI is important, but context itself, where would you start?

Sanjeev Mohan

42:52 So that's seeing how much I like to talk, I don't know if I can do justice. So basically context is the, the situational awareness of everything that you do to run your business. You have every knowledge about the product, about your customers, but situation changes, but habits change. A customer that you think is really your most loyal customer may churn tomorrow. That's— so having that situational awareness is what context gives you.

Austin Kronz

43:35 That's great. Sanjeev, I know we're coming up on time here, so I just wanted to thank you again for, for coming on the show and, Of course... Appreciate the insights. Everyone, we've sent a link to the most recent blog from Sanjeev in the chat. You can follow him on social medias and continue the conversation, and I'm sure there'll be many more comments on your Jesus posts about getting your Uber—... To the DNA Summit. But always great to talk to you, Sanjeev, and we look forward Likewise... To catching up at the future conferences. To the audience, we'll see you in July for our next episode.

44:08 As I mentioned, we have Snowflake Summit and Databricks Summit. It's a very busy June, so I hope to see you in person. Please stop in and say hi, and we'll catch you on the next episode of WTF Is the Context Layer. So thanks everyone. Have a great day.

Back to the video

KEY TAKEAWAYS

BLOG ARTICLE · EP 02

Industry Perspective: Why is Context So Important?

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, David Mariani, co-founder and CTO of AtScale, joined Austin to examine how semantic layers and context layers actually relate — whether they're the same vocabulary with different architectures, or the same thing described twice. Watch the recording.

Thu, Sep 17, 12:30 PM ET

Can a Context Graph Alone Make AI Reliable?

Jaya Gupta called the context graph AI's next trillion-dollar opportunity: the reasoning behind decisions that systems of record never stored. Jaya and Austin work through what a context graph must hold.

spinner