Persistent Agent State Across Session Boundaries

An agent that forgets everything the moment a session ends isn't an autonomous system; it's a chatbot with extra steps, no matter how capable the model underneath it is. Continuity is what separates the two. A single-turn tool answers a question and disappears. A persistent agent keeps a memory of what it did yesterday, picks up a scheduled task tomorrow, and carries out work across days without someone re-explaining the job every time.

Agents that reset between sessions are not autonomous systems

Every developer who has built an agent past the demo stage knows the feeling: you close the terminal, open it again the next morning, and the agent has no idea what happened yesterday. You re-explain the context. You re-paste the files. You re-state the preferences you already gave it last week. Re-explaining context, re-pasting files, and re-stating preferences every session is a sign the system was never built to last past a single conversation.

The gap between agents that remember and agents that don't appears in hard numbers, not just anecdotes. A 2026 comparison of ephemeral versus persistent agent architectures found that for recurring workflows needing memory and scheduling, persistent setups beat ephemeral ones by a wide margin on completion rate, error recovery, and cost per complex task, while one-shot research tasks came out close to a tie. Statelessness doesn't hurt you on a single quick question, but it breaks down fast the moment a task spans more than one sitting.

The Claude Agents SDK shows how this plays out in a real, widely used tool. The SDK tracks conversation history within a session, writing it to local JSONL files by default, and offers an optional SessionStore interface for mirroring transcripts to external backends. That state is keyed by session ID, not by user identity. Two developers on the same team can each run the agent for months, building up separate sessions the whole time, and neither session ever learns a thing about the other person's habits, preferences, or history. The SDK's built-in option, InMemorySessionStore, is marked by its own documentation as unsuitable for production. Teams that want real persistence have to build the SessionStore protocol themselves, backed by actual durable storage.

Building agent frameworks the way web services have always been built produces exactly this outcome: stateless by design, with persistence bolted on only if someone goes looking for it.

The two distinct problems developers conflate when they say "memory"

Ask a developer what "agent memory" means and you'll usually get one answer, when there are really two separate problems hiding inside it. Conflating them is how teams end up with systems that half-solve both and fully solve neither. Conversational memory tracks what the agent said and heard. Tool state tracks what the agent actually did.

Conversational memory covers past interactions, user preferences, and the accumulated sense of who a person is and what they care about. This is the user-identity layer the Claude Agents SDK explicitly leaves out. Tool state is a different animal entirely: cursor positions in a paginated API call, a partially built report sitting half-finished, a list of records already processed, a repository an agent has already indexed. It's the execution record of what the agent did with the outside world.

Ask yourself which one your system is actually missing. If your agent forgets a user's preferences between sessions, that's a conversational memory gap. If your agent re-fetches every page of an API it already paged through, or re-indexes a codebase it indexed yesterday, that's a tool state gap. Most production failures trace back to the second kind, and teams notice it least because it doesn't make the agent act rude. It wastes compute and slows work down through repeated effort.

Compaction makes both problems worse, but not in the same way. Compaction is the summarization step that keeps a long-running conversation inside the context window. The ATWZ paper identifies compaction and session termination as separate problems: compaction condenses the conversation into a summary, causing an agent's working details to become vague, while working state vanishes when a terminal closes, and both must be addressed separately. Each needs its own fix. A third failure mode occurs specifically on multi-agent teams: decisions and operations pile up inside old compacted chats, and the project slowly becomes harder to maintain and review. The paper calls this agentic technical debt.

Even a model with a huge context window doesn't make this go away. Feeding an agent its entire history every single turn is too slow and too expensive at scale, which is why production agents still need an external memory store built for retrieval rather than full replay.

There's also a failure mode that's easy to miss because it doesn't look like a failure at all: the wrong state gets preserved, or the right state can't be found, or old state gets treated as if it were current. Call it the problem of a dead teammate whose state lingers on as if it were still alive. On releases of Claude Code before version 2.1.178, on-disk state outlives the session even after the runtime registration for that teammate is gone. A dead teammate's entry just sits in the team directory, and whatever runs next has to treat it as if it were a live teammate. Stale state like that is arguably worse than no state at all, because the agent reasons from a confident but wrong picture of the world, and nothing about its behavior signals that anything is off.

State management belongs at the infrastructure layer, not the application layer

Handing state management to whichever application developer happens to be building on top of the framework isn't a neutral choice.

Agent work is inherently stateful in a way a normal web request never is: every tool call, every exchange, changes the internal state of the agent or the system it's touching. Treating that like a stateless web request is a category mismatch from the start. And the burden this creates isn't abstract. The pluggable SessionStore model puts real operational weight on the developer: wiring up a Redis or similar session store takes serious infrastructure work that sits well outside the SDK itself. A position paper on collaborative agentic AI interoperability names state management as one of four essential building blocks for any agentic ecosystem that wants to work at web scale, alongside agent-to-agent messaging, interaction interoperability, and discovery. Its argument is direct: build these primitives in isolation, team by team, and you get a landscape of fragmented, incompatible systems that can't talk to each other.

The clearest way to think about this is the same way operating systems settled the equivalent problem decades ago. Application developers don't write their own memory management or process scheduler. They build on top of an OS that already solved durability, isolation, and recovery, and they trust it to keep working. Agent developers are, right now, mostly in the position of writing their own memory manager from scratch, every time, for every project.

The twist is that the old OS abstractions don't transfer cleanly. Processes, threads, files, sockets, and resource controllers were built for predictable, deterministic workloads, not for dynamic, adaptive agents making semantically rich decisions. Agent infrastructure has to be designed from first principles rather than inherited wholesale. AIOS is one attempt at building that kind of system: an LLM-agent operating system that pulls scheduling, context management, memory, storage, and access control out of individual agent applications and into a shared kernel that manages many agents at once. The OS layer, in this framing, is what gives agent state an identity, isolates it from other agents, and makes it durable and recoverable.

"Operating system" here isn't software you download and install; it's a coordination layer: something that gives a group of agents shared memory, shared tool access, shared decision logic, and a channel for human oversight. That framing has already moved past the research-paper stage. Fiserv launched agentOS in May 2026, an agentic AI operating system meant to help financial institutions deploy, manage, and scale AI agents, built to run natively across Fiserv's own platforms, core, payments, issuer processing, and servicing, with policy controls, auditability, and human oversight built into the design. Whatever you make of Fiserv's specific execution, the fact that a company operating at that scale is building this as infrastructure rather than leaving it to individual application teams says something about where the industry has decided this problem actually belongs.

What each layer of the 2026 memory stack solves

The memory tools available in 2026 span a set of layers that solve different problems, and picking the right one depends on diagnosing which of the two problems from earlier, conversational memory or tool state, is actually the one you're short on.

On the tool state side, there are five main strategies, running from lightest to most capable. In-memory state buffers, things like a plain Python dictionary or an in-process graph state, are fast and need no extra infrastructure, which makes them fine for short, single-session tasks, but a crash or restart wipes them out completely and they can't be shared across processes. Database-backed checkpointing captures the full agent state at every transition and lets you pause a task, resume it later, or replay it from an earlier point, though schema changes force migrations and large binary outputs can bloat the database fast. File-based persistence, meaning JSON snapshots, YAML configs, or binary artifacts written to disk, is easy to inspect by hand and works well for long workflows that produce large outputs, but local files don't travel across machines, and moving them to cloud storage adds latency and credential management overhead. Key-value and document stores, the Redis and DynamoDB and Firestore family, give you fast reads and writes with automatic expiration, which suits high-throughput agents running concurrently, but they don't handle files natively and add their own operational overhead to run. Workspace-native persistence stores tool state in a shared workspace both agents and humans can read directly. This is the approach the ATWZ layer takes with Claude Code, treating each agent like a human employee with its own durable "workstation" directory sitting on disk.

Conversational memory is a separate market with four systems worth knowing in 2026. Letta, the production successor to MemGPT, is a full agent runtime where memory management sits at the center of how the agent executes, built around a core memory that's always in context like RAM, archival memory that's an external searchable store like disk, and recall memory that holds the conversation history, with the agent itself deciding what to keep in core memory and what to archive. Mem0 works differently: it's a memory service any agent can call into, acting as an add-on rather than a full runtime, and it reports accuracy gains over OpenAI's memory system on the LOCOMO benchmark while processing a large volume of tokens daily across its customers. Zep, built around the Graphiti temporal knowledge graph engine, is tuned specifically for reasoning about time and sequence. It scores 71.2% on LongMemEval against a notably lower score for Mem0 on the same benchmark, a gap that matters most for workflows where knowing exactly when something happened, not just that it happened, changes the decision. Teams already committed to a graph-based orchestration style can use a native memory SDK for lightweight checkpointing without standing up a separate memory service, trading scope for low friction. Cognee is open-source and graph-based, combining relationship graphs with semantic embeddings, integrating with several orchestration frameworks and MCP-compatible runtimes, supporting auto-generated ontologies and five data sources with more planned, and offering self-hosting with multi-tenancy and user-level isolation for teams that need to keep memory separated by user.

None of these, as of 2026, solve one particular gap: no production system does adaptive cross-level compression; no tool automatically decides what should be compressed, archived, or thrown away as an agent's history grows. The literature has taken to calling this the "missing diagonal" of the 2026 memory stack. That tuning work stays manual until something fills the gap, so no one tool here is a complete answer.

ATWZ and the file system as a persistence primitive for agent teams

ATWZ starts from a simple premise: agent state has to live outside the session's in-context memory by default, not as a feature added later, and an ordinary file system is enough to hold that state as long as each agent's working state is treated as a real, durable artifact rather than a throwaway side effect of running the agent. ATWZ, short for Agent Team Work Zone, is a filesystem-based operations layer built around Claude Code's native Agent Teams feature, described in a paper published in July 2026 by Shouren Wang at Case Western Reserve University.

The design principle behind it treats every agent and every teammate the way you'd treat a human employee: each one gets a durable "workstation" directory. Roles, working context, decisions, messages, task files, and the team roster all become persistent, per-agent files sitting on disk, connected to Claude Code through a thin layer of hooks, scripts, and skills. The agents themselves don't change how they run. ATWZ doesn't touch Claude Code's execution model at all. What changes is that everything an agent would need to pick back up where it left off gets written down somewhere durable, which makes one-command reactivation possible after almost any kind of interruption.

That design targets three specific failure modes that session-scoped memory can't touch. The first is the irrecoverable agent team: Claude Code's own documentation states that closing a terminal or dropping an SSH connection means /resume and /rewind will not bring back in-process teammates, so a lead agent resuming a session may try to message teammates that no longer exist. ATWZ's automatic checkpoints and one-command reactivation flow rebuild the team from what's on disk instead. The second is compaction erosion: periodic backups mean an agent's working knowledge can be recovered even after compaction has summarized away the fine detail. The third is cross-session communication, handled through a file-based inbox that lets agent "employees" leave documents for each other, cutting down on the need to rewrite long handoff prompts every time a task changes hands.

The Claude Code API itself shifted under this design, replacing manual team registration with an automatic, session-scoped team that gets cleaned up when the session exits, while the task list directory stays on disk so a resumed session keeps its tasks. ATWZ is built to work across both the old and new API, treating the newer one as the primary case. The core argument underneath ATWZ doesn't change with that API update: favor files over context, checkpoint constantly, and make reactivation a single command rather than a manual rebuild. That argument is really the same one running through this whole piece, just applied at the level of a single tool: state that only lives in context is state you will eventually lose, and the fix isn't a smarter model, but a place for that state to live when the session ends.