When AI agents truly connect, businesses move beyond isolated AI experiments to unlock scale and innovation. In this episode, Confluent's Sean Falconer dives into the Agent2Agent protocol (A2A), why agents need both fresh data and a powerful infrastructure, and how a data streaming platform turns isolated agents into a connected, business-driving force.
All AI problems are data problems—and one of the biggest is getting AI agents to talk to each other. This special episode with Sean Falconer dives into how agents built by different teams often end up stranded in “intelligence silos,” unable to collaborate or share context. The result? Fragmented AI that struggles to deliver real business value.
Tune in to learn why moving beyond isolated AI experiments calls for a robust data streaming backbone—and how Confluent's strategic partnership with Google Cloud sets organizations up for building multi-agent AI systems at scale. With technologies like Apache Kafka®, agents can tap into a central stream of trustworthy data—effectively creating a nervous system for your AI ecosystem. That backbone enables real-time exchange, scalable collaboration, and reliable intelligence across the enterprise—unlocking speed and innovation that siloed AI can’t deliver.
About the Guest:
Sean Falconer is a Senior Director, Product Management - AI Strategy at Confluent where he works on AI strategy and thought leadership. Sean’s been an academic, startup founder, and Googler. He has published works covering a wide range of topics from AI to quantum computing. Sean also hosts the popular engineering podcasts Software Engineering Daily and Software Huddle.
Guest Highlight:
“What is the message between agents? It's just data. You're moving that data from one agent system to another agent system, whether that's a multi-agent system that's collaborating or even these agents that exist in different, you know, parts of the business, you can use data streaming essentially be the bridge where those agents shared language, the shared communication becomes events.”
Episode Timestamps:
*(00:00) - Introduction
*(00:34) - Why AI is Fundamentally a Data Challenge
*(02:17) - Data Streaming: The Foundation for AI
*(07:21) - The “Island of Agents” Problem
*(09:46) - Streaming Agents vs. Chatbots
*(12:35) - The Consequences of Disconnected Agents
*(14:09) - The Power of Event-Driven Architecture
*(25:04) - The A2A Protocol—Google Cloud and Confluent
*(31:19) - Model Context Protocol (MCP)
*(34:13) - Agent Development Kit (ADK)
*(37:36) - Real-World AI Use Cases
*(42:20) - Key GenAI Features on Confluent Cloud
*(45:43) - Wrap-Up: Takeaways
Links & Resources:
Our Sponsor
Your data shouldn’t be a problem to manage. It should be your superpower. The Confluent data streaming platform transforms organizations with trustworthy, real-time data that seamlessly spans your entire environment and powers innovation across every use case. Create smarter, deploy faster, and maximize efficiency with a true data streaming platform from the pioneers in data streaming. Learn more at confluent.io.
About the Show
Hosted by Joseph Morais, Life Is But A Stream is for technology leaders looking to embrace the data revolution and transform their organizations through data streaming. Instant analytics, next level customer experiences, and business innovation that was previously unimaginable: it all starts with Life Is But A Stream.
Joseph: [00:00:00] Welcome to a very special episode of Life Is But a Stream. I have the pleasure of filming on-site today’s episode to discuss data streaming, streaming agent AI, and our fantastic strategic partnership with Google. My guest today is Sean Falconer. Sean, so nice to see you. Can you tell the audience your title here at Confluent and what your areas of focus are?
Sean: Yeah, absolutely. I’m the senior director of product, and I focus on AI and AI strategy at Confluent.
Joseph: Fantastic. So here at Confluent, we often say that AI problems are fundamentally data challenges. Can you unpack that for us?
Sean: Yeah. If we look at the data requirements for powering these types of models—especially as we’ve gone from the first wave of AI with purpose-built or statistical models to now foundation models and generative AI—most people working with foundation models are not [00:01:00] building models. We’re building applications on top of models. These are really powerful models. They’ve been trained essentially on everything that’s publicly available on the internet. There are only a handful of companies in the world that are going to do that work, and they package it up in this nice API.
As an application developer, I don’t need to know anything about deep learning or neural networks or how any of this was constructed. I essentially just call an API endpoint—that’s the only thing I need to know how to do—and I get this AI magic out of the box. And that works. It’s amazing.
But as powerful as the models are about general information, when it comes to your specific tasks, your specific needs, or information about your customer, they don’t know anything about that. They’re pretty dumb about your business, and the only way to get at that information is to feed it during something called prompt-time assembly with [00:02:00] a fresh representation of that information.
So if I want the model to do some sort of reasoning related to my customer, then ideally I’m giving it the freshest representation of my customers possible. Otherwise, it’s going to make decisions that are maybe not in the best interest of that customer or my business. Just like an employee operationalizing against static or stale information, it’s going to lead to mistakes—and you see the same thing with these models.
Joseph: Right. So if the objective is to present the freshest data, data streaming is a great way to achieve that. Mm-hmm. Speaking of continuous data flow, let’s take a step back with the basics. For our listeners who aren’t data engineers, can you describe what data streaming is—in the simplest terms you can give?
Sean: Yeah. I often use a Lego analogy. I have kids, so I naturally go to toys. If I wanted to build something out of Lego—or my kids wanted to build something out of Lego—there’s the mode where I can wait for the Lego factory to manufacture Lego, deliver it to a toy store, I go to the toy store, buy in bulk, and [00:03:00] bring it home. Then we try to build something. That’s like the traditional batch way of handling data. I collect all this stuff; now I have it all available to me, and we can start building.
An alternative would be that the place where Lego gets manufactured sends those bricks directly from manufacturing and distributes them to everybody who wants them. You fan it out to everyone as soon as the brick becomes available. That way, I don’t need to wait for all those bricks to get assembled, shipped to a toy store, and then retrieved to start the building process. I could be building as those bricks become available.
That’s really what data streaming is about: as information is being generated, I can [00:03:00] react to that data immediately, not wait for it to collect somewhere, and then access it.
Joseph: Right—the second I have that brick, I can be inspired. Yeah. I’ve been here for five years, and that’s the first time I’ve heard that analogy for data streaming, so I’m absolutely going to [00:04:00] steal it—just so you know. So why is this conversation so urgent right now? What is it specifically about agent AI that pushes traditional data exchange methods to the breaking point?
Sean: Yeah, I think there are a couple of things. One big thing is if you think about what an agent actually is—and there’s no widely agreed-upon definition, that’s true, and I’m not overly pedantic about it—I like to think of an agent as a software system that has some level of agency [00:04:00] to make dynamic decisions and is using these powerful models to help facilitate that dynamic decision-making. There are different levels of how dynamic and how fluid that really is versus something that’s completely deterministic, which is what the history of software has essentially been. We pre-program a bunch of if-then statements into the software, and it reacts based on that pre-programmed behavior. With agents, we’re using the model to do some level of dynamic decision-making, and in a lot of ways that mimics how humans think and process things.
So if I take a human process like crossing the street, I have [00:05:00] a lot of history of successfully crossing a street that I can draw upon—thousands and thousands of times.
Joseph: Evidenced by you being here right now.
Sean: Yes, exactly. So far, so good. I have this database—this long-term memory—I can draw upon. But if I don’t take into account what’s happening in the moment—if I closed off all my sensors: my eyes, my ears, maybe my sense of smell, I don’t know how much of a factor that is—and then tried to cross the street, I probably wouldn’t be here right now. So for human decision-making, you typically need a combination of factors: real-time sensory signal information—knowing what’s happening in the moment—as well as historical information, so that you can draw on patterns of behavior that you’ve successfully performed in the past.
I think the same thing applies to agents. We need to understand a customer’s history with us, right? But I also want to know what they’re doing in the moment—where they are [00:06:00] on my website, how they’re interacting with the product, those types of things. For most companies, they have decent data systems in place for historical data. We’ve been doing databases for 50-plus years. People understand that domain to some level. It’s not perfect—there are challenges—but people understand it.
The real-time side is something that a lot of companies have historically underinvested in as an overall strategy. Absolutely. But it becomes even more of a requirement when you’re trying to build these powerful AI systems.
Joseph: Yeah. It’s interesting when you use the analogy of the stoplight, or crossing traffic. In a controlled system, just following whether it’s green or not is sufficient. Mm-hmm. But we know that people run red lights. Yeah. So providing fresh data gives all the angles that allow this, like you said, non-deterministic system to make the right decision. I imagine at some point we’re going to get to the point where we don’t even really understand the thought process behind the LLMs. I [00:07:00] don’t—
Sean: I don’t think we do now.
Joseph: Right, I don’t think we do now. So providing it everything gives it an opportunity to do things we’re not even expecting it to do. I really think that’s the magic I’m seeing. Now, let’s talk about a core challenge: data exchange between agents built by different teams. What happens if we cannot find a way to effectively allow agents to communicate with each other?
Sean: I think it has similar characteristics to what we’ve seen with data systems historically. A lot of companies are plagued by data silos that get created. Different teams are running their own databases and data systems that don’t necessarily talk to each other—exchange information.
Joseph: Integration’s a big space.
Sean: Yeah, it is a multi-billion-dollar, maybe trillion-dollar market. So that has been a problem that’s existed for a long time. Okay. And we haven’t fully solved it. There are different approaches to trying to solve it, but it plagues a lot of companies. With AI, in particular AI agents, I [00:08:00] think we’re potentially creating a similar type of problem, but instead of data silos, they’re intelligent silos.
You have these islands of agents. I can have a bunch of agents built in one platform—maybe it’s my CRM—and a bunch of agents built on top of my warehouse. Maybe I have a team building agents and running them in the cloud using whatever agent SDK they want to build with. But if none of those communicate with each other, then you’re creating different intelligence silos and not sharing information.
If one team builds an agent that can analyze customer behavior to create a compelling offer, that could be useful in different parts of the business. You don’t want to keep rebuilding that agent over and over—just like APIs exist and we have good software architecture. One problem I see right now is everybody’s so excited to charge [00:09:00] ahead with AI that it’d sometimes be helpful to slow down a bit and think about this as a real investment as a company. What are the things from traditional software engineering and architecture that allow us to build scalable systems successfully? We have to apply those same platform learnings to building AI systems as well.
Joseph: Yeah, it makes a lot of sense. Isolated agents, isolated intelligence—it’s really just a next-generation data silo or integration challenge for the future generation. So let’s build these things the right way. Building on that idea of communication, let’s define a key term. What exactly is a streaming agent, and how does it differ from a siloed chatbot that many of our viewers are probably accustomed to interacting with at this point?
Sean: Yeah. A streaming agent is about embedding agent capabilities directly into the data stream. The way I like to think about it is these become the eyes and ears of the organization—the sensors that are reacting to business [00:10:00] events. A lot of what is being built today—and what people are used to interacting with—are more chatbot experiences. Part of that is you have a hugely successful consumer-facing product like ChatGPT. Absolutely. Now it’s strongly associated that the natural interface into AI is going to be a chatbot. Sometimes that makes sense, but there are many times where it would be better if something just understood when it should take action and understood my business events. If a customer is complaining about something, should I have to go and prompt a bot to find out, or should it automatically detect it?
Joseph: There are probably data points that can tell you this customer is calling into the call center constantly—things that could be, what’s the word I’m looking for—not implied, but deduced by an intelligence. That makes a lot of sense to stream it that way. So how does that lead into the streaming?
Sean: Yeah, and we’ve been doing that kind of thing for a long time with alerts and alarms that we set up [00:11:00] in our cloud systems or other systems. But they’re basically restricted to being a fire alarm for someone to go investigate. With streaming agents, you bring the agent capabilities to go beyond just alerting or some heuristic-based way of measuring that something happened or egressing that event to some other system. You’re bringing the agent to where the data exists, where the [00:11:00] real-time contextual data exists. You can always reach out to other systems—the static data is the easy part. How do you situate those workloads as close to the source of the information as possible so they can react in the moment and take a proactive stance?
At Confluent, we have customers that do these types of things for monitoring the supply chain. Historically, you wait until something goes wrong and then you react to it. But can you get ahead of those problems and take a proactive stance? That’s going to save you a lot of money and a lot of headaches, and even if a person is still involved, you can arm [00:12:00] them with the materials they need to start solutioning so you’re not leaving them in the dark to figure it out.
Joseph: Makes a lot of sense. Yeah. If we start with the streaming data, we’ve already figured out the hard part. You make the agents respond to the streaming data, but also give them the tooling to access static data—but as you said, that’s the easier part. Now I want to dive further into this idea of being stuck on an island. Could you give us a practical business example? Specifically, where do we see the negative consequences of a sales agent being unable to communicate with—or unaware of—a support agent?
Sean: Yeah. In that scenario, there are things in the sales system that are important signal information for the support side of the business—and vice versa. For example, if the customer’s at risk of churn—
Joseph: Yes.
Sean: —and you’re responding on either the sales side or the support side, that’s important information to know. But if that’s siloed somewhere, or an [00:13:00] agent can determine the person is at risk of churn but that determination only exists in one system, then I can’t take advantage of that intelligence in the other system. So we’re creating intelligence silos that can’t do this inter-ecosystem cross-communication.
Joseph: Yeah. You don’t want the sales agent to send a happy, friendly email like, “Hey, I hope you’re loving your system,” when you know they have four open support cases. That would be very inappropriate. But the way things work now, that is the reality. You could be having a terrible support experience, but you’re still going to get those marketing emails, which feel pretty bad in that scenario.
Sean: It’s a lot like the challenge around data freshness. If I have some AI system or marketing personalization that operates against a static representation of the customer, it might send an email like, “Go purchase this product,” when they actually did purchase that product. Now they’re frustrated because you’re telling them to buy something they just bought. I think [00:14:00] we run the risk of a similar level of frustration by creating silos in terms of the AI agents we’re building.
Joseph: So how does streaming architecture solve this? When do you enable agents to tap into the central stream of data, and what do they gain?
Sean: When you look at data streaming—Confluent has been in this game for a long time—it’s about becoming the central nervous system of different data systems; you’re moving data around. That’s really where Kafka was originally used: [00:15:00] how do you fan that out to all these different places? That’s very similar to cross-communication between agents, because a message between agents is just data. You’re moving that data from one agent system to another, whether that’s a multi-agent system that’s collaborating or agents that exist in different parts of the business. You can use data streaming to be the bridge where those agents’ shared language—the shared communication—becomes events. They’re just producing and consuming events, like we’ve seen with microservices for the better part of a decade.
Joseph: So talk to me more about shared context and system-level coordination.
Sean: Yeah. In terms of context for an agent: what are you giving the agent so it understands the task at hand? It’s like with people—if I walk up to someone randomly on the street and say, “Help me,” they don’t have context for what kind of help I need. I have to give more information, or they’ll think, “This person’s crazy—get me out of here.” It’s similar when you’re interacting with models. If I went to a model and just said, “Help me,” it’s not going to understand. But if I fed in a support doc and it had that context, it understands, “Okay, you’re probably talking about this particular feature,” or whatever the support doc is about. So you have to correctly contextualize it.
For shared context across multiple agents collaborating together: [00:16:00] one agent might take sales lead information—maybe that’s the original context—pull in additional information about that business, and then hand off the lead score to another agent that decides how to engage the person. Much of the contextual information pulled in by the first agent is relevant to the second agent that’s picking up the work. That’s where shared context comes in.
In terms of system coordination: think about multiple microservices interacting with dependencies. We can build those using RPC calls and point-to-point connections, but the downside is you end up with a quadratic explosion of dependencies. If one part of that graph goes down, the whole thing is impacted. It’s similar with agents. If we have a bunch of point-to-point [00:17:00] connections and one agent generates bad output that we don’t catch, it can have potentially catastrophic downstream effects. If one agent isn’t responding, that also impacts the entire system.
Event-driven architecture was designed to solve that problem. We decouple these things. We use events as the shared language, and we switch from direct orchestration to choreography, so we don’t have explicit dependencies. That’s really useful in AI systems as well, because building these successfully today involves lots of tests and iteration: you’re changing the prompt, the model, the context data—and you need to do this rapidly without impacting other dependencies. I want to be able to launch a sub-part [00:17:00] with a new version and test its behavior before I touch other parts of the system.
Joseph: Yeah. And with data streaming, the persistence and the fan-out all come back to [00:18:00] shared context and system-level coordination. It just makes sense as a substrate to facilitate those things.
Sean: And we talked a lot about fresh data and its importance. Absolutely. Even if the contextual data is fresh, the messages being sent between systems are also real-time data. That’s true—all data that gets generated is essentially real-time data.
Joseph: Right. It’s not accessed immediately—
Sean: It’s not accessed, but it’s [00:18:00] written immediately, right? Yeah. All data is essentially real-time. It’s true, but we’ve used batch systems and databases because we didn’t have a way to react and process effectively, historically. Now, a lot of those challenges are going away. We have tools like stream processing to compute on these things before waiting for them to land. Some of the investments that Confluent is making as a company, both in open source and within our products, have been about how to bring AI to these systems as well. [00:19:00] So I don’t have to wait for data to land somewhere before processing it within a model.
Joseph: I have some more product questions for you later—sure, we’re going to dive deeper into that. But I was just thinking: when you talked about what if one agent created bad data that would have catastrophic downstream effects, that’s where stream processing could be powerful—having stream processing in the middle that can do validation to say, “This is way off; this is clearly hallucination; I’m not going to let this get to the rest of the agents.” That could be an interesting tool.
Sean: Yeah, I think it’s a combination of stream processing and schemas that define output and data-quality rules. One reason the tip of the spear for AI—pushing the envelope—has been engineering is because there are ways of validating things like code. You can use a model to generate code; I can co-pilot it so I at least know it’s syntactically correct. I can run it, run unit tests, do integration tests—all these checks and balances to validate correctness. If it’s not correct, I can go back and ask the model again. In a lot of domains, we don’t have good systems to validate. That’s one of the things that’s [00:20:00] really hard when starting to productionize some of these systems, especially where inputs can be unbounded. How do I build a test set to validate outputs if those are also unbounded?
Joseph: Right. Yeah, it’s a complicated problem. I’m really interested to see how AI helps us fix those AI problems in the future. Now, once these agents are working together, what new—almost futuristic—capabilities can unlock for a business?
Sean: I think a lot of where we are today is about augmenting existing human processes. If an internal knowledge worker’s job is to look at multiple systems and stitch multiple pieces of data together just to get to a point where they can analyze the problem and start to solution it, models are very good at assisting in that process today. These look more like playbooks and workflows. I don’t think they’re fully agentic in the truest sense—there may be some dynamic decisions [00:21:00] about what data to pull in, what tools to access, or what actions to take—but a lot of it is about assisting a person on a specific task. There are a lot of companies being successful with that today. The truly agentic stuff that’s more aspirational is a lot harder to put into production in businesses.
Joseph: Especially using your example of unbounded data—and I imagine that’s where a lot of the use cases want to be. How do we validate that the answer we’re going to give a customer is a good one? With engineering, that’s straightforward. If it’s mathematics, that’s easy to check as well. But giving someone advice, or determining whether they qualify for a program—that’s a lot harder to validate. I’m really interested to see how that’s going to work. So, to use a music analogy, what can an orchestra of agents achieve that a solo performer never could?
Sean: The way I think about it—using another real-world analogy to build on yours—you don’t have one employee [00:22:00] in a business who does everything. You have a team of people who work together, coordinate, and have specialized skills to help you solve complex problems. As you add more people, there are communication challenges—that’s where the data infrastructure points we’re talking about come into play, and good design around an event-driven system.
When it comes to agents, there are lots of downsides to building a monolithic system—just like there are downsides to monolithic software. You’re tasking one agent with many goals and tasks. Just like a person gets confused by that, models get confused as well. Studies show that if you give models too many things to do—too many tools, too many options, too large a context—they remember maybe the beginning and the end. It’s similar with people: if I give you a list of 100 items, you might remember the first couple and the last couple; you probably don’t [00:23:00] remember the middle. It’s easier for me to ask you to complete one thing, then ask someone else to complete one thing.
The same applies to agents. To build these things with trust and reliability, make them more task-oriented. It’s somewhat akin to building purpose-built models in traditional ML. You’re not necessarily restricting a model to one task forever—the model can still be used for different tasks—but for a particular agent’s role, you make it task-specific so you have more confidence in what it produces. That also helps you [00:23:00] figure out how to test it. If the agent’s one job is to score a lead, I know the score should be between 1 and 100. I know the input is a lead—anything that’s not a lead shouldn’t be processed. Any output not between 1 and 100, I can ask it to reprocess, or go look at why it made a mistake. I’m not polluting the entire system with misinformation.
Joseph: Even from an engineering standpoint, it makes sense to break everything up into smaller agents because how do you make tweaks, right? Think about monoliths versus microservices. You may have teams that own the prompts for these three agents, but not the next ten. You wouldn’t want to change a prompt in a mono-agent—we already know that’s bad methodology. Breaking it down, in addition to the reasons you stated, makes a lot of sense.
Sean: Yeah. I think it’s just good software engineering—practical computer science skills applied to building agents, just like they’ve historically applied to any software system.
Joseph: Absolutely. So now that we’ve established the power of connected agents, let’s discuss A to A, the now open-source agent-to-agent communication protocol. What was [00:25:00] the origin story here, and what problem was it specifically designed to solve?
Sean: Yeah. Google originally came up with this protocol earlier this year, and now it’s been donated to the Linux Foundation. There are a number of companies contributing to it. It was originally designed to solve the islands-of-agents problem we talked about earlier. If we believe enterprise businesses are going to have thousands of different agents running in different systems built by different teams, how do we avoid creating different intelligence silos? How do we facilitate inter-ecosystem communication across platforms? Google is trying to get in front of this problem. A lot of businesses may not be feeling the pain yet, but it’s probably [00:26:00] imminent for many companies as they invest in more of these AI systems.
Joseph: Makes a lot of sense. Speaking of the protocol, we have a fantastic clip from [00:26:00] Merlin, from Google, breaking this down. Let’s roll that now.
Speaker: I’m Merlin Yi, Generative AI Partner Engineering Lead at Google Cloud. Agent-to-Agent, or A2A, protocol is Google’s answer to this islands-of-agents problem. It’s an open protocol that lets agents describe their capabilities, negotiate how to work together, and actually collaborate—no matter who built them. It’s designed specifically to handle the dynamic and long-running nature of agent collaboration with enterprise use in mind, delivering a secure and governed experience.
How does the Google and Confluent partnership benefit you? Together, we provide seamless integration of Confluent’s real-time data streaming with Google’s AI ecosystem, including models, vector stores, BigQuery, and more. Without fresh, real-time data, you can’t [00:27:00] build reliable AI systems; and without models and powerful infrastructure to run those models at scale, you can’t make the data do anything of value to your business.
Joseph: So Merlin mentioned that you need both fresh data and powerful infrastructure to make reliable agentic systems. What are your comments on that clip?
Sean: Yeah, we touched on the need for fresh data earlier in the conversation. Clearly, if I have an AI system making decisions about customers—real-time product personalization, deciding that [00:28:00] an alarm went off in my infrastructure and I need to wake some poor on-call engineer at two in the morning—all those decisions have to have fresh representations of the data in order to be intelligent, just like humans do.
In terms of powerful infrastructure, there’s a lot involved in just running these agents reliably. Agents not only depend on a non-deterministic model to make certain decisions, but typically they also rely on a lot of APIs—tool calls—with models deciding what parameters to pass. You end up with a large-scale distributed systems problem, which people have historically solved using event-driven designs and systems like Kafka to decouple, to have history, to retry when mistakes or faults happen—how do you roll back the tape and [00:28:00] make it happen again? Those problems become even more prevalent when you’re building these agentic systems. That’s really what I think Merlin’s talking about.
Joseph: And more simply—I’m a simple ops guy—you need somewhere to run your agents. You need scaffolding, a system to do that.
Sean: Yeah. There’s all this message passing happening, all the communication with external and internal systems. There’s a lot going on, and you don’t really want all that data to live and die on the vine of [00:29:00] a single network call. Ideally, you’re fanning those out to multiple systems because you’re going to need observability and logging on top of that. And you don’t want all that data to eventually hit a database and then hammer the database to fan out to all these places.
Joseph: Absolutely. Let’s talk a bit deeper about A to A.
Sean: Yeah. With agent-to-agent, you have an agent running [00:30:00] in one environment, and it provides a definition of how that agent can communicate with other agents. Other agents can advertise their capabilities so the model can decide, “This agent over here has the information I need, or can calculate what I need; I’ll go talk to it.” But how do you deliver the contextual data and trigger that agent to do something? You could do it with direct HTTP calls or RPC—point-to-point—but then you have all the downsides of point-to-point that we’ve seen for decades.
If you back that with an event-driven design, you can still call the agent, but you also get history, fan-out to multiple systems, retries, and reliability built in. A big part of building reliable agents is being able to test new versions. If you’re using something like an immutable log—or Kafka—as the backbone, you can replay those logs with the new version [00:30:00] so you get what you want. It becomes a way to build evals based on live data.
Joseph: Makes a lot of sense. There are a lot of nice characteristics.
Sean: Yeah—characteristics we’ve used historically for powering microservices for a long time, and they apply here as well.
Joseph: I think that’s the core of it. The reason people have driven toward event-driven architecture is the benefits, especially when you’re talking about compartmentalized compute—in this case, compartmentalized intelligence. So if in doubt, think about how you build microservices—you should build your agents the same way. Now, we know how and why agents should talk to each other, but what about everything else? How does MCP—the Model Context Protocol—allow agents to access other critical resources like a vector database or a traditional API?
Sean: MCP—the Model Context Protocol from Anthropic—was a standard proposed last year around November, I believe. The problem it tries to solve is similar to agent-to-agent, but specific to tools. If I’m building an agent, a characteristic is that the model can decide what data to pull in [00:32:00] or what actions to take. Those are tool calls. I can define to the model: here are the API endpoints or functions available, here are the parameters, and the description of the functionality. The model then decides whether it needs to call one of these to get enough information to accomplish its goals. It goes through a reasoning loop. The model doesn’t call the tool directly; it passes back, “Here’s the function you should call and the parameters.”
If I’m building one agent that talks to three tools—no problem. I can hand-code that. But as soon as my business builds 10 agents that talk to some of the same tool endpoints plus new ones, you get an explosion of point-to-point connections between similar tools, and I can’t take advantage of another team’s integration. There’s no standard; everyone is writing bespoke code to interconnect systems. It’s like data ingestion—if everyone writes their own ingestion scripts, it becomes a lot to manage and adds technical debt. The same thing is happening with agents already; it doesn’t take many agents before you start to feel this tool-pain.
MCP standardizes tool calling. It’s a client–server model. The agent has an MCP client. When it spins up, it knows which servers it can talk to and does a handshake. The servers say, “Here are my capabilities and tools, with descriptions.” That context is taken into account when the model is called; then the model decides, “Go talk to this tool at this endpoint,” and the client knows how to translate that.
Joseph: That makes a lot of sense. So MCP is about enabling the individual agent—though an MCP server might be used by multiple agents—for tooling. A to A is about empowering agents to be aware of and communicate with each other. While both are powerful together, how does a developer get started building one of these agents? Let’s talk about the Agent Development Kit, or the ADK. What does it provide?
Sean: An Agent Development Kit gives you an abstraction for how to put together an agent. In whatever programming language you choose, you define an agent class or object and specify: here’s the role you perform, here are the tools you have or the MCP servers you have. The toolkit takes on the responsibility of running that agent, doing the inference loops, calling the tools or MCP servers. You don’t have to build that yourself—it’s abstracted away. You’re defining things with a fairly high-level abstraction, most of it expressed in natural language: “Here’s your role, here are the tasks, here’s additional context.” The tool calling, looping, and inference loops are abstracted.
Joseph: Makes sense—gives you not only the toolkit but the framework to start building agents and implementing things like A to A and MCP. Now talk to me about the Google and Confluent partnership. How does our better-together story provide customers with a complete end-to-end solution for building real-time multi-agent AI systems?
Sean: Great question. We’re focused on enabling customers to tap into the sources of their data. A lot of operational systems—whether you’re doing CDC from a database or collecting mobile app data—produce user behavior data flowing through your data streams today. You can use things [00:36:00] like stream processing to build various signals and understanding of what’s happening.
With Google, they’re providing tooling through things like A to A, where we can do cross-platform communication. You could use a streaming agent built in Confluent Cloud, and that streaming agent could communicate with agents externally through something like A to A that you’re building using an ADK—because another team decided that was the right framework for them.
Joseph: Excellent. So the combination of technologies really gives end customers the freedom to build anything and everything they want.
Sean: Yeah. I think you want to give people the ability to be adaptable—especially right now, where we’re trying to build beautiful [00:37:00] castles on a fragile foundation that’s kind of shaky and has some cracks because the models are changing all the time. The approaches and frameworks are shifting all the time. So you have to build and architect for adaptability from the get-go. That’s why I keep preaching event-driven design—because you can decouple these systems, microservices, and so on. You have to be thinking at the system-design level when composing these things.
Joseph: Yeah. You don’t want your castle to slide into the ocean.
Sean: Yeah.
Joseph: We’ve covered a lot of ground, and I think for many people, real-life use cases or examples will tie everything together. Taking these pieces—data streaming, streaming agents, A to A, and the tooling—how could these come together to solve a problem for a retail company?
Sean: In retail, a lot of people are interested in highly personalized experiences. Retailers have been doing this for a long time in some fashion with traditional ML and other techniques. But now, with these powerful models and agentic systems, you can make it really personal and reactive if you treat this as real-time data. [00:38:00] As someone’s on my site—maybe they put certain things into a cart, or they’ve looked at certain product pages for a while—all that information, those events, retailers are already using and sending over data streams. There’s so much visibility into what customers are doing on a website or mobile app. You can use stream processing to figure out the signal that should trigger engagement—maybe after 10 minutes lingering on a product page, you decide how to nudge the person forward.
When you build agents directly in the stream, that streaming agent could do real-time price analysis against competitive products. You could bring in other information about the customer based on past purchase history to create a compelling offer. In e-commerce, if you’ve captured someone’s attention and their eyeballs, you don’t want to wait— [00:39:00] not even an hour or the next day, or send an email next week. You’re throwing money away at that point. You want to do it in the moment, but you don’t want to send something noisy—you want something personal.
Joseph: Right—even an email that doesn’t look like the next person’s email. Right now they’re all templatized. But with AI, you could have something—maybe even get signals that seem scary to some people—but really target a communication to get that person’s interest. I think that’s interesting. Let’s tap another industry. Do you have examples for financial services or industrial IoT?
Sean: Common things: take IoT or even manufacturing. Historically, many of those companies use event streaming to get signal information off [00:40:00] devices. They’re collecting a lot of information, but they also want to know if devices are at risk of failing. Can you self-heal? Can you self-diagnose? Those become the natural extension of past rudimentary approaches—into agentic workflows where you can solution, offer suggestions, or even take actions to self-heal or fix problems.
Joseph: Or maybe don’t trigger actions just on a high or low watermark—maybe you trigger based on rate of change, or external metrics we couldn’t simply put into an if-then state.
Sean: Yeah. Think about real-time [00:41:00] inventory balancing—between different factories or retailers. If you have multiple branches in a geo, one place is running out of toilet paper and another has a surplus. Those are important signals. You can fix that if you architect it correctly and use the right data systems.
Joseph: Even external news—like a sudden lumber shortage—which may not appear on an inventory report. If an agent had access to that, it might predict downstream problems: “Let’s get in front of this. Let’s over-order because this product line will be affected.”
Sean: Those signals are really important in financial services—trading and so on. Quants have built systems like that for a long time. Now, with powerful models and the systems we’re building to process information, you empower more people to build sophisticated systems that previously only [00:42:00] a handful of companies or specialists could build. You’re enabling broader adoption of highly effective systems.
Joseph: To make these use cases easier to achieve, let’s discuss key GenAI features on Confluent Cloud that are available today, helping developers build, deploy, and manage these complex systems. Can you take us through those features?
Sean: Absolutely. We’ve been trying to bring AI closer to data streaming because there’s a lot of rich, valuable information flowing in streams—signals about what your customers are doing, and so on. You want those systems to be as reactive as possible so you can be proactive as a business.
In terms of features, we now have built-in ML functionality—easy buttons for AI. I can do anomaly detection with a function; I can do forecasting—things many businesses have used for a long time. [00:43:00] On the GenAI side, we’ve had support for using AI models directly within our managed Flink offering for a long time, and we’ve contributed to open source. Now I can bring the full weight of a foundation model into the data stream to do things like real-time inference. For example, take product reviews flowing in and do real-time thematic analysis, real-time sentiment analysis, or scoring to figure out if there’s a problem we should get ahead of—without making it a post-analysis step.
Even at Confluent, the way we do lead scoring: sales leads flow through Salesforce to a Kafka topic; then we use Flink and inference against the lead-scoring model to score those and have a real-time feed of lead quality. A natural extension is: how do we action those leads? [00:44:00] That’s where our Streaming Agents product comes into play—we can go beyond one-shot inference to support full agent systems that operate on the stream, do tool calling, support MCP—all the standard things you see in an agent framework.
Joseph: That’s what exists today. How about a peek at what’s on the horizon? What upcoming tooling or features are you most excited about in Confluent Cloud in the context of agent AI?
Sean: I’m really excited about continued enhancements around Streaming Agents. It’s a recent launch for us. We have a lot of customers engaged with it; people are excited, I’m excited, the team’s excited—which is great—but there’s still a lot of work to be done. We’re working on making it a delightful developer experience, adding traditional semantics, supporting other protocols and standards like A to A for inter-agent communication, and so forth. [00:45:00]
Also, these things don’t exist in silos—they’re ecosystems. You don’t build an AI system with one vendor. So there’s a partnership angle as well: building those partnerships, making integrations available so you have easy buttons. I talked about easy buttons around anomaly detection and forecasting, but I think agents should also eventually be easy buttons that anybody can leverage.
Joseph: Absolutely. Like you said before about these systems being limited to a small pocket of people—the more accessible we make agents, the better the future of agent AI will be. To wrap up, what’s the single most important takeaway you want our audience to remember about the future of AI and the critical role that data streaming plays in it?
Sean: I think the biggest thing is understanding why [00:46:00] fresh information is critical for building these systems. It’s not always thought of that way because historically we’ve used traditional ML and analytics and we bucket foundation models and agents into a post-analysis step. But these are not dashboards. They can be dashboards—that’s a use case—but if you want to truly transform your business, take a proactive approach, and augment your existing workforce to help them be more efficient—reacting to actual business events—you need to change your mindset. Think about how to [00:46:00] take a proactive stance and know what’s going on in your business. Shift a lot of that responsibility left.
We’ve seen that shift-left stance in many businesses over the last several decades—certainly in my lifetime. When I first started as an engineer, testing was: you write code, check it in, throw it over the wall to QA, and they test it, find problems, and throw it back. [00:47:00] Now we’ve shifted responsibility left. If you told engineers then that they’d be responsible for testing, they’d say, “No way.” But we did it because the creator of the code is better positioned to figure out what the tests should be. QA didn’t go away—people still QA—but now you leverage them for more than basic testing.
I think data has to go through a similar transformation: shifting the definition of the data product, the schemas, all that, left—closer to the source. Those people have more knowledge about what the data is. If you do that, it opens up new use cases around AI and agentic AI that every company wants to invest in—but most companies aren’t ready to take advantage of—because their data systems aren’t ready.
Joseph: Yeah. If you understand the source of your data and the challenges you’re trying to address with that data, suddenly you’re building better systems. Well, thank you [00:48:00] so much, Sean. I really appreciate the time, and that was extremely insightful. For everyone, thank you for joining us for this very special edition of Life Is But a Stream. I’m your host, Joseph Morais, and as always, happy streaming.