Keynote: Building Intelligent Systems on Real-time Data

In a world without data streaming, you might be waiting a while for that rideshare. And that flight the agent booked you on?

It left 20 minutes ago.

But don't worry, your bank will catch the fraudulent purchases on your account eventually.

Maybe.

Try not to think about it. At work, you'd still be getting 3 AM alerts when the infrastructure breaks and having to listen to your CEO talk about digital transformation in the morning because all your data is frozen here. Or at least it was. That's the world without data streaming. That's the world without you and you and you and all of us. The pioneers who transformed the world we live in today with real-time data and who are already building the world we'll live in tomorrow. Real-time AI agents, instant analytics, unprecedented customer experiences. A world that's faster, smarter, frankly, it's just better. That's the world we'll continue to build together. Welcome to Current 2025.

Please welcome CEO and co-founder of Confluent, Jay Kreps. Hey everyone, welcome to Current. I'm really excited about this. This is our first time in New Orleans and it's a really awesome city to host this. I hope everybody got a chance to get out there and see a little bit of the city yesterday. If not, hopefully in the next few days. We're gonna do all the fun stuff. We'll have some deep dives in Kafka, in Flink. We'll have some great product announcements. You know, really this is one of the few times you can get these communities together. To talk about what they're working on, what they're building. Always, you know, the sessions are great, but the hallway conversations are even better. And so I, you know, I think we have a great lineup for today and tomorrow. I'm gonna be talking today about something that I think is on all of our minds, which is, you know, the, the rise of AI and how do we build intelligent systems, how do we connect those into the software states that exist in our organizations today? I'm gonna connect that into the world of data streaming and real-time data and agents that take action on that. But to set this up, I wanna start and just talk a little bit about where we're at right now. You know, I, I think there's a sense in which we're kind of moving out of a world of business intelligence and into a world of AI. And what do I mean by that? I mean, you know, if you ask an organization, What does it mean to be data driven? The answer to that question would've changed. You know, if you asked that question 10 years ago, I think it would've been about, hey, how can we get all the data into our lakehouse, into our warehouse? How can we be really smart in the reporting and analytics? How can we arm our data scientists to address the right questions for our executives? That's, that's what it would mean to have good business intelligence. That's what it would've meant to be data-driven at that time. But if we think about what it means today, that's changing and it's changing in a way where it's no longer about just deriving insights from data. It's about taking action. It's about being able to build systems that actually act on behalf of the business in software that kind of close the loop in what we're doing. And that's the age that we're moving into. And in a sense, this is nothing new. You know, we think about the software systems that we've been building, you know, probably for the last 5 years. A lot of them are doing this in some sense, right? They're, they're trying to be smarter, they're trying to harness data to take action on behalf of the customer. They're trying to personalize things and make better customer experiences. Uh, so there's a sense in which, you know, this is not different, but there's a sense I think in which it's really different, right? Ultimately, AI systems are a really different world and it's, it's easy enough to use Claude or ChatGPT and ask it some questions and get an answer. It's actually a lot harder to build something that's a concoction of traditional code along with AI that actually takes over some business process that automates some part of a big at-scale business and does this in a way that's high quality enough that it actually works, that it can actually go to production and, and actually fulfill its goal. And part of the reason this is so hard is the paradigm is actually completely different, right? If we think about how things have changed, the biggest difference is that traditional software is ultimately a bunch of hardcoded rules. You know, it's a pile of logic and we've gotten incredibly good at crafting this logic, packaging it up, abstracting it away, coming up with modules and systems of isolating parts of this that we can support these these fantastically complicated, uh, piles of business logic. But at the end of the day, when you think about, uh, AI and AI-based systems, it's really not that. You're not programming it in the same way. You're not specifying it in the same way. It's a little bit more like you're guiding it with data. You're, you're pushing it in a certain direction, but ultimately it's a probabilistic system, right? It, the output is not precisely specified, or at least the output that we're looking for. And you know, this shows up in a really fundamental way when you think about how you develop and validate these systems. In traditional software, you can reason about the correctness of your application without any reference to the underlying data. You know, you can write a set of unit tests that cover the different cases. If that unit test coverage is good enough, You expect 100% to pass even though maybe all you're plugging in is just, you know, lorem ipsum, just some fake data that you, that you're validating on. And this is really different from an AI system. At the end of the day, if you're building an AI system that's gonna support your customers, there's no sense in which you could say that that system works if you haven't tried it on real customer issues with the real data that would've been available to a real support person who would've helped that customer. If you haven't tried that, there's no amount of looking at your logic or the workflow or specifications or anything like that, that would say that the system actually does what it's supposed to do. And so fundamentally, the world of evaluation goes from being primarily about checking logic to now checking this combination of model, logic, and data all together in real interaction and checking it against the metric, which is not exact. It's not gonna be 100% perfect. You're gonna have a set of evals that tell you you're better, you're, you're 90%, you're 95%, you're improving. You know, it, it's much more a statistical notion of correctness. And really importantly, your development cycle is now very tied to the real data that you use. In some sense, in, you know, traditional software, the business logic is king. That's really everything, right? The data is just something that lives in production that you're gonna go use. In these AI systems, ultimately the data, and particularly the context data, is the fundamental thing. That's how you're guiding the model. That's what it has to go off of. And making that really good is, is your ticket to making this, uh, actually effective. So how, how can you build, uh, effective systems in this world? What are the important problems that we have to solve? If this is different in some way, how do we have to adapt what we're doing? Well, I'll talk about some aspects of this. So, you know, I mentioned that this was ultimately about context data and this is, you know, this is a really important part of the problem. If you think about the success of these systems, the two things that are gonna matter in terms of the quality of the output are the model and the context data that it has, right? And I'll tell you one of those things you have a lot of control over, right? The models are being developed by a relatively small set of companies that are taking that forward. You can always upgrade to the next best one, but your ability to advance that state of the art is not that high. The context data that is spread all across the organization that you wanna harness for these problems, that's where you can iteratively make things better. That's how you can take a system from 90% of good enough to, to 100% of good enough. That's how you can actually make, take a system from demo to production is by getting that right. So getting really good at this is key to this area. And when you ask how, how can you really harness context data? Yeah, I think people start with a, you know, basic intuition that kind of makes sense. When we think about context data for models, there's something called the Model Context Protocol. And if we hooked up the systems we had to, to an agent, it should be able to then get the context data that it needs. So in some sense, the naive approach here would be let's go put MCP in front of all the systems we have. We'll, we'll give the agent kind of the login to all of our databases and SaaS systems. And we'll say, okay, you, you figure it out, you know, go make sense of this mess. And anybody who's tried this knows that it doesn't quite work. That's not actually quite how it works, right? That's not gonna get you the result that you're looking for. And the problem here isn't MCP. MCP is great. Um, but MCP is just a way of accessing, uh, a system. It doesn't actually fix what's in the system. It doesn't actually curate that in a way that's useful for decision making. and so the, you know, ultimately the data that we're accessing is the thing that's a problem. So what, what goes wrong if you try and do this? Well, there's, there's a set of challenges. I mean, the obvious one is you're connecting this new agent into a bunch of systems where you're gonna generate operational load and workloads it wasn't really built for, but that's not even the real problem. The, the bigger problem is about access control, right? Ultimately, if I'm serving customer A, it can't be the case that there's any probability, no matter how small, that I'm gonna leak data from customer B or that it's gonna have access to things that it shouldn't. All of the control of data has to be there. And ultimately a lot of the data that we have in the existing applications and systems is hidden behind bad APIs or it's very much tied to obscure inner details of our applications. You know, what does it mean when this column has code 4? I don't know, but you probably have to go check some enum in the code base to really make any sense of that. And it's not like models intuitively understand the meaning of for any more than humans do, right? At the end of the day, you have to have the full context to be able to make a decision. So when you think about harnessing this data, you're ultimately gonna have to build a useful data set. You're gonna have some kind of data pipeline that takes data out of the production environments, does some kind of transformation on it, builds it into the appropriate context that an agent may need to act and serves it back up on demand. You know, this is ultimately the pattern that, that's gonna be really important. There may be some things where you can just hook it up with MCP, but the most common thing you're gonna have is working on this context data. And th— this is commonly called context engineering. This, this idea of refining processing data from different systems, preparing it for use in an agent. So how can we do this? How can we make this really effective? If this is the key for us to be successful with AI is really mastering context data, how can we do it well? Well, the, the obvious place to start would be how do we build these data pipelines elsewhere in the organization? And the answer there is, is commonly batch processing. You know, a really simple way to start would be go to the data warehouse or lakehouse. There's a bunch of data sitting there. Build out a set of processing steps and prepare that data, you know, for access by the AI. And, you know, we're, we're actually quite successful at this, you know, as part of our analytics flows. You know, a fair amount of rich processing goes into preparing data for analysis. So we might end up with an architecture kind of like this, you know, some, something in your lake house or warehouse where you're kind of running a set of iterative processing steps. and then the output of that you might upload to some kind of live serving database where it could serve live queries from the agent. So what's the problem with this? Well, you know, first of all, there, there's some good things. I mean, we're actually quite agile at working with batch data. We can be quite iterative. So in a sense, we've solved this problem of being able to grab new ingredients, refine them, make them better. That development workflow is actually pretty good. But when it comes to taking it to production, it gets a little bit harder. You know, first of all, we have this somewhat tenuous integration with the live serving system where we're uploading big batches of changes all at once and hopefully not knocking that system over. And anybody who's built that kind of, uh, reprocessing and indexing pipeline knows that can be a little bit squirrely, but that's not even the big problem, right? The, the big problem is ultimately this data is getting processed in batch. You know, best case we're talking maybe 4 hours later, we, we know what the state of things are. More likely it's tomorrow. And you know, for feeding context to a system that's gonna be making real-time decisions, it's gonna be interacting as part of the business, this is a complete non-starter. You're gonna get totally wrong answers. Um, you know, you could use the analogy, of, you know, if you were gonna cross the street, uh, a busy street, would you be willing to do that if all you had access to was a photo of where the cars were yesterday? And the answer is no, that would be a very dangerous proposition. But ultimately, if you have some software system that's gonna be interacting with the real state of your business right now, then doing that off some snapshot of data is not gonna be good enough for, for hardly any use cases. That matter, the where the consequences are important. So you're ultimately gonna have to move this into something that is real time, something where the context data is in sync. So how, how can you do it? Well, we're here at Current, so you know, part of the answer is gonna be streaming data, right? There's no, no surprise there, but, but it's not as easy as just, okay, change it all to stream processing. There's some things you have to do right to make this productive, right? And, and so the architecture can be something like this where you have streaming data capture, you know, some, something like Kafka or Kafka Connect, stream processing, something like Flink, some, some way of serving this up. But there's a few things we're gonna have to do well to make this actually productive. So first of all, I talked about the fact that iterating on this data was really key to our productivity, that we had to have a whole evaluation loop around it. And I said that one of the things that was really good in the lakehouse was that this batch processing was really productive for development. I could actually try different ingredients, create a dataset, throw it away, try it a different way. You know, I could actually iterate really effectively. And so it's gonna be really important that we preserve that. And you know, in order to do that, you need to have a conception of this stream processing that's, that's broader than many people all, often have. It's not gonna be enough to just have something that you can string together that processes the data of right now. It's gonna have to be able to process the historical data and the real-time data together. Yeah, I'm gonna need something that's, you know, not a specialized system, but kind of a generalization of batch processing where I can build my program and have it, uh, run, uh, offline against a test dataset, evaluate that, and then have it run continuously as it goes to production to create a continuously fresh data set that I'm gonna use. So, uh, what do I need to do to accomplish this? Well, this is something we've been working on at Confluent. I think there's two critical ingredients. You know, first at the data layer, I have to unify batch and streaming, and we've been doing this with what we call Tableflow. And this is a way of taking the real-time streams of data that are coming in Kafka and be able to continuously populate and represent that as open, uh, data tables in cloud object storage using, uh, standards like Iceberg or Delta so that you have a historical data set as of a point in time as well as the real-time flow of changes. And these two are not just two distinct systems but are actually linked. You understand the point in time across these systems you can process seamlessly between the two things. When you've done this, you, you now have the ability to build systems that process history and then go on and, and start processing the real-time stream that, that are, you know, effective in batch but also effective in real-time. And on top of that, you have to actually do this in the processing layer. And this is something that Flink brings, this ability to build a program, you know, with a particular set of logic in SQL or programming language, run that offline as a batch process, be able to iterate on that, try out different things to get it right, and then have it run in a streaming fashion and be able to go back and do that over and over and over again. 'Cause that's ultimately gonna be our development cycle. That's gonna be the iteration loop by which we make our system better. So if we put these two things together, we can have effective streaming pipelines that actually make this, you know, easy to use in development in the way that our batch system was, able to produce real-time data, which is gonna be essential for agents. So we've really made a substantial step forward on the first part of this data supply chain. But what about, what about the last step? So I said it's not that easy to strap the real-time serving onto the data lake. Is it any easier if you're strapping it onto a stream processing system? The answer is not really, right? We're gonna have a continuous flow of updates coming out of our streaming, but every time we go back and reprocess things to improve our context data, we're gonna have a big batch load. It's gonna be relatively hard to keep these two things in sync. It's gonna be hard to avoid disrupting these real-time queries that are looking up the right bits of context at the right time. And we're gonna have a set of problems, right? There's gonna be operational problems about the load that we're creating. There's gonna be data model problems of just matching thing A to thing B, carrying the security model through. We're ultimately balancing across two distinct systems that we have to somehow keep in sync. And very often these live serving systems are just not built to take the volume of batch updates that come from real, you know, reprocessing of data. And they're often impacted by the real-time load of streaming updates. So how, how could we make this easier? Ideally, we shouldn't have to think about this last step at all. It should be just like an implementation detail that as we've created this new dataset, it's somehow ready to serve. You know, how, how could we accomplish that? Well, you know, we've effectively accomplished something like this with Tableflow where you have, you know, a flow of real-time data from Kafka. You may have processing on that in Flink and then it lands in a table. That's structured where you could query it, uh, do things with it. What's, what's the problem with these Tableflow tables that are in Iceberg and Delta? Well, there's only one problem, which is they're slow. They're, they're pretty slow. They're high throughput, they're scalable, but they're a little bit slow. And so how can we speed this up? If we could somehow speed this up, we could actually support fast queries off this materialized dataset and we could do that in a way that was well integrated. And in fact, this is very possible, right? Rather than strapping on a completely separate database, we, we could, you know, maintain a fast cache of this data. And instead of just waiting until it flows out into the Parquet files, we could keep an optimized index that's kept in sync and we could have a fast path for queries that avoids, you know, the, the full processing runtime of Flink and actually does, you know, fast analytics or lookups against this dataset. And if we did this, we could have access for things that were indexed this way with milliseconds instead of multiple seconds. And, and that would allow us to have, you know, two representations of this data without all the overhead of having to load back and forth and manage these processes between two distinct systems. And you know, th— this concept of building materialized views in stream processing is, is not a new one, but this makes it, I think, a lot easier to do. And so we're excited today to be announcing early access to our real-time context engine. And what this does is it takes the streams of data in Kafka, allows you to process and reprocess them, and then provides, uh, access to the resulting data in a fast, low-latency model, which is exposed via MCP and which can be plugged into any agent or AI system built in any framework you like, like anything that works with MCP will plug into this data and have access to it. And you can iterate on that data, evolve it, make it better, and keep it in sync, uh, over on the streaming side and serve it up in real time. That's right. That's right. And so, you know, if you're interested in this, this is in early access. There's a QR code. You can read more about it. I think ultimately this is a very powerful pattern, this ability to do, you know, streaming data capture, stream processing, create a new dataset, be able to iterate on that in batch and then take it out to production and have that dataset evolve in real time, be able to serve real-time queries against it. It's useful for these workloads around AI and AI agents, but if you have the query capabilities, it's actually useful for a lot. Of use cases. Building and maintaining these kind of materialized views is useful for analytics. It's useful for populating derived caches. It's useful for observability. We're just getting started. You know, what we have right now is pretty simple queries with good performance. We, we would love to expand that to richer sets of queries with fantastic performance across a wide range of use cases. And this is something that we're actively working on. So this, this is a little bit about our steps on, you know, how to build context data for agents. But there, there's another problem we have to solve, which is how do we actually build the agents themselves? We talked a little bit about this integration of batch and streaming that, you know, in this development model for AI, I'm kind of working in batch offline until I get something that passes all my evals and seems good enough. I'm kind of deploying it in, into production where it's gonna run continuously, and I want to have similar evaluation of performance coming off of it. Um, I need to do that for my context data, but ideally I would like to do it for the whole system, the data plus the agent plus everything together. So how can I do that? Well, this is where it gets more complicated because when people say agent, there's a bunch of things that they mean. I mean, sometimes they don't even know what they mean. But, you know, some people are talking about something that is effectively clicking on things on a computer. Some people are talking about a chatbot that maybe has some background, you know, actions it can take. I'm gonna be talking about, you know, actually automating business tasks, taking some workflow that happens in a company and automating it, you know, with AI. So this, this is kind of the definition that I'm focused on. When we talk about this next section, which is building streaming agents. So agents that tap into the events that are happening in the business and react to what's there. So, you know, this could be something where a sale occurs and there's a fulfillment process that the agent should take on and orchestrate parts of. Could be something where an insurance claim is filed and part of that processing flow has steps where the AI is gonna take over aspects of. Aspects of that. A support ticket is lodged, you want to actually process some of that. So, you know, this is building agents that kind of work in the background and take over some chunk of business activity. And to do this, we can use, you know, very much the same thing I described for context data, the ability to, uh, plug something into the streaming model, run it on historical data sets till we get it right, launch it into a streaming, uh, world where it runs continuously. And the architecture for this is, is actually quite simp— simple, right? You, you have, uh, an agent built in Flink. It has access to an LLM. The kind of resulting logic is gonna be in your Flink code. The LLM is going to be actually orchestrating a lot of the decisions. Um, the events coming in, you can tap into and respond to. The actions going out are gonna be another stream of events. Of what you're deciding. This is actually a really powerful model. One of the reasons it's powerful is because I can run it offline and have it not just, you know, make side effects in production, but actually produce this output stream of events. And I can evaluate that like a dataset. It makes it really easy to score it. And so this idea of streaming agents, we've written more about this. This is something we've been developing with customers. There's a blog post for this as well. This is out in open preview. You can use this in Confluent Cloud in our Flink service. Check it out and you can see more about that. So I've talked about context data for agents. I've talked about building these streaming agents. There's one more thing, which, you know, for all this talk of AI, you know, sometimes we forget about the good old-fashioned machine learning and, You might think, well, that stuff's like so old, it's been around for, you know, multiple years. Uh, but, but sometimes the old stuff is actually pretty good. And you know, it's true that these older machine learning algorithms, they don't have the power or the generality that, uh, modern foundation models have, but they do have, uh, a couple of advantages. One, they're really fast. Two, they're comparatively extremely cheap. To operate. And both of those things are good, especially if you're dealing with high volume data. And there's a lot of areas which are just a little bit outta reach on the cost frontier with, with more agentic AI foundation models. And so this same model that I described for plugging LLMs into streaming agents, and this works with traditional ML algorithms as well. And we're adding some of these, we've We started with one of the things that makes the most sense for streaming data, which is anomaly detection, forecasting, fraud detection, anything where you're looking at a pattern and looking for any perturbations or abnormalities. This is something that, you know, effectively all our customers have in their problem set, you know, detecting network outages, you know, monitoring business activities. Looking at purchasing behavior, return behavior, stock trading systems. And so there's a set of, you know, auto-fitting ARIMA models that we've built into Flink. They're incredibly easy to use. You don't need a team of data scientists to fit it. It will just adjust to the stream that it sees and tell you what's out of the normal range, what is the normal range, what would you expect to see next. You can plug these directly into your systems. And for those interested in this, there's another QR code, you can check this out as well. So I've talked, I've talked about 3 capabilities here, you know, the context data, the streaming agents, traditional machine learning models. Uh, to give us an easy way to talk about it, we wrapped all these together and gave it a name. Uh, we're calling this Confluent Intelligence, and these are 3 tracks that, that we're doing a lot of development on.

Thank you.

Thank you. And so we're, we're really excited about this area. Each of these pieces of functionality kind of standalone and can be used independently. You know, you can use this context engine to build derived datasets to feed any model you like in any framework you like. You can also use it to feed context data into streaming agents if you like that run inside of Flink. You can also hook this together with these machine learning functions, which I'll show you a little bit of how this fits together. This is a common pattern we've seen with customers where, you know, you can actually link these things. You have some stream of business events coming in, you can detect anomalies on this. So, you know, maybe this is some operational aspect of the business. I wanna see if it's working well. If I see something unusual, then I wanna say, aha, I don't recognize that, that looks wrong. but when I do that, usually what happens, it's gonna go to some human and they, they get a notification to go look into it. So wouldn't it be more helpful if I had the agent do that first pass of work first, take the anomaly, dive in, try and figure out what's going on and give kind of a first draft diagnosis, maybe a proposed remediation, or maybe just fix it if it can. Um, and so that you could hook that up as the next stage in this pipeline. Pipeline, you know, keying off of the anomaly events. And of course, if I want to provide that agent that's doing this analysis some kind of context data, I could feed it with this context engine. So, you could actually use all of these parts together as well as separately. And so, you know, I, I think this is a really exciting area. I think ultimately, if we think about our industry, when we think about using data, harnessing data, What are the systems and foundations we need for that? I do think we're kind of moving out of a world where the most sophisticated use of data was about business intelligence. It was about insights, it was about reporting, it was about analysis. We're moving into a world where the most sophisticated use of data is about taking action. It's about the things that happen in your production applications that happen in that world. And to harness data in that world, you ultimately need a real-time streaming foundation. And so we're really excited about what that means for the world of streaming and really excited about what this is gonna open up, you know, in all of our customers and all of their use cases. And to dive a little bit deeper into this, I'm excited to, to welcome a really important partner of ours from Anthropic. So Anthropic, as many know, is a company really leading the way on developing the most cutting-edge foundation models. Uh, many of you have probably used their product as part of your coding workflows. Uh, if you've used Cloud Code, um, you know, fantastic work that they've been doing and they've been doing it, I think, in, you know, a very safe and responsible way. And so I'm really excited to welcome to the stage for a conversation on these topics, uh, Sean Falconer, our product leader for AI. And Rachel Lowe, the head of Applied AI from Anthropic. So Sean and Rachel, uh, welcome. Really looking forward to what you have to say, and thank you all very much.

Well, Rachel, welcome to New Orleans. Welcome to Current. Thank you so much for being here.

Thank you for having me.

Yeah. So there is a ton of big questions in the world of AI right now. A lot of unknowns, unknowns might say.

Yes.

Uh, you know, when is AGI coming?

Mm-hmm.

When are we gonna have transformers? And I, I don't mean transformer models. I'm talking about like Optimus Prime.

Yes.

Bumping my car into a robot.

Yeah. I like mumblebee too.

Yes. So big questions. So I've been thinking a lot about you're trapped on stage with me. What is the big question I can ask you? And I think the thing that I settled on, which not only impacts me but impacts everybody in this room, you've been to New Orleans a number of times.

I have.

Where do I go to find the best beignets?

That is a hard-hitting question. I don't want to polarize this this audience here, as I'm also personally have my own affinities. And so I feel like we should ask someone that's much more neutral. So why don't we ask Claude? Okay. So let's see. I love that it's already pulling up the classic Café du Monde we all love. I've got a lot of local recommendations here. Very exciting list. But the thing is, I need this tomorrow morning with my coffee at 8 AM. I don't have time today, unfortunately. And so let's see if it is able to give me a slightly better recommendation based off of these parameters. I, of course, know that I cannot leave New Orleans without a beignet. Oh, a lot of specificity, some timing here. All right, so I think you all will see me at Canal Street Café Beignet tomorrow morning. Right.

Well, amazing. Hopefully that helped everyone here. But as smart as, you know, Claude is, yeah. Imagine if it actually was sort of knew what was going on in the business right now. You know, what are the, what's the queue look like? What are the inventory levels at the particular café? So they don't show up and oh my God, the beignets are gone.

No one wants that.

Yeah, exactly. So if we could connect actually Claude to sort of having awareness about, the moment and we'd be able to operate it sort of with the same awareness that the business would be able to operate in.

Yeah.

Wouldn't that be amazing?

Pretty powerful.

Mm-hmm.

So the— Jay talked a lot about this idea of intelligent systems, you know, not only learning from history, but being able to sort of act in the moment.

Yeah.

And in your customer conversations, like how is this idea kind of showing up with them and How are they thinking about navigating, you know, maybe the next, you know, year or so?

Yeah, it, it's a really important question. I think it's actually a question that we get from our customers quite a bit. I think before I look forward in the next year of what's going to happen, it's important to also recognize where we are right now. I think if we just even look at the conversations that we were having around AI a year ago, it was really the chatbot era, I like to call it. And even in the last 6 months, I think we were really focused based on just this very linear input to output. Yes, there is a bit of an LLM feedback loop there, but it was very, um, it was single step.

Yeah.

And we need to see and recognize that models have significantly evolved, um, even in just the last couple of months. We recently released Sana 4.5, Haiku 4.5 for the faster, more like daily tasks. And I think that that's where it's become incredibly powerful to be able to build more and multilayer agentic architecture. Um, and I think that's really what we're having that conversation with more and more enterprises where they're no longer thinking about it as like a single experiment and they're not thinking about it in more of like a sandbox within a portion of their company. They're really looking across all of their different lines of businesses and thinking about where can I embed AI in here so this becomes a more agentic workflow and so that all of the different teams that I have within my company are more expansive. And I think that's a significant shift that is really exciting. Jay's talking about, exciting that we're talking about right now. I mean, I think that that'll significantly help us think more about the future and power of AI as being tied to context. And that is gonna be very critical across the different lines of businesses that companies need.

Yeah, absolutely. I mean, I think context might be the word of the day here. Yeah. You know, context data is king. It really seems to be the key for productionizing these AI systems. So I guess like, what does that actually mean in practice? What are the challenges that these, you know, your customers face with actually bringing their enterprise data to power a system like Claude?

Yeah, absolutely. Um, there, first of all, there, there is the first step of recognizing that there is this shift. I think like, again, moving out of the eras of the chatbot, We really wanna move to these multi-layer agentic architectures that I keep talking about. But what does that actually mean? It's essentially thinking through a system that can reason, plan, and act so that we have this team of harmonious agents that are working together. Um, but again, like when I talk to companies and kind of prompt them to think about what context they have, they, they think of that more as just like context engineering. Um, but it's so much more than that. I think it's, it's really thinking about the overall business-specific data that they have and not just thinking about it in terms of like what do they assume is data oftentimes in more structured places, but thinking through like what is critical to my particular business from both a structured and an unstructured standpoint. And then I think the second piece really is that it's easier than ever to build an agent. I think Jay made that very, very clear just now for, for us. At Anthropic, we're leveraging a number of different pieces to be able to make that easier for enterprises from the Agents SDK or Cloud Developer Platform. These are scalable building blocks for all of you to be able to start thinking about embedding AI more easily. We're also thinking about how to be able to have more context-specific evals that go into every single model evolution. Really exciting, cool story. One of our customers customers actually created their own coding language in just in the last couple of months. Of course, Claude, Sonnet 3.7 didn't have awareness of that, and we built that into our LRL environment and allowed Claude to really be pre-trained that way before Sonnet 4.5. And that I think now allows us to make much more intelligent models. Mm-hmm. But no matter how intelligent the model is, if we don't have all of the data architecture that's available, it's much more difficult for businesses to be able to build these powerful agents. And so while building the agent is becoming easier now, it's the data foundation that is a critical piece of the conversation.

Mm-hmm.

Right.

And then when you are working with these customers, like, how are, I guess, like, your most innovative customers, like the ones that are either getting this right or maybe they're on the cusp of getting this right, like, what are they doing essentially to unlock that data and how does real-time data play a role?

Yeah, absolutely. I think our most sophisticated customers, um, are recognizing, like I was saying, that first of all, the foundation is really key, but there's also a lot of relationships and patterns and nuance within data that we often forget. And that's kind of what I was referencing when I was saying that there's this need for both structured and unstructured data. Structured data I think is pretty clear. We all know where that is. But I think when you're looking at how much AI can really empower each of your teams, you need to focus on how are your teams actually working. That could be Slack, Teams, whichever, you know, team you decide to go for. It can be for email, for calendaring. It can be a lot of the ways and the systems that your teams are interacting. That unstructured data actually has a lot of information that is extremely relevant to Claude or any frontier model. And that's really where we need to recognize that that's real time data tied to all of the historical context and data that we also need. And that feeds into a more context-aware agent. That tying that together is, is really extremely powerful. I already mentioned Agents SDK, which is a more universal, easier way to build generic agents across a number of different lines of business, not just coding, which I think is one that we've jumped so quickly to. And that really allows us to harness the power of Claude, right? Because again, models are becoming wildly more intelligent, but they're also able to perform tasks on a much longer horizon. We were just testing— we have this game that's like Claude plays software engineer, which is a very exciting internal game. Everyone knows that Claude's played Pokémon. A lot of fun things that we play around with at Anthropic, and Claude can actually do so for 30 hours. I'm pretty sure Claude time of 30 hours is not even Rachel's time of 30 hours, probably like 6 months of my time. Yeah. And being able to tie that together, especially in the greater ecosystem of MCP where it has access to that real-time data, allows us to again build that context that allows the agent to be able to reason and execute much more efficiently in a multi-way layer agentic architecture.

Mm-hmm.

Yeah. And you mentioned MCP. I'm sure that's a huge topic of conversation.

It's a huge topic.

Definitely a big conversation at Confluent as well. Something we're very excited about. And as Jay mentioned, we just announced our fully managed MCP server today for a real-time context engine. I guess like, how do you see real-time and sort of MCP fitting in together with the broader data and AI ecosystem?

Yeah, first of all, congratulations. That's really, really exciting. Um, I think we're excited to be able to see that announcement ourselves at Anthropic. I think we love to call it MCP. Tech loves abbreviations. I think when we are slowing down and just talking about the Model Context Protocol, something that Anthropic released about a year and a half ago that is now globally leveraged, which is really, I think, exciting for us because for us we really care about how models retrieve and reason a bunch of different sources of external data and how that streams into that particular model. It also, I think, something that we forget is that MCP allows AI to be able to stay extremely accurate, not just from a real-time standpoint, but from that historical level that we were talking about before, and ensures that it's grounded in really relevant information. I've been talking a lot about how AI has become incredibly more intelligent, um, and there's a lot of power in that, but how do you make sure that it is contextually relevant? And that's, I think, where, um, we're seeing seeing that shift to much more operational use cases being born. And I think MCP is absolutely the key there. And I think together, you know, especially with release from Confluent, it allows all of this live context streams directly into Claude, or I suppose other frontier models, to be able to power the agents itself. And that I think is a really magnificent partnership.

Yeah, absolutely. So I guess You know, we're running out of time, but before we wrap, what is your sort of one prediction for enterprise AI going into 2026?

Yes, um, I would love to predict transformers. I have mentioned that Bumblebee is my favorite, but unfortunately in San Francisco we just have Waymo. Though I won't be— I don't know what's going to happen on, um, that side of the fence. But I would say when I'm thinking specifically about enterprise AI, I don't think that we're going to be having dialogues like this anymore. I genuinely think that, um, we're gonna get to the place where a lot of enterprises, a lot of businesses are going to understand that context is king. And so that data architecture layer, that foundation is gonna be where we're going to build all of our houses, AKA agents. Um, and so the question really more now is how can you start building today? Because I do think if not, a lot of us will be playing catch up later. And that's how I'm encouraging quite a quite a bit of our customers. And so what I would really encourage everyone to think about is look at all of the different teams that you work with or your own team in particular. I definitely am encouraging my own team to think about it this way as well and think about all of the very amorphous problems that you have that have a lot of variables in it and have a lot of different data streams feeding into that that creates quite a bit of just like unknown and think about like how you can better connect all of that into real-time data tied to any of the historical patterns that you'll also need. And think about building an agent there. Think about how to be able to have a better agentic workflow. As I was saying, it is never easier to build an agent. And that's where I think that in a year we'll really be able to move away from this conversation of accuracy like, are we actually operationally accurate when it comes to building with AI and actually into like meaningful expansion? That's where I think the power unlock is, is really being able to expand each of us in a much more meaningful way.

Well, awesome. Thank you so much for being here. We're really excited about our partnership with Anthropic and all the things that we're gonna do together. Next, I want you all to hear from our customers, Marriott and Metronome, on their data streaming AI journey. Journey. Thank you so much.

Thank you.

Please welcome VP Vice President of Application Development and Architecture at Marriott International, Rajesh Kandasamy.

Good morning, everyone. I'm very excited to be here with you all. I'm Rajesh Kandasamy, Vice President at Marriott. I manage entire data streaming and also lead customer domain, which includes identity, access management, and profile management, serving over 248 million members across globe. Today I will share how data modernization behind Marriott Bonvoy Elevates the guest experience from shop to book to stay. We at Marriott been in the business since 1927. We started our journey as a root beer stand in Washington, D.C. From that small beginning, we grew to 9,600 properties. 30+ brands in 144 countries. Our vision is to become world favorite travel company and not just being a hospitality leader. You probably know Marriott Bonvoy, our loyalty program. If any of you are not member yet, please let us know. We will be very happy to sign you up for— Delivering your customer loyalty is a high-stakes business for Marriott because 70% of the revenue comes from the most loyal and valuable customers like you. Our customers have high expectations on us to know who you are, what is your need, and optimal ways to engage you. So having customer data real-time is key to our success, and data streaming becomes a critical part of our business. Imagine you are a traveler who loves to plan your trip last minute, like me. When you make the reservation, within 24 hours of your Arrival. We get your reservation, understand you and your preferences. You may like that extra towel or that special wine for your occasion. We get all the relevant data from multiple systems, enrich the data, and make the data as mature data product and deliver that to the property in real time. Our associates in property prepare well in advance to welcome you and to provide the best experiences you deserve during your stay. In the past, this used to be a fragmented experience because our batch process took from 24 to 48 hours to deliver. The most valuable data. Let me take a step back. You are familiar with this. We had this spaghetti complex point-to-point integration architecture. Even a simple, even a simple schema change was a big deal because our reservation system integrates to 20 to 30 different integration points. And data moving from point A to B to C introduced the lack of auditability and data redundancy all over, which you all familiar with. So we embark our data streaming journey by introducing our first ever Kafka platform and we quickly moved into Confluent platform and to the Confluent Cloud. Which powers our business today. Today we have this simple and flexible architecture built for a scale. By moving to Confluent Cloud, our engineers are no more spending their valuable time managing a cluster or upgrading a platform. Instead, they love developing products, tools, real-time analytics using Flink, and advancing our governance by securing our PI data using CSFLE. That enabled our platform as a self-services capability to developer and business communities. Because of that, we have 900 critical business transactions and 2,000+ consumers are consuming those data in real time, which could not be possible in the past. At Marriott, our core products are what you see in the property. Examples, room, spa, and golf. And emerging products comes from the partnership. Our co-brand cards, airline partnership, Uber, Starbucks, and we have 100+ partnership across the globe. Our Bonvoy members are not just earning points. They earn points while they're taking a ride on Uber, or having a sip of coffee in the Starbucks. Previously, any partner integration used to take 6 to 9 months. Too slow for our growth. By introducing data streaming and using connector ecosystems and enabling all our API as a self-service capability, We brought the time down to 6 weeks. Yes, you hear 6 weeks. Amazing. That this technology can help when business and technology moves together. We are in the tail end of the biggest digital and technology transformation in Marriott history. From the beginning, we had one simple architectural principles. No surprise, every data has to be real-time. And I am so excited what the transformation can bring to our guests, to our associates, and to the property owner in the next chapter. Before I close, let me leave with 3 key takeaways. Number 1, make your business-critical transaction real-time and operationalize them. Number 2, once you have that real-time data, enrich it, make the data as more mature data product using technology like Flink. Number 3, apply AI on top of that to provide hyper-personalized experience to the most valuable customer. And I've not done it. This one is very close to my heart. Develop ecosystems and tools for your developer and business communities. When you empower them, they are gonna make you look good today and in the future. Marriott data streaming journey has become core part of who we are, and I would like to take this moment to thank Confluent for their amazing partnership throughout this journey. And I would like to thank all of you for driving this community forward. Together, we are not just streaming data, we are streaming trust at scale. Thank you so much for listening to us today.

Please welcome Chief Technology Officer at Metronome, Cosmo Wolf.

Hey all, I'm Cosmo, the CTO of Metronome, and I'm super excited to be here to talk about the confluence Confluent Metronome journey for two reasons. The first reason is Confluent is a big customer of Metronomes, which means if you've ever gotten an invoice from Confluent, which I imagine most of you have, or you've logged into your Confluent account to check your usage or your spend, or you've taken advantage of the Confluent Cloud free trial, those are all experiences that have been powered in some ways by the Metronomes monetization infrastructure. But the second reason I'm excited to be here, which is even more important, is it's not an exaggeration to say that con— Metronome would not exist without streaming data, and thus without Kafka and without Confluent. And I want to explain why that is. But first, let's talk a teeny bit about what Metronome does. Metronome builds monetization infrastructure, which is to say We build the tools and the APIs and the infrastructure that allow you to collect value and monetize your product. And we do that for some of the fastest moving and most innovative software companies in existence, including many companies which you use or know day to day, including Confluent, like I already mentioned, OpenAI, Anthropic, Databricks, DataStax, and many more. Metronome is powering the core monetization for for all of these companies. And monetization has been changing a lot recently. 10 or 15 years ago, it was not uncommon to be able to build a billion-dollar company off of a simple subscription, or a seat, or like simple license monetization model. But that is changing. That world is over. Today, how you monetize is a core part of your product. And almost every company is experimenting consumption-based billing, hybrid models, credits, prepaid commits, and other more complex monetization strategies. And even in the most competitive markets, we're seeing more novel approaches like outcome-based pricing or dynamic pricing. And all of these are real-time data challenges because if your, if your billing is now flexible, and can no longer sit downstream of your product, if user spend can change minute to minute, hour by hour, day by day, users will demand more visibility into your spend. So you, they will seek out products with better spend visibility and controls that they have access to, and they need those controls to be real-time. And on top of spend controls, if you're rolling out flexible pricing, you might need entitlements like Confluence free trial I already mentioned, or OpenAI's free credits when you sign up. And those entitlements require timely gating so you can cut users off once they've used their allocated amount of whatever product you are selling with the entitlement. And if you're selling some sort of consumption-based product, you need to protect yourself from fraudulent usage, especially in low margin businesses. Like AI or infrasaaS. So you wanna make sure you can cut users off when they've used more of the product than they have paid for and wait for them to re-up so you're not losing money on fraudulent usage. And on top of all of that, the rest of the business, like go-to-market and finance, needs frequent up-to-date visibility into spend so that they can do their jobs, upselling, closing the books, intervening and course-correcting customers who are using more more or less than you expected, et cetera. And this means every company now has to become a real-time data company. And this is basically what Metronome has built. We're a real-time observability system, but for your revenue data. So our customers are streaming in events as they occur in their systems, thing like user signed up, or API inference occurred, or broker minute occurred, or bytes sent or received or stored. They're streaming that data into Metronome in real time. And then we are computing their revenue and financial data based on complex pricing and packaging. Things like what is the business model, how much do the products cost, what is the product catalog? And then we are streaming them back real-time visibility, control, and insights into their revenue data. And this is a difficult problem. In the classic kind of streaming iron triangle, normally you could give up one of correctness, availability, or latency. You, maybe you decide, you know, I want to be a highly available, very low latency product, but I don't need to be exactly correct. I could do at least once or at most once delivery, or maybe you want very, very correct, highly available, processes, but you can give up a little bit of latency and run a slower process to, to error correct or whatnot. But at Metronome, we can't sacrifice any of those three. We have to run a highly available, incredibly low latency, and exactly end-to-end correct transactional observability system. And we have to run that at extreme scale. We're currently doing hundreds of billions of events all with sub-second latency, feeding into compute hundreds of millions of invoices per day. And again, all of this end-to-end has to be 100% accurate because we are a financial product and we're still a startup. We have less than 150 total employees now, and we got started, we only had 3 engineers, but we still needed to solve those problems on day one. Our product wouldn't have worked without that core data streaming architecture. And that's what Confluent enabled for us. From the very beginning, we were able to build a production-grade, real-time financial platform with a truly tiny team. And then over the past years, we've been able to scale that with a lean team to be truly world-scale infrastructure that we operate today. And looking ahead, You are all going to need to solve the same problems. Less nimble companies are always outcompeted by faster moving companies. And I would guess every one of your companies in the audience is thinking about how to incorporate AI into your products, or if you're not, your competitors are, and you will feel the competitive pressure to evolve your pricing and packaging because you are in the same market with companies that are. Which means you're gonna have to become a real-time data and a real-time monetization company whether you like it or not. And this is what Confluent and Metronome exists to help you with, so you can focus on building your product and not on building the core monetization and data systems in-house. And me and some people from the Metronome team are here all week, and if you have any questions, about anything real-time, whether it be monetization or otherwise, please come find us. We'd be happy to chat. And thank you, Confluent, for having me here to talk about our story.

Please welcome Chief Product Officer of Confluent, Sean Clowes.

Alrighty.

Well, a big thank you to Anthropic, Metronome, and Marriott. What a tremendous set of use cases. You know, I think that our partner Anthropic said it best when they said that without real-time data, there really is no practical production AI. And you saw that validated through some real-world proof. You heard about the data streaming platform powering AI for real-time billing for digital natives and for powering really intimate guest experiences at the largest hotel brand in the world. But we see those same benefits play out at our almost 6,000 customers all over the world, and we want those benefits for you in whatever projects you are currently working on in whatever industry you are in. Our mission for you is actually really simple. We wanna make streaming ubiquitous, get all of your data moving from the simplest application to the AI agents that are transforming your business. And once streaming is ubiquitous, we can find a better way to build. We can shift governing and processing left, closer towards the source, do that work once, and then reuse the data to power our AI agents, our analytics, and our real-time customer experiences. Stream once, use everywhere. But today, instead of telling you how, we'd like to show you how through a series of different demos. We're going to take a look at a really traditional, interesting streaming use case— ridesharing. But given that we're here in New Orleans, the Big Easy, as they say, let's make this a little bit fun. Yep, we're doing it. We're doing it. So where— thank you. Thank you. Yeah. We're going to be looking at the data streaming platform at River Robotaxi. They're a startup specializing in, you guessed it, autonomous riverboat taxis on the Mississippi. Now, they're getting really popular here in the South. And they're looking to use AI to optimize vessel routing, staffing, and logistics around surges in demand, often around large events. Think things like when the Saints are playing in town, Mardi Gras, or even events like this one, Current, here at the convention center. Now, this, like I said, this is a really interesting streaming use case because we have to receive a lot of real-time information. We have to recognize that there is a surge in demand, we have to analyze what is causing that and then respond by rerouting, uh, vessels to, to meet that demand. Now we're gonna show you how the data streaming platform lets River unleash streaming for every use case, cost effectively, all the way across their business. And then they can power their AI agents, applications, and experiences with governed, processed, trustworthy, real-time data. And by the time we're done, the data mess that plagues organizations like River, and maybe some of you, will be a thing of the past. Now, let's start with that first step, streaming. Now, given we are here at Current, I'm not going to need to explain to all of you that streaming is the living, beating heart of the data streaming platform, and that's all thanks to Apache Kafka. The energy in this community has never been higher. You, this community, is the reason that Kafka has gone from being a niche data technology to being a foundational part of the way modern applications and indeed businesses are built. Today, over 150,000 organizations use Kafka, and there are more than 1,800 Kafka meetups all over the world, and Kafka itself keeps getting better and better. Earlier this year, the Kafka community celebrated a really major milestone with the release of Apache Kafka 4.0. And yet time has marched on, and we've also already seen the release of Apache Kafka 4.1. These have been some of the biggest releases the Kafka community has ever seen. We've completed the migration from ZooKeeper to Kraft. In fact, soon there will be no supported version of Kafka that works with ZooKeeper. We've also seen dramatic improvements to consumer rebalancing to make it simpler and faster so that your applications are just better and more reliable. But the Kafka community has been cooking up something really big, and so I'm excited to share that Queues for Kafka is now available in open preview in Apache Kafka. This is a really big deal. With queues, developers can access message queue semantics directly on top of Kafka without the need for separate messaging or queuing systems. You don't need to do anything. Every Kafka topic is available as normal, as a stream, or as a queue, or both at once. So you can now power really classical use cases, things like asynchronous APIs, job scheduling, order management, notifications, and many more on top of the reliability and, uh, stability of the Kafka platform. Now, in many organizations, Kafka has already replaced a lot of their need for message queues, so this makes completing that transition to one reliable foundation really trivial. Please scan the QR code if you'd like to learn more about that. But what's next? Well, you heard me say we wanna make streaming ubiquitous, With streaming, we have found a better way to build more reliable customer experiences, but sadly, some organizations still use streaming sparingly. Why is that? Well, it's because they fear that it will be too costly or risky to expand streaming to all of their data and all of their data use cases. And there's a few reasons for that, but none of them are laws of physics. First, organizations often overprovision their streaming infrastructure to make certain that they can meet peak demand. But that means that in general, 50% of the infrastructure cost is wasted, underutilized technology. Storage can be a real pain. Teams are forced to choose between, uh, short retention on local disks or trying to figure out how to bolt on external object storage to retain data for longer in Kafka. Networking can be unbelievably painful. In some scaled cloud implementations, networking ends up representing over 80% of the total cost of ownership of Kafka. And at the end of it all, self-managed Kafka really can't provide the SLA, governance, and security capabilities that enterprises really need. You could just try using a managed Kafka, maybe you could try the one from your cloud service provider, but at the end of the day, all that really changes is where your invoice comes from. Comes from. What looks like a one-click managed Kafka is really just Apache Kafka on the backend, and all of the scaling, tuning, and firefighting ends up being left to you and your team. Now, that's why we created Cora. It's our Apache Kafka engine built for the cloud, and Cora lets us offer a cloud-native Kafka experience to our almost 6,000 customers all over the globe. With Cora, we offer a serverless, elastic, instantly auto-scaling Kafka that delivers 10 times better tail latencies, a 4 nines SLA, and infinite storage out of the box. But I don't have a lot of time on stage this morning, so if you'd like to learn more about the architectural advantages of Cora, I'd encourage you to check out the QR code on the on the screen. Instead, today, I really want to focus on one key aspect of Cora that's critical to our mission of making streaming ubiquitous, and that's cost. Our mission is to make streaming cost-effective for every use case everywhere, no ifs, ands, or buts. Whether you need a massive throughput topic with tremendously low latency, or you just need the least expensive way to stream data from A to B, We're focused on delivering the exact right streaming option for you and your cost profile. And that's what Cora was built to deliver. With Cora, we have removed costs at every single layer of the stack. Cora instantly auto-scales so that 50% of over-provisioned infrastructure is a thing of the past. Cora ships with diskless Kafka out of the box. Infinite storage is just there. And if you choose to use object storage as the replication layer, all of that cross-availability zone network, networking traffic that can end up being so, so much of the networking cost of Kafka is a thing of the past. Speaking of networking, with our brand new private network interface powered by AWS's Elastic Network Interface technology, you can get secure private cloud networking for 50% less cost. And all of that comes with the 4 nines SLA and security and governance capabilities that enterprises really need. But how exactly does this show up for all of you? Simple, options. We have a variety of different, sorry, we have a whole fleet of different fully auto-scaling clusters that meet exactly the performance capabilities and cost profile of your data streaming needs. But what you really need to hear is no matter what your use case is, we have the highest performance, most capable, lowest cost streaming option, no ifs, ands, or buts. And we operate all of these cluster types at massive scale. So what's normally the hardest part, managing Kafka becomes the easiest part. And this isn't theoretical. We operate over 30,000 clusters across over 100 cloud regions, sustaining more than 8.2 trillion messages a day with that four nines SLA and rock solid resilience that I was talking about a moment ago. And that's how, at our customers from Indeed to SAS and beyond, we reduce their streaming costs by between 40 and 70%. But more importantly, we unlock streaming for all of their data use cases. And we can do the same for you too. Whatever your data or workload is, we will get it streaming at scale, and we will make the economics undeniable. But like I said, let's see this in action. River have their vessel information stored in an Oracle DB. They have vessel telemetry and ride requests coming in from some custom-built applications. So to walk us through that demo, please welcome back Sean Falconer.

All right.

Well, thank you, Sean. It's good to be back up here. It looks like it's going to be the Sean and Sean show where one of us spells our name correctly and the other one thinks they do. I'll leave it up to you to decide who it is, but it's this guy.

Well, I think we're going to have to agree to disagree on that one, but at least we're both well dressed, which is the most important part.

All right. Well, I'm excited to be back up here to, uh, to take all of you through some demos. Hopefully you're excited as well. Let's get started. Let's cue the demo. So Sean talked about how we want to keep data streaming cost effective for everyone, and we're gonna put that to the test with our River Rowboat taxi company. So here we have two very different types of data. We have our ride requests, which are time sensitive. We don't want people waiting around for their boat. So we're gonna use enterprise clusters for this. They, they're built for speed. And then on the flip side, we have things like telemetry data that's continuously streaming from our vessels. Here we have a huge volume of data. We don't necessarily need blazing speed, but we wanna be able to do this and store that data without essentially breaking the bank. So we're gonna use Fright clusters for that, which I'm setting up now. They're built for this. Both are elastic and autoscale, so you only pay for what you need, and they're both being protected using private networking through our new private networking interface. This is based on the same AWS core primitives that protect their services deployed within your VPC to minimize data transfer costs. All right, so we have our cluster set up. Now we actually need some data and we're gonna start with our vessel catalog data, which represents all the ship information that we have. This is currently stored in Oracle. So in order to get the data from Oracle into Confluent Cloud, we're gonna use our new Oracle Extreme CDC connector. Connector, which I'm setting up here. Pretty simple. Basically point it at your database, put in your credentials. Once I have that, I select continue. And then the next step is just to choose the Kafka topic that I wanna stream this data into. And there we go. This is fully managed. Just click through, launch the connector, and we have data flowing from Oracle directly in the Confluent Cloud. And we can take a look at what this looks like. So we'll pull up one of those, the sample data, and this essentially represents our ships within our fleet. All right, so that's our database data. Then now for the fun stuff, our real-time data coming from all of our fleet. So every one of our ships is a moving data generator. We're talking fuel levels, temperature of the engine, speed, GPS location, all coming from these ships in extremely high volume. So when you have essentially, you know, thousands of different sensors sending millions of different data. And we'll, we'll pull up an example of one of these in a second. The big question of course is how do you prevent bad data from potentially poisoning the entire system? How do you make sure that you have data quality enforced from the very beginning? So there's an example of some of our telemetry data. The way that we solve this problem is through schemas. These act as a contract for your data where you can essentially enforce enforce the rules and the shape of your data the way that you want that data constructed. So this is an example of our vessel telemetry. So that's our operational data. The next step is our ride request. And for this we're gonna go over to the app. So when you're a rider with River, you essentially go into the app, select the location, request a boat.

There we go.

And then behind the scenes, this request is written into a Kafka topic called ride request. We'll pull up an example here in a second. And there we go. In less than 5 minutes, we're streaming, we have our database connected, we have our telemetry data flowing in, we also have our ride request. So what used to be one of the hardest things to essentially manage and configure Kafka is now one of the easiest. And with that, I'm gonna hand it back to Sean.

All right.

Thank you.

Thank you, Sean. So you'll notice how Sean was able to mix and match different cluster types to meet the different needs of his data, but to do so cost effectively. I hope you also saw how Sean was easily able to connect to his Oracle database, and that was 'cause he was able to take advantage of Connect and Confluent Hub, which is the richest collection of connectivity in the entire streaming ecosystem. There are hundreds of connectors on Confluent Hub, We're constantly adding more, but also our partners and community members like you are constantly adding more connectivity to the ecosystem. All right, I said earlier that we're aiming for ubiquity, and to truly be ubiquitous, we need to reach data everywhere that it lives. And it turns out that about 50% of the world's data lives on-premise or in private clouds. So we need the right streaming capabilities for those deployment models too. Now, almost exactly a year ago today, Warpstream joined the Confluent family, and they have a fantastic streaming offer for customers who prefer a bring-your-own-cloud deployment model, thanks to their purpose-built bring-your-own-cloud control plane. And for customers who really need to run all of their streaming environment inside their own data center or to run it entirely within their virtual private cloud, Confluent Platform is perfect for that too. Well, these are a great start, but we still think We can do better. Kafka success can create sprawl. It starts with one team, then it's tens of teams. Before you know it, you have a bunch of different topics and clusters spread across different business units or departments. And the central platform team is usually the one who carries all that weight. They're the one who scale the fleet, apply patches, manage access, keep everything compliant and resilient. They're understaffed, underappreciated, We know the pain well. We have been running Kafka for hundreds of customers for over a decade, so we want something better for those teams. We're introducing today Confluent Private Cloud. With, with Confluent Private Cloud, you can self-manage a cloud-like Kafka environment within your virtual private cloud or data center. Think things like multi-tenancy, scaling, performance, patches, upgrades, and a lot more. And Conformed Private Cloud isn't just about management, it also extends all the way to governance too, because CPC ships with Gateway, our smart policy-aware front door for Kafka. With Gateway, you can centralize authentication and authorization, You can enforce schemas and quotas, and you can smartly route traffic by policy. Now, what does that mean? Well, that means that you can prevent one team's bad access patterns or client configuration from impacting another team. You can securely control and enable sharing of data across teams, or even with your external partners, and client failover and disaster recovery is dramatically simplified. Now, Conform Private Cloud is really perfect for organizations in highly regulated environments or even managed service providers where a platform team is managing Kafka on behalf of many other teams. But not only does Conform Private Cloud make it much easier to manage Kafka at scale, it actually makes it less expensive too. In fact, Confluent Private Cloud can reduce your cost of operations and infrastructure for Kafka by over 50%. How's that? Well, first, in Confluent Private Cloud, we're shipping the intelligent replication layer from Cora in the cloud into your on-prem environment, and that means that your brokers are up to 10 times faster. Second, we also ship CPC with intelligent bin packing, which which means you get better resource scheduling, maximize the utilization of your underlying infrastructure, and reduce the need for this overprovisioning that plagues most self-managed Kafka environments. And finally, with Gateway, you get the ability to enforce standards at one central point and reduce the need for cluster sprawl to reduce blast radius of individual teams' usage across your Kafka environments. And it's gonna get better. Soon we're going to ship the entire logical multi-tenant layer of, uh, Cora in the cloud into the on-prem environment, so you can get even better utilization of your Cora environments as well. Sorry, your Conform Platform Cloud environment as well. Now, Conform Platform, Conform Private Cloud is GA today. Check out the QR code to learn more about that. But honestly, we recognize that most large organizations don't have just one deployment model, and that's what has made our cluster linking technology so successful. With cluster linking, you can stream data between your on-prem, private cloud environments, and the public clouds, AWS, GCP, and Azure. You can stream the data seamlessly within milliseconds, offset preserving, with zero knobs or dials to configure. That's what we mean by ubiquitous streaming. But we also want to make it easier for you to understand this complicated data flow and infrastructure. So today we're excited to announce our brand new Unified Stream Manager. With Unified Stream Manager, you can manage all of your Confluent clusters from one place. You can see all of your schemas, all of your metrics, all of your lineage across all of your streams from a single pane of glass. Unified Stream Manager is shipping GA today, connecting to Conform Platform 8.1. You can scan the QR code to learn more. All right, let's get back to our use case. We've got our data connected and our streams are up and running, but if we're really gonna power AI agents, we don't just need real-time data, we need data that is trustworthy and has been contextualized to the business problem we're trying to solve or the decision we want the AI to make. And processing data with Flink is the key to making rich real-time data an actual reality. With Flink, you can work with, shape, and transform your data in real time without first needing to land it in a database or a data lake. And in Confluent Cloud, our serverless Flink offering, lets you instantly autoscale a Flink job to any scale that you need, making it trivial for you to filter, join, aggregate, enrich, or standardize data while it is still in motion on the move. In the last year since we GA'd our Flink offerings, they've proven themselves to be the most successful products we have ever launched as a company. But how does that all play out at River? Well, obviously they have a bunch of information they need instantly to run their business. Vessel location, weather, local events. But real-time signals aren't by themselves enough. They also need information about historical ridership patterns or seasonal demand patterns. That information is not generated in real time, but it's needed in real time at the point of decision. Now, luckily the Data Streaming Platform already has all of the data that we need to power these use cases. And that's where Confluent Intelligence comes in. As Jay shared a moment ago, with Confluent Intelligence, you can unlock your fresh governed data for instant use inside your AI agents. So let's see it in action. Sean, show us some AI agents.

All right, sounds great, Sean. So to recap, we want to use AI to coordinate logistics, things like our staffing levels, how many vessels that we have available, based on the number of ride requests that we're seeing at any given moment. And we're gonna break that up into smaller chunks just so that you can see how achievable an AI use case like this truly is. To start, we're going to apply anomaly detection for our ride requests in real time. Let's cue the demo. All right, so we're gonna use built-in anomaly detection available in Confluent Intelligence. This is the easiest place to start, like, with applying AI to your real-time data. What we're doing here is we're using anomaly detection over essentially periods of time as we analyze this real-time stream of ride requests, and we're looking for deviations in that pattern that represent these types of anomalies. And once we recognize that, we can flag it, and this allows us to act proactively, potentially dispatching new boats to the area rather than being reactive and dealing with this problem downstream. Well, once we, we've identified we've run the, we have that job running. We can take a look at our anomalies detected and we see that there's actually been an anomaly. There is a surge in the number of ride requests that are happening right now. Of course, anomaly detection is just the start. There's a lot more work to do. So let's go back to slides to talk about what's next. All right, so we're gonna take this a step further. We want to be able to take our anomalies and cross-check them. With local events that are happening in the area. You know, as Sean said, you know, perhaps you have something like Mardi Gras happening, or maybe there's a band going up Canal Street that's blocking access to your hotel room like there was at my hotel last night. Or it could be that, you know, everybody is on a rush to get to Current to be at the keynote right now, and they all wanna take riverboats cuz that's the, I dunno, fastest way to get around. Whatever it is, essentially we wanna know not just that something is happening, but why it's happening and how long it might be taking so that we can intelligently respond and mitigate the issue using AI agents. In order to do this, we're gonna use our streaming agents capability. Let's cue the demo. All right, so usually when people think of an AI agent, they think about a chatbot waiting around for a user to ask a question. And what we're talking about here is something completely different. This is an event-driven agent. It's not prompted, is not reacting to user prompts. It's triggered essentially by the data itself. And the way that we make that possible is we've built agents as a core component within Flink. I just specify essentially the model that I'm using, this example Claude, the prompt, the tools that I need, and then I run that agent definition directly in the Flink runtime. In this case, pulling in additional data about the local events that we're pulling essentially from a vector search. As well as the vessels that are nearby. And once we run this, we use the powerful reasoning and model to make decisions. In this case, if there's enough boats in the area to deal with the surge, nothing happens. But if not, then we use tool calling capabilities through MCP to dispatch new boats to the area. And what you end up with essentially is real-time proactive informed reasoning about every decision. And if we just pause for a moment and think about what we just did is we built a fully automated fleet management system using a combination of anomaly detection and an AI agent. It's always on, it's proactive, it's streaming native. All right, let's go back to the slides to talk about what's next. All right, so that was a great example, but if you remember, we want to use the same real-time contextual data to power AI wherever you need it, not just within Confluent. So imagine that a rider has requested a boat and despite our best efforts, there's been a delay. Now the rider goes to the mobile app, to the customer service chatbot, and starts asking questions. And that chatbot is powered by an AI agent that's built outside of Confluent. Well, in order for that customer service chatbot to be able to intelligently respond to the user, it needs to understand what is happening right now in order to make those types of decisions. So in order to solve this problem, we're gonna use our real-time context engine. Let's cue the demo. All right, so for this customer service chatbot using an agent that's been built outside of Confluent, in order to make intelligent decisions, it can't be doing that based on stale data. We need to connect it to this real-time high-value context. So in order to do that, we're gonna take our Kafka topics, some of the data that we have flowing through Kafka now and enable them for the context engine. This turns those topics into tools that we can consume through a fully managed MCP server. And when I go into the app and I ask about the status of my ride, behind the scenes on the left, you can see Claude's chain of thought reasoning as it interacts with our MCP server, first asking about the data that's available and then finding out there's been a surge and what the action was taken for it. And then it can use that to contextualize the response, letting the user know that there's been a delay because thousands of people are on their way to current keynote right now, and we've dispatched new boats to the area. Please be patient. So if we take a step back and look at what we just built over the last couple minutes, is we powered two completely different AI use cases. One, proactive and system-triggered using a combination of anomaly detection and an AI agent, and the other one reactive and user-driven using the real-time context engine. All right, let's go back to slides. All right, so we just saw all 3 core tenets of Confluent Intelligence in action. We started pretty simple with applying anomaly detection to the number of real-time ride requests that we were seeing using Flink's built-in machine learning capabilities. And then from there we added a streaming agent, which allowed us to essentially go deeper, cross-reference that anomaly with other information about local events and actually make intelligent decisions. And this was, you know, easy to build. Of course, the agent can access all your real-time data that's flowing within Confluent, but it also has access to data that exists outside of Confluent through external tables as well as through MTP. And when our AI system, was built outside of Confluent, we use the real-time context engine to give instant access to your streams so that to power any AI system anywhere. And what that all really means is the same real-time contextualized trustworthy data powers every AI system you build, whether it's a streaming agent on Flink or an external app or agent. And if you wanna learn more about this, You can scan this QR code, and with that, I'll hand it back to Sean.

All right. Honestly, how cool is that? Streaming agents in 15 lines of SQL. Amazing. So we're really excited about our vision for Confluent Intelligence, and we're not the only ones. Obviously, you heard from Anthropic earlier, but we'd like to take a moment to highlight our other partners along this journey. So where are we at? Back, back to the overall demo. Well, now we've got our AI agents up and making real-time decisions, but obviously if you're River, you need to understand the quality of those decisions and what is going on, something you typically do in analytics. So probably inside your data lake or data warehouse. Now, sadly, traditionally it's actually been kind of hard to get data from streaming into your data lake or data warehouse, just like it used to be hard to power your AI with with streaming data. But as Jay shared earlier, thanks to the emergence of Delta and Iceberg, these open table formats, it doesn't have to be that way anymore. As Jay shared, with Tableflow, we've extended Kafka's storage engine so that you can access your Kafka topics also as Iceberg or Delta tables. So the exact same real-time, reliable, reusable data that is literally already powering your AI agent and your customer experiences can now also immediately appear in your data lake, your data warehouse, and all of your analytical tools. There is no need for ETL, ELT, endless data prep. It's just seamless data flow from the streaming ecosystem into your analytical ecosystem. Honestly, this is one of the most powerful technologies I've ever had the opportunity to release. Now, Tableflow went GA a little bit earlier this year, with support for AWS and Iceberg. But we have been hard at work since then, and actually today we have a cavalcade of new announcements for you around Tableflow. Firstly, we're announcing the GA of support for Delta format with Unity Catalog support. We're also announcing the GA of support for upserts, dead letter queues, and for encryption across both Delta and Iceberg. And finally, we're super excited to announce the early access release of support of Tableflow on Azure as well.

Woo!

So what does all that mean? Honestly, from my perspective, Tableflow once again demonstrates the value of shifting left, moving governance and processing closer towards the source. By doing that, the data arrives clean and well-governed. That means that it's schematized. Data that doesn't quite fit can be routed to a dead letter queue, and encryption exists throughout. And then what you're looking at is not just a raw dump of the Kafka changelog. To be clear, we take care of inserts, upserts— sorry, inserts, updates, uh, compaction, and table maintenance so that you get the keyed, merged, silver analytical tables, which are the ones that you really need. So for example, if I was taking in a stream of customer profile updates with customer IDs and individual fields of a profile that are being updated, Tableflow can present a table keyed by customer ID with complete customer profiles easily. And the best bit is, if you— the business logic changes, you don't need to rewire a bunch of pipelines. You can just replay the data from Kafka, and the tables will rebuild themselves. Now, Tableflow obviously gives you better, faster data in your analytical ecosystem, but the best part is it also reduces your costs too. We see it time and again at customers from Notion to Siemens and many more. When you shift governance and processing left, you reduce your data quality issues by up to 60%, your infrastructure costs for analytical processing are reduced by 30% and more, and your engineering teams can move faster than they ever have before. All right, let's see Tableflow in action. Sean, take it away.

All right, thanks Sean. So now River wants to run some analytics on how busy each zone is and also the decisions being made by their agents. So they essentially wanna be able to take the data that exists in CompWare pull it and stream it into Databricks in order to run this analytics. In order to solve that problem, we're gonna use Tableflow. Let's cue the demo. So Tableflow makes it push-button simple to turn your Kafka topics into Delta Lake or Iceberg tables. And we want to take the decisions being made by our agents and stream those into Databricks. So it's pretty simple. We set up Delta tables, format there, and then I choose my S3 bucket where I wanna store my data. Click continue, launch, launch Tableflow, and there with zero code, zero pipelines to manage, I'm moving data from Kafka Cloud into Tableflow. With Tableflow, your Kafka topics simply become your tables. And it's not just about the data, it's also the schema is kept in sync within Unity Catalog. And now we can go over to Databricks and start to explore this information. In this data. And we can do that using Genie AI where I can express my questions like, what are the number of ride requests we're seeing per zone? And it will take that natural language query and convert it into SQL, as you can see here, and actually execute that and allow me to explore this data in a table as well as in some visual format. And I can continue to ask questions. For example, I can ask about what actions have been taken by our agents. Based on zones so I could start to assess the quality of the AI decision making and the AI investments that I've made. And the amazing thing about when you have high value, clean data continuously refreshed through Tableflow in near real time within Databricks is it unlocks new use cases for your business. For River Robotaxi, that means that they can assess their staffing needs, their vessel capacity, even determine their ROI for their AI investments through streaming agents and the anomaly detection features they're using within Confluent Intelligence. And if you're using things like GenAI, you can now have any user within your business be able to explore that data. No technical expertise required. All right. And with that, let's go back to the slides. All right, so we're excited to work with all our partners on this journey to provide and deliver rich, reliable, real-time data to power any lakehouse or analytics platform. Today, we're very excited to announce another major partnership that opens up an entirely new fran— frontier for your streaming data. Confluent and Salesforce are partnering together. Thank you. These are two platforms that sit at the heart of how modern enterprises operate. We're connecting the world's leading data streaming platform with the world's leading CRM. This is a pretty powerful idea. I mean, think about how many of your organizations stream data through Kafka and also use Salesforce to power your customers, your service, and more. Together, we're unlocking really a new generation of AI-driven personalized customer experiences. So how do we make all that happen? Well, Tableau powers Salesforce Data Cloud with trusted real-time data across the enterprise. This means that every customer profile, every dashboard is continuously refreshed and up to date. In parallel, Flink is analyzing those real-time streams, detecting patterns, trends, anomalies, key moments in your business. And when something interesting happens, it uses streaming agents to invoke and trigger an agent force workflow, turning your AI investments within Salesforce into event-driven AI. And together we make the Salesforce vision of agentic enterprise possible. To talk more about this, please welcome Gunther Haagleitner, SVP of Engineering at Salesforce.

Hey Sean, how's it going? I have a small bone to pick with you, actually.

Oh, no beads?

No beads, man. You did not give me the dress code, so now I feel really underdressed for the occasion.

All right, well, one of us has to be a professional. Well, thank you so much for being here. I really appreciate it. We're very excited about Salesforce. Salesforce. So, you know, Salesforce talks a lot about and is really leading the conversation around this idea of the agentic enterprise where you use, you basically build more autonomy, power through AI agents to automate more work within your business. If from your experience, like why is real-time data so central to essentially unlocking that vision? Yeah.

Yeah. So at Salesforce, we've been able to work with, uh, enterprises across, uh, virtually every industry. To help them bring AI into the flow of how they serve their own customers, how they support their employees, or how they run their operations. With Agentforce, our AI platform, we've really been able to touch every part of the, of the business. The pace of innovation that we've seen has been absolutely amazing and really stellar to witness. But as I suspect many of you here in the room, We've also noticed a pattern that, that there is a growing divide between the type of applications, agentic applications that really deliver elevated outcomes and those that kind of never really fully achieve the potential that they set out to achieve. There's been, you know, documented cases in the industry about this as well. So digging into it, Salesforce, and as we heard here from Jay and others today, we think that context is really the key, uh, in bridging that divide and getting over this. Uh, and specifically real-time context, uh, real-time governed personalized, uh, context, uh, makes all the difference there. If you can provide your agents with the right level of information just at the time, um, that the interactions happen, that's really when you can achieve these outcomes. And so yeah, that's why we believe that, uh, real-time context really is the key here in real-time really plays an outsized role in that agentic enterprise.

Yeah, it's all about the right data at the right time. And so, you know, the, we announced this partnership, Confluent Salesforce partnering together, you know, two of the most widely used platforms in their particular domain, you know, Confluent with data streaming, Salesforce with customer intelligence, essentially with Confluent being able to bringing Kafka data into Salesforce in high volume, real time? Like, what are some of the key unlocks for your customer in terms of value?

By the way, I've been able to talk to some of those shared customers here in the audience today already and yesterday, and I think they all echo what we anticipated, that putting the two platforms together, you really get more than the sum of its parts. You can really unlock a lot of value. I have a couple of concrete examples of, uh, uh, you know, things that we've seen where this kind of, uh, combination of these platforms makes a huge difference. Um, the first of them is, uh, a customer support agent in the telco industry, um, that we helped build. Uh, there the, the key was really to have the latest network load, uh, outage information available to these customer chatbots right at the time when the customer is investigating and trying to find out what it is. Minutes later, hours later doesn't help you for this kind of application, but having this context in real time, they were able to drive down resolution times by over a third, which I think is an amazing achievement. Another example that I think many of us probably have run into is personalized ads. So we've all kind of seen the type of ads that you get served up after you've already made your purchase decision, right? After you already clicked buy or after you've moved on to something else. That is not really useful. That is annoying in some cases. And having that type of real-time context when these systems are making those decisions really can help you overcome this and really can, as we've seen, get you 60% higher conversion rates, uh, drive up relevance and those types of things. So I think we will see more and more of these systems, and I think these systems are really critical to unlock that type of value.

Yeah, absolutely. And you know, I, I joked earlier, context is the, the, the word of the day, maybe the word of the conference. You can add it to your, along with AI, to your keyword bingo cards. But you know, just so you kind of wrap up, I wanted to ask from an engineering perspective, I know this is something dear to your heart. And I started my career as an engineer. Now I mostly pretend to be one, but what excites you the most about how these platforms, you know, work together?

Yeah, yeah. I started as an engineer as well, and the architecture is actually very exciting to me. I'm really pleased with what we've settled on here. So the architecture centers around Iceberg as an open and powerful format for us to share information on. The work you've done with Tableflow really, really helps simplifying getting the data from Kafka into these Iceberg tables. And then the work that we've done at Salesforce with zero copy to get the data without any additional management overhead, without any additional copies or ingest or any of that nature directly into Data360. And then from there being able to activate it across all of our channels, be it Tableau, be it Slack or, marketing, sales, agents, you can really bring that data immediately through this architecture into those channels. So that is super exciting. If you pair that with something like Flink on top of it where you can just react to business changes very quickly and then trigger agent force workflows directly from there, I think that is super powerful and I think we'll see this architecture kind replicated many, many ways and power a lot of the applications in future. So I'm super excited to see what our customers will do with that partnership and with that combined architecture.

Absolutely. And me too. And well, thank you, Gunther, so much for coming. We're really excited about this partnership and what we can do together and unlocks for our customers. And with that, we're gonna hand it back to Sean to close this out. Well, thank you so much.

Thank you.

Alrighty. Thank you, Sean, and thank, thank you, Gunther. Uh, and that's it, folks. We solved the use cases that we set out for River. We made streaming ubiquitous. We set every workload, every dataset in motion at scale, and we did it cost effectively. And using that streaming data, we found a better way to build. We shifted governance and processing left. That meant that we could do the work once at the source and reuse it to power our AI agents, our analytical use cases, and our real-time customer experiences. And what does that do? Well, ultimately, it converts real-time data to real business advantage. For River, that means better vessel utilization, better customer satisfaction, and more revenue coming in. That is the power of a data streaming platform, and we are really excited to see what the data streaming platform can do for you. Thank you everybody for joining us here in New Orleans. We hope you have a fantastic day. Thank you.