ATO 2026: Orchestrating Autonomous AI Agents with Apache Kafka and Apache Flink

Presented at All Things Open 2026 in Raleigh, North Carolina

In the data streaming universe, we’ve established the patterns and stacks that work: Apache Kafka to move data and Apache Flink to transform it. We’ve built dashboards that tell us exactly when something is breaking. We’ve built chat agents to automate common customer interactions. But isn’t there MORE to event-driven architecture than just “knowing” what has happened and “answering” when asked? We need our systems that act on events in real-time.

Apache Flink Agents steps into this gap between standard LLM frameworks – built on the “request-response” paradigm – and the realities of our modern event streaming world. The “chatbot brain” isn’t designed for a high-throughput, unbounded stream of Kafka events – resulting in a maze of unhandled backpressure, lost state, and increasing TCO.

In this session, we’ll explore the shift from passive stream processing to active agentic streams. We’ll discuss how Flink Agents provide the durable execution layer needed to give AI agents a memory that survives restarts and a runtime that can keep up with Kafka’s throughput. We’ll hit these points in detail:

The Streaming Brain: Why LLMs need to be treated as stateful operators in a Flink DAG rather than external side-calls.
Event-Driven Autonomy: Using Kafka as the “central nervous system” to trigger agents based on complex patterns, not just single prompts.
The JVM Advantage: How to leverage your existing Java (or Kotlin, Scala, Clojure) ecosystem to build type-safe agents with strong data contracts (Avro/Protobuf).
Demo: Let’s see this in action.
Stop building AI that just talks. Start building AI that streams.

Transcript

1. ALL THINGS OPEN 2026 · RALEIGH, NC Orchestrating Autonomous AI Agents with Apache KafkaⓇ and Apache FlinkⓇ Sandon Jacobs · Senior Developer Advocate at Confluent, an IBM Company
2. ABOUT ME Sandon Jacobs Senior Developer Advocate at Confluent, an IBM Company “Talk data to me…” or Java, Kotlin, Scala, DevOps, Kafka, Flink… @SandonJacobs · linkedin.com/in/sandonjacobs · github.com/sandonjacobs
3. Most AI agents wait to be asked. Your business doesn't wait. It happens as events: orders, logins, payments, alerts, support tickets — thousands every second.
4. WHY From passive streams to active agentic streams Stream processing today Agentic stream • Filters, joins, windows, aggregates • Rules written in advance • Emits facts for someone else to act on • Reasons over each event in context • Decides, then acts through tools • Emits decisions and actions
5. PRIMER Kafka: a immutable, durable event log Fraud service group: fraud · offset 7 Topic orders Producers apps, services, devices, CDC new events append here → P0 0 1 2 3 4 5 P1 0 1 2 3 4 5 P2 0 1 2 3 4 5 6 7 Audit service group: audit · offset 4 6 Flink job group: analytics · offset 3 Durable and replayable Ordered per key Decoupled Events are kept, not deleted on read. Any consumer can rewind to an offset and replay. Same key, same partition, same order. Partitions are also how Kafka scales out. Producers never know who reads. Add a new consumer group any time, without touching anything upstream.
6. PRIMER Zoom out: the ecosystem around the log Lake house Databases (CDC) SaaS apps Kafka Connect source connectors Kafka topics Kafka Connect sink connectors Files & logs Search index Object storage Kafka Streams in your app Kafka Connect Kafka Streams Schema Registry Move data in and out with configuration, not code. Hundreds of connectors, including change data capture (CDC) from databases. A Java library for stream processing inside your own service. No separate cluster: it scales with your app instances. Contracts for every topic in Avro, Protobuf or JSON Schema, so producers can't break their consumers.
7. PRIMER Apache Flink: stateful stream processing at scale Kafka source reads offsets keyBy(ticketId) partition by entity process / window keyed state per entity Kafka sink writes results Checkpoint state + Kafka offsets, snapshotted together to durable storage State, built in Exactly-once recovery Event time One engine, many APIs Per-key state lives with the operator: in memory, or on disk with RocksDB for very large state. After a failure, restore the checkpoint and rewind Kafka to the matching offsets. Watermarks let results follow when things happened, even when events arrive late or out of order. Flink SQL, Table API and DataStream, in Java or Python. Scales separately from your apps. Kafka keeps the stream. Flink computes on it. Each is better because of the other.
8. WHY Where request/response agents struggle on Kafka Concern Request/response agent Flink Agents on Kafka Throughput One call at a time; caller waits Async calls, Flink backpressure State In-process, or a store you wire up Keyed Flink state, checkpointed Failure Retry and hope it's idempotent Restore checkpoint, replay offsets Order & scale Up to you Per-key order; scales with partitions
9. HOW Kafka is the nervous system. Flink is the brain. Events in Kafka apps, services, devices durable, ordered log Flink + agent LLM · tools · memory Kafka Actions decisions as events teams, systems, other agents The LLM becomes a stateful operator inside the Flink job — not a side call bolted on from outside.
10. HOW Apache Flink Agents in a nutshell Agent Events Actions A class that groups actions and the resources they use. Input, chat request/response, tool call, output — or your own types. @Action methods that run when an event they listen for arrives. Resources Memory Runtime Chat models, prompts, tools, embeddings, vector stores, MCP servers. Sensory and short-term in Flink state; longterm in a persistent store. An operator in a DataStream or Table job. Java and Python APIs.
11. HOW A Flink agent is an event loop, not a call stack event your @Action event built-in InputEvent routeTicket ChatRequest LLM ⇄ tools sink event your @Action event Kafka topic OutputEvent onResponse ChatResponse
12. HOW Durable execution: memory that survives a restart 01 02 03 Memory is Flink state Replay, don't redo Pay for a call once Sensory and short-term memory are keyed state, snapshotted with every checkpoint. After a failure, Flink restores the last checkpoint and Kafka re-delivers from its offsets. Durable execution caches completed LLM and tool results, returned on recovery.
13. HOW Type-safe agents on the JVM Contracts at the edges {"type": "record", "name": "TicketRouting", "fields": [ {"name": "ticket_id", "type": "string"}, {"name": "team", "type": "string"}, {"name": "priority", "type": { "type": "enum", "name": "Priority", "symbols": ["P1","P2","P3","P4"]}}, {"name": "escalated", "type": "boolean"}, …]} Avro and Schema Registry on both topics: consumers know exactly what an agent can emit. Plain Java inside Generated classes in, POJOs through the agent, compiletime checks throughout. The model can't break the contract LLM text is validated into a known team and a Priority enum — or routed to triage.
14. DEMO A support desk that routes itself T-4510 · globex · CHAT routing decision Everything is down "Your dashboard has returned 502 errors for the last 15 minutes for our whole team." platform-sre · P1 "Outage affecting multiple users" — on-call paged. Seven teams to choose from, priorities P1–P4: payments identity platform-sre mobile data-integrations security customer-success
15. DEMO What's running on this laptop Producer Kafka · Avro samples or live input support. tickets Ollama · qwen2.5:7b, native on the GPU TicketRoutingAgent 1 · Router LLM: team + priority 2 · P1 only: pager LLM + tool 3 · Validate, then emit Avro Schema Registry · Avro on both topics Kafka · Avro Consumer support. tickets.routed prints decisions Flink 2.2 · MiniCluster, UI on :8088
16. Let's see it in action.
17. TAKEAWAYS Three things to take home 01 Put the agent where the events are — on the stream, not behind an API. 02 Let Flink own state and recovery. 03 Keep each LLM step small, and guard what comes out of it.
18. RESOURCES Try it yourself This demo github.com/sandonjacobs/flink-agents-talk Apache Flink Agents github.com/apache/flink-agents Flink Agents docs (0.3) nightlies.apache.org/flink/flink-agents-docs-release-0.3
19. Thank you. Questions? Sandon Jacobs · Senior Developer Advocate · Confluent, an IBM Company @SandonJacobs · linkedin.com/in/sandonjacobs · github.com/sandonjacobs/flink-agents-talk
20. Learn more in the IBM Generative Computing Lounge! https://ibm.biz/ibm-ato All Things Open | © 2026 IBM