Real-Time Context Engineering for AI With Databricks

Summary

Context engineering—continuously supplying AI agents with refined, low-latency operational data rather than stale batch snapshots—is identified as the critical missing architectural layer for reliable AI in 2026.
Confluent's fully managed streaming platform uses Apache Flink and Kafka, combined with TableFlow to stream data into open table formats, feeding trusted operational data into the Databricks Data and AI platform for agents and AI/BI.
Model Context Protocol (MCP), proposed in November 2024, reached over 97 million SDK downloads in a single month and has become a near-universal standard for tool integration in agentic systems.

Real-Time Context Engineering for AI With Databricks

Just like we don’t put crude oil in a car, we refine it into gasoline. AI can’t run on raw data either. It needs continuous, refined context. Serving fresh context is the missing architectural layer for reliable AI. In this video, learn how Confluent Intelligence and Databricks turn operational data into low-latency context for AI agents and applications. See how Confluent’s fully managed streaming platform feeds trusted data into the Databricks lakehouse for Agent Bricks and AI/BI. We’ll demo real-time architectures for anomaly detection, product personalization, and AI-powered data enrichment, showing how to keep ML models and LLMs grounded in the live state of your business, not stale batch snapshots. You’ll leave with practical, streaming-native patterns to move from brittle pipelines and demos to production-grade AI on Databricks while reducing TCO.
Talk By: Sean Falconer, Head of AI , Confluent ;

Chapters

FAQs

What is context engineering for AI?

Context engineering is the practice of continuously supplying AI agents with accurate, low-latency data from live business systems rather than relying on stale batch-processed snapshots. This video argues it is the missing architectural layer that makes AI agents reliable in production.

How does Confluent work with Databricks for real-time AI context?

Confluent's streaming platform uses Apache Flink and Kafka to process and route operational data, with TableFlow streaming it into open table formats for the Databricks lakehouse. This keeps AI agents and AI/BI models on the Databricks Data and AI platform grounded in the current state of the business.

What is Model Context Protocol (MCP) and why does it matter?

MCP is an open standard first proposed in November 2024 for connecting AI agents to tools and data sources. It rapidly reached over 97 million SDK downloads in a single month and is now being adopted as a near-universal standard by major technology companies.

Why can't AI agents run on raw or stale data?

Just as crude oil must be refined before a car can use it, raw or outdated data degrades agent accuracy and reliability. Agents making real-time decisions need the current state of the world, not data that is hours or days old.

Full transcript

[00:08] So, my name is Sean Falconer. I lead AI or artificial intelligence the AI product team at Confluent. And we're going to be talking about real-time context engineering for AI with Databricks. So, you clearly there's
[00:20] been a lot going on in the world of technology over the last couple years and even in this conference in the last couple of weeks, you know, things are moving at a pace probably certainly in my career uh faster than anything we've ever seen. I would say arguably faster
[00:33] than any other time in human history in terms of the amount of innovation that's happening right now. And it's overwhelming at times. It's also very exciting at times. So, there's a lot to kind of like get through and think about. And if we look back a couple
[00:46] years ago to 2023, 2024, a lot of what we were kind of talking about when it came to AI in particular the data around it was about rag or retrieval augmented generation and vectors and vector
[00:58] databases and so forth. And then that kind of evolved over the last year to 2025. It was really the year of agents and everyone was talking about agents. And certainly that the concept of agents is certainly not going away, but it kind of
[01:12] takes more than just, you know, model innovation and purely essentially raw data serving into models to actually make these things work. It turns out that you also need to kind of understand the meaning behind this data and that's really why I think 2026
[01:26] is a lot about context and context engineering which we're going to talk about. So, I started off by talking about how there's this huge amount of innovation that's going on in the last couple years and the speed is really really staggering and I think one good
[01:39] example of that is with MCP or model context protocol. Um so, this was first uh um proposed as a spec in November of 2024. I remember it very well. I just started
[01:52] at Confluent at the time and I I it would be very interesting. The I thought it was solving kind of a real need that was starting to crop up in in the world of agents at the time, which was around tool fragmentation and so
[02:04] forth. But I don't think, you know, even early believers like like myself or the people at Anthropic could have believed the amount of engagement that I saw in a single year. It went from SPAC to over 97 million downloads of their SDK in a single month during that time. And
[02:17] essentially every major company in the world started adopting MCP as sort of their standard. There's probably no standard in technology history that's ever moved at this pace and kind of became this industry standard. So every company from Databricks to, you know,
[02:30] Confluent, Google, and so forth, or even direct competitors like OpenAI, all adopted MCP. And then I think another example is really around agentic engineering where
[02:42] over the last 6 months or so, the entire developer experience has really transformed for people. If you look a year ago, people were certainly using AI for coding tasks, but it was a lot of kind of like glorified term completion,
[02:55] I would say, where people were using could go from prompt to maybe a minutes or a few hours of work. And now we're really in a era where even the laggards of the of the people kind of denied what
[03:07] was going to happen in terms of the amount of AI-generated code, I think are starting to come around to face the facts that really the future now is not that far away where most code is going to be generated by some sort of AI model
[03:19] in some capacity. And right now we're probably in a world where we can go from prompt to certainly like a day of work or a couple days of work, depending on what it is. And then if you look at the sort of the trend lines of innovation in the space, by the
[03:31] end of the year, we're probably looking at, you know, prompt to maybe a month of work. And it's not always 100% successful and perfect, but it's pretty amazing amount of compression in terms of the hard part of the software
[03:43] development life cycle or the long part of the software development life cycle, which was sort of coding. And now we've compressed that timeline at least from sort of prompt to POC significantly, And I think that has a lot of impact on
[03:55] how we think about, you know, organizing ourselves in the question in as a business. It's made us kind of face, I think, some ask tough questions in our companies about what it means to be an engineer in in this world and so forth.
[04:07] And these are not answers I questions I necessarily have the answers to, but I think they're important questions to ask. Now, despite all the innovation that we've had in sort of the standards model innovation, agentic engineering,
[04:20] when it comes to sort of B2B enterprise AI, a lot of that is kind of lag behind. So, why is that? Well, I think if we look at sort of the two eras or two ways of AI,
[04:32] we can kind of start to understand like why this is a problem. So, broadly speaking, there's been kind of two different ways of AI. We've had classic ML, so these are like statistical models, purpose-built ML.
[04:44] This was kind of what I was trained on in school. And here, the what you would typically do is you go through this offline batch process, and you would use your data to train a model. And then once you were happy with the performance of that model, you deploy it and start
[04:56] using it. And these can work great, and they still work, you know, very effectively today. But the the limitation of the model is that since they're purpose-built, they're kind of built for one thing. So, once I built my model for fraud detection, I can't just turn around and
[05:09] start doing image classification with it. I have to go and train a a completely different model with, you know, different features and so forth to do that. But the the advantage of the models is that since they're trained on your data, they know a lot about your business.
[05:21] Essentially, there is a representation of your business baked into the weights of the model. And these foundation models that power generative AI and agentic AI have this opposite set of characteristics, where
[05:33] there's huge massive models that have been trained on a lot of general information, and they can be used for kind of infinitely many things, which is amazing, and that's I think what has led to this, you know, boom in interest and
[05:46] innovation around AI. but the disadvantage of the models is that as smart as they are about general information, they're kind of dumb about your business because they don't they weren't trained on that information. So, the job to be done
[05:59] is during prompt time assembly when uh I'm about to call essentially the API for the LLM, I need to as a business go and get that data from somewhere. I need to go and deliver the right data at the right time.
[06:11] And in enterprise business, this is kind of a hard problem because there's a lot of messy infrastructure data infrastructure when it comes to enterprise businesses. You have hundreds, maybe thousands of different sources of information, and this has
[06:23] always been a problem, but in the world of maybe business intelligence and so forth, we kind of learned to live with that problem to some degree. And I think in the world of AI, this becomes something that is really a non-starter, and this is what
[06:35] really prevents essentially a lot of businesses from going from, you know, demos and POCs, that part's kind of easy, but then we have this huge production gap. And it's because we can build these things in isolation, and they work great
[06:49] with, you know, sort of mock data, but then when it comes to actually deploying them, being able to give that contextualized data that's specific to the business, that makes that business who they are, becomes a really, really hard problem to
[07:02] solve. And this is kind of what brings us to the context engineering area that we're going to talk about now. So, a couple years ago, a lot of what we were talking about when it came to instructions into models was this kind
[07:14] of notion of a prompt of prompt engineering. And prompt engineering is really sort of in a one-shot, one-call to the API, how do I give a set of instructions to get a result that I want? And this kind of was dominated the
[07:26] conversation in terms of instruction sets into models in, you know, 2022 to maybe early 2024, and now has given way to sort of context engineering. But, in prompt engineering, what you had to do back then, besides giving set of
[07:39] instructions for uh sort of one-shot instances of API, is the models are not as good as they are today. So you also learn the kind of how to manipulate different models depending on the type of model and what you want to get out of
[07:51] them. So you knew that with certain models if I structure the input in a certain way, use certain tags for whatever reason the attention mechanism would really result in a better outcome. And as the models have become more sophisticated we haven't really needed
[08:04] to do this quite so much. Now context engineering has really come out of the space of agents. And what exactly is an agent? Well if you trust or listen to Anthropic essentially
[08:16] their definition of an agent is an LLM calling a you know tools in the loop. I personally prefer the the idea that an agent is really software with agency. So almost all software that we've created through history or interacted with has
[08:29] followed essentially a deterministic control logic where I pre-program everything that's going to happen in the software. So someone clicks on a button, something happens that has been pre-programmed in the software. So no real dynamic to the software itself. And
[08:43] with agents what I'm doing instead is I'm giving essentially a goal to the software. And then the software is using this powerful reasoning model, the foundation models, and a bunch of resources and tools that are available to it. And it's
[08:56] going to essentially try to figure out how to accomplish that goal. It's very similar to how you know you might interact with an employee where I can go to an employee and I can say the goal is I want you to figure out what
[09:08] our competitive strategy is for next year. And then that person's going to use their you know powerful reasoning model in their head and whatever tools and resources they have available to them to figure out what that strategy is and then come back with some sort of report
[09:21] and maybe ask questions along the way. And that's really the dream of what we're trying to accomplish with agents is we can essentially give this thing a goal and then it'll act somewhat autonomously given the resources it has available to figure out
[09:33] how to accomplish that goal. Now actually making that work is harder, but it sounds great. So, what goes into the context? You could think of context as like a structured document. It where it has
[09:45] certain sort of segments. So, we have a system prompt. This typically specifies what the role is that you want the the agent or the model to take on. So, this could be something like you're really, you know, great customer support agent
[09:57] that's very good at writing emails or something like that. Then you have tools. So, these are what your actions, APIs, functions are available for the LLM to call.
[10:10] You have documents. So, these are typically things that you might pre-fetch or dynamically fetch from, say, a vector database or something like that. So, all the stuff in terms of prompt engineering, vectors, and so forth doesn't go away. It's all just essentially subsets or components of
[10:23] what we're talking about here. Then you have user messages. We typically, you know, people typically think of user messages human-generated inputs to a model in like a chat interface, but suddenly doesn't have to be that. It could be another agent
[10:35] calling this agent, some sort of external event that's essentially going in to the model. So, we have a collection of these. Then we have things like the assistant
[10:47] messages. So, these are what is the output essentially from the model? The AI output. And then we have tool calls and results. So, when I call a tool, I'm going to get some sort of response from the API or whatever it is I'm calling, and now I need to have that
[11:00] part of my context as well. Now, a number of these things grow over time. Oh. It's wide bug here. There we go. So, we have user messages, we have tool calls, we have assistant messages. These things
[11:12] tend to grow, and they grow, and they grow, and they grow. So, the job essentially of context engineering is how do I manage this information environment as essentially the context grows. I don't have infinite context. I don't have infinite tokens I
[11:24] can feed in. How do I manage that information environment so I can deliver essentially the minimal set of information into the model that gets with the outcome that I want. And that's the job to be done. So, we don't have infinite tokens and even
[11:36] if we did, as the token window increases, it's not necessarily ideal to just stuff it full of everything that we have because just like a person, there's only so much attention to go around in the model. So, if I gave you, you know,
[11:49] a thousand of us a thousand things to do, you're probably not going to remember all thousand. You might remember only a couple and they may not be the couple that I think are the most important. And it's very similar to if I give the model essentially all the context I have in the business and I
[12:01] tell it to solve some sort of problem, it might end up paying attention to it's going to pay attention to something, but it might not be the thing that I want it to pay attention to. So, I have to optimize this information environment. All right. So, how do we do this? Well, there's a couple, you know,
[12:14] things that we think about when it comes to context engineering. One is we drive up reliability by managing this context window limits. All essentially models degrade as we expose them to more tokens. This is a phenomenon known as
[12:27] token rot. So, we want to drive up accuracy by essentially giving the right amount of information, not all the information. And then we also, by optimizing this information environment, we can also help optimize
[12:40] for things like cost and latency as well. Cuz the more things that we give it, essentially the more compute time that we're going to spend and obviously there's a ingress cost to that in terms of the number of tokens that we're sending into the model.
[12:56] Now, in terms of a couple, you know, tips to think about is with the system prompt, so, this is the, you know, precise set of instructions that we're giving. There's kind of a Goldilocks principle when it comes to the system prompt where we don't want to give too little of
[13:09] information, but we also don't want to give like a, I don't know, entire instruction manual as well. And ideally, I should be able to give that system prompt to a person and they should be able to follow it. And if they can't follow it, if a person cannot follow it, then the model certainly is not going to
[13:22] be able to follow it. And then when it comes to tools, even the best models in the world tend to start to have problems when the number of tools available grow above
[13:34] somewhere between 40 and 80 depending on the types of tools that we're talking about. And that continues to grow, but it's not like an exponential thing. I don't think it's going to go from 80 to 800 uh next year. Of course, I'll be back here next year and you'll tell me how wrong I was. But uh even if it does,
[13:48] essentially, you still have to really manage essentially the number of tools and then also how do you differentiate them? Cuz if you have a lot of tools that kind of look similar, then it's going to look similar to the model and the model is sometimes going to call the wrong thing.
[14:00] Data retrieval, so we're going to talk a lot about this, but this is essentially how much data do we preload and where do we get it? Or how do or the data we dynamically fetch depending on what it is that we're trying to accomplish?
[14:13] So that's the the challenge in the enterprise of like I got to navigate this messy infrastructure. How do I do that? And then finally, there's long horizon optimizations that we can do. So over time, the context is going to grow and
[14:25] at some point, as it grows, I'm going to run out of tokens. So how do I compress it? And there's different compaction techniques. I can drop messages uh over time if I'm I'm doing a certain amount of runs uh or or loops, you know, maybe certain things that happen earlier
[14:38] in the life cycle are no longer important I can drop from essentially this message history. All right, so let's talk about the data retrieval piece. Since we only have so much time. So how do we actually curate context when it comes to data retrieval?
[14:50] Now, there's a couple different things that we need to think about here. And the first thing is just to think about like what are we trying to accomplish when it comes to AI or reasoning? So if we go
[15:02] back all the way to the very beginnings of when people started thinking about AI, Alan Turing in like the 1930s with you know, thinking machines and so forth. What we've always been trying to accomplish essentially is to sort of
[15:14] mimic or recreate some human level of ability. And whether that's solving puzzles or different problems or playing games, generating text, whatever it is. Essentially, we were trying to mimic
[15:26] some something that we consider, you know, human-level intelligence. So, what goes into our sort of information environment about how we make decisions and reasoning? Well, we take a, you know, simple example of like crossing the street.
[15:39] Probably everybody in this room has successfully crossed the street probably thousands of times in your life. And you were taught as a child, you know, look both ways and all these types of things. So, we have a lot of history and pattern recognition with how to accomplish this, you know, reasonably
[15:52] simple task. But there's other things that also are taken into account besides the history of how we accomplish this. Because if I was to cross a busy street like this, based only on a still snapshot of where
[16:05] the cars were yesterday, it'd be hard for me to accomplish that task in a reliable way. I would probably be a little bit nervous about crossing the street. Even though I have all this history with it. So, I need not only history and
[16:18] pattern recognition, these are of course important, but I also need to know what's going on in the moment essentially. What is the current state of things? And I think that this is the part that is really difficult for a lot of businesses and a part of our business from like a data
[16:31] infrastructure standpoint that we've tended to underserve for decades now. But if I have an agent that's helping provide recommendations about patient care in a hospital to doctors and nurses, and the last temperature reading
[16:44] from a patient was 6 hours ago, it's going to be hard for that agent to be trusted with that kind of task. So, this is something that we have to solve. Because without it, essentially we leads to this context problem. You can
[16:57] imagine that bottom thing that looks weird is an arrow pointing from context to the prompt time assembly. But essentially, during prompt time assembly, I need to go and gather this data. And as we talked about, that is a hard
[17:09] problem in the enterprise just because the data is everywhere. So, how do we solve this? Well, there's a couple different ways that people have thought about solving this problem. So, the first thing I can do is I can go back to, you know, MCP where we started talking about things and I can kind of
[17:22] MCP-ify everything. And this can help in terms of now I've created MCP entry points into, you know, whatever my sources of truth are. But you can imagine in the enterprise
[17:34] that this also creates new challenges where from a security perspective I now opened up like a lot huge surface area to try to cover. Like how do I control access to all these hundreds or thousands of
[17:46] different locations in certain in a reasonable way. I've also have a lot of tools that in in services that I need to try to navigate and as we talked about the models struggle with that once it reaches a certain scale.
[17:59] And then I've also given direct access to a lot of things that were probably not resourced from a infrastructure standpoint with AI in mind. So, if I have some some legacy
[18:11] database or mainframe or whatever it is, it's probably not provisioned for a thousand agents to start hammering it in an uncontrolled way. I need to offload that in some way. And then probably the biggest problem is
[18:23] that none of these systems were really designed for AI consumption in mind. So, if I take some SaaS application that and I'm calling the API, that API was designed for an engineer to read the API spec, interpret, map into their specific
[18:37] data model, drop what they don't need, map it to their business requirements, and write code around it to be successful. They're essentially contextualizing that data is a part of that process. And the models have not done that work. So, throwing a bunch of
[18:49] raw data generally doesn't lead to the outcomes that we want. What we really want is refined or derived data. It's a little bit like we don't put crude oil in a car. Crude oil goes through a refinement process to create
[19:01] gasoline and we need a gas powered car to create gasoline and that becomes the fuel situation like the car go. And we have to do the same thing with AI where we need to take raw data, create essentially sort of purposeful or
[19:13] refined derived data sets and that becomes the fuel to make the AI go. So, where do we go to get derived data? Well, what about batch processing? So, if we think about how we've typically
[19:25] moved data from like our operational systems into our analytical systems, we've typically done that in batch through ETL or ELT and so forth. So, we're moving this kind of left to right into the data lake and then we're going
[19:38] to go through a cleanup process and create essentially these derived data sets through maybe like a medallion architecture or something like that. And that's how we create these data products in our data lake or warehouse that powers like our analytics.
[19:51] Now, this solves the problem of now we have essentially this derived data, but it introduces new problems where a lot of times it's hard to make these systems fast. Essentially, the data is only as up to date as your slowest pipeline.
[20:04] And then it's also hard to make these things stable because the downstream system doesn't have control essentially of the operational state. So, if the data model changes in the upstream, it breaks the consumers downstream and that leads to essentially
[20:17] unstable pipelines as well. So, we have potentially stability problems and also slowness of delivery of that data. So, we need to try to address this problem.
[20:30] And if we don't do that, it's hard to solve for use cases like this. So, I talked about the, you know, patient monitoring and recommendation in the hospital. This is a simple one. I just actually came back from from Spain a couple of days ago and rebooking flights is a common
[20:43] experience these days. So, if I'm trying to rebook a flight through an agent, the agent obviously needs to know about what flights are available right now and also what seats are available or it's not going to be able this very effectively.
[20:58] So, what about streaming? So, there's a couple things when we think about streaming that are useful. So, a lot of operational data goes through streams today. Technology like Kafka, for example, really serves the as one of the
[21:10] primary messaging and channels within the operational state and also even for moving data down into our analytical state. So, it's very good essentially where databases represent essentially a
[21:22] fixed data. We're moving data in and then it's kind of waiting to be queried. Kafka really represents change data. So, when changes happen essentially in our operational systems, we're capturing that. So, it's good for capturing state
[21:34] change. And we need to capture state change in order to understand what's happening in the business right now. So, that's great in terms of representing what is happening currently in the business. And then technology like Flink or some
[21:46] sort of stream processing technology is very good at essentially allowing us to connect and refine the data essentially run compute over the stream to create what we call universal data
[21:58] products directly within the operational state. And then deliver those data products in different ways. But we need some way of essentially serving that data. So, we can we Ideally, we need to unify essentially streaming data
[22:12] capture, stream processing, and context serving ideally under sort of one service. Cuz then, by bringing all these things together, we can also manage the the changes that happen where the upstream data model changes, how do we
[22:24] manage that in the downstream? Well, if the downstream is essentially part of all this in one one process, we can handle those types of changes that happen gracefully. So, this gives us derived data that represents kind of current state of the business.
[22:41] Now, at Confluent, we've been working on some version of this kind of idea for a long time, for you know, over a decade, through something we call a data streaming platform. So, with a data streaming platform, really the idea is how do we move some of the concepts of
[22:55] the data product earlier in the lifecycle of data? And it's very similar to the movement that we've taken with things like testing or security. So, 20 years ago when I started my career as an engineer, you know, I didn't write tests. I wrote
[23:07] code and then I threw that code over a fence to another group that QA'd it and tested it and then they would, you know, find my bugs and send it back to me. And then it would go back and forth and then over time, we've actually shifted the
[23:19] responsibility of writing tests to the people writing the code as well. So, why is that? Well, it's because the people who are writing the code essentially are in a better position to understand the types of tests that they would actually need to write to effectively test that
[23:32] code because they wrote it, they have the context. And I think it's very similar to when the way that we have to think about data as well is the team that's generating that data is in a better position to understand how do I clean it, normalize it, how do I kind of define and contextualize that data. So,
[23:46] if we can move some of that process earlier in the life cycle, then we can create these universal data products to not only power analytics, but also power applications in a such way eventually. So, that's the idea. And
[23:58] at Confluent, we have a a product called TableFlow that lets you do this essentially within open table format. So, you can take this concept, this change data that exists in a Kafka stream and essentially turn it into a
[24:11] table structure so that you can then query it in a sort of familiar way through SQL, through open table formats like Delta Lake, as well as Iceberg. And then it's not just the movement of the data, but it's also
[24:24] essentially synchronizing the schema and essentially the metadata around it cuz that's also a challenge with typical ETLs we kind of we drop a lot of the schema part of it because we don't want to deal with the breaking changes and then we kind of reverse engineer the
[24:36] schema as part of the clean up process. Now, TableFlow's good at moving the data essentially into our data lake, but it doesn't quite solve the problem of those
[24:50] upstream changes as well as some of the challenges around actually delivering this data fast enough for a lot of operational use cases in AI. So, what we did to try to fix that problem was we launched a product called Real-time Context Engine,
[25:03] which really is the unification of streaming data capture, stream processing, and then context serving. So, essentially you can turn your stream into a fully managed database table, which then continuously gets updated and
[25:16] and re-indexed by the stream, and then you can query at through natural language. And of course, this doesn't replace something like Databricks where you're going to run, you know, far more sophisticated
[25:28] analytical operations, but it can essentially be the bridge to the delta of what's happening in the operational state versus what you might have in the lakehouse.
[25:40] All right, so we just a couple of sort of use cases that we we've uh you know done with customers here. One in particular is with a real estate agent so that a real estate SaaS. This is one of the largest real estate SaaS companies in the United States. And what
[25:52] they're built is a lease audit agent, where they have property managers essentially come in and they use agents to help them understand uh you know uh uh lease cycles as well as monitor all the IoT devices and sensors and things
[26:05] like that that might exist in the properties, and essentially help provide guidance up to them using these agents. Uh and and there is really important for them to kind of understand like what is sort of the current operational estate
[26:17] of the properties that they're looking at. Aviation, we talked about sort of flight booking agent. We need to understand what flights are available now, what seats are available, and so forth. And then of course, banking is a big area as well where we're looking at things like fraud,
[26:30] client journey, uh um you know, um managing of transcripts and so forth. It's really about how do we compress essentially the time from the generation of some sort of information to when we can actually do something about it. And the longer the delay,
[26:43] typically the higher the cost to the business. All right, and then last thing before we kind of get into a demo here is a couple of uh references. Focal is an interesting one where
[26:55] they actually use camera feeds to monitor inventory systems in in real time. So, you think of like a retailer, maybe it's a Walmart or something like that, they're going to use camera feeds to actually monitor what's happening on the shelves and understand when to
[27:07] restock those. They're using essentially the streaming data capture over those camera feeds to understand when changes are happening and then do the processing directly on the stream to understand when they need to restock the shelves
[27:19] and stuff. Uh uh very very interesting and obviously does um uh drove up accuracy and significantly compresses the time from when that thing is happening, like inventory is getting
[27:31] low, to the business actually understanding that it's a problem and then being able to react to it. All right, so let's get into a demo here. Start to make some of this stuff real. So, as I mentioned, I was in uh Spain uh this last weekend at the actually at the
[27:44] Formula 1 event. Confluent is a Formula 1 sponsor for the Racing Bulls team, which is the the second Red Bull team. And they are also a customer of Confluent. So, some of the things that are
[27:56] interesting about this is as sophisticated as these cars are, obviously from like an engine like a just like a mechanical standpoint, they're also essentially traveling supercomputers. So, they have over 300 sensors on these cars with generating
[28:10] over a million data points every second of telemetry data. And there's also a lot of other data that they're taking into account in terms of where the other drivers are on the track, even things like weather conditions. There's a lot of inputs essentially they're taking
[28:22] into account. And they actually deploy our data streaming platform directly in the pit and then they use something called cluster linking to create a bidirectional feed to the R&D department as well as their headquarters. So, everybody kind of has all this data
[28:35] simultaneously. And this demo that we're going to talk about is not exactly what they're doing, but it was kind of inspired from some of the stuff that they're doing. So, I talked a little bit about how it's really important in a lot of businesses to kind of compress the time from when
[28:49] some important event happens to us learning about it and us being able to do something about it. And there's probably no better example of this than something like driving race cars because they're driving at 360 km an hour and it's
[29:02] extremely competitive. They're all looking essentially for an edge over each other. So it's all about optimizing as much stuff as they can from the car to the driver's performance to all the stuff that's happening in R&D. So that's kind of what we're we're going to look at here. So the idea is we're going to
[29:15] use AI to essentially create a pit recommendation agent. So there's a couple different things happening here. It's it's kind of a simplified view of what the Racing Bulls team might be doing for real. We have at the top there
[29:29] we're capturing through CDC of a Postgres database all the driver race history. So this is all the drivers, the position, you know, where they finished, where they started, what strategies they used. And we're simply moving that data
[29:41] into Databricks through Table Flow. So as I mentioned, we're turning that into essentially a Kafka stream, Table Flow materializes it into a Delta Lake table, and then we can query it directly within Databricks. Below that we have our car telemetry
[29:54] data. So as these cars are driving around, they're throwing off tons and tons of telemetry data and we're capturing that essentially and removing that into a stream. And then we're combining that with the race standings that we're pulling from
[30:06] AccuWeather. So this gives us the current positions of all the other drivers in the race beyond just like what we know about our current driver. We're taking these two streams, we're joining them. And then we're using anomaly detection to detect when things
[30:19] are going wrong with the car, like a a temperature reading on a tire spikes to a certain level or we're seeing brake degradation or something like that to indicate uh a change in the car state. And then we're going to use this car state as a trigger for an agent that's
[30:34] essentially going to go and investigate what this problem is and make a recommendation to the driver and the and the team about what to do next. And then all those pit decisions also flow in the table flow for uh sorry uh through table flow into data bricks where we can
[30:47] investigate this later. So, that's the idea, all right? So, we're going to take a quick look at a demo of this. And I'll explain it along the way. So, here we have this is Confluent Cloud and we're going to just going to go and take a look at our topics here. So, here
[30:59] we have our uh race standings, we have our car telemetry data. So, our race standings, as I mentioned, are just essentially all the data about our drivers, where they are right now, what their positions are.
[31:12] And uh you know, what pit stops they've had, you know, uh and so on. So, we're going to take that data and we're going to essentially enable that with the real-time context engine. So, what this does is it turns essentially that data, instantly
[31:24] materializes it into a fully managed database table, where the query operations are exposed through MCP so that any AI agent or application can essentially query this data directly uh in a low-latency way, they'll do various
[31:36] point point-in-time lookups. Next thing we're going to do, now that we have this context, is we're going to define our agent that's actually going to do our pit strategy. So, within Confluent, agents are
[31:48] first-class citizens, so I simply define their goal, the role, the model they're using, the tools they have available, and I can run them natively within the screen. And this these concept these are essentially event-driven agents, so they're triggered by changes in the in
[32:01] the business state. And this is going to be all sort of always-on, always processing. And we obviously don't want the agent just reacting to raw telemetry data. So, we're going to enrich the stream you
[32:14] through DBT, combining essentially the car telemetry data with the driver standings and the information that we have about the drivers. This way we get enriched data, and we're going to use anomaly detection to check those spikes. All right, so now we have our car state
[32:26] topic, so this is being uh uh a representation of changes essentially in the car state. So, temperature readings change, um brake degradation, and so on. So, we can here see here, if we take an example, we're on lap 32 right now. We
[32:40] have not pitted the We haven't taken the car into a pit stop. And and we look here, for the first time in the race on lap 32, we've actually seen a spike in tire temperature. So, this triggers anomaly detection, which fires
[32:53] our agent. The agent investigates that anomaly, realizes that we're on 32 laps, we haven't we haven't uh taken the car in for a pit stop, we're losing positions, and recommends essentially box now, switch to mediums, and race to
[33:07] the finish. So, that's the idea. And now, what we're going to do, once this finishes running, is we're going to go over to Databricks. So, we moved all this data into the data Databricks, where we can use Genie AI to
[33:20] also explore this data using natural language. So, I can ask, you know, how many positions have we gained, you know, following the agent's pit recommendation strategy? And here, we can see Genie AI converts that into a SQL statement, runs
[33:32] it against the data, takes the raw data, reinterprets it into language, and tells me that we've gained 11 positions over the last four races, including two wins in Bahrain and Spain. So, pretty good
[33:44] ROI for this you know, AI agent essentially that's making these recommendations. So, and then we can continue to explore this data. I can ask about, you know, which tire strategies are performing best. But, really, the key unlock here is that
[33:57] by combination of of of tools that give essentially our AI systems access to this continuously refreshed contextual data that really represents the current state of the business, it opens up all
[34:10] kinds of possibilities. You know, we're talking about racing here, but for essentially any business, where R&D departments can leverage Databricks to really explore and analyze this data, while essentially the pit crew can
[34:22] leverage essentially the real-time data to be able to make recommendations, and compress that time from an event happening to them actually being able to do something about it. All right. So, if you want to check out any of this stuff, you can try out the
[34:35] real-time context engine for free there on the QR code or at the URL. And then also, you can talk to Confluent or IBM at the various booths at 510,
[34:47] 537. And then I think we do have Yes, we have 5 minutes. If people want to ask questions if anybody has questions, there's a microphones there. Uh and also happy to take questions one-on-one after the call. But, hey,
[34:59] let's see.

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.