The Apache Flink community has been pushing hard into the agentic AI space, positioning stream processing as the foundation for production AI agents. Conference talks showcase sophisticated architectures where Flink jobs consume events, call LLMs, and coordinate multi-agent workflows. It looks impressive—until you try to build it yourself and realise you’re bringing a stream processing sledgehammer to solve what’s fundamentally a distributed systems problem.
The OSO engineers have spent considerable time working with both Flink and Akka in production environments, and we’ve learned something important: whilst Flink is brilliant for high-throughput data analytics and stream processing at massive scale, it’s completely overkill for building AI agents. Worse, it adds significant complexity that most teams don’t need and can’t justify. Akka, by contrast, was designed from the ground up for exactly the problems agentic systems present—stateful, long-lived processes that need to coordinate across distributed infrastructure whilst handling failures gracefully.
If you’re evaluating frameworks for building production AI agents, you need to understand where Flink shines (spoiler: it’s not agents) and why Akka’s simpler, purpose-built approach delivers better results with dramatically less overhead.
The Stream Processing vs. Agent Mismatch
Yes, agents need access to real-time data. But that doesn’t mean your agents should be implemented as stream processing jobs. A Flink job excels at transforming high-volume data streams—think millions of events per second flowing through stateless or lightly stateful operations. It’s designed for analytical queries over windows of data, for joining streams, for calculating aggregates. These are batch-style operations executed continuously.
AI agents, by contrast, are fundamentally different beasts. An agent isn’t processing millions of events per second. It’s having conversations. It’s maintaining context over potentially hours or days. It’s making decisions that require complex reasoning, not just aggregating metrics. It’s coordinating with other agents through workflows that may pause, wait for human approval, or retry failed steps. These are transactional, orchestrational concerns—not stream processing patterns.
When the OSO engineers first evaluated Flink for agentic systems, we kept running into the same fundamental mismatch. Flink wants to process events and move on. Agents want to hold state, have conversations, and coordinate complex workflows. You can force Flink to do this—the recent additions for calling ML models from Flink SQL show that the community is trying—but you’re working against the framework’s design rather than with it.
The Complexity Cost
The complexity cost is substantial. Flink requires you to understand stream processing concepts like watermarks, event time versus processing time, and state backends. You need to manage Flink clusters with JobManagers and TaskManagers. You need to worry about checkpointing strategies and savepoints for state recovery. For stream analytics at scale, this complexity is justified. For building a handful of AI agents that might process a few dozen requests per minute? It’s architectural overkill that adds operational burden without corresponding benefit.
More fundamentally, Flink’s execution model doesn’t align with how agents actually work. Flink processes events in a pipeline—data flows in, gets transformed, and flows out. But agents don’t work in pipelines. They have conversations. They maintain sessions. They make decisions that affect their internal state. They coordinate with other agents through request-response patterns and pub-sub events. These are stateful, entity-oriented behaviours that require a different architectural foundation.
What AI Agents Actually Need (And Flink Doesn’t Provide)
Understanding why Flink isn’t the right fit requires understanding what production AI agents genuinely need. The OSO engineers have identified several core requirements through our work deploying agentic systems for enterprise clients.
Conversational State vs. Stream State
First, agents need durable, conversational state. Not stream processing state—conversational state. When a user interacts with an agent across multiple exchanges, that agent needs to remember the entire conversation history, understand the context of previous questions, and maintain any intermediate results from tool calls or external API interactions. This isn’t a windowed aggregate or a join operation. It’s a conversation that might span hours, with long pauses where no events are flowing.
Flink can persist state, but it’s designed for state that supports stream processing—counters, aggregators, recently-seen keys. Managing a full conversational history with all the nuances of tool calls, LLM responses, and context windows requires a different persistence model. You need event sourcing where every interaction is captured as an event and the conversation state is reconstructed by replaying those events. Flink’s state backends weren’t designed for this pattern.
Workflow Orchestration and Human-in-the-Loop
Second, agents need workflow orchestration with human-in-the-loop capabilities. A production agent workflow might look like: receive a request, call an LLM to analyse it, invoke three different specialist agents in sequence, aggregate their results, pause to request human approval, then execute an action in an external system. If any step fails, retry with exponential backoff. If the system crashes mid-workflow, resume from the last completed step when it restarts.
This is fundamentally different from stream processing. Workflows can pause for hours waiting for human input. They need to coordinate between multiple services that may be in different clusters or regions. They require explicit error handling at each step, not just global recovery from checkpoint. Flink can execute multi-step operations, but forcing it to handle long-lived, pausable workflows with manual approval steps is fighting the framework.
Multi-Agent System Patterns
Third, agents need first-class support for the patterns that multi-agent systems require. When you have a coordinator agent that needs to dynamically select which specialist agents to invoke based on analysing a request, you need agent discovery, dynamic invocation, and result aggregation. When you have agents that need to share context across a session, you need session management with flexible scoping. When you have agents in different regions that need to collaborate whilst respecting data locality rules, you need distributed state with replication controls.
These are distributed systems problems, not stream processing problems. You could build all of this on top of Flink—after all, Flink is Turing complete—but you’d essentially be implementing a distributed actor system using stream processing primitives. Why not just use an actual distributed actor system?
Deployment and Operations Reality
Fourth, agents need simple deployment and operation. In production, you want to deploy agents across multiple regions for latency and compliance reasons. You want them to scale based on load. You want them to handle partial failures gracefully, where one agent might be temporarily unavailable but the system continues functioning. You want observability into what each agent is doing and why it made specific decisions.
With Flink, this means managing a stream processing cluster for what’s essentially a set of conversational microservices. You’re maintaining infrastructure designed for big data analytics to support AI agents that might process a handful of requests per second. The operational complexity doesn’t match the actual workload.
Why Akka Is Purpose-Built for Agentic Systems
Akka takes a completely different approach because it was designed to solve the distributed systems problems that agentic AI actually presents. Rather than adapting a stream processing framework, Akka provides primitives specifically for building stateful, distributed applications that need to coordinate across infrastructure whilst handling failures.
The Actor Model for Agent Behavior
At its core, Akka is built on the actor model—lightweight, isolated entities that maintain internal state and communicate through asynchronous messages. This maps perfectly to the agent model. Each agent is an actor with its own state. Agents communicate by sending messages to each other. The framework handles routing, persistence, and failure recovery automatically.
For AI agents specifically, Akka provides components that directly address the requirements we outlined. The Agent component in Akka maintains conversational state through built-in session memory, automatically persisted using event sourcing. When you implement an agent, you don’t need to write code to store conversation history or replay events to reconstruct state—that’s handled by the framework. Your agent code focuses on the prompts, the model selection, and the business logic.
This is dramatically simpler than trying to maintain conversational state in Flink. With Akka, you define an agent in a few lines of code, specify its system prompt and available tools, and the framework handles persistence, recovery, and state management. The OSO engineers have found that teams can go from zero to a working agent in hours, not weeks of learning stream processing concepts.
Workflow Orchestration in Practice
Workflow orchestration is another area where Akka’s design shines for agents. Akka’s Workflow component provides durable execution specifically for long-lived, multi-step processes. You define your workflow as a series of steps, and the framework ensures each step executes reliably with automatic retries and recovery after failures. If your workflow needs to pause for human approval, that’s a first-class feature—the workflow state is persisted, and it resumes when the approval comes through, whether that’s seconds or days later.
The OSO engineers implemented a multi-agent system where a coordinator workflow dynamically plans which specialist agents to invoke, calls them in sequence, and aggregates results. With Akka, this was straightforward: define the workflow steps, use the ComponentClient to invoke agents by ID, store intermediate results in the workflow state, and handle errors at each step. The entire implementation was under 200 lines of code. Attempting the same thing with Flink would require building custom orchestration logic on top of the stream processing abstractions.
Session Management and Context
Memory management in Akka is another stark contrast with Flink. Akka provides both short-term session memory (automatically maintained for each agent conversation) and long-term shared memory (available across agents and sessions). This memory is implemented using event-sourced entities that can be queried, updated, and subscribed to just like any other component. When an agent needs context from previous conversations or shared state with other agents, it’s a simple component call—no need to wire up state backends or manage checkpoints.
For multi-agent coordination, Akka’s programming model makes complex patterns simple. Want a coordinator agent that discovers available specialist agents and dynamically invokes them? Akka provides an AgentRegistry and dynamic method calls. Want agents to communicate through events rather than direct calls? Akka’s pub-sub is built in. Want to deploy agents across multiple regions with selective replication? Akka handles multi-region clustering and data locality.
Simple Deployment Model
Most importantly, Akka’s deployment story is fundamentally simpler for agentic workloads. An Akka service is just a binary—you can run it locally on your laptop, in a Docker container, on Kubernetes, in any cloud, or on bare metal. The same code that runs during development works in production. Services self-cluster without external infrastructure, automatically distributing agents and their state across nodes for resilience and scale.
Compare this to Flink, where you need to deploy and manage a cluster with multiple components, configure state backends and checkpointing, and deal with JobManager failover. For stream processing at massive scale, this infrastructure makes sense. For a dozen AI agents handling conversational requests, it’s operational overhead that delivers no value.
Where Flink Actually Makes Sense (And It’s Not Agents)
None of this means Flink is a bad technology—far from it. The OSO engineers use Flink regularly in production systems, and it’s brilliant for the problems it was designed to solve. The key is understanding where those boundaries lie.
Flink shines when you have high-throughput data streams that need continuous transformation, aggregation, or enrichment. If you’re processing millions of events per second from IoT sensors, joining multiple Kafka topics to create materialised views, or running complex event patterns to detect anomalies in real time, Flink is absolutely the right tool. The framework’s performance characteristics, exactly-once processing guarantees, and sophisticated watermarking for handling out-of-order events make it the gold standard for stream analytics.
The Data Layer vs. The Agent Layer
In an architecture that includes AI agents, Flink still has an important role—but it’s in the data layer, not the agent layer. Use Flink to process your raw event streams, create aggregated views, and prepare the data that agents will consume. Use it to detect patterns that should trigger agent actions. Use it to provide real-time analytics that inform agent decisions. But implement the actual agents using a framework designed for stateful, orchestrated, distributed services.
The OSO engineers frequently design architectures where Flink processes high-volume event streams and publishes results to topics that Akka agents subscribe to. This separation of concerns plays to each framework’s strengths. Flink handles the heavy lifting of stream processing at scale. Akka agents consume those processed results and make decisions, coordinate workflows, and interact with users. Each framework does what it does best.
We’ve also seen successful patterns where Flink provides real-time context enrichment for agents. An agent handling a customer query might need recent transaction history, account status, or behavioural patterns. Flink can maintain these materialisations in real time from raw event streams, and the agent queries them when building prompts. This is a much cleaner separation than trying to make the agent itself responsible for stream processing.
The key insight is that “agents need access to streaming data” doesn’t mean “agents should be implemented as stream processing jobs.” These are different layers of the architecture. Flink excels at the data processing layer. Akka excels at the agent orchestration layer. Using the right tool for each layer produces simpler, more maintainable systems than forcing one framework to do both jobs.
The Simplicity Advantage in Practice
When we talk about Akka being simpler for agentic AI, we’re not talking about toy examples or hello-world demos. The OSO engineers have implemented production multi-agent systems for enterprise clients, and the simplicity advantage is real and substantial. Let’s look at actual code to see the difference.
A Basic Conversational Agent
Consider what it takes to implement a basic conversational agent. With Akka, here’s the complete implementation from the ask-akka-agent sample:
@Component(
id = "ask-akka-agent",
name = "Ask Akka",
description = "Expert in Akka"
)
public class AskAkkaAgent extends Agent {
private static final String SYSTEM_MESSAGE = """
You are a very enthusiastic Akka representative who loves
to help people! Given the following sections from the Akka
SDK documentation, answer the question using only that
information, outputted in markdown format.
""";
public StreamEffect ask(String question) {
return streamEffects()
.systemMessage(SYSTEM_MESSAGE)
.userMessage(question)
.thenReply();
}
}
That’s it. That’s a complete, production-ready conversational agent with built-in session memory, automatic persistence, and streaming responses. The entire implementation is 18 lines of code. The framework handles state management, recovery, and clustering automatically.
HTTP Endpoint with Streaming
To expose this agent via an HTTP endpoint with server-sent events for streaming:
@HttpEndpoint("/api")
public class AskHttpEndpoint {
private final ComponentClient componentClient;
public AskHttpEndpoint(ComponentClient componentClient) {
this.componentClient = componentClient;
}
@Post("/ask")
public HttpResponse ask(QueryRequest request) {
var sessionId = request.userId() + "-" + request.sessionId();
var responseStream = componentClient
.forAgent()
.inSession(sessionId)
.tokenStream(AskAkkaAgent::ask)
.source(request.question());
return HttpResponses.serverSentEvents(responseStream);
}
}
Another 15 lines. The componentClient handles service discovery, routing, and invocation. The session management is automatic. The streaming is built-in. Deploy this, and you have a production-grade conversational API.
The Flink Alternative
To do the same with Flink, you’d need to set up a Flink job that consumes input events from a Kafka topic, maintains conversation state in a state backend, calls the LLM API, and writes responses to an output topic. You need to handle checkpointing so conversation state survives failures. You need to write additional services to route user requests to input topics and consume responses from output topics. You need to manage the Flink cluster with JobManagers and TaskManagers. The implementation complexity is an order of magnitude higher, and you still don’t have first-class support for the conversational patterns agents need.
The OSO engineers have migrated teams from Flink-based agent implementations to Akka, and the code reduction is typically 70-80%. More importantly, the remaining code is focused on business logic rather than infrastructure concerns.
Multi-Agent Orchestration
For multi-agent orchestration, the gap widens further. Here’s how you orchestrate multiple agents with an Akka workflow:
@ComponentId("agent-team")
public class AgentTeamWorkflow extends Workflow<State> {
private final ComponentClient componentClient;
public AgentTeamWorkflow(ComponentClient componentClient) {
this.componentClient = componentClient;
}
public Effect<Done> start(Request request) {
return effects()
.updateState(new State(request.userId(), request.message(), ""))
.transitionTo("weather")
.thenReply(Done.getInstance());
}
@Override
public WorkflowDef<State> definition() {
return workflow()
.addStep(askWeather())
.addStep(suggestActivities())
.defaultStepRecoverStrategy(maxRetries(2).failoverTo("error"));
}
private Step askWeather() {
return step("weather")
.call(() -> componentClient
.forAgent()
.inSession(sessionId())
.method(WeatherAgent::query)
.invoke(currentState().userQuery))
.andThen(String.class, forecast -> {
logger.info("Weather forecast: {}", forecast);
return effects()
.updateState(currentState().withWeatherForecast(forecast))
.transitionTo("activities");
})
.timeout(Duration.ofSeconds(60));
}
private Step suggestActivities() {
return step("activities")
.call(() -> {
String request = currentState().userQuery +
"\nWeather forecast: " + currentState().weatherForecast;
return componentClient
.forAgent()
.inSession(sessionId())
.method(ActivityAgent::query)
.invoke(request);
})
.andThen(String.class, suggestion -> {
logger.info("Activities: {}", suggestion);
return effects()
.updateState(currentState().withAnswer(suggestion))
.end();
})
.timeout(Duration.ofSeconds(60));
}
}
This workflow coordinates two agents in sequence: first getting a weather forecast, then using that information to suggest activities. The workflow persists automatically at each step. If the system crashes or a step times out, the workflow resumes from where it left off. Retries are configured declaratively. The state is durable. The entire implementation is under 60 lines.
The OSO engineers implemented a system where a coordinator analyses requests, selects relevant specialist agents, plans execution order, and aggregates results. With Akka workflows, this is a straightforward state machine with steps that call agents and handle results. The workflow persists automatically, retries failed steps, and supports human approval points. The complete implementation was under 200 lines.
Error Handling and Recovery
Attempting this with Flink would require building custom orchestration on top of the stream processing model. You’d need to manage the state of which agents have been called, track results, handle errors, and persist workflow state through checkpoints. You’d essentially be building a workflow engine using stream processing primitives, when you could just use an actual workflow engine.
Consider what happens when a step fails in this workflow. Akka automatically retries with the configured strategy. The workflow state is already persisted, so there’s no risk of losing progress. If the entire service restarts mid-workflow, Akka loads the persisted state and continues from the last completed step. You don’t write any of this recovery code—it’s provided by the framework.
With Flink, you’d be managing savepoints, configuring checkpoint intervals, writing custom code to detect and handle failures, and ensuring your state serialization is correct. The operational complexity is substantially higher for equivalent functionality.
Operational Simplicity
The operational simplicity is equally important. Akka services are simple binaries that self-cluster and manage their own state distribution. Adding nodes to handle more load is just deploying more instances—the framework handles data rebalancing automatically. Observability is built in through event logs that capture every agent interaction. The OSO engineers deploy Akka services to Kubernetes with minimal configuration, and they just work.
Here’s what deployment looks like for the agent we showed above:
# Build the service
mvn clean install
# Deploy to Akka (with secrets for API keys)
akka service deploy ask-akka-agent ask-akka:1.0.0 \
--secret-env OPENAI_API_KEY=secrets/openai-key \
--push
The service self-clusters, automatically distributes agent sessions across nodes, handles failover, and provides a unified API. You don’t configure load balancers, service meshes, or state backends separately. It’s all handled by the framework.
Compare this to a Flink deployment where you need to manage JobManagers, TaskManagers, configure state backends (RocksDB or heap), set up savepoint strategies, configure high availability with ZooKeeper or Kubernetes, tune checkpoint intervals and timeouts, and monitor job status separately from application metrics. For stream processing at scale, this infrastructure provides value. For agentic workloads that might process a few hundred requests per minute, it’s complexity without benefit. The operational team needs to understand Flink-specific concepts and monitoring, when they could be managing simple containerised services.
The OSO engineers have seen teams spend weeks learning Flink’s operational model—understanding watermarks, configuring checkpointing, debugging state serialization issues, tuning memory allocation between JobManager and TaskManagers. These same teams can be productive with Akka in days because the operational model is simpler: deploy containers, and the framework handles the distributed systems complexity.
Practical Migration Patterns
If you’re currently exploring Flink for AI agents—or worse, already implementing agents as Flink jobs—the good news is that migration to Akka is straightforward because the architectures are compatible at the integration points.
Recognizing What to Keep
The first step is recognising that your existing Flink infrastructure still has value. If you’re using Flink to process event streams, create materialisations, or run real-time analytics, keep doing that. Flink remains the right tool for those jobs. The migration is about moving the agent logic out of Flink and into Akka, not replacing your entire streaming infrastructure.
Start by identifying what’s actually agent behaviour versus what’s data processing. If you have Flink jobs that are calling LLMs, managing conversational state, or orchestrating multi-step workflows, those are agent behaviours that belong in Akka. If you have Flink jobs that are aggregating events, joining streams, or calculating metrics, those are data processing behaviours that should stay in Flink.
Integration Through Pub-Sub
The OSO engineers typically implement a pattern where Flink jobs publish processed data to Kafka topics, and Akka agents subscribe to those topics using Akka’s streaming consumers. This maintains the clean separation—Flink processes data at scale, Akka agents consume that data and make decisions. The integration point is just pub-sub over Kafka, which both frameworks handle natively.
For teams that have implemented agent state management in Flink’s state backends, the migration path involves moving that state to Akka’s event-sourced entities. This is actually an improvement, because Akka’s event sourcing model provides better support for conversational history, audit trails, and state inspection. The OSO engineers built tools to export state from Flink savepoints and import it into Akka entities, making the migration incremental.
Mindset Shift: Streams to Entities
The biggest mindset shift is moving from thinking in streams to thinking in entities and workflows. With Flink, you think about events flowing through transformations. With Akka, you think about agents as stateful entities that receive messages, update their state, and send messages to other entities. Workflows orchestrate these interactions. It’s a more natural mental model for agent systems because it maps directly to how agents actually behave.
When You Might Actually Want Both (But Not How You Think)
There are scenarios where using both Flink and Akka makes sense in a single architecture, but the division of labour is important. The OSO engineers have designed several systems where both frameworks play to their strengths.
Clear Separation of Concerns
The typical pattern is that Flink sits in the data processing layer, handling high-volume event streams and creating the data products that agents need. Akka sits in the application layer, implementing the agents themselves and orchestrating their interactions. The two frameworks communicate through Kafka topics—Flink publishes processed data, Akka agents consume it.
For example, we built a system for a financial services client where Flink processed transaction streams to detect patterns and calculate risk scores in real time. These enriched events were published to Kafka. Akka agents subscribed to events requiring attention, used LLMs to analyse them in business context, and coordinated with specialist agents to determine appropriate actions. Flink handled millions of transactions per second; the agents handled perhaps a hundred decision points per minute.
This architecture played to each framework’s strengths. Flink’s throughput and exactly-once semantics ensured no transactions were missed. Akka’s workflow orchestration and stateful agents ensured decisions were made reliably with full audit trails. Neither framework was being forced to do work it wasn’t designed for.
Real-Time Feature Engineering
Another pattern is using Flink for real-time feature engineering that feeds agent prompts. An agent providing customer support needs context—recent activity, account status, known issues. Flink can maintain these materialisations by processing raw event streams. The agent queries a view (which might be powered by Flink’s state queries) when constructing prompts. The agent isn’t doing stream processing; it’s consuming the results of stream processing.
The key principle is that if you’re using both frameworks, each should be doing what it does best. Flink processes data. Akka implements agents. The integration point is clean pub-sub over Kafka or direct queries to materialised views. You’re not trying to make Flink jobs behave like agents or make Akka agents do stream processing. This separation produces systems that are simpler to understand, operate, and evolve.
The Bottom Line for Engineering Teams
If you’re evaluating frameworks for building production AI agents, the decision comes down to a simple question: do you have a stream processing problem or a distributed systems problem?
If you’re processing millions of events per second and need continuous analytics, aggregations, and transformations, you have a stream processing problem. Flink is absolutely the right choice. Its performance, semantics, and operational characteristics are unmatched for this workload.
But if you’re building AI agents—systems that have conversations, maintain context, coordinate workflows, and make decisions—you have a distributed systems problem. The fact that agents need access to real-time data doesn’t make them stream processing jobs.
Code Complexity Reality
Look at the code examples we’ve shown in this article. An 18-line agent implementation. A 15-line HTTP endpoint with streaming. A 60-line workflow orchestrating multiple agents with automatic persistence and recovery. These aren’t theoretical examples—they’re from actual production systems. The ask-akka-agent sample running in enterprise environments demonstrates that you can build sophisticated RAG agents with session memory, vector search integration, and streaming responses in a couple hundred lines of total code.
Try to imagine building the same functionality with Flink. The Flink job to maintain conversation state and call LLMs. The checkpoint configuration to ensure state survives failures. The input and output Kafka topics. The consumer services to route requests. The custom orchestration logic for multi-step workflows. The savepoint management for deployments. You’d easily be looking at 10x the code, and most of it would be infrastructure plumbing rather than agent logic.
The OSO engineers have seen teams struggle with Flink-based agent architectures, fighting the framework to implement conversational patterns, workflow orchestration, and stateful coordination. We’ve helped these teams migrate to Akka and watched the complexity drop by an order of magnitude. The same functionality that required thousands of lines of Flink boilerplate becomes a few hundred lines of straightforward Akka code that’s actually focused on the agents’ behaviour.
Choosing the Right Tool
This isn’t a criticism of Flink. It’s recognition that different tools suit different problems. Flink is brilliant at what it does. But what it does isn’t building AI agents. If someone pitches you on implementing agents as Flink jobs, they’re either selling you Flink or they haven’t actually tried to build production agent systems at scale.
For teams serious about deploying agentic AI to production, Akka provides a simpler, more maintainable foundation. You get stateful agents with automatic persistence, workflow orchestration with durable execution, built-in session memory and context management, first-class multi-agent coordination patterns, simple deployment and operations, and complete audit trails for every agent decision. This is what production AI agents actually need, delivered through a framework designed for exactly these requirements.
Cognitive Load Matters
The real simplicity advantage isn’t just about lines of code—though that’s substantial. It’s about cognitive load. With Akka, you think about agents, workflows, and distributed state using abstractions that map directly to the domain. You’re not translating agent behaviours into stream processing concepts. You’re not fighting framework limitations to implement patterns it wasn’t designed for. You’re building distributed agent systems using a framework purpose-built for distributed systems.
If you’re starting a new agentic AI project, save yourself the complexity tax and start with Akka. The code examples we’ve shown aren’t aspirational—they’re what you actually write. If you’re already using Flink for agents, it’s not too late to migrate to a simpler, better-fit architecture. The OSO engineers can help you evaluate your current setup and chart a migration path that preserves your existing stream processing infrastructure whilst moving agent logic to where it belongs—a framework designed for agents, not one designed for analytics.
