Why Does My AI Agent Forget Everything Between Sessions?
"My AI agent forgets everything between sessions" is one of the most common complaints from people building their first agent, and it is frustrating precisely because the agent seemed so capable a minute ago. You had a long, useful conversation. It remembered your name, your project, the three decisions you made together. Then you restarted it, or came back the next morning, and it greeted you like a stranger. The good news: an agent that forgets everything between sessions is almost never a broken model. It is a missing storage design, and it is fixable with a few concrete changes.
There are exactly two causes, and they stack on top of each other. Understanding both is the whole game, so let us take them one at a time before getting into fixes.
Cause One: Language Models Are Stateless
The first cause lives in the model itself. A large language model has no memory of previous API calls. Each request is independent. When you send a message, the model reads the tokens in that one request, produces a reply, and retains nothing afterward. The "memory" you experience inside a single chat session is an illusion created by the client: it resends the entire conversation history with every new message, so the model can see what came before.
That works fine within one session. The problem is what happens at the boundary. When the session ends, whatever code was holding that growing history in a variable is done. Unless something wrote that history to durable storage, it is gone. The next session starts with an empty history, the model has never had memory of its own, and so the agent genuinely knows nothing about you. Statelessness is not a bug to patch in the model. It is a property you design around by keeping the history yourself.
It helps to separate two ideas that beginners often merge. There is the model, which is a pure function from input tokens to output tokens with no side effects and no storage. And there is the agent, which is the program you wrote around the model: the loop that gathers context, calls the API, runs tools, and decides what to keep. The model will never remember anything. The agent can remember as much as you make it store. Once that distinction clicks, "why does it forget" stops being a mystery about the model and becomes a straightforward question about your own storage code.
Cause Two: Ephemeral Containers Wipe Local State
The second cause lives in the runtime, and it catches people who thought they had solved the first one. Say you were smart and wrote the conversation to a local SQLite file or a JSON file on disk. Locally, on your laptop, that works. Deploy the same agent to a container platform and it can still forget everything, because most containers have an ephemeral filesystem.
When a container restarts, crashes, gets rescheduled, or is redeployed with a new image, its local disk is wiped and replaced with a fresh copy of the image. Anything the process wrote to the container's local filesystem, your SQLite database, your saved embeddings, your notes file, disappears. The agent looks like it forgot, but really the storage underneath it was reset. This is the failure mode behind a surprising number of "my agent lost its memory in production" reports: the code was correct, the volume was not persistent.
Here is the trap in short form:
Stateless model plus in-memory history: forgets at the end of every session.
Correct history-saving code plus ephemeral container: forgets on every restart or redeploy.
Durable external memory plus a persistent volume: remembers across both.
You have to fix both layers. Saving state is pointless if the disk you saved it to vanishes. A persistent disk is pointless if your code never writes anything durable to it. Now the fixes.
Fix One: Persist State to a Volume That Survives Restarts
The foundational fix is a filesystem location that outlives the process. On a laptop that is just your home directory. In production it means an attached volume that is decoupled from the container lifecycle, so a restart or redeploy mounts the same data back.
A minimal pattern is to keep an append-only log of the conversation on a durable path and reload it at startup:
import json, os
STATE_DIR = os.environ.get("AGENT_STATE_DIR", "/data")
HISTORY = os.path.join(STATE_DIR, "history.jsonl")
def load_history():
if not os.path.exists(HISTORY):
return []
with open(HISTORY) as f:
return [json.loads(line) for line in f if line.strip()]
def append_turn(role, content):
with open(HISTORY, "a") as f:
f.write(json.dumps({"role": role, "content": content}) + "\n")
# On startup, rebuild the model's view of the conversation.
messages = load_history()import json, os
STATE_DIR = os.environ.get("AGENT_STATE_DIR", "/data")
HISTORY = os.path.join(STATE_DIR, "history.jsonl")
def load_history():
if not os.path.exists(HISTORY):
return []
with open(HISTORY) as f:
return [json.loads(line) for line in f if line.strip()]
def append_turn(role, content):
with open(HISTORY, "a") as f:
f.write(json.dumps({"role": role, "content": content}) + "\n")
# On startup, rebuild the model's view of the conversation.
messages = load_history()The key detail is that STATE_DIR points at a path that is actually persistent. On a plain container, /data is thrown away on restart. On a host that mounts a durable volume there, the same history.jsonl is waiting after a redeploy. That single distinction is the entire difference between an agent that remembers and one that does not.
There is a quick test to confirm you actually have persistence before you trust it. Write a file to your state path, restart or redeploy the container, and check whether the file is still there. If it survives, your volume is durable and your storage code can rely on it. If it is gone, you are writing to ephemeral disk and every fix above will keep failing no matter how correct the code looks. Run that test once, early, so you are debugging the right layer. It is far easier to confirm the ground is solid before building on it than to discover mid-project that months of "memory" were being written to a disk that resets on every deploy.
Fix Two: Use an External Memory Store
A flat history file works for a simple assistant, but it does not scale to long-lived agents. As history grows you cannot resend all of it on every turn (see our walkthrough of context engineering for AI agents for why the token budget forces the issue). The durable answer is an external memory store the agent writes facts to and retrieves from on demand.
Common choices:
A relational database with pgvector: store conversation summaries and embedded facts in PostgreSQL, then do similarity search to pull back only what is relevant. The extension is at github.com/pgvector/pgvector, and the PostgreSQL side is documented at postgresql.org/docs.
Mem0: a purpose-built memory layer that extracts durable facts about a user and retrieves them across sessions, so the agent "remembers" preferences without you resending the transcript.
Zep: a memory server that summarizes and indexes conversation history for long-running assistants.
The pattern is the same regardless of the tool: on each turn, retrieve the top few relevant memories, add them to context, generate a reply, then write any new durable facts back. Memory becomes something you query, not something you carry in full. Understanding which facts belong where is easier once you know the types of AI agent memory, because episodic, semantic, and procedural memory each get stored and retrieved differently.
An external store also fixes a subtler version of the forgetting problem: cross-device and cross-agent recall. A flat file on one container is invisible to a second replica of the same agent. Once memory lives in a shared PostgreSQL instance, every replica reads the same facts, and a returning user gets consistent answers no matter which process handles the request. That matters the moment you run more than one copy of your agent for reliability or load.
Do run a quick sanity check on the store itself, because a memory database that silently fails to write produces the exact same symptom as no store at all. After a session, query the table directly and confirm the new facts landed. It is a two-minute check that saves hours of blaming the model for something the write path caused.
Fix Three: Summarize So Memory Stays Affordable
Even with durable storage, you do not want to reload a 200-message transcript into every request. It is slow and expensive. The complement to persistence is compaction: periodically fold older turns into a compact summary that keeps decisions, facts, and open tasks while dropping filler.
A workable policy:
Keep the last 8 to 10 turns verbatim, because recent context matters most.
When stored history crosses a threshold, summarize everything older into a few hundred tokens and save that summary to your durable path.
Keep the raw transcript on disk too, so a later turn can retrieve a specific old exchange word-for-word if it needs to.
This keeps per-turn cost roughly flat even as a relationship with the agent spans weeks. The summary lives on the same persistent volume as everything else, so it also survives restarts.
Summarization is lossy, and that is the tradeoff to accept knowingly. If you compress too aggressively, the agent drops a detail the user mentioned days ago and looks forgetful again, this time for a different reason. Keeping the raw transcript alongside the summary is the hedge: the summary carries the everyday load, and the full log is there when a later turn needs a specific old exchange verbatim. Because both files sit on durable storage, neither is lost when the container cycles.
How Sokko Handles This
The reason so many agents forget everything between sessions is that the two fixes above require infrastructure most quick deployments skip: a durable volume plus a running memory store. This is the specific problem Sokko is built around. Sokko gives every agent a durable home where its files and memory are saved automatically and survive restarts, crashes, and redeploys. Long-term memory is a built-in add-on, so the facts and history an agent accumulates are still there after the process comes back. You get durable memory out of the box, without wiring up storage yourself. See the Memory guide to turn it on.
If you are starting from scratch, the practical order is: give the agent a persistent path first, write history to it, add an external memory store when the history outgrows a flat file, and layer in summarization when cost climbs. Our guide on how to deploy a personal AI agent walks through standing one up end to end. Do those in order and the complaint that started this article, an agent that greets you like a stranger every morning, simply stops happening.