Enterprise AI brokers as we speak face a elementary timing drawback: They’ll't simply act on vital enterprise occasions as a result of they aren't all the time conscious of them in real-time.
The problem is infrastructure. Most enterprise information lives in databases fed by extract-transform-load (ETL) jobs that run hourly or day by day — finally too sluggish for brokers that should reply in actual time.
One potential strategy to sort out that problem is to have brokers immediately interface with streaming information methods. Among the many major approaches in use as we speak are the open supply Apache Kafka and Apache Flink applied sciences. There are a number of business implementations based mostly on these applied sciences, too, Confluent, which is led by the unique creators behind Kafka, being one in all them.
Right this moment, Confluent is introducing a real-time context engine designed to unravel this latency drawback. The expertise builds on Apache Kafka, the distributed occasion streaming platform that captures information as occasions happen, and open-source Apache Flink, the stream processing engine that transforms these occasions in actual time.
The corporate can also be releasing an open-source framework, Flink Brokers, developed in collaboration with Alibaba Cloud, LinkedIn and Ververica. The framework brings event-driven AI agent capabilities on to Apache Flink, permitting organizations to construct brokers that monitor information streams and set off routinely based mostly on situations with out committing to Confluent's managed platform.
"Today, most enterprise AI systems can't respond automatically to important events in a business without someone prompting them first," Sean Falconer, Confluent's head of AI, instructed VentureBeat. "This leads to lost revenue, unhappy customers or added risk when a payment fails or a network malfunctions."
The importance extends past Confluent's particular merchandise. The business is recognizing that AI brokers require totally different information infrastructure than conventional functions. Brokers don't simply retrieve info when requested. They should observe steady streams of enterprise occasions and act routinely when situations warrant. This requires streaming structure, not batch pipelines.
Batch versus streaming: Why RAG alone isn't sufficient
To know the issue, it's vital to tell apart between the totally different approaches to transferring information by way of enterprise methods and the way they will hook up with agentic AI.
In batch processing, information accumulates in supply methods till a scheduled job runs. That job extracts the info, transforms it and hundreds it right into a goal database or information warehouse. This would possibly happen hourly, day by day and even weekly. The method works nicely for analytical workloads, nevertheless it creates latency between when one thing occurs within the enterprise and when methods can act on it.
Information streaming inverts this mannequin. As an alternative of ready for scheduled jobs, streaming platforms like Apache Kafka seize occasions as they happen. Every database replace, consumer motion, transaction or sensor studying turns into an occasion revealed to a stream. Apache Flink then processes these streams to hitch, filter and combination information in actual time. The result’s processed information that displays the present state of the enterprise, updating constantly as new occasions arrive.
This distinction turns into vital when you think about what sorts of context AI brokers really want. A lot of the present enterprise AI dialogue focuses on retrieval-augmented technology (RAG), which handles semantic search over data bases to seek out related documentation, insurance policies or historic info. RAG works nicely for questions like "What's our refund policy?" the place the reply exists in static paperwork.
However many enterprise use circumstances require what Falconer calls "structural context" — exact, up-to-date info from a number of operational methods stitched collectively in actual time. Think about a job advice agent that requires consumer profile information from the HR database, shopping conduct from the final hour, search queries from minutes in the past and present open positions throughout a number of methods.
"The part that we're unlocking for businesses is the ability to essentially serve that structural context needed to deliver the freshest version," Falconer mentioned.
The MCP connection drawback: Stale information and fragmented context
The problem isn't merely connecting AI to enterprise information. Mannequin Context Protocol (MCP), launched by Anthropic earlier this 12 months, already standardized how brokers entry information sources. The issue is what occurs after the connection is made.
In most enterprise architectures as we speak, AI brokers join by way of MCP to information lakes or warehouses fed by batch ETL pipelines. This creates two vital failures: The info is stale, reflecting yesterday's actuality reasonably than present occasions, and it's fragmented throughout a number of methods, requiring important preprocessing earlier than an agent can motive about it successfully.
The choice — placing MCP servers immediately in entrance of operational databases and APIs — creates totally different issues. These endpoints weren't designed for agent consumption, which might result in excessive token prices as brokers course of extreme uncooked information and a number of inference loops as they attempt to make sense of unstructured responses.
"Enterprises have the data, but it's often stale, fragmented or locked in formats that AI can't use effectively," Falconer defined. "The real-time context engine solves this by unifying data processing, reprocessing and serving, turning continuous data streams into live context for smarter, faster and more reliable AI decisions."
The technical structure: Three layers for real-time agent context
Confluent's platform encompasses three parts that work collectively or adopted individually.
The true-time context engine is the managed information infrastructure layer on Confluent Cloud. Connectors pull information into Kafka subjects as occasions happen. Flink jobs course of these streams into "derived datasets" — materialized views becoming a member of historic and real-time alerts. For buyer help, this would possibly mix account historical past, present session conduct and stock standing into one unified context object. The Engine exposes this by way of a managed MCP server.
Streaming brokers is Confluent's proprietary framework for constructing AI brokers that run natively on Flink. These brokers monitor information streams and set off routinely based mostly on situations — they don't look forward to prompts. The framework contains simplified agent definitions, built-in observability and native Claude integration from Anthropic. It's obtainable in open preview on Confluent's platform.
Flink Brokers is the open-source framework developed with Alibaba Cloud, LinkedIn and Ververica. It brings event-driven agent capabilities on to Apache Flink, permitting organizations to construct streaming brokers with out committing to Confluent's managed platform. They deal with operational complexity themselves however keep away from vendor lock-in.
Competitors heats up for agent-ready information infrastructure
Confluent isn't alone in recognizing that AI brokers want totally different information infrastructure.
The day earlier than Confluent's announcement, rival Redpanda launched its personal Agentic Information Airplane — combining streaming, SQL and governance particularly for AI brokers. Redpanda acquired Oxla's distributed SQL engine to present brokers customary SQL endpoints for querying information in movement or at relaxation. The platform emphasizes MCP-aware connectivity, full observability of agent interactions and what it calls "agentic access control" with fine-grained, short-lived tokens.
The architectural approaches differ. Confluent emphasizes stream processing with Flink to create derived datasets optimized for brokers. Redpanda emphasizes federated SQL querying throughout disparate sources. Each acknowledge brokers want real-time context with governance and observability.
Past direct streaming rivals, Databricks and Snowflake are basically analytical platforms including streaming capabilities. Their energy is complicated queries over giant datasets, with streaming as an enhancement. Confluent and Redpanda invert this: Streaming is the muse, with analytical and AI workloads constructed on high of information in movement.
How streaming context works in follow
Among the many customers of Confluent's system is transportation vendor Busie. The corporate is constructing a contemporary working system for constitution bus corporations that helps them handle quotes, journeys, funds and drivers in actual time.
"Data streaming is what makes that possible," Louis Bookoff, Busie co-founder and CEO instructed VentureBeat. "Using Confluent, we move data instantly between different parts of our system instead of waiting for overnight updates or batch reports. That keeps everything in sync and helps us ship new features faster.
Bookoff noted that the same foundation is what will make gen AI valuable for his customers.
"In our case, each motion like a quote despatched or a driver assigned turns into an occasion that streams by way of the system instantly," Bookoff said. "That stay feed of data is what is going to let our AI instruments reply in actual time with low latency reasonably than simply summarize what already occurred."
The challenge, however, is how to understand context. When thousands of live events flow through the system every minute, AI models need relevant, accurate data without getting overwhelmed.
"If the info isn't grounded in what is going on in the actual world, AI can simply make incorrect assumptions and in flip take incorrect actions," Bookoff said. "Stream processing solves that by constantly validating and reconciling stay information in opposition to exercise in Busie."
What this means for enterprise AI strategy
Streaming context architecture signals a fundamental shift in how AI agents consume enterprise data.
AI agents require continuous context that blends historical understanding with real-time awareness — they need to know what happened, what's happening and what might happen next, all at once.
For enterprises evaluating this approach, start by identifying use cases where data staleness breaks the agent. Fraud detection, anomaly investigation and real-time customer intervention fail with batch pipelines that refresh hourly or daily. If your agents need to act on events within seconds or minutes of them occurring, streaming context becomes necessary rather than optional.
"While you're constructing functions on high of basis fashions, as a result of they're inherently probabilistic, you utilize information and context to steer the mannequin in a route the place you need to get some sort of consequence," Falconer said. "The higher you are able to do that, the extra dependable and higher the result."
