How AI Agents Keep State Across Sessions

A fresh session forgets everything and re-explores. Bigger context windows do not fix this. Externalize a session-end handoff artifact instead.

An AI coding agent keeps state across sessions only when you externalize that state on purpose, because every fresh session starts with an empty conversation and rediscovers the work from scratch. The reliable pattern is a structured handoff artifact written at the end of each session: the decisions made and why, the files touched, the approaches already tried and rejected, the current test state, and the exact next actions. The next session reads that artifact and resumes, instead of re-exploring the codebase and second-guessing choices the last session already settled.

Multi-day agent work almost never fits in one sitting. A feature that spans several sessions, or several sandboxes, crosses a boundary every time the process ends: the window is reset, a new container spins up, or a day passes and you reopen the task. On the other side of that boundary the agent has no memory of the last one. It knows only what is on disk and whatever you hand it. If you hand it nothing, it reconstructs a partial, lossy version of yesterday and often contradicts a decision it cannot see.

This post argues that cross-session state has to be a deliberate artifact, and that thesis points somewhere commercial: we build TLM Forge, a process layer for AI coding, and a persistent memory layer is adjacent to what we sell. So read the vendor-neutral mechanics as the load-bearing claims, and treat the one product paragraph as disclosed self-interest.

Bigger context windows do not solve this

The obvious objection is that context windows keep growing, so the problem should shrink on its own. Gemini 1.5 Pro shipped a 2 million token window to all developers, and Claude Sonnet 4 added a 1 million token window on the Anthropic API, a five times increase that fits codebases over 75,000 lines. These are real jumps. They do not make cross-session state a solved problem, for three separate reasons.

Sources: Google: 2M context window for Gemini 1.5 Pro, Anthropic: Claude Sonnet 4 now supports 1M tokens of context

First, a session boundary discards the window regardless of its size. A new process, a new sandbox, or a reopened task starts at zero tokens whether the ceiling is 200,000 or 2 million. The window measures how much a single live session can hold, not what carries from one session to the next. Nothing about a larger ceiling changes what survives a reset.

Second, long tasks exhaust even a large window from the inside. A multi-day feature accumulates file reads, tool output, failed attempts, and back-and-forth until the running total approaches the limit. Claude Code, for example, works against a 200,000 token session budget and compacts the conversation into a summary when it nears the ceiling, then keeps going on that summary rather than the full history. A bigger number pushes the compaction point later; it does not remove it. The task still outgrows the window eventually.

Sources: Claude Code: explore the context window

Third, a full window is not a well-used window. The paper "Lost in the Middle: How Language Models Use Long Contexts" found that model performance is highest when relevant information sits at the very beginning or end of the input and degrades significantly when the model has to use information buried in the middle, and that accuracy drops as the context grows longer, even for models built for long contexts. Stuffing a million tokens of yesterday into a prompt is not the same as the agent reliably acting on the one decision that matters, which may now sit in the low-attention middle.

Sources: Liu et al., Lost in the Middle: How Language Models Use Long Contexts (arXiv:2307.03172)

Both compaction and reset lose something

When a session ends there are two ways state disappears, and both are lossy. A hard reset loses everything: the new session sees only the repository and forgets the reasoning entirely. Compaction is softer but still lossy: summarizing a long history into key facts is a compression pass, and compression drops detail by definition. The summary keeps what the summarizer judged important and quietly discards the rest, including, often, the reason an approach was abandoned or the constraint that ruled out the obvious fix.

The failure mode is specific and expensive. A second session, working from a reset or a thin summary, re-explores files the first session already understood, re-derives conclusions it already reached, and sometimes re-attempts an approach the first session tried and rejected for a good reason that did not survive the boundary. The wasted tokens are the small cost. The larger cost is the contradiction: two sessions of the same task can ship two incompatible mental models of the code, and the second one overwrites the first without knowing it disagreed.

This is a different problem from managing the window inside one session. Trimming reads, ordering the prompt, and deciding what to keep live are within-session concerns, and context management for AI coding covers them. Cross-session state is about what deliberately survives after the session is gone and how the next one verifies it. You can be excellent at the first and still lose a day to the second.

The fix: a session-end handoff artifact

Write the state down before the session ends, in a structured file the next session reads first. Treat it the way a careful engineer treats a shift handoff: not a transcript of everything that happened, but the durable conclusions and the live state, in a form the next reader can act on without reconstructing the reasoning. The artifact is deliberately small and high signal, so it lands in the high-attention start of the next prompt rather than the lossy middle.

A useful handoff has five parts. Decisions and rationale record what was chosen and, more importantly, why, so the next session does not relitigate a settled call. Files touched name the surface area, so the next session knows where the work lives without a full crawl. Approaches tried and rejected are the highest-value section, because they stop the next session from walking into the same wall. Current test state records what passes, what fails, and what has not run, so green is not assumed. Next actions spell out the immediate steps in order, so the session resumes with a task, not a question.

• Decisions and rationale: the choices made and the reason each one won, so settled calls stay settled.
• Files touched: the modules and files in play, so the next session locates the work without re-crawling the repo.
• Approaches tried and rejected: what failed and why, so the next session does not repeat a dead end.
• Current test state: what passes, what fails, and what has not been run, so nothing is assumed green.
• Next actions: the immediate steps in order, so the session resumes with a concrete task.

Leave the workspace clean enough to resume

The handoff describes intent; the workspace has to match it. A session that ends with half-applied edits, a stash of unrelated experiments, a failing build the artifact does not mention, and three debug files left in the tree hands the next session a puzzle before it can start. Resumability is a property of the repository state, not just the note. Before writing the handoff, get the tree into a state the artifact can describe unambiguously: commit or revert in-progress work, remove scratch files, and make sure the recorded test state is the actual test state.

Unambiguous is the operative word. If the handoff says the auth module is done and passing but the working tree has uncommitted changes in that module, the next session cannot tell which is true and has to investigate, which is exactly the re-exploration the artifact was supposed to prevent. A clean tree plus an accurate handoff means the next session can trust the note and act, rather than treating it as one more claim to verify against a messy reality.

Hydrate, then verify, at the start of the next session

The next session opens by reading the handoff and reconciling it against reality, not by trusting it blind. The artifact is a claim about the world made by a process that is now gone, and the world may have moved: a dependency changed, a teammate merged, or the summary quietly dropped a caveat. Hydration is read the artifact, then confirm the load-bearing parts: run the test suite to check the recorded state, glance at the named files to confirm they match the described decisions, and only then act on the next actions.

Verification is cheap relative to what it prevents. Running the suite once at the start costs seconds and either confirms the handoff or exposes the one line that drifted, which is far cheaper than building an hour of work on a false assumption of green. The habit also disciplines the writer: a session that knows the next one will run the suite has an incentive to record the test state honestly rather than optimistically.

A handoff file in the repo is the simple version and a fine place to start. It has limits: it lives in one repository, one person maintains its format, and it does not travel across projects or accumulate the longer arc of what an agent learned about a codebase over weeks. A private, persistent memory layer such as MemX externalizes that durable context across sessions and projects, so the state an agent needs to resume is stored deliberately rather than reconstructed each time, and it persists past any single session boundary.

The reason this belongs in your process and not just your tooling is that a good handoff starts with a good spec. If a session does not know what "done" means or which decisions are load-bearing, its handoff will record noise. This is the gap TLM Forge is built for: a spec audit fixes the boundary and the definition of done before code exists, so each session knows what to hand off, and independent review checks that the resumed work still matches the spec rather than a drifted summary of it. Writing specs for AI coding agents and how to do agentic coding cover how to scope the work so a multi-day task survives its own session boundaries.

Larger context windows are a genuine improvement and make more single-session work possible, and in-session compaction is a reasonable way to stretch one session further. The claim is narrower: neither one carries state across a session boundary, because a boundary discards the window and compression discards detail. Multi-day agent work needs its state externalized on purpose, in an artifact the next session hydrates from and verifies, on a tree clean enough to resume without guessing.