AI Agent Forgets Context Between Sessions — Why & the Fix

Before an agent resumes work, check which decisions and constraints it actually received. A fresh conversation may lack the previous working context, but agent tools can also load project instructions, saved sessions or persistent memory. The practical problem is incomplete or stale carried context, not a universal absence of memory.

Separate stored state from loaded context

A repository, test suite, handoff note and automatic memory can each carry useful information. They do not all load in the same way. Inspect the tool’s current configuration and documented behaviour, then confirm the relevant material is available in the new session.

For example, Claude Code documents project instructions and automatic memory as cross-session mechanisms. Those instructions guide behaviour; they are not a guarantee that every decision is remembered or obeyed. Do not transfer one tool’s loading rules to every agent product.

A terminal session remaining open also does not prove that an agent has the rationale behind an earlier choice. Verify the actual task state and loaded sources.

Preserve rationale without duplicating the repository

A handoff should direct the next operator to authoritative evidence. Code often shows what changed; tests show particular expected behaviours. Neither necessarily records why an approach was rejected, when a compatibility shim can be removed or which owner decision is pending.

Useful notes include:

• A temporary shim, its reason and removal condition.
• A non-obvious choice with the evidence that motivated it.
• A rejected approach and the observed failure that rules it out.
• An open blocker, its owner and the next permitted action.

Avoid copying large code fragments into a progress note. Link to the relevant file, revision or test and explain only the missing decision context. Code and tests can also become stale or incomplete, so the next session must reconcile them with the current task.

A three-case handoff check

Scroll horizontally to compare the columns on a narrow screen.

This is a proposed editing aid, not a rule that forbids documenting tested behaviour. Safety, review or audit needs may require an explicit record even when code exists.

Make the handoff checkable

Task / current revision:
Completed outcome / verification evidence:
Decision and reason / source:
Temporary condition / removal trigger:
Known failed approach / evidence:
Open blocker / owner:
Next permitted action:
Unknown or unverified state:

Before continuing, the next session should check the revision, inspect the cited evidence and confirm that the proposed action is still needed. A note that says deployed is not a substitute for the live verification record. An old permission or plan may also need to be distinguished from the current instruction.

Measure recovery effort before choosing session length

A handoff can reduce repeated reading, but it does not make recovery cost zero. Track the time or tokens spent restoring task context, the sources re-read and errors caused by missing or outdated information. Compare similar tasks and retain failed attempts; no fixed threefold saving is established here.

Start a new session when context capacity, isolation, review, permissions or a clean task boundary makes it useful. Continuing one session can avoid repeated setup, while splitting can prevent unrelated instructions from interfering. The right boundary depends on the workflow. Whichever you choose, keep one current source of task state and a small handoff that points to the evidence.

Start with a written brief if repeated sessions reverse decisions or redo finished work: show the boundary, the loaded context and the decision that failed to carry across. Documentation checked 15 October 2026; no new runtime memory experiment is reported here.