Confluent’s Real-Time Agents Build on Kafka Streaming Data
Today, Confluent unveiled its Streaming Agents feature in open preview in Confluent Cloud. The new functionality allow organizations to select models, engineer prompts, specify tools and sources, implement testing, and provide data enrichment for event-triggered, multi-agent AI systems.
Confluent’s addition to the AI agent-based paradigm is memorable for two reasons. Firstly, it’s designed to realize the full vision of the promise of smart agents by equipping them with the most recent data available from the platform’s Apache Kafka underpinnings, endowing agents with the latest situational intelligence.
Secondly, it inverts the model in which humans trigger AI agents (typically via natural language prompts to chatbots) to full-fledged event-triggered agents reacting to low-latency enterprise data.
According to Sean Falconer, Confluent‘s head of AI, Streaming Agents are partly designed to propel the enterprise closer to a reality in which AI is characterized by “ambient, event-driven agents that are embedded in your infrastructure, monitoring the state of the business, and reacting based on the changes of that state. And then, reacting to those changes, investigating issues, and taking action.”
As such, these AI-powered agents may provide the “eyes” and “ears” for organizations to glean the latest data-driven developments impacting business cases, before ensuring intelligent systems adapt to them immediately. By coupling the storage and messaging capabilities of Apache Kafka with the analytics, AI models, and Streaming Agents found in Confluent Cloud for Apache Flink, Confluent’s new agent feature has the potential to do just that.
Building Agents in Flink
Confluent users can construct Streaming Agents via a straightforward process in Confluent Cloud for Apache Flink. Flink provides the compute for agents to interact with tools through MCP, the emergent standard for agents calling out to resources. Confluent users can connect to MCP, vector and SQL databases, and API endpoints directly from Confluent Flink “securely and we’ll manage any of those endpoints for you,” Falconer said.
Flink is also where organizations can specify the actions they want agents to take and access Confluent’s array of models (including those from Gemini, OpenAI, and Anthropic) to fortify those agents. “Typically, you’re using one or more models and that’s where the process of building an agent begins: which model is it going to use,” Falconer said.
System and Task Prompts
In Confluent Cloud for Apache Flink, users also define the prompts for agents, which is a bilateral concern that’s part of the overall context engineering process. Prompts for agents include system prompts, which indicate what role an agent will play within a larger process, and prompts that define the job characteristics agents are expected to perform.
For example, one might issue a system prompt that “this agent is an expert in writing emails, and you also give it explicit instructions about what you want it to do, like write an email based on the following input that describes this particular user,” Falconer said. The prompt delineating the job characteristics narrows the scope of the agent’s actions while codifying its inputs and outputs. “If I’m scoring a lead, then I know the input is going to be a lead and the output should be a score between one and 100,” Falconer said. “If the output is wildly off, I can catch it at that very moment, which makes it easier to test and evolve these things.”
Kafka Communication and Storage
Despite its considerable reliance on Confluent Cloud for Apache Flink, much of the appeal of Streaming Agents lies in its Kafka foundation for inter-agent communication. Instead of utilizing protocols like A2A, Streaming Agents employ Kafka for agents to hand off different parts of a workflow to complete a larger task — like detecting network failure for a telecommunications provider.
Hinging on source data like weather reports, IoT sensors, and more, the initial inputs for this use case are “multiple events coming in from heterogeneous inputs that represent the state of the business,” Falconer mentioned. “Once an agent takes that data, it also talks to some external system to gather some additional context. Then it spins out an output which probably fans out to multiple systems, including other agents, where those agents then operationalize the output.”
Typically, the initial events Falconer described land in Kafka topics, from where that data may be routed to Flink for aggregation, processing, or analytics. Once that data is taken by an agent for its role in the use case, the agent then returns that data to Kafka (more than likely to different Kafka topics than the original one, Falconer indicated).
The new topics data then prompts other agents to act in this continuum. Kafka’s messaging and storage capabilities are equally valuable for this aspect of Streaming Agents deployments and provide “traceability between agent one and agent two,” Falconer commented. “If I want to know what agent one said to agent two and I need to change agent two with a new prompt or model, or evolve it in some some way, or if I want to be able to go back and replay the history of communication so I can test it against real traffic to see if that’s actually improving the outputs, you get all these replayability properties out the box by using Kafka.”
Testing and Enriching Agents
Confluent also provides dark launch support as part of its testing capabilities for Streaming Agents. Via the dark launch paradigm, an agent operates in production traffic, but doesn’t interact with end users. Organizations can have this agent in production systems, then launch a second version of it, perhaps with a different model or different prompts, and gauge the performance of the second one without affecting operations.
The original agent “is doing things like providing data to interact with users, while the other is processing the messages and generating outputs so you can measure its performance to see if version two is better than the second one,” Falconer explained. Users can also subject agents to A/B testing in Confluent’s environment, and enrich the data they access through Confluent’s external tables. With this construct, users can remain in Confluent and query external tables (like those in MySQL) and access the results in the streaming data platform.
Enterprise Eyes and Ears
By augmenting agents with real-time streaming data, Confluent is increasing the capabilities of these digital tools to act on behalf of the enterprise. Falconer likened this real-time intelligence to the eyes and ears of the enterprise, while juxtaposing it with that derived from historical data.
“Most business cases need both,” Falconer revealed. “Historical data, what the customer did six months ago, and what they’re doing right now while they’re on my website.” If AI-infused agents have that same information, they have tremendous potential to work in concert to optimize business results and organizational objectives.
