Sponsored by: Cognizant | From Lakehouse to Agent-Ready Context

Summary

The gap between a working AI pilot and a production-grade agentic system is not model capability but context readiness, including governed data products, semantic resolution, multi-source federation, and provenance.
Cognizant's Unified Context Stack is a four-layer architecture built on top of lakehouse platforms, covering a domain ontology foundation, event-driven context refresh pipelines, a unified access layer, and an agents plane powered by the Databricks ecosystem.
The phased adoption journey starts with Metric Views on an existing lakehouse and evolves incrementally toward a full agent-ready context platform, with regulatory readiness enabling production AI sign-off.

Chapters

FAQs

What is the Unified Context Stack and what problem does it solve?

The Unified Context Stack is a four-layer architecture (L1 through L4) built on top of lakehouse platforms that gives AI agents the structured, governed context they need to move from pilot to production. The layers cover domain ontology, event-driven refresh pipelines, a unified access layer, and an agents plane — addressing the context readiness gaps Cognizant observes as the most common blocker across enterprise deployments.

Why is context readiness more important than model capability for production AI?

Cognizant's experience across customer implementations shows that model capability is no longer the constraint — context quality is the key differentiating factor across all three enterprise scenarios described in this video: moving pilots to production, scaling use cases across domains, and advancing from human-in-the-loop to human-on-the-loop autonomy. Without high-quality, governed context, even the best model produces unreliable results.

What does the L1 domain ontology layer in the Unified Context Stack contain?

The L1 layer establishes a domain ontology and taxonomy as the foundational context layer, defining the business entities, their relationships, and the governance rules that apply to them. This gives AI agents a shared semantic vocabulary to work from, preventing the ambiguity and misinterpretation that cause agents to fail in production.

How does the phased adoption journey work for building an agent-ready context platform?

The journey starts with implementing Metric Views on an existing lakehouse — a step that provides immediate value without a full platform overhaul. Organizations then incrementally add event-driven pipelines, unified access controls, and cross-domain context capabilities, progressing through experimentation, production, and cross-domain autonomy phases over time.

Full transcript

[00:07] First of all, a very good morning to all of you and thank you for being here and attending this uh session today. Um this is Satish Heg, practice leader and uh chief enterprise architect from Cognizant AI and analytics practice. I
[00:20] also have my colleague uh Anal, a chief solutions architect from the same practice. Uh today we are very excited to talk about a very interesting and a popular topic from lakehouse to agent ready
[00:35] context all based on our uh aggregated experience across our customer implementations. Uh so you will see lot of references to the examples and some of our experiences
[00:47] um throughout the journey here. uh in the first part I'm going to talk about some of the challenges faced by our customers in this space and and also we'll touch upon some of the solution
[01:01] components on how to address those challenges along with some architecture examples which we learned from our previous implementations and in the second half anal is going to talk about as an enterprise how should
[01:15] we approach this journey in terms of phase wise right um and also he will talk about some of the best practices and lessons learned from our implementation experience. With that um we will get started.
[01:30] Let me ask you a simple question, right? How many of you in this room have established and set up the lakehouse with the governed pipelines and delivering the data products for your business? Any hands here? Yeah, that's a
[01:45] good u you I'm sure you will find it very relevant and interesting and I'm assuming you are also on the pathway to implement some of the agent use cases. So it will be very relevant in that case.
[01:58] Let me list three scenarios, right? The scenario one is some of our customers have implemented few use cases in pilot and trying to move towards production,
[02:10] right? Scenario two um the some customers have implemented few use cases in production and trying to scale that up uh within the domain or outside the
[02:22] domain um for several use cases. Scenario three is where for customers who already implemented few use cases in production, they are trying to move up in the autonomy chain from human in the
[02:36] loop to human on the loop. Right? One common observation across all these three scenarios is the model capability is no longer the constraint but the
[02:48] context readiness is. Certainly the context quality is the key getting criteria in all these three um scenarios. So if you look at the challenges um
[03:02] across the board right from our customer angle um the the context readiness problem mainly depends on how your data is actually distributed in your enterprise and also where you are in the
[03:15] agentic AI journey. Like if you are in the beginning the kind of problems what you deal is like slightly different but if you are in the middle of the journey the kind of problems what you face is totally different but there are some consistent set of
[03:28] problems every enterprise faces and again our customers also facing similar challenges. So I will highlight some of them here. agents are being built in silo and its
[03:41] own with its own wiring and plumbing to the data sources right and again its own interpretations of the data when a new agent needs to be built again a new interpretation and new wiring new plumbing that's not good right and there
[03:55] is no unified access layer of course and lot of business logic is embedded in system prompts or prompt libraries there is no adherence to ontologies no
[04:07] connections, no relationship established, right? For example, if you take supply chain as an example, you you have lot of um connecting pieces be um
[04:19] planning, sourcing or manufacturing, then logistics, right? After sales support or even if you take manufacturing as in a vertical way, there are quality controls, there are regulation aspects, the demand
[04:32] forecasting, right? um bomb uh all these things need to be connected and related for the agents to reason about else they hallucinate a lot or there is no meaning
[04:44] out of it and even for some of the business concept for example you take in supply chain itself the party if you take as a party right and it can mean a different
[04:56] interpretations depending on the domain what you're dealing with like if it it can be supplier it can be carrier or it can be uh end customer itself. If you move on to the next challenge, it
[05:08] is more of unstructured data underutilization. Right? So the unstructured data is all over the place spread across multimodel complexity is increasing. Customers are facing lot of challenges in extracting the information
[05:20] from the complex documents. Some customers have are stuck at basic rag and whoever have figured out some of the complexities of the rag. We all know that embedding similarity doesn't mean similar semantic similarity. So that's
[05:34] also not helping much. And also in some organizations the the whole knowledge is sitting in people's head. It is not even in a place where you can query it, where you can version it and you can codify it.
[05:48] Then we have a context freshness problem. Right? So agents are operating in seconds whereas your context is getting refreshed in kind of minutes or hours depending on whether it is batch or real time. Then you have a context
[06:02] governance problem where there is no ownership to the context. In some places you the human access is taken care but agent access to the context is still evolving how to set it up and all this stuff. Then cross domain integration cross
[06:15] domain context is altogether a new problem and we have seen some customers in insurance domain right three distinct definitions of policy effective date across underwriting claims finance and so forth that's altogether another
[06:27] challenge so if you I can go on and on but if you look at all these challenges from the diagnosis angle this is what it is right now if you look at this all
[06:40] these challenges from a prescription angle How many of you have are more closer to the enterprise agentic AI architecture at least from an architecture perspective in this room?
[06:54] Good. So you will definitely find this more relevant and this is based on our most recent um implementation experience. Lot of uh uh things are connected here. So you will see lot of components here be it infrastructure
[07:07] agent ops or monitoring observability agent control plane or um uh the agent runtime collaboration plane all these stuff right but if if enterprises are
[07:22] maturing each of these components over a period of time right you can set all these components straight everything fine but the one important thing which is highlighted in red here the engineered context layer. This is the
[07:35] fuel behind this architecture and this is the connecting tissue of this entire architecture. And if you don't set this right, your agents are just flying blind. So which means this is the
[07:47] prescription for all the challenges which I highlighted uh earlier. Right? So let's look into this. We'll zoom in a little bit and then kind of look into some of these components on how to set
[07:59] this up and then how do we approach this right the diagram may look a little complicated but um I will make it very simple right and it it exactly goes in
[08:13] line with whatever you heard in keynote today so lot of things you will feel very relevant right so let's look at this in a more layered way L1 L2 L3 L4 right so I'll make it very simple. L1 is
[08:25] more of enterprise data layer. You have all the structured data spread across RDBMS, ERP systems, unstructured data spread across SharePoint locations or object store and all those stuff. And
[08:37] then on the real time data be telemetric data or grid data and so forth and then external data of course if you have any uh thing right that's enterprise data L1
[08:49] and on top of it like I mentioned you you also might have figured out how to establish the lakehouse with all the govern pipelines data products are getting delivered to your business and you have your semantic layer ready which
[09:01] is AI and sorry for ML and uh BI workloads all these things you would have set it using unity catalog and all the latest and greatest things of data bricks right including metrics views and
[09:13] all those stuff including the declarative pipelines. Now go to the top right you have L4 which is agents plane depending on what domain or what kind of use cases you are
[09:25] trying to uh solve you may have several agents including datab bricks genie agents and depending on what um enterprises you're one you may have some other cloudnative agents or third party
[09:38] agents or open source framework agents but netn net you have some agents where are it is getting they are getting designed and they need context to reason about and from the bottom you have your
[09:50] lakehouse which is ready and data products are getting delivered. This is the situation now right. So now let us look at how to move from lakehouse to the context layer for the agents to
[10:03] consume. Right? So if you look at that blue rectangle that's what we will do some double clicking. So let's start from the extreme left ontology and taxonomy. Right? So I'm assuming um some
[10:16] of you are in the keynote as well. So you will find it very relevant now. Right? So you need to start establishing the ontology and taxonomies depending on what domain and use cases you are dealing with right. So you can inherit
[10:30] some of the pre-built ontologies and taxonomy for the domain and sit with your business team and then um start kind of tuning it or in parallel you could also look at AI assisted um ontologies
[10:43] autogenerated ontologies by crawling into the source metadata. We have an asset called um data nanite uh from cognizant um which does automated ontology discovery by looking into the
[10:55] source elements and again this is based on our recent experience. So if you happen to visit cognizant booth we can even show the demo of that. So netn net you need to establish ontologies and taxonomies.
[11:08] Then you you need to kind of instantiate that a taxonomy and um whatever you have through you already have data products right at the lakehouse level. So
[11:21] leveraging the investments what you have already made on lakehouse and data products start instantiating your knowledge graphs or the domain graphs using those data products. So now you
[11:34] you have your business meaning defined in ontology and taxonomies. You have your data kind of getting connected in domain. So now everything is connected and semantically enriched. Right? The same example whatever I was talking
[11:47] earlier the supply chain example. So think that it is all connected now using the domain graph and a cross domain graph and with the help of extended knowledge catalog and ontologies and
[11:59] taxonomies. Now all your metrics like if I take here as an example lead time right um lead time can mean something different in logistics and something different in uh manufacturing. So since
[12:12] you already established those business semantics now whatever semantic layer you had which was ML and BI ready earlier now it is agent ready that's what is the agent ready semantic layer
[12:25] now with this you have ensured that all these the domain orientation and semantic enrichment is done now you have unstructured data coming whatever in the enterprise layer so start thinking about
[12:39] creating the lexical graph out of those unstructured data embeddings and then start connecting that to your domain graph. In that process, you're connecting structured data and unstructured data and making sure that
[12:51] explicit and implicit relationships are connected. Now make sure that the context is refreshed in real time by bringing the best practices of near realtime sorry um
[13:05] eventdriven um architecture principles and by combining the u principles of realtime streaming and other stuff what you have right so make sure your context is always fresh and it is getting refreshed
[13:19] in real time. Last but not the least, the context lineage. Set it straight. Make sure observability is set up, lineage is set up throughout and trace you are able to have the complete traceability of this layer.
[13:33] We still have not solved one more problem, right? How many of you at least have encountered some of the crossdain related use cases in the agent era?
[13:47] So even if you have not encountered you will you'll encounter this in the future right that is where the industry is moving on. So if it is little bit complicated we are also in the experimentation phase but the idea here
[13:59] is you have to have the enterprise um glossery level you define all these abstract terms in this supply chain example if I take lead time revenue or party all these things define the common
[14:11] uh abstractions at a enterprise level and then for each domain level make sure that you have your alignment registry and have your domain specific definitions and formulas and other stuff
[14:23] right so and have a dotted connection with your enterprise glossery and domain specific alignment registry. Then wherever you need to have the cross-domain linkages start introducing the concept of bridge ontologies and
[14:37] that is where you need to sit with the business and make sure that you very align very well on how to define those bridge ontologies as per your enterprise guidelines and then um start instantiating those bridge ontologies
[14:50] with the domain graphs cross domain graphs basically right and that is where again you need to spend lot of time with the business to ensure that who should get access to that particular cross domain graphs. Um so that's altogether um different exercise you
[15:04] have to go through. Now your whole box right whatever you have that federated context box is domain oriented now it is semantically
[15:16] enriched and it is becoming a enabler for business reasoning from an agent perspective right and in the process you also ensure that the relationship intelligence is established and also the
[15:31] intelligent hybrid retrieval is activated and it is fresh now it is governed and it is real time. So now again look at from the agent plane
[15:44] perspective. The context is ready. Agents are ready to consume the context. So one thing you need to introduce is now the unified context layer which is more of a single point entry for the agents to consume the context which
[15:56] comes with mainly three components. The context router to route it to the right context blocks from an agent perspective. Then you have context fuser which is where you can merge the context if it is coming from different contexts. And then the actual you access layer
[16:10] which is where you can control the access to the agents by enforcing some policies and guardrails and so on so forth. Again alignment to domain contracts. This is actually um very um easy these
[16:26] days because the AI gateway comes with lot of these features handy and then you that is a default starting point for any enterprises to look at from the unified access layer. So you heard in the
[16:38] keynote as well the datab bricks AI gateway right so that is very coming very handy here for you to start with and when it comes to the engineered context layer you heard um Ali talking about
[16:51] um Genie um ontology right so that is something you should definitely start looking into that um and wherever required you can work with data bricks partner components as well and start
[17:03] looking at datab bricks native components as much as possible in in the federated context layer and if at all if it is required look at what data bricks partner components you have to kind of bridge that any other gap you have right
[17:17] so to sum it up the the key takeaway from here is from this diagram is that dotted rectangle the blue colored is the
[17:29] key prescription for all the challenges which we kind of highlighted earlier and that's what is going to make your existing lakehouse the context ready for the agents.
[17:42] With that I will hand it over to uh Anel to talk about some of the uh lessons learned and best practices and also the uh how we should look at it from a phase wise right it's a journey so we have to
[17:54] look at it from a face wise from an enterprise implementation perspective over to you thank you thanks
[18:06] >> okay uh let's talk about data or context readiness u yeah this is this is a burning question that every data team faces in the organization. You spent months or even years building uh data products, governing it through Unity catalog and
[18:20] maybe ongoing data quality related uh monitoring as well. So now if your organization wants to get started on their agent journey right uh the first question is is my data ready for me to
[18:33] get started on agent journey right uh the answer is not straightforward it's much more nuanced u I I've seen teams where they feel like my data is agent ready uh my first question uh to them is
[18:47] like uh a ready in what aspect is it ready for an ai kind of a dashboard or is it ready for say an internal AI assistant or is it ready for any customerf facing autonomous agents
[18:59] that's going to take uh decisions. So the readiness aspect varies for each of these use cases. It's a it's a spectrum right. So the way we see it right u you need to look at data readiness from three different dimensions uh analytics
[19:12] readiness agent readiness and regulatory readiness. Analytics readiness gives you the insight in the form of governed metrics then the data products that you have built some ongoing data quality work and also the semantic layer that
[19:25] you might have built keeping in mind the BI and machine learning uh kind of use cases right and this is mostly a solved problem um the teams have been dealing with this for more than a decade now so
[19:37] this is where I'm assuming most of you are right now and the agent readiness is the new tier just Because we have integrated data into a lakehouse and maybe we have put together a semantic
[19:50] layer with some governed metrics doesn't mean it's ready for AI right think of semantic you can you would see semantic layer both in the analytics readiness and agentic a readiness but it's not the same okay uh the semantic layer that you
[20:03] see in the analytics readiness uh it it it's set up based on it's set up by a user a business user or analyst or a data product owner keeping in mind the kind of metrics that you expect to be
[20:15] seen in the report or a dashboard or you expect an user to play with, right? So up front you know what what kind of answers you need to provide to the users. So it's it it's it's set up keeping that in mind. But with an agent ready semantic layer that layer is
[20:29] supposed to answer questions that the agent is going to come up on its own as part of its reasoning process while it takes some decisions. It's not easy to guess all possible questions or all possible reasoning traces that the agent
[20:41] is going to come up with. Right? So, so what you need to cover in that is ensure you provide the business semantics to the agent of your data universe. Uh, which means you need to ensure that the agent understands what the entities mean
[20:55] in your real life in your business operations. So that's where the ontology, taxonomy, all those things come into picture. And apart from providing the business semantics, if at all you're going to serve an agent which is going to take a decision or an
[21:07] action, right? Uh there's obviously the question in terms of having explanability, traceability, which means that if you pass any data or context to the agent, you should be able to provide a trace of it. uh say regulated team
[21:20] comes to you and saying that I've seen this agent take a decision and I need uh I need to sort of provide that for compliance and if they come to you asking for can you provide the data or the context with which that agent provided or made a decision you should
[21:34] be in a position to provide that decision trace or the context lineage to it. So capabilities like this have to be in place in your data ecosystem for your data to be agent ready. Okay. And
[21:47] finally the regulatory readiness aspect. Uh so you might build any flashy agents in your sandbox or you might even build PCs and pilots showcase it to the business users but it's going to never it's it's never going to see a
[21:59] production environment unless you have these kind of capabilities like context lineage decision traces data audit uh data residency related things and any orc specific or domain specific or industry specific complaints are in
[22:12] place. If if you don't cover these aspects, even if your agents provide outstanding or IB business value capabilities, uh your senior leadership or your complaints team is not going to sign off to put it in production. Right?
[22:24] So bottom line, think of uh think of the readiness as u these three dimensions. Analytics provides you the insight. Uh agent readiness provides you or gives the license to be autonomous. and
[22:37] regulatory readiness is the one that's going to give you the permission to actually deploy your agents in uh production. Okay. Um uh let me take a snap poll here. Uh so how many of you are serving data to a agents within your
[22:50] organization in any form of shape? Maybe you or your team. Okay. Uh keep your hands raised. Uh so say a regulator comes to you and asks like can you show me the data or the context with which the agent took a decision? How many of
[23:03] you think that you would be able to provide that information to the regulator? Okay, I still see some ants. Okay, so uh would you be able to provide that uh information within an hour?
[23:15] No. Okay, see in both these categories, right, uh you are actually not ready for AI because you're not able to provide that complete decision traces. In fact, the first category it's uh less riskier because at least the team knows that
[23:27] they can't provide that decision trace. The second category probably you've instrumented some observability. you think you might be able to provide the addition trace but unless you do that investigation you're not sure whether
[23:39] you can provide that or not that's to me that's even more risky to business uh so bottom line uh before you start serving agents which are going to take autonomous decisions ensure that you set up the parameters across these three
[23:51] dimensions and have some serious conversation within your data team as well as engage with the teams who are going to consume these uh data sets or this information from your platform and then treat it as a checklist test or a
[24:03] benchmark or a road map so that you can you can be sure what you're covering and what you're not covering and for what kind of use cases your data is actually ready. Okay. So let me move on.
[24:16] So we've seen the context layer architecture that Satish presented and uh we briefly discussed on when or how your data would be ready for AI. Uh but knowing is one thing and doing is another right. So these are some of the
[24:30] learnings from our experience, some of the mistakes that we have done and what we have seen some of our customers make in their uh agent journey. I'm not going to walk through each and every one of it. But uh what we have observed is all
[24:42] of these mistakes are a result of three root causes. Root cause one, treating context uh engineering as a one-time activity or more like a project. That's
[24:54] something you take up, you finish it in 6 months and move on. uh that's not how it plays out, right? Uh your your landscapes changes, your industry landscape changes, your customer behavior changes. So it's natural that the context will degrade over time. So
[25:08] it's it's it you have to treat it as a living product, not as a one-time activity. And the second root cause is assuming just because you brought them together in a data product and maybe you
[25:20] moved all your uh documents into a vector store. you've embedded created some vector embeddings and exposed it through an AI search capability doesn't mean the agents can understand your business right so it has to be
[25:33] engineered okay the bottom line the message I'm trying to convey is you have to engineer your context layer in such a way that agent gets the complete understanding of what the data set means in that particular situation within that
[25:46] domain within that business operations and also in the context of with whom it's interacting What I mean by that is say a sales cycle could be different from an accounting cycle within an
[25:58] organization right so the agent say it's dealing with a sales team uh members it should understand when the when the when the team member says a cycle or a financial cycle right it needs to understand that it's dealing with this person as part of this business
[26:11] operations so the cycle actually means a sales cycle not an accounting cycle because accounting cycle and sales cycle could differ right so it's important that you engineer that context layer okay in terms of providing the right ontology, right semantics and what have
[26:25] we covered in the earlier side slide. So, and this is not something you can solve with technology. Uh that's the third root cause. Uh we see people take a tool first or a product first
[26:37] approach. U in our experience based on whatever we have seen in the last 18 months this layer the context engineering layer it's an engineering problem. It's not a product or a platform problem.
[26:49] um even with some of the services that are being announced right now, right? Uh that will help you uh travel much easier but doesn't mean don't let any of these technologies be a black box. Say if
[27:01] there is an ontology service that will build ontology behind the scene. You can't let it be a black box. You have to look at what it's constructing behind the scene and you should have some levers to play with it so that you have control over how you engineer your
[27:14] context layer. Right? So that that's going to be really important and like I think Ali didn't mention see every customer all of your competitors are going to have the same foundation models all of your customers are going to have
[27:26] the same kind of services from data bricks Azure AWS everything right your real mode would be your how you instrument or set up your context engineering layer that's the only way you can differentiate the insights or
[27:38] the intelligence that you generate within your organization so it's important that you engineer don't don't think of it as putting together some Legos so that the context engineering layer would be set upon its own. You you
[27:50] have to be engineering it and you have to be at it, maintaining it and evolving it over time. Okay, maybe I'll do one more uh snap poll here.
[28:04] Okay, so I think I did I did see some raising hands in terms of them serving data to the agents, right? So in your environment, right, raise your hands if you think that you would be able to spot context degradation over time. So raise your hands if you think that
[28:17] say you are serving data to your agents right so do you have have you instrumented in such a way that if a context degrades over time that is something that you monitor as a signal so that's going to be important and uh
[28:30] like Ali mentioned in the earlier one not Ali I think it was someone else uh see the problem here is different like if something goes wrong here in a traditional application it fails right everyone gets no immediately but with an H&TK implementation if something goes
[28:43] wrong if the context X degrades the agent is going to take decisions in a very confident manner with the wrong data right it's it's going to take long time when I say long it could be days or hours depending on your business but the
[28:56] decision is already taken and you have to face that impact so it's important that you set up and instrument your context changing layer in such a way that you monitor uh it should be like a mon
[29:08] signal that you can monitor over time the context degradation should be a signal that you can monitor on a daily bas basis or even on an hourly basis. Okay. So, yeah, let's move on.
[29:22] Yeah. So, now that we have seen all of that, the question is how do I start or where do I start? Right. So, this is a four-phase journey that we typically recommend our customers and think of it
[29:35] as four different kind of answers that you need or your agent forces you to answer. The question one is can you find data right so this is the cheapest fastest and easy to put together uh
[29:47] ensuring that you bring in data from across different systems in your organization into say lakehouse or any data platform and make it discoverable and I'm sure most of you are in this phase already if if at all you're using
[29:59] uh data bricks and the second phase is the enrich phase where you provide that connected meaning to the agents in terms of ontology or agent specific semantic layer and this is the enrichment phase And uh what gets you what what gets you
[30:14] here is with phase one it enables you to get started with experimentation. And with phase two you can start building PC's and useful PC's and pilots and showcase it to your business team. And the third phase is the govern phase. Can
[30:27] we actually trace and trust what the agent is doing? Like I said earlier uh without uh this phase you're not going to get approval from your leadership team or from a complaint team to actually put it in production and serve your customers. So all these three
[30:40] layers or the three phases are critical for any use case. So even if you're serving just your particular department or a domain, it's important you cover all three before you start pushing out your product uh agents to production.
[30:53] And the last one is the route and scale phase uh where we put together a cross domain contract or basically we're trying to link information or the context that you have built for each domain. Okay. And that's where you move from the L2 layer that Satish was
[31:06] showing earlier from L2 layer to L3 layer. And again that's optional. It depends on if at all you have any use case where you need a cross domain context. That's where you get to that stage. And uh if at all there's two
[31:19] things that I want you to take away from this slide is uh start local and build it in an increment incremental fashion. What I mean by start local is focus on your domain first. Don't try to spread too much. Don't try to address or handle
[31:32] cross domain contract before you have a matured domain specific context within your system. Ensure your uh context is well governed monitored and you are able to uh evolve it over time and monitor
[31:45] all the degradation. Ensure it's quite mature for your particular domain before you try to connect cross domain because it's it gets messy if you try to uh sort of share your context across domains
[31:58] when you don't have control of your own context within the domain. So don't get to that stage before you are clear that within your domain you are handling your context in a well matured manner. So yeah so this is again this is like it's
[32:12] not like a prescriptive thing we have seen this kind of a journey help the customers move in a confident mature fashion and experiment with agents but yeah depending on your organizations maybe you might have to tweak this. So yes,
[32:24] >> thank you. Thank you for thanks for attending session. Hope this was useful. >> You can stop by at our booth um Cognizant booth uh in zone 6 and we have lot of interesting demos around ontologies and uh the whole context
[32:37] layer. So we'll be able to have some conversations as well. Please stop by at our booth. >> Thanks for attending. Thank you.

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.