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. 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:00 A.M. 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 in tow 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 going to do all the fun stuff. We'll have some deep dives in Kafka, in Flink. We'll have some great product announcements. 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, the sessions are great, but the hallway conversations are even better. And so I think we have a great lineup for today and tomorrow. I'm going to be talking today about something that I think is on all of our minds, which is the rise of AI and how do we build intelligent systems? How do we connect those into the software estates that exist in our organizations today? I'm going to 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 want to start and just talk a little bit about where we're at right now. 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, if you ask an organization, what does it mean to be data-driven, the answers to that question would have changed. If you asked that question 10 years ago, I think it would have 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 what it would mean to have good business intelligence. That's what it would have 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. If we think about the software systems that we've been building probably for the last five years, a lot of them are doing this in some sense. 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. So there's a sense in which this is not different. But there's a sense, I think, in which it's really different. Ultimately, AI systems are a really different world. 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-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 actually fulfill its goal. And part of the reason this is so hard is the paradigm is actually completely different. If we think about how things have changed, the biggest difference is that traditional software is ultimately a bunch of hard-coded rules. 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 fantastically complicated piles of business logic. But at the end of the day, when you think about 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 pushing it in a certain direction, but ultimately, it's a probabilistic system. The output is not precisely specified, or at least the output that we're looking for, and 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 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 lorem ipsum, just some fake data 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 going to 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 have been available to a real support person who would have 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 a metric which is not exact. It's not going to be 100% perfect. You're going to have a set of evals that tell you you're better, you're 90%, you're 95%, you're improving. 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 traditional software, the business logic is king. That's really everything. The data is just something that lives in production that you're going to 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 your ticket to making this actually effective. So how can you build 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 I mentioned that this was ultimately about context data. And this is a really important part of the problem. If you think about the success of these systems, the two things that are going to matter in terms of the quality of the output are the model and the context data that it has. And I'll tell you, one of those things you have a lot of control over. 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 want to 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 100% of good enough. That's how you can actually 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 can you really harness context data, I think people start with a 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 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 give the agent kind of the login to all of our databases and SaaS systems, and we'll say, "Okay, you figure it out. 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. That's not going to get you the result that you're looking for. And the problem here isn't MCP. MCP is great, but MCP is just a way of accessing 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 ultimately, the data that we're accessing is the thing that's a problem. So what goes wrong if you try and do this? Well, 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 going to generate operational load and workloads it wasn't really built for. But that's not even the real problem. The bigger problem is about access control. 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 going to leak data from customer B or that it's going to have access to things that it shouldn't. All of the control of data has to be there. 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. 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. It's not like models intuitively understand the meaning of 4 any more than humans do. At the end of the day, you have to have the full context to be able to make a decision. When you think about harnessing this data, you're ultimately going to have to build a useful data set. You're going to 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. This is ultimately the pattern that's going to be really important. There may be some things where you can just hook it up with MCP, but the most common thing you're going to have is working on this context data. And this is commonly called context engineering, 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, it's really mastering context data. How can we do it well? The obvious place to start would be, how do we build these data pipelines elsewhere in the organization? The answer there is commonly batch processing. A really simple way to start would be to 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 for access by the AI. We're actually quite successful at this as part of our analytics flows. A fair amount of rich processing goes into preparing data for analysis. We might end up with an architecture kind of like this, something in your lakehouse or warehouse. We're kind of running a set of iterative processing steps. Then the output of that, you might upload to some kind of live serving database where it could serve live queries from the agent. What's the problem with this? Well, first of all, 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. 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 reprocessing and indexing pipeline knows that can be a little bit squirrely. But that's not even the big problem. The big problem is ultimately, this data is getting processed in batch. Best case, we're talking maybe four hours later, we know what the state of things are. More likely, it's tomorrow. And for feeding context to a system that's going to be making real-time decisions, it's going to be interacting as part of the business, this is a complete non-starter. You're going to get totally wrong answers. You could use the analogy of if you were going to cross the street, 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 going to be interacting with the real state of your business right now, then doing that off some snapshot of data is not going to be good enough for hardly any use cases that matter where the consequences are important. So you're ultimately going to have to move this into something that is real-time, something where the context data is in sync. So how can you do it? Well, we're here at Current. So part of the answer is going to be streaming data. There's no surprise there. 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. And so the architecture can be something like this, where you have streaming data capture, something like Kafka or Kafka Connect, stream processing, something like Flink, some way of serving this up. But there's a few things we're going to 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 data set, throw it away, try it a different way. I could actually iterate really effectively. And so it's going to be really important that we preserve that. And in order to do that, you need to have a conception of this stream processing that's broader than many people often have. It's not going to be enough to just have something that you can string together that processes the data of right now. It's going to have to be able to process the historical data and the real-time data together. I'm going to need something that's not a specialized system, but kind of a generalization of batch processing where I can build my program and have it run offline against a test data set, evaluate that, and then have it run continuously as it goes to production to create a continuously fresh data set that I'm going to use. So 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. 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 data tables in cloud object storage using 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 now have the ability to build systems that process history and then go on and start processing the real-time stream that are 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 with a particular set of logic in SQL or a 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 because that's ultimately going to be our development cycle. That's going to 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 easy to use in development in the way that our batch system was, able to produce real-time data, which is going to 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 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. We're going to 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 going to have a big batch load. It's going to be relatively hard to keep these two things in sync. It's going to 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 going to have a set of problems. There's going to be operational problems about the load that we're creating. There's going to 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 reprocessing of data. And they're often impacted by the real-time load of streaming updates. So 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 data set, it's somehow ready to serve. How could we accomplish that? Well, we've effectively accomplished something like this with TableFlow, where you have 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, do things with it. 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 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 data set. And we could do that in a way that was well integrated. And in fact, this is very possible. Rather than strapping on a completely separate database, we could 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 the full processing runtime of Flink and actually does fast analytics or lookups against this data set. And if we did this, we could have access for things that were indexed this way with milliseconds instead of multiple seconds. And that would allow us to have 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 this concept of building materialized views and stream processing 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 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. 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 over on the streaming side and serve it up in real-time. That's right. That's right. And so 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 streaming data capture, stream processing, create a new data set, be able to iterate on that in batch, and then take it out to production and have that data set 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. What we have right now is pretty simple queries with good performance. 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 is a little bit about our steps on how to build context data for agents. But 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 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 into production where it's going to run continuously, and I want to have similar evaluation of performance coming off of it. 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 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 actions it can take. I'm going to be talking about actually automating business tasks, taking some workflow that happens in a company and automating it with AI, so 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 this could be something where a sale occurs and there's a fulfillment process that the agent should take on and orchestrate parts of. It could be something where an insurance claim is filed and part of that processing flow has steps where the AI is going to take over aspects of that. A support ticket is lodged. You want to actually process some of that. So 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 very much the same thing I described for context data, the ability to plug something into the streaming model, run it on historical data sets till we get it right, launch it into a streaming world where it runs continuously. And the architecture for this is actually quite simple. You have an agent built in Flink. It has access to an LLM. The kind of resulting logic is going to be in your Flink code. The LLM is going to be actually orchestrating a lot of the decisions. The events coming in you can tap into and respond to. The actions going out are going to 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 make side effects in production, but actually produce this output stream of events, and I can evaluate that like a data set. 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 for all this talk of AI, sometimes we forget about the good old-fashioned machine learning, and you might think, well, that stuff's so old. It's been around for multiple years. But sometimes the old stuff is actually pretty good. And it's true that these older machine learning algorithms, they don't have the power or the generality that modern foundation models have. But they do have 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 out of reach on the cost frontier with more agentic AI foundation models. And so this same model that I described for plugging LLMs into streaming agents, this works with traditional ML algorithms as well. And we're adding some of these. We've 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 effectively all our customers have in their problem set, detecting network outages, monitoring business activities, looking at purchasing behavior, return behavior, stock trading systems. And so there's a set of 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 about three capabilities here: the context data, the streaming agents, traditional machine learning models. To give us an easy way to talk about it, we wrapped all these together and gave it a name. We're calling this Confluent Intelligence. And these are three tracks that we're doing a lot of development on. Thank you. Thank you. And so we're really excited about this area. Each of these pieces of functionality kind of stand alone and can be used independently. You can use this context engine to build derived data sets 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. And so I'll show you a little bit of how this fits together. This is a common pattern we've seen with customers where you can actually link these things. You have some stream of business events coming in. You can detect anomalies on this. So maybe this is some operational aspect of the business. I want to see if it's working well. If I see something unusual, then I want to say, "Aha, I don't recognize that. That looks wrong." But when I do that, usually what happens is it's going to go to some human, and 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, and so that you could hook that up as the next stage in this pipeline, 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 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 going to open up in all of our customers and all of their use cases. And to dive a little bit deeper into this, I'm excited to welcome a really important partner of ours from Anthropic. Anthropic, as many know, is a company really leading the way on developing the most cutting-edge foundation models. Many of you have probably used their product as part of your coding workflows if you've used Claude Code. Fantastic work that they've been doing. They've been doing it, I think, in a very safe and responsible way. I'm really excited to welcome to the stage for a conversation on these topics, Sean Falconer, our Product Leader for AI, and Rachel Lo, the Head of Applied AI from Anthropic. Sean and Rachel, welcome. Really looking forward to what you have to say. Thank you all very much. Rachel, welcome to New Orleans. Welcome to Current. Thank you so much for being here. Thank you for having me. So there is a ton of big questions in the world of AI right now, a lot of unknowns, might say. When is AGI coming? When are we going to have transformers? And I don't mean transformer models. I'm talking about Optimus Prime, turning my car into a robot. Yeah. I like Bumblebee 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 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 lists. But the thing is, I need this tomorrow morning with my coffee at 8:00 A.M. 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. Well, amazing. Hopefully, that helped everyone here. But as smart as Claude is, imagine if it actually knew what was going on in the business right now. What's the queue look like? Where 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, it would be able to operate with the same awareness that the business would be able to operate in. Wouldn't that be amazing? Pretty powerful. So Jay talked a lot about this idea of intelligent systems, not only learning from history, but being able to sort of act in the moment. And in your customer conversations, how is this idea kind of showing up with them, and how are they thinking about navigating maybe the next year or so? 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 we were having around AI a year ago, it was really the chatbot era, I like to call it. And even in the last six months, I think we were really focused on just this very linear input to output. Yes, there is a bit of an LLM feedback loop there, but it was single-step. And we need to see and recognize that models have significantly evolved, even in just the last couple of months. We recently released Sonnet 4.5, Haiku 4.5, for the faster, more daily tasks. And I think that that's where it's become incredibly powerful to be able to build more multi-layer agentic architecture. 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 a single experiment. And they're not thinking about it in more of 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 is talking about exciting that we're talking about right now. And 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 going to 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. Context is king. It really seems to be the key for productionizing these AI systems. So I guess, what does that actually mean in practice? What are the challenges that your customers face with actually bringing their enterprise data to power a system like Claude? Yeah, absolutely. First of all, there is the first step of recognizing that there is this shift. I think, again, moving out of the eras of the chatbot, we really want to 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, but again, when I talk to companies and kind of prompt them to think about what context they have, they think of that more as just context engineering, but it's so much more than that. I think it's really thinking about the overall business-specific data that they have, and not just thinking about it in terms of what do they assume is data, oftentimes in more structured places but thinking through 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 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 Claude 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 actually created their own coding language 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 RL 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. 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. Right. And then when you are working with these customers, I guess your most innovative customers, the ones that are either getting this right or maybe they're on the cusp of getting this right, 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 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 team you decide to go for. It can be for email, for calendaring. It can be a lot of the ways in 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. Tying that together 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. It's a very exciting internal game. Everyone knows that Claude's played Pokémon. We have 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 six months of my time. 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-layer agentic architecture. 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, 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. 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 were 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, and 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, 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 we're seeing that shift to much more operational use cases being born. And I think MCP is absolutely the key there. And I think together, especially with this 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 we're running out of time. But before we wrap, what is your sort of one prediction for enterprise AI going into 2026? Yes. I would love to predict Transformers. I have mentioned that Bumblebee is my favorite. But unfortunately, in San Francisco, we just have Waymo. So I don't know what's going to happen on 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 we're going to 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 going to be where we're going to build all of our houses, a.k.a. agents. 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 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 unknown, and think about how you can better connect all of that into real-time data tied to any of the historical patterns that you will 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. Are we actually operationally accurate when it comes to building with AI, and actually into 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 going to do together. Next, I want you all to hear from our customers, Marriott and Metronome, on their data streaming AI journey. Thank you so much. Thank you. Please welcome VP 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 the globe. Today, I will share how data modernization behind Marriott Bonvoy elevates the guest experience from shop to book to stay. We at Marriott, being in the business since 1927, started our journey as a root beer stand in Washington, D.C. From that small beginning, we grew to 9,600 properties, 30-plus brands in 144 countries. Our vision is to become a 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 a member yet, please let us know. We will be very happy to sign you up for. Delivering 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. Having customer data real-time is key to our success. 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 a 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're familiar with this. We had this spaghetti, complex point-to-point integration architecture. 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're all familiar with. So we embarked on 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 scale. By moving to Confluent Cloud, our engineers are no more spending their valuable time managing a cluster or upgrading a platform. Instead, they allow developing products, tools, real-time analytics using Flink, and advancing our governance by securing our PII data using CSFLE. That enabled our platform as a self-service capability to developers and business communities. Because of that, we have 900 critical business transactions, and 2,000-plus 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 come from the partnership: our co-brand cards, airline partnership, Uber, Starbucks, and we have 100-plus partnerships 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 six to nine months, too slow for our growth. By introducing data streaming and using connected ecosystems and enabling all our API as a self-service capability, we brought that time down to six weeks. Yes, you hear it, six weeks. Amazing that this technology can help when business and technology move 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 principle. No surprise, every data has to be real-time, and I am so excited about 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 three key takeaways. Number one, make your business-critical transactions real-time and operationalize them. Number two, once you have that real-time data, enrich it. Make the data as a more mature data product using technology like Flink. Number three, apply AI on top of that to provide a hyper-personalized experience to the most valuable customer, and I'm not done yet. This one is very close to my heart. Develop ecosystems and tools for your developer and business communities. When you empower them, they are going to make you look good today and in the future. Marriott data streaming journey has become a 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 at trusted scale. Thank you so much for listening to us today. Please welcome Chief Technology Officer at Metronome, Cosmo Wolfe. Hey, all. I'm Cosmo, the CTO of Metronome. And I'm super excited to be here to talk about the Confluent Metronome journey for two reasons. The first reason is Confluent is a big customer of Metronome's, 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 Metronome's 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 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 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 seat or 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 with 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 billing is now flexible and you 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 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 Confluent 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 Infra SaaS. So you want to 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 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, things like users 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. Maybe you decide, "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-m ost- once delivery." Or maybe you want very correct, highly available processes, but you can give up a little bit of latency and run a slower process 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 when we got started, we only had three 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 going to 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 exist 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, Shaun Clowes. All righty, well, a big thank you to Anthropic, Metronome, and Marriott. What a tremendous set of use cases. 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 we 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're currently working on in whatever industry you are in. Our mission for you is actually really simple. We want to 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 toward 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, ride-sharing. 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 thank you. Thank you. Yep. 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, 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 vessels to meet that demand. Now, we're going to 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 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 want to 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 over-provision 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 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. Now, 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. What looks like a one-click managed Kafka is really just Apache Kafka on the back end. And all of the scaling, tuning, and firefighting ends up being left to you and your team. Now, that's why we created Kora. It's our Apache Kafka engine built for the cloud. And Kora lets us offer a cloud-native Kafka experience to our almost 6,000 customers all over the globe. With Kora, we offer a serverless, elastic, instantly autoscaling Kafka that delivers 10 times better tail latencies, a four-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 Kora, I'd encourage you to check out the QR code on the screen. Instead today, I really want to focus on one key aspect of Kora 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. That's what Kora was built to deliver. With Kora, we have removed costs at every single layer of the stack. Kora instantly autoscales so that 50% of over-provisioned infrastructure is a thing of the past. Kora 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 networking traffic that can end up being 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 four-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 whole fleet of different fully autoscaling 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 it'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 cost 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, Shaun. It's good to be back up here. It looks like it's going to be the Shaun 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 take all of you through some demos. Hopefully, you're excited as well. Let's get started. Let's cue the demo. So Shaun talked about how we want to keep data streaming cost-effective for everyone. And we're going to put that to the test with our River Robotaxi 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 going to use Enterprise clusters for this. 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 want to be able to do this and store that data without essentially breaking the bank. So we're going to use Freight 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 clusters set up. Now we actually need some data. And we're going to start with our vessel catalog data, which represents all the ship information that we have. This is currently stored in Oracle. In order to get the data from Oracle into Confluent Cloud, we're going to use our new Oracle XStream CDC 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 want to 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 the sample data. And this essentially represents our ships within our fleet. All right. So that's our database data. 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 thousands of different sensors sending millions of different data, and 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 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 going to 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 gets 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 five 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 going to hand it back to Shaun. All right. Thank you. 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 because 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. Now, 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 ones 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 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 Confluent 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, Confluent 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 Confluent 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 layout from Kora 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 means you get better resource scheduling, maximize the utilization of your underlying infrastructure, and reduce the need for this over-provisioning 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 going to get better. Soon, we're going to ship the entire logical multi-tenant layer of Kora in the cloud into the on-prem environment so you can get even better utilization of your Kora environments as well, sorry, your Confluent Platform Cloud environment as well. Now, Confluent 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 Li nking 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 Confluent 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 going to 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. 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 GAed 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, Shaun. 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 going to 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 going to use built-in anomaly detection available in Confluent Intelligence. This is the easiest place to start 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've run, 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 going to 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. As Shaun said, 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 everybody is on a rush to get to Current to be at the keynote right now, and they all want to take river boats because that's the fastest way to get around. Whatever it is, essentially, we want to 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. And in order to do this, we're going to 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. It's 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, 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 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 going to 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 going to 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 can be consumed 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 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 of minutes, we power 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 three 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 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 MCP. And when our AI system was built outside of Confluent, we used 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 want to learn more about this, you can scan this QR code. And with that, I'll hand it back to Shaun. 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 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 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 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, 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, 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 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, Shaun. 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 want to be able to take the data that exists in Confluent and stream it into Databricks in order to run this analytics. In order to solve that problem, we're going to 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 table format there, and then I choose my S3 bucket where I want to store my data, click Continue, Launch, Launch TableFlow, and there, with zero code, zero pipelines to manage, I'm moving data from Confluent 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 and 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 can 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 and 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 Genie AI, 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 that power any lakehouse or analytics platform. Today, we're very excited to announce another major partnership that opens up an entirely new 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, TableFlow 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 Agentforce 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 Hagleitner, 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, so Salesforce talks a lot about and is really leading the conversation around this idea of the Agentic Enterprise, where you basically build more autonomy, power through AI agents to automate more work within your business. From your experience, why is real-time data so central to essentially unlocking that vision? Yeah. Yeah. So at Salesforce, we've been able to work with enterprises across 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 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 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 has been 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 in bridging that divide and getting over this. And specifically, real-time context, real-time governed, personalized context makes all the difference there. If you can provide your agents with the right level of information just at the time that the interactions happen, that's really when you can achieve these outcomes. And so, yeah, that's why we believe that real-time context really is the key here and real-time really plays an outsized role in that Agentic Enterprise. Yeah. It's all about the right data, the right time. And so we announced this partnership, Confluent, Salesforce partnering together, two of the most widely used platforms in their particular domain, Confluent with data streaming, Salesforce with customer intelligence. Essentially, with Confluent being able to bring Kafka data into Salesforce in high volume, real-time, 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 things that we've seen where this kind of combination of these platforms makes a huge difference. The first of them is a customer support agent in the telco industry that we helped build. There, the key was really to have the latest network load 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, after you've 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, 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 I joked earlier, context is the word of the day, maybe the word of the conference. You can add it along with AI to your keyword bingo cards. But just to kind of wrap up, I wanted to ask from an engineering perspective, and 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 work together? Yeah. I started as an engineer as well. The architecture is actually very exciting to me. I'm really pleased with what we've settled on here. 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. 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 Data 360. 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. 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 Agentforce workflows directly from there, I think that is super powerful. And I think we'll see this architecture kind of replicated in 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 the unlocks for our customers. And with that, we're going to hand it back to Shaun to close this out. Well, thank you so much. Thank you. All righty. Thank you, Sean, and thank you, Gunther. 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 data set 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.