Agent Memory and State Persistence Across Coding Sessions

Coding agents forget everything the moment a session ends. This is not a bug in any one product, it is a structural consequence of how large language models work: a model can only reason over what sits inside its active context window, and that window resets to empty the next time you open a new session.

Why coding agents start every session knowing nothing

A large language model has no memory outside the text fed to it at inference time. Whatever the agent read, wrote, or decided in a prior session exists only within that session's context window, and once the window closes, none of it carries forward on its own. File edits, architecture decisions, dead ends the agent already tried and abandoned, naming conventions the team settled on weeks ago: all of it disappears unless something outside the model's own operation chose to save it. The agent does not choose to forget. It simply has nothing left to remember with.

Making the context window bigger does not solve this. A survey of persistent-state LLM agent systems documents a pattern called "lost-in-the-middle" degradation: as context grows longer, a model's attention does not spread evenly across it, and information buried in the middle of a long context gets retrieved less reliably than information near the start or end. Stuffing a session with the entire history of a project does not mean the agent will reliably recall the detail that matters three screens later.

Coding makes this worse than most other LLM applications, because a codebase is not a casual conversation with a few facts to track. An agent working on code has to hold onto far more than a user's name or a stated preference. It needs the shape of an entire project and the reasoning behind that shape, and by default it gets none of it, every single time a session starts.

The concrete costs of rebuilding context from zero on every session

Starting from zero is easy to dismiss as a minor inconvenience, something that costs a developer a few minutes of re-explaining at the top of each session. Over the course of real, iterative work, that cost compounds in several directions at once.

Debugging and refactoring that spans multiple days depend on an agent that can pick up a thread exactly where it left off. Rebuilding that context is not free in token terms either: the architecture docs, error logs, and API contracts a team sends to re-establish context on every session add up, and that cost scales with how many developers are doing it and how often. Documentation from claude-mem puts this directly in terms of agent time: over a two-week sprint run at one session per day, the time spent re-establishing context rather than doing actual work consumes a meaningful share of the agent's total capacity for that sprint.

The deeper cost is architectural. The reasons behind a technical decision rarely live in the code itself, so the agent can be right about the code while still missing the half of the picture that never made it into the files it can see.

That gap widens further at the scale of multiple services. When each repository is indexed on its own, an agent working in one service has no way of seeing that a schema change there breaks a consumer in another. None of this appears as an error in the moment; it appears weeks later, as a production incident nobody can trace back to a single bad decision, because the decision looked locally sound.

The four memory types a persistent agent must manage

Fixing statelessness requires knowing what "memory" actually has to cover, and it is not one thing. Persistent agent memory breaks into at least four distinct types, and each one calls for different storage and retrieval treatment.

Episodic memory covers what the agent actually observed and did in past sessions: the files it edited, the tool calls it made, the specific error messages it ran into along the way. This is the record of events, tied to a particular moment in the project's history.

Semantic memory covers the stable facts about a project that do not change session to session: which module owns authentication, what the data model looks like, which external APIs the system depends on. Where episodic memory is a record of what happened, semantic memory is closer to a reference, a standing description of how the project is put together.

Procedural memory covers the patterns an agent has learned about how work gets done in this particular codebase: the linting rules the team follows, the test patterns it expects, which libraries are approved and which are not. This is less a fact about the project and more a habit the agent has to carry forward, one that shapes how it writes code rather than what it knows about the code.

Control-relevant state is the governance layer: task ledgers tracking what has been started and what remains, permission records defining what the agent is allowed to touch, provenance and audit records showing where a decision came from, and records of commitments the agent has already made to systems outside itself. This layer determines what the agent is permitted to do next and what it has already done that cannot simply be undone.

The distinction matters because these four types cannot all be stored and retrieved the same way. A vector store, built around similarity search, handles episodic and semantic retrieval reasonably well: it can find the passage of text that resembles a query closely enough to be relevant. Procedural and control-relevant state need something else: structured records that track when a piece of state became valid, when it stopped being valid, and whether it has been changed since it was written. Similarity search alone cannot tell an agent whether a permission has since been revoked.

How state moves through a session: the write-validate-organize-retrieve arc

Treating memory as a static store, something an agent simply writes to and reads from, misses most of what makes memory reliable. Memory is a lifecycle, and each stage of that lifecycle is a place where things can quietly go wrong.

A survey of persistent-state LLM agent systems describes this lifecycle as having two arcs. The forward arc runs through observing, writing, validating, organizing, retrieving, and acting. The return arc runs through updating, forgetting, auditing, and rolling back. Across the literature the survey reviews, attention concentrates heavily on the first half of that cycle, accumulation and retrieval, while the second half, the governance side, is underserved.

The forward arc starts with a decision about what becomes memory. Not every tool call or file read deserves to be stored. An agent that saves everything indiscriminately ends up with a memory store as noisy as no memory at all, so the choice of what counts as signal happens right at the point of observation, before anything gets written down.

What comes after writing is where most systems fall short. The survey calls validation "the missing gate": most systems write new state without checking whether it is consistent with what is already stored, or whether the new information can be trusted. A fact written without that check can sit in memory indefinitely, contradicting something written earlier, with nothing in the system positioned to catch the conflict.

The rarest capability in deployed systems sits at the very end of the return arc: forgetting and rolling back. An agent that can accumulate and retrieve memory but cannot update a fact that has gone stale, forget a decision that has since been reversed, or show how a stored fact shaped a past action is running an append-only log with a search function attached to it.

Storage substrates: what each layer of the stack stores

Knowing what needs to be stored and how it should move through a lifecycle still leaves the question of where each piece of it actually lives. No single storage substrate covers all four memory types well. Production coding agents combine several layers rather than picking one: context-window injection, vector retrieval, and structured graph or relational stores, each handling a different part of the job.

The context window itself works like RAM: fast, immediately available to the model, and gone the moment the session ends. Many developers already work around this by hand, keeping an instruction file in the repository that records project conventions for the agent to read at the start of each session. That workaround helps, but only partway. A static file captures the project as it looked the last time someone edited that file. It says nothing about why a decision was made, nothing about which approaches were tried and failed before the current one was settled on, and nothing about the fact that a payment API the file still references was deprecated two weeks ago. The file is accurate until the moment it isn't, and nothing in the system tells the agent when that moment arrives.

Vector stores solve a different part of the problem: they return chunks of stored text that resemble a query, which works well for episodic traces and semantic facts that can be matched by similarity. What a vector store does not have is any sense of how two facts relate to each other. A question like "what did the team decide about the session store after the race condition" needs the system to connect a decision to the incident that caused it, a relationship that similarity search alone cannot trace. A vector database stores embeddings and returns similar records; deciding which facts deserve to become memories, linking related facts together, replacing a fact once it goes stale, and ranking memories before they enter an agent's context are separate jobs, and tools built purely around vector search do not do them.

Graph-structured stores fill that gap by representing entities, events, and relationships explicitly, and by tracking when a fact was true rather than treating every fact as permanently current. That structure supports multi-hop reasoning, following a chain of connected events and decisions across sessions, something flat retrieval has no mechanism for. Zep, built on the open-source Graphiti temporal graph engine, converts conversations, documents, and structured data into entities, relationships, and facts carrying temporal metadata, so the system can tell a current fact apart from an earlier version of that same fact and preserve the order in which things changed.

A further layer treats agent state as something the runtime itself manages, rather than something assembled fresh for every prompt. Letta, formerly known as MemGPT, applies a similar logic at the level of an individual agent: it reads, writes, and modifies persistent memory blocks as part of its normal execution loop, paging information between external storage, playing the role of disk, and the active context window, playing the role of RAM. Adopting Letta means adopting both an agent runtime and a memory system at once, since the two are bundled together, which tends to affect the shape of the broader application built around it.

Tools that implement cross-session memory for coding agents specifically

Several tools now add persistent, structured memory on top of existing coding agents, each one making different choices about what to capture, where to store it, and when to bring it back into context.

claude-mem, currently at version 13.8.0 and released June 21, 2026, works as a plugin across Claude Code, Gemini, Codex, OpenCode, OpenClaw, Hermes, and Copilot. Its documentation describes five lifecycle hooks: SessionStart, UserPromptSubmit, PostToolUse, Stop, and SessionEnd. PostToolUse does the heavy lifting, capturing every tool call the agent makes, edits included, as the main signal for what gets remembered, while a separate PreToolUse hook handles read operations. What it captures gets written to two local stores: SQLite, searchable by keyword through FTS5, and a Chroma vector store for semantic search. Retrieval runs through a three-layer search pattern that scans a compact index first and only pulls full observations for the results that actually look relevant, which keeps the retrieval step itself cheap. The documentation gives a concrete picture of what this looks like in practice: an agent debugs a JWT authentication issue in a TypeScript service, reading the auth middleware, editing the token validation logic, and fixing a race condition in the session store. Three days later, a new session starts with that context already injected, and the agent moves straight into refresh-token rotation without anyone re-explaining what happened earlier in the week. Installation runs through either npx claude-mem install or, from inside Claude Code, /plugin marketplace add thedotmack/claude-mem followed by /plugin install claude-mem.

Mem0 takes a different approach, acting as an open-source memory layer that sits on top of an existing agent, without requiring a separate runtime. It extracts useful information from an agent's interactions through single-pass extraction and entity linking, then retrieves it later by combining semantic, keyword, and graph-based signals. Because retrieved memories stay smaller than a full conversation history, the amount of context injected into a session stays lower than it would with a naive replay of everything that happened before. Mem0 runs either as a managed service or self-hosted, depending on how a team wants to operate it.

What these tools share is a rejection of the default assumption that a coding agent has to start from nothing every time.