Sponsored by: Impetus Technologies | Context Engineering: The New Control Plane for Agentic AI

Summary

Impetus Technologies' Context Engineering methodology addresses the context gap—the distance between what enterprise data contains and what AI agents actually know—which the company identifies as the primary reason most enterprise agentic AI projects fail to scale beyond chatbot-level capability.
The methodology defines four types of context gaps (data, semantics, execution, and knowledge) and four corresponding pillars: data modernization, semantic awareness with ontology-led modeling, knowledge graph creation, and a context fiber layer for continuous AI grounding.
Impetus Leap AI Services and Solutions Family is built on the Databricks Data and AI platform, providing a phased path from data modernization through knowledge graph construction to production agentic activation with validation, certification, and ground-truth quality checks.

Chapters

FAQs

What is the context gap in enterprise AI and why does it matter?

The context gap is the distance between what an enterprise's data contains and what AI agents actually understand—including rules, policies, pricing logic, SKUs, and fraud patterns that raw data alone cannot convey. Impetus argues this gap is the primary reason most enterprise agentic AI projects fail to scale, because agents without enterprise context cannot take reliable, nuanced actions.

Why do RAG, fine-tuning, and long context windows fall short of closing the context gap?

RAG works well for small, relatively static data corpora but does not scale to the breadth of enterprise context. Fine-tuning is expensive and becomes stale as the enterprise changes. Long context windows can help but do not provide structured enterprise semantics or the operational execution context agents need to act reliably.

What are the four pillars of Impetus's Context Engineering methodology?

The four pillars are: (1) modernize and migrate data for AI readiness; (2) build semantic awareness through ontology-led modernization; (3) create enterprise knowledge graphs that encode business relationships and rules; and (4) establish a context fiber layer for continuous, ongoing AI grounding as the enterprise evolves.

How does Impetus Leap integrate with the Databricks Data and AI platform?

Impetus Leap is built natively on the Databricks Data and AI platform, using it as the foundation for data storage, transformation, and model serving. The Context Engineering methodology provides a phased implementation path—from initial data modernization through semantic layer construction to agentic activation—with validation and certification steps to ensure output quality.

Full transcript

[00:07] Good afternoon and thank you for coming here for this session. Uh context engineering uh what's it's it's a new control plane for the Gentex AI. Um so why are we here, right? Why are we today talking about context engineering?
[00:20] Uh we all know that the model is quite powerful, you know, the AI labs have created models which are quite powerful. But they do not know your uh enterprise context. They do not know about your
[00:32] rules, about your policies, about your SKUs, pricing rules, and all that, right? They're quite powerful at least on a world knowledge, world intelligence perspective, but not so much on your own enterprise context, right? So that's number one. Two, I think, you know, all
[00:46] of you over here would have a lot of data. I think you all of you are data rich. But agents cannot basically talk to raw data and make, you know, very useful decisions and, you know, kind of take actions, right? Your data can give
[00:59] an uh insight to an agent that there's a return uh that a customer has done, right? But the agent cannot or the data cannot tell the agent that those three returns from one customer in 10 days is a fraud,
[01:13] right? Or there's a some kind of a competitor price down which has happened because of which that return has has been created. Or there is some kind of a merchandising issue because of which that return has been created, right? So while data is there, but again, you
[01:26] know, the context is not there for the agents to be powerful. And that kind of lands into, you know, the context gap that we are trying to solve for enterprises for these agentic uh program projects that we work with our customers
[01:38] to be successful. Why? Because what we have seen is that, you know, so far uh most of the agentic programs which has gone live are rather on, you know, the chatbot kind of a things, right? And not so many, you know, complicated uh
[01:50] agentic solutions have gone into productions which are scalable or which have been uh successful. And our theory is that one of the big reasons why that has not happened is lack of the context that is not provided to the agents
[02:03] themselves. Now, there are different ways to basically, you know, close this context gap. Uh you know, we have tried uh rags, uh but rags is good uh when there is, you know, some kind of a small corpus corpus of data that needs to be
[02:15] taken care of. Uh we have tried long context windows, you know, uh Gemini has kind of increased the context to good extent. But then again, those are those are good when there's a bonded uh kind of an action that needs to be taken,
[02:27] right? Uh we have tried fine-tuning, but again, fine-tuning is is is good when you have to kind of, you know, improve the tonality of the agent and you know, the work that needs to be done, right? Uh prompt engineering is again good good
[02:40] uh intervention, but that good intervention is there when you have some kind of a static rule, some kind of a persona, some kind of an output structure that needs to be adhered to, right? So, all of these approaches help, but they do not in a way kind of, you
[02:54] know, cover the context gap that the agents will have. So, what is that context gap? What we have analyzed is the context gap kind of, you know, uh is is categorized into four broad windows, right? The
[03:06] first is the data gap. Now, data gap is the gap in terms of, you know, uh data residing in silos, not all data coming together, uh creating the complete picture for the agents. So, that's number one. Uh then is your semantic
[03:18] gap. It's basically, you know, who knows what uh what's happening in the system, uh how are how's how's the business processes running, all that information, all that business tools, the digital identity of a company is kind of missing
[03:31] for the agents. For us, that's the semantic gap, right? The third is execution gap. Now, you have your agents, but have you built the right constraints? Have you built, you know, the right guardrails, right? Uh how do you actually go ahead and build those uh
[03:44] agents themselves is an execution gap that we have found. And lastly is the trust gap. I think, you know, all of you will agree, you know, one of the uh biggest challenges in in the agentic world today is to create the right evals, make sure those evals can
[03:56] perform, make sure those agents perform against those evals in the real time. And for that matter, when an action has been taken, there is some kind of a proof, some kind of a lineage when, you know, your auditor comes back and ask
[04:09] you why this action was taken when with the banking regulation regulatory authority comes and ask, you know, why this particular loan was disapproved, there has to be some kind of a trade. So, for us, these are the four gaps that
[04:22] kind of classifies in a way what what context gap is, right? Now, how do we solve that? So, answer is, of course, having a structured enterprise context.
[04:34] What does it mean? It means four things. Number one is the knowledge graph, you know, who knows whom, who's connected to whom in an enterprise. Second is ontology, that's the business rules, you know, the
[04:46] rules on which your organization actually runs, right? So, that's the ontology part. The third is memory, you know, what does agent need to remember when an action needs to be taken? So, that's the third part,
[04:58] which is the memory part, right? And fourth is signals, what do I do now? You know, how do I clear the noise which is there in the system? And what is that I need to basically look at and take an action? That's the signal part, right?
[05:11] So, these are the four things that we think needs to be built when a context engineering problem needs to be solved, which is what we'll talk today.
[05:25] But before we go ahead and talk about our approach, you know, our solutions, our services to basically take care of this context gap, I'll take a minute and talk about Impetus, the company I represent, you know, I I run the growth office for Impetus. Impetus
[05:38] is a company has been around for more than 20 years, you know, 17 years we have solved, you know, some of the most complicated data estate challenges for our customers. We have built uh you know, uh customers for the
[05:50] biggest bank, biggest airline, uh you know, biggest retailer of the world. So, that's something we've been doing. It's in our DNA. Uh we have built uh you know, AI-ready data platforms for our customers for
[06:03] uh you know, to do their fraud check, regulatory check, you know, for airlines to run their operations, uh for you know, retail customers to basically run their merchandising and so on and so forth. And now, what we are doing is we are basically helping our customers to
[06:16] take care of the context problem, to basically cover the context gap, right? That's why we are helping our customers so that the agentic solutions that they're building, uh the uh investment that they're doing in agents is successful.
[06:29] We are a very uh solid partner of Databricks. We have a very good uh Databricks COE. Uh lot of competencies both, you know, from a technology-wise, industry-wise, uh won lot of awards. Uh you know, it's
[06:43] often said anything whenever Databricks finds themselves in a complicated situation in terms of data estate modernization, migration, or I don't creating those data estates, they kind of reach out to us. So, we are a proud partner of Databricks and and that's
[06:56] something a legacy that we want to carry forward. But now, let's go back. Let's go back to uh context engineering. Let's go back to how Impetus basically solves context engineering. Now, this is the four ways that we basically solve the problem. The
[07:09] first is the modernize and the migrate piece. So, now, when we modernize and migrate uh you know, data estates for our customers, we make sure that, you know, the context carries with it. We do not only migrate a technical uh
[07:22] landscape to the next environment, we basically also understand the context and take the context along with the uh modernization, right? That's the first part. Second is having context in itself
[07:34] doesn't solve the problem. You need to then engineer the knowledge graph, the ontology layer, the memory using that particular context. So, that's the second thing that we do when, you know, our either either we help our customers during modernization or they're already
[07:47] modernized, but the context is missing. We come and engineer that context for our customers. That's the second way. Third way is, you know, all right, you once you have that particular context, then how do you basically make use of
[07:59] it? That's where we come, reimagine the business processes in an AI first way, and try to use those, you know, context that we have created in business processes or tech processes, and try to
[08:11] create the right set of orchestration which is required for the business to run, agents to make decision in a context-rich environment, right? And we do all that by making sure there is there is uh trust built in in uh various components of trust, right? You know,
[08:24] right from security to basically uh you know, authorization to, you know, playback, to audit trails, to red teaming. All that is what we do for our customers, right? Now, we do this with help of our solution. Uh the solution is
[08:37] called as Impetus uh Leap AI family. Uh it's it's an it's our own IP, and uh that's what we use basically to solve the context problem for our customers.
[08:49] So, if you see the middle uh layer over here, which is the Impetus uh Leap Logic Suite, that's the layer which basically essentially helps create uh those uh you know, uh those those catalogs, uh those,
[09:02] you know, uh uh lineages, which is then used to create the uh the the context for uh the migrated data estates that we have, right? And I'm going to talk about it in a minute, but the first layer basically helps, you know,
[09:15] uh get the context out of the environment, and, you know, basically take it along with it when we modernize and migrate our customers. That's number one. Number two is the second set of products, which is the uh the fabric itself, which has got three components
[09:28] to it, right? Uh the first component is essentially, you know, the knowledge management itself, where we create the knowledge graphs, the ontology layers, and and and so forth. Second is layer is where we create the memories, the MCPs for the uh customers, and third is a
[09:41] control plane where you basically figure out the drift and uh you know, how the context is actually performing. Uh the bottom uh component that you see is Impetus Prism. That's our platform to basically provide observability and make
[09:55] sure that, you know, the agents are performing the way it should be for the way it's have been built, right? So, now let's double click into, you know, each of these component and how this component basically helps create or solve the uh context engineering
[10:07] problem. So, the first part, as I said, is where, you know, our customers, you know, again, you know, our customers meet us at very various point of time. There are customers who are still in the process of, you know, modernizing their data estate. And now, when we are doing
[10:20] that particular part, we make sure that we bring the ontology along with it, right? And how do we bring the ontology or how do we bring the context along with it? You know, we have our Leap Logic Assess, which basically goes
[10:32] figure out, you know, uh the the lineage so that there's a there's a metric which is called revenue. Now, that revenue metric is net of discounts or, you know, gross or whatever it is, it's written in this old ETL rules. So, it will
[10:44] basically go figure out where the context lives, and it would attach that particular context along with, you know, the uh data estate objects and create that particular catalog, right? And we then do also certification of uh you
[10:57] know, the work that's been built and the works that's been migrated and modernized, right? So, essentially, as part of uh of our uh Leap Logic uh modernization migration tool, we first start with ontology-led migration,
[11:11] right? So, there are customers who would come and tell us that, you know, we want to basically build customer uh service solution or agentic customer service solution for a bank. We know what does an ontology for a bank for a customer
[11:23] service looks like. We would compare the data estate that they have with what should be uh a context-rich environment, and we would identify the gaps up front even before that particular migration
[11:35] modernization is happening, right? And once we identify that, we try to capture those gaps, we try to you know remedy those gaps. If not, at the very least we would basically carry the context along with it. So, that's that's number one, right? And then we create that whole
[11:48] semantic intelligence platform which propagates the context across the layers that's been built and been a kind of you know taken to the DataBricks layer or the cloud layer that we have. So, that's number one where we
[12:01] kind of have more ontology led modernization kind of an approach so that you know the context carries along with the migration and modernization that we do. So, that's the first part.
[12:16] Now, the second part that we have is the context fabric, right? Now, again, if you remember what I told you is when we modernize migrate, we carry the context, but context itself isn't isn't useful to the agents. We now need to basically create
[12:29] you know create create those those knowledge graphs and semantics out of it, right? And this is the product which basically helps us do that for us for our customers. It's got three components you know knowledge context, context fiber, and context studio. What it does
[12:42] it it's essentially builds these nine components. In our in our experience, these are the nine components which are required to basically essentially build the right set of context for our for our
[12:54] customers, right? And what do you do actually in this? I'll I'll go through you know few of them. It's a 20-minute session. There's only so much I can, but I'll try to you know walk you through few of these components that how this helps us build the context layer.
[13:08] The first part is you know the whole foundation itself. So, how do you basically map, register, and define? So, these three tools what it does it basically the metadata discovery it would try to go find you know what's happening behind a particular object,
[13:21] you know how that object is getting populated, what are the rules behind and you know what are the unstructured data which is impacting that particular data estate object, it will basically identify all that. It will create a
[13:33] catalog for it. It would create business glossary along with that particular object. It will create links to those related the right set of, you know, unstructured data which is which is influencing those
[13:46] kind of metrics and those dimensions, right? And all of this can then be kind of, you know, onboarded on Unity Catalog. It is basically an assistant tool which can be used along with Unity Catalog. So, that's the first thing that we do, which is, you know, create the
[13:59] foundation using these three subprojects, right? Then next part is we go and start defining the structure of the data, right? So, we start defining the data products itself. So, our tools, what it
[14:12] does it, given, you know, of course, given the outcome that we want to reach, we and given the kind of structure of the data that we have, we'll start auto defining what is that product which will look like, right? How that data product
[14:24] needs to be created. So, we would start giving that kind of a recommendations that how the product needs to be created. And that when when you create the product, you make sure that the context that you carry has been kind of, you know, inbuilt in that particular
[14:36] data product. So, that's the first part that we do. Then we help find, you know, contracts. We help, you know, create the contracts between, you know, these data and the business owners, right? What is the SLA? When the
[14:49] data freshness needs to be taken care of? What are the errors? What would happen to a data when the data is stale and cannot be used, right? So, all that data contracts, data quality contracts is something that we help build along with
[15:01] the the context fiber that I have, right? So, that's the second part, which is helping create the structure for the data, right? The third part that we have is which is defining which is creating
[15:13] the meaning of that particular data, right? Over here we start doing, you know, semantic modeling. Over here we start creating the knowledge graph. Over here we start attaching the policies, the uh uh the FAQs, you know, all the
[15:26] unstructured documents which is required, all the unstructured data which is required along uh with the agent. So, we start attaching those policy documents with it. And that's where we then start building the ontology, right? So, the ontology build
[15:38] basically happens with these three sub-products that we have. So, now we have uh we have that data, we have the lineage, we have the catalog, we have built uh the data products, we have built
[15:50] uh the the rules, the contracts uh for those data. We have now built the uh ontology, we have built, you know, to some level the semantics. Now, we basically go ahead and start enriching the data what is missing. Uh we start
[16:04] creating those knowledge graphs, we start creating, you know, the end product which will then be used by the agents themselves, right? And that's what we come in in terms of, you know, uh for our customers which are on the Databricks side. That is where the Genie
[16:17] comes in, kind of uses this particular layer to get more context-rich uh answers and take more context-rich decisions that will happen, right? So, this is one part of it, but all of us would know that context doesn't stay
[16:30] same, context changes, and it changes very fast, right? So, uh what we also have an ability to basically monitor the context drift, an ability to see uh why the context has been created, what was
[16:43] the reasons behind that particular context, and how the context drift is happening, right? So, we are not only looking at uh the agent performance, the data performance, and so on so forth. We are also looking at the context drift. So, that for us is key uh because that's
[16:57] what, you know, will make those agents uh perform in a similar manner as they go ahead, right? So, all that uh is something that we deliver on the Databricks platform, right? So, we know the components, we know what Databricks
[17:10] brings in, uh we know what they have in their labs, what they have announced yesterday. So, we kind of, you know, make sure that we leverage the max out of data bricks. At the same time, and the blue box over here is what we bring
[17:23] from Impetus side, which we feel are missing. So, we know at this point of time, you know, the memory part is missing. We know at this point of time, the regulatory uh decision-making which is required is missing. We know at this point of time,
[17:36] the feedback loop which is there is kind of missing, right? So, we would try to bring in you know, we know the data contract play uh pain is missing, right? So, we would kind of bring in those missing components along with, you know,
[17:48] the data bricks stack so that we maximize the use of uh what data bricks has, and you know, bring our solutions in it, right? So, how does this all look like? Uh this is our view of what an end-to-end
[18:02] context-rich data bricks stack uh would be would be there. Uh if you if you focus on the middle layer, which is the context layer, that's where you want to basically build the semantics and metrics views. That's where you want to
[18:14] basically build bring in the uh domain ontology using their onto things and all that. That's where we want to basically build the knowledge graph. And we want to make sure that particular uh you know, uh semantic layer has a proper
[18:27] memory attached to it, has proper audit attached to it, and that's what we kind of use to, you know, power the Genie applications that we build for our customers, right? Now, um a lot of those
[18:39] things is easy said and done, and it's a moving exercise. It's something that we cannot do for all our customers in 2 months and in few weeks. Uh so, it takes time. And what we have done is we have invested in certain
[18:51] agents which will help us kind of do it uh you know, as we as we go um you know, from a business unit to a business unit, from a use case to another use case. So, these agents basically help uh create uh
[19:03] maintain, you know, the uh various components of the uh context layer that I just talked about, right? So, there's there's a a of investment that's been done over here. The last thing that I'll say and and that's where I'll end uh this particular
[19:16] session is that uh all this is good, but there has to be a very different way of thinking, a very different way of building agents, which has to be a context-aware uh uh agents, right? And we feel the
[19:28] methodology which is there currently to build these agents, uh to build, you know, the data estate or AI-ready data estate, needs some change. And that's where we are investing as an organization in a new philosophy, in a new way of doing things, which we call
[19:41] as CEDL. So, we basically want to make sure that as we build any agents, as we modernize any data estate, as we work on any data engineering uh program, we first figure out what is the context that which is required for that
[19:54] particular uh project that we are doing, right? Uh and that would come in, you know, in terms of uh uh you know, building those knowledge graphs, uh building those ontologies, and so on and so forth, right? Then we would make sure that, you know, we
[20:06] ground uh in the engineering piece, we ground, we validate everything that we have done. We kind of tie it back uh to the ground realities, the truth of the organization is something that we do in engineering, right?
[20:18] Uh when we deliver these programs, we want to certify, uh we want to make sure that the context is uh the context is right. We want to make sure that uh the decisions which will be taken by the agents uh will be based on the context
[20:30] that has been built. Uh so, that's a certification that we do. And there's a learning part to it. As I said, you know, context keep evolving, uh you know, new data uh uh keeps on coming in, uh models keep evolving. So, we want to
[20:42] make sure that we keep on learning what's happening uh in the estate, and that learning is something that we need to take back into the whole uh circle again to make sure that, you know, the uh the continuous improvement which is
[20:54] required, it happens uh of the agents, of the data estate, of the context that we have built. So, that's the CEDL approach that we have taken, you know, 3,200 employees of ours uh kind of now
[21:06] works on this particular approach when we go and implement programs data programs for our customers. Uh, with this, thank you so much for coming. I know this is the session right after lunch. Um, so thanks for spending some time with me.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.