Agentic systems are distributed systems.

In our blog posts, videos, and conference talks, we've been spreading the word that event sourcing is the key foundational technology on which agentic systems should be built. This is because the built-in features you get with event sourcing are the same elements of the core foundation you need for the distributed-systems requirements of agentic AI. The demos on a laptop hide those requirements. Production forces them all back into view.

Looking at agentic AI demos and assuming they can be taken to production is a common early mistake. Any application with agentic AI components requires a robust set of frameworks and tools for distributed systems. Before the demo, before the model choice, the five capabilities below have to be in place.

Section I · Distributed memory

Where the conversation lives when the process is gone.

If you have used AI assistants and agents, you have encountered memory in one form or another. The simplest form might be an agent that maintains conversation history for a specific session — short-term — or all conversations with a certain user, long-term.

In a monolithic demo running on a laptop, memory is just a variable. It lives in the process. When the process dies, the memory goes with it. That is fine for a demo. It is not fine when a real user is halfway through a conversation, or when an agent has spent ten minutes building context for a complex task and the pod restarts.

Distributed memory is durable, sharded across the cluster, and available to any replica that picks up the next request. It survives restarts, deploys, and region failovers. In event-sourced systems, memory is a natural artifact of the event journal — every conversation turn is an event, and rehydrating an agent's state is replaying its events.

Section II · Streaming I/O with LLMs

Every non-trivial model interaction is a stream.

Most interactions with LLMs are streaming interactions. Agents submit token streams as input to the model and they receive token streams as output. This does not present much of a problem when we are working with "hello world" demo applications running on laptops. In production, streaming becomes a first-class distributed-systems concern.

The stream needs backpressure so a fast model does not overwhelm a downstream consumer. It needs supervision so a stalled connection doesn't tie up an agent forever. It needs multiplexing so an agent can consume from one model while emitting to another. And it needs a story for what happens when the stream fails halfway through — which in production, it will.

Anything short of proper stream-oriented infrastructure means an agent that stalls, loses tokens, or fails partway through a long response with no recovery. Users notice.

Section III · Stateful orchestration

Micro-orchestration first. Macro-orchestration next.

We need to be able to do per-agent orchestration — sometimes called "micro-orchestration" — where we manage single-agent failures, network connectivity loss, retries, and exponential backoffs during failures. These are all basic features of reliable, distributed systems. In addition, once you have multiple agents cooperating, macro-orchestration coordinates the flow between them. That flow needs to be durable — a workflow that has completed steps 1 through 5 should not restart at step 1 when the coordinator restarts.

Durable execution is the property that distinguishes a production workflow from a demo one. A demo workflow lives in memory; when the coordinator dies, the workflow is lost. A durable workflow persists its progress at every step. It resumes exactly where it left off.

Section IV · Semantic search and context generation

The retrieval half of every real agent.

Semantic search is a crucial part of agentic workflows for tasks like Retrieval Augmented Generation and context generation and enrichment. Most agents do not have a stateless interaction with an LLM — they have enriched conversations. When users ask agents to reason about their data, the agent needs a way to find the right slice of that data quickly.

In production, this means a vector store that scales with the corpus, an embeddings pipeline that keeps up with ingest, and a retrieval layer that responds within the latency budget of the agent's turn. All three are distributed-systems concerns. Building each of them from a database plus a bolt-on vector library and hoping for the best is the shape of most current attempts. It works until it doesn't.

Section V · Running resilient components in clusters and regions

Component placement across clusters and regions.

There are many important reasons to want to control where services are running. In addition to wanting to shorten the distance between the customer and their services and data, there are also resilience and scale concerns. In the world of monoliths, one bad thing can take down the whole system. In a distributed agentic system, the failure of one agent should not affect the rest.

Before you start deploying agentic AI to production, take a hard look at the demo and ask which of the five capabilities it is faking. The production readiness question

Section VI · Closing

Distributed-systems primitives every agentic framework requires.

Any application with agentic AI components needs to be supported by a robust set of frameworks and tools for distributed systems. Before you start deploying agentic AI to production, take a hard look at the demo and ask which of the five capabilities above it is faking. If the answer is any of them, that gap becomes real when a user connects, a pod dies, a model stalls, or a region degrades.

Event sourcing supplies the distributed-systems primitives agentic AI needs. Several of the five capabilities emerge from it directly. The Akka platform builds on it for that reason.