Akka Memory: durable, in-memory, and sharded data.
Every agent needs memory. The kind that survives a crash, moves with the shard, streams changes to whoever's listening, and lands in an audit trail. Akka Memory ships that as the default.
Akka Memory provides durable, in-memory, and sharded data for AI agents. It gives agents the ability to recall and reason across both short-term and long-term sessions, supporting fast, low-latency decisions and maintaining continuity across sessions, users, and goals. That memory is required for context engineering — structuring what an agent knows so it can perform complex tasks reliably across multiple interactions.
Durable event-sourced memory
Every state change is an immutable event.
One of the things I love about Akka Memory is its event-sourced backbone. If you're not familiar with event sourcing, it is an architecture pattern that tracks state changes sequentially as a series of events and persists those events transparently to an event journal. Think of it as an audit log: every time something transpires, we record it as an immutable historical event.
For optimization we also provide snapshotting to capture the current state of an agent or entity. Then, on startup, we do not have to replay all events to reconstruct the current state — we only need to load the most recent snapshot and replay the events that happened after it.
Figure 1
Recovery from an event journal.
Subscribe to memory changes
Every stored event is also a stream event.
Whenever a piece of information is updated, Akka's event-driven memory tracks it as an immutable fact and instantly streams those changes to any interested agents or components. With Akka Streaming, setting up these subscriptions feels invisible: an agent declares what it cares about, and it starts receiving change notifications the moment they happen.
This capability enables adaptive systems. Agents respond, coordinate, and update their behavior the moment something shifts in their environment. Multiple streams can be composed with Views to shape the information flow to fit whatever the downstream needs.
Figure 2
Memory events flow outward as they happen.
Events as evaluation signal
An LLM-judge pattern falls out for free.
Evaluation events give your agents a built-in feedback loop by emitting state-change notifications that other agents can consume and act on in real time. For example, a PreferencesEntity emits an event whenever user preferences are updated. You can hook an EvaluatorAgent to that event stream via a Consumer, and the evaluator scores the interaction against the new preferences the moment they change.
I have found this "LLM as judge" pattern invaluable for enforcing business rules and maintaining high response quality without polling or manual triggers. Agents simply listen for events, evaluate, and adjust their behavior on the fly.
@ComponentId("evaluator-agent")
@AgentDescription(
name = "Evaluator Agent",
description = """
An agent that acts as an LLM judge to evaluate the quality of AI responses.
It assesses whether the final answer is appropriate for the original question
and checks for any deviations from user preferences.
""",
role = "worker")
public class EvaluatorAgent extends Agent {
public Effect<String> evaluate(Interaction interaction, Preferences prefs) {
return effects()
.memory(MemoryProvider.session())
.systemMessage("You are an evaluator. Score the interaction against the preferences.")
.userMessage(interaction.summary() + "\n\nPreferences:\n" + prefs.asJson())
.thenReply();
}
}
Every memory interaction — user inputs, tool calls, LLM exchanges — is recorded as an immutable event in a replayable stream. Audit falls out of the event journal
Sharded and in-memory
State partitions across the cluster; the runtime hides it.
Akka Memory uses the SDK's stateful components — Agents (session memory), Event-sourced Entities, Key-Value Entities, and Workflows — which automatically distribute across your cluster via cluster sharding. Each component instance is bound to a single shard, and those shards rebalance transparently as nodes join or leave.
When instances become idle or memory pressure builds, Akka passivates the least-recently used components, snapshotting or offloading their state to durable storage. Heap frees without any extra code. For geo-scale resilience, every write in the primary region propagates asynchronously to the read-replica regions.
Figure 3
Sharding and rebalancing, side by side.
Tracing and auditability
Every interaction is a replayable event.
Tracing and auditability are non-negotiables in agentic AI, and Akka Memory addresses them thoroughly. Every memory interaction — user inputs, tool calls, LLM exchanges — is recorded as an immutable event in a replayable stream, with workflows logging each transition and call stack.
This level of traceability accelerates incident response and root-cause analysis. Events are persisted in an encrypted, tamper-evident journal, ensuring immutability and non-repudiation for audit and compliance. Retention policies meet governance requirements, and downstream systems can subscribe to the same stream to feed a SIEM or a data warehouse.
Figure 4
The event journal is the audit trail.
Two memory horizons
Short-term is invisible; long-term is queryable.
Short-term memory comes built into the Agent component as transparent "session memory." Every user message, agent decision, and tool invocation is recorded in sequence and persisted as an event-sourced entity tied to a session id. No extra code required.
Long-term memory is powered by stateful components — Workflows, Event-Sourced Entities, Key-Value Entities — that persist semantic knowledge, skills, and retrieved data across users, sessions, agents, and systems. Compaction keeps session histories manageable: a CompactionAgent summarizes past interactions via an LLM, replacing verbose event streams with concise, context-rich snapshots that retain the detail later reasoning depends on.
Table 1
Short-term vs long-term memory in Akka
| Dimension | Short-term (session) | Long-term (durable) |
|---|---|---|
| Scope | one session, one user | across users, sessions, agents |
| Backing component | Agent session memory | Workflow / ES-Entity / KV-Entity |
| Persistence | event-sourced per session id | event-sourced per entity id |
| Compaction | automatic on session end | CompactionAgent on schedule |
| Retention | session TTL | policy-driven |
| Query surface | none (agent-internal) | Views (typed projections) |
Transparent memory
The developer never wires it up.
With Akka Memory, you do not spend hours wiring up state stores or persistence layers — memory "shows up" for agents, workflows, and streams out of the box. A developer spins up an agentic service and immediately has a working memory layer underneath, without writing a single line of boilerplate. The framework provides it; you consume it.
Custom memory types are supported too. If you need shared memory objects — cross-session counters, shared preferences, global configuration — you define them once and have them injected into your agent.
public Effect<String> ask(String question) {
return effects()
.memory(MemoryProvider.custom())
.systemMessage("You are a helpful assistant.")
.userMessage(question)
.thenReply();
}
// MemoryProvider.custom() — plug your own implementation of the SessionMemory
// interface to store session state anywhere: Redis, Postgres, a custom KV store.
Figure 5
The Akka Agentic Platform. Memory sits alongside the other three components.
Closing
Recall belongs at the infrastructure layer.
The mix of instant session recall and durable persistence is a change of category. Session memory hooks directly into agents for micro-latency context, while Event-Sourced and Key-Value Entities journal every change for full replayability and audit trails. Cluster sharding and geo-replication carry all of that at infrastructure grade. The developer writes the agent; the runtime remembers.
Notes & references
- Agent memory docs — session memory API, custom providers, and compaction.
- Entity component docs — event-sourced and key-value entities for long-term memory.
- Views docs — typed projections over events for read-side queries.
- Diagrams in this post are the same ones used in the Akka Memory product page; captions have been rewritten for the article context.