Content
Picture an AI agent approving a refund at 9:02 a.m. based on an order status last synced at midnight. The package shipped at 7:40. The agent answered in under a second, got it wrong, and nobody will notice until finance closes the month.
That gap between what your systems know and what is true right now is the story behind Confluent Current 2026. Once AI acts on orders, claims and payments, the age of its data turns into a cost you can count in refunds and write-offs.
Current San Francisco 2026 runs November 4-5 at Moscone West, with 80+ sessions on Apache Kafka, Apache Flink and Apache Iceberg. It is also the first Current since IBM closed its Confluent acquisition in March, which puts data streaming in the same budget conversation as IBM MQ, webMethods and IBM Z.
Our position going in: real-time data counts as AI infrastructure for decisions where stale data costs money, and only when access control, audit and recovery come with it. Below are the two themes we will watch this week and the questions we will put to every announcement.
Why Confluent Current 2026 matters now
If your transactions still run through MQ or a mainframe, streaming used to be a side project for the cloud team. That changed this year. Current 2026 is Confluent’s first conference as part of IBM, with AI agents at the top of the agenda, so the question for buyers has moved from “is Kafka fast?” to “can we feed live data to AI inside the estate we already run, without adding risk?”
What the Confluent IBM deal changes
When IBM closed the deal on March 17, it named four integration points: watsonx.data, IBM MQ, webMethods Hybrid Integration and IBM Z. For an IBM shop, event streams could now sit right next to the systems that hold orders, accounts and policies.
On October 28, IBM followed with watsonx.data integration for Apache Flink. Engineers can design stream-processing jobs in a visual editor, with AI help or in Python, and run them as native Flink jobs on Confluent Platform. IBM also lists pipeline validation, failed-record routing and schema-change handling, and says openly that scarce Flink skills hold teams back.
A longer product list does not tell you how much integration work is left. That is what we want Current to show.
Survey numbers worth reading twice
Confluent’s 2026 Data Streaming Report surveyed 4,625 IT leaders in 14 countries. It is vendor research with a global sample, so read the figures as what respondents believe, not as a US benchmark:
| What respondents reported | Share |
|---|---|
| Insufficient real-time processing infrastructure is a challenge in scaling AI | 72% |
| Unsure about data lineage, timeliness and quality | 66% |
| Data ownership is fragmented | 65% |
| Agentic AI already in production | 32% |
Rows two and three say more than the headline. In most enterprise data programs the hold-up is rarely speed. Usually no one owns the data end to end, and no one can vouch for what feeds the model. Our AI-ready data checklist starts there.
Much of the AI story is six months old
Several capabilities likely to feature in this week’s keynote were announced earlier in the year:
| Date | Already announced | Stated maturity |
|---|---|---|
| May 19 | Real-Time Context Engine, Streaming Agents, Agent Management Console | GA |
| Aug 18 | REST “lightning queries” for the context engine | Early access |
| Aug 18 | IBM Granite and Google TimesFM time-series models | Early access (AWS) |
| Sep 15 | Streamhouse Working Group (Aiven, Confluent, Redpanda, StreamNative, Ververica) | Industry initiative |
| Oct 28 | IBM watsonx.data integration for Apache Flink | Announced |
When the keynote turns to agents, check what is new since May: a new capability, a move from early access to GA, or support in more clouds and regions. Anything else is a May announcement with new slides.
Theme to watch: event-driven architecture for AI agents
Most AI pilots wait for someone to type a question. The processes that cost you money do not wait: a shipment slips, a credit limit changes, a machine starts to vibrate. Event-driven architecture lets AI respond to those changes as they happen. Whether the response is safe still depends on schemas, idempotency, recovery and access control, and an agent adds one more consumer that can also take action.
From prompts to business events
AWS defines event-driven architecture as decoupled services that publish and consume events. Services scale independently, though asynchronous flows get harder to trace when something breaks.
An event can trigger many things, and few of them need autonomy. It might fire a fixed rule, start a predefined workflow, ask a model for an assessment or hand work to a tightly scoped agent. Anthropic’s advice on building effective agents is to pick the simplest design that works, and for plenty of processes that is still a deterministic rule running on fresh data.
Four lines your architecture has to keep
- Events and commands.
OrderCancelledrecords a fact.IssueRefundasks for an action. Keep a hard boundary between what an agent may observe and what it may do. - Data changes and business meaning. CDC tells you a row changed. Someone still has to rebuild transaction boundaries, entity identity and deletes before an agent can interpret that change.
- Choreography and orchestration. Loosely coupled reactions suit simple flows. Claims, refunds and other long, high-impact processes need explicit coordination and a named owner.
- Replay and re-execution. Replaying events into a dashboard is harmless; replaying a refund costs money. Kafka’s delivery semantics give exactly-once processing between Kafka topics, while writes to outside systems need their own safeguards.
The fourth point is the one to raise with your board. An agent that can issue refunds needs a mechanism that stops it from issuing the same one twice after a timeout. It is the problem we described in Agent Sprawl Is an Integration Problem, with events now in the loop.
Two sessions on our list
The published lineup has several relevant talks. We are watching two:
- Kafka as the Agent Action Log: Replay, Recovery, and Observability for AI Agents. We want to see how replay avoids repeating side effects.
- The Guarantee Gap: Kafka Connect, S3, and the Illusion of Exactly-Once. A talk on where delivery guarantees stop, scheduled at the vendor’s own conference. If your team attends one session, make it this one.
Not sure which processes need real-time data?
In 30 minutes we look at your event streams, MQ and API connections, point to the decisions where live data would pay off, and outline what it takes to make them safe for AI.
One call, no commitment.
One call, no commitment.
Theme to watch: real-time data as AI context
“Real-time” may be the most stretched word on any vendor slide. For an executive, the freshness that counts is the age of the data at the moment a decision gets made. Real-time data streaming can deliver that, as long as every claim answers one follow-up: which clock are you measuring?
Four clocks behind every “real-time” claim
Anthropic’s context engineering guidance recommends pulling information at runtime and keeping context small and relevant, because more context can make answers worse. The streaming layer should hold current state outside the model and hand over only the slice a decision needs.
| Clock | What it measures | Why it matters |
|---|---|---|
| Source age | Time since the business change happened | A brand-new message can describe an old event |
| Pipeline freshness | Delay until the change reaches the context layer | A fast broker does not guarantee fresh context |
| Retrieval latency | Time to return the requested context | A fast answer can still be stale |
| Decision-to-action delay | Time from reading the data to committing the action | State can change while the agent reasons or waits for approval |
Back to the refund. An agent can read the order in milliseconds and still see yesterday’s status, which is a monitoring problem. Or it reads the right status, and that status changes before the refund goes through, which is an action problem you solve by checking again right before execution. Both get called “real-time,” yet the fixes have nothing in common.
Live context, history and training do different jobs
Vendors often sell real-time AI as one package, but you will be funding separate pieces. Live context gives the model current inputs at decision time; it does not retrain the model whenever an event lands. RAG is as fresh as its ingestion and indexing allow. History stays essential for analysis, audits and explaining decisions, and even the Streamhouse Working Group presents streaming as an addition to the lakehouse. Plenty of operational AI is not chat at all: Confluent’s updates also cover anomaly detection and time-series forecasting.
What the docs say that keynotes won’t
Product documentation is a better guide than launch slides, and Confluent’s Real-Time Context Engine docs are refreshingly direct:
- Queries are read-only, with no joins or aggregates, so rich context has to be computed upstream.
- Some schema changes can suspend materialization, which quietly turns a live source into a stale one.
- Direct REST access through lightning queries is early access, with no service-level commitment.
There is also a second freshness path. Tableflow, which turns streams into open tables, lists roughly five minutes of freshness for new records. That suits analytics and can be too slow for an agent’s decision, so plan and budget them as two paths with two service levels.
Limits like these are normal in a young product category. Build around them, and ask at Current which ones are about to change. For the data side of agent readiness, see Enterprise AI Agents: From Pilot to Production.
The questions announcements must answer
Keynotes are designed to make you want the product. Your job is to work out whether a feature lowers the cost or the risk of putting current data behind a real decision. We will run every Current announcement through six tests, and a vague answer to any of them means the feature is not ready for production.
Six tests for any real-time AI announcement
| Test | What to ask | Red flag |
|---|---|---|
| 1. Business value | Which decision gets better, and how fresh must the data be to change it? | “AI-ready” with no named workflow or KPI |
| 2. End-to-end freshness | How old is the data when the agent reads it, counting source and CDC delay? | Only broker or query latency is reported |
| 3. Identity and access | Which identity reads each resource, on whose behalf, and can access be revoked mid-task? | One shared credential with broad access |
| 4. Action safety | What checks an action right before it runs, and what stops duplicates after a retry? | “Exactly-once” offered as protection from double refunds |
| 5. Failure and recovery | What happens when the source stalls but the context service keeps answering? | A happy-path demo only |
| 6. Cost and maturity | What does one completed workflow cost at peak, and is this exact feature GA? | Broker pricing only, or platform GA status applied to every feature |
Test 3 is where most demos go quiet. In March, NIST reported that red-teamers hijacked all 13 frontier models in its competition across more than 250,000 attempts, many through instructions hidden in external content. A live data stream is external content. NIST’s October design tenets for agent identity respond with a structural rule: separate systems should decide what an agent wants to do and what it is allowed to do. However fresh the data, the safeguard belongs in permissions enforced outside the agent.
IBM shops have one more question. A lot of event-driven integration in IBM estates already runs through IBM Cloud Pak for Integration and Event Streams. Before adding Confluent to that picture, you need to know which product owns which part of the path, and who supports it when something fails.
How we will judge what comes out of Current
No one from our team will be in San Francisco. We will follow the keynote, the published announcements and the updated documentation, then sort each item into one of three groups:
- Deployable now: GA in the required cloud and region, documented, supported, with customers in production.
- Pilot with controls: promising, but in preview or early access, or with unclear support, cost or security terms.
- Watch for now: roadmap items, or features without clear answers on access control, recovery or action safety.
Every verdict comes back to one question: does this make current business data easier to integrate, govern and use safely in a specific process? On November 9 we will publish the follow-up, Event-Driven Architecture for Enterprise AI: Lessons from Current 2026, with what was announced and what is ready to use.
Key takeaways
- Current 2026 is Confluent’s first conference under IBM, so the real question is how streaming fits with MQ, webMethods and IBM Z.
- Context Engine, Streaming Agents and Agent Management Console have been GA since May. Judge this week’s news by what changed since then.
- Event-driven architecture lets AI react to change. Stopping duplicate refunds takes idempotency and a check at the moment of action.
- Ask which clock any “real-time” claim measures. Stale reads and actions on changed data need different fixes.
- Access control belongs outside the agent, however fresh the data is.
Next step: pick one process where stale data already costs you money, such as refunds, stock allocation or claims. Measure how old the data is when someone acts on it. That number tells you whether real-time data is worth funding.
