How AI Agents Remember Between Sessions

Start with the fact that explains everything else: the model has no memory. A language model is a function from input to output. Send the same input twice, and nothing carries over from the first call to the second. There is no place inside it where yesterday is stored.

So when an agent refers to a decision you made last Tuesday, nothing was remembered. Something outside the model retrieved a record of Tuesday and placed it into today's input before the model ever ran. Every memory feature you have used is a variation on that one move, and the differences between them are entirely about what gets stored and how it is chosen for inclusion.

That framing is useful because it tells you where to look when memory misbehaves. It is never the model forgetting. It is a retrieval decision, made by ordinary software, that you can inspect.

Mechanism 1: the conversation transcript

The simplest form. The whole exchange so far is resent with every message.

This is why a chat appears to remember what you said three messages ago and why costs climb through a long conversation: you are paying to resend the history every turn. It is also why the illusion collapses at a hard boundary. Once the transcript exceeds the context window, something must be dropped, and the earliest messages usually go first.

Failure signature: flawless recall up to a point, then the beginning of the conversation vanishes completely. Not fuzzy, gone. If your agent forgot the constraint you set in message one but recalls message forty, this is the mechanism.

Mechanism 2: the summary

Rather than resending everything, the system periodically compresses the conversation into a summary and carries that forward instead.

Cheaper, and it survives much longer sessions. The cost is lossy compression: whatever the summariser judged unimportant is gone permanently, and it made that judgement without knowing what you would ask next.

Failure signature: the agent recalls the shape of a decision but not its specifics. It knows you chose a database and not which one. Details that seemed incidental at summarisation time are exactly the ones that disappear.

Mechanism 3: the memory file

The pattern behind most persistent-memory features in coding agents and desktop assistants. Facts are written to a file, and that file is loaded at the start of every session.

# project memory
- Deploys go to staging first, never straight to production
- The API client lives in lib/http, not lib/api
- Owner prefers pytest over unittest
- Currency handling uses integer minor units everywhere

Two things make this the most useful mechanism for day-to-day work. It is durable, surviving indefinitely across sessions. And it is legible: you can open the file, read what the agent believes, and correct it with an editor.

Where the file lives and how it is loaded varies by tool, and increasingly that plumbing is standardised: the Model Context Protocol exists partly so that memory, files and tools can be exposed to any agent through one interface rather than a bespoke integration per product.

That legibility is worth more than it sounds. It is the only memory mechanism you can debug directly. A conventions file like an agents.md is exactly this pattern with a name and a location.

Failure signature: confident application of something that is no longer true. A memory file has no expiry. A fact written in March about a library you replaced in June is still asserted with full confidence in September, because nothing ever revisits it.

Mechanism 4: retrieval from a store

For anything larger than a file, the pattern generalises. Past interactions, documents and notes are stored, converted into embeddings, and the ones most similar to your current message are fetched and inserted into the prompt.

This scales to volumes no context window could hold, and it is selective: only the relevant slice arrives. It is the same machinery as retrieval-augmented generation, pointed at conversation history instead of documentation.

Failure signature: recall that depends on phrasing. Ask about "the deployment problem" and it finds the right note. Ask about "that thing that broke on Friday" and it retrieves nothing, because retrieval matched on semantic similarity and your phrasing missed. Users read this as forgetfulness. It is a search miss.

Reading the four together

Real systems combine them: a transcript for the current turn, a summary when it grows, a memory file for durable conventions, a store for everything historical. When memory behaves oddly, identifying which of the four is responsible is most of the diagnosis.

What this means in practice

Write the durable things down yourself. Anything you would be annoyed to repeat belongs in a memory file, where it is explicit and editable, not left to a summariser's judgement about what mattered.

Prune it. Memory files rot. A quarterly read-through, deleting anything no longer true, prevents the most damaging failure mode, which is confident action on stale information.

Notice degradation before it becomes error. An agent whose answers get vaguer as a session runs long is showing you the summary mechanism at work. That is the moment to start a fresh session with a clean handover, a pattern that matters most in long coding sessions over a large codebase.

Do not confuse quantity with quality. More retrieved context is not better context. Loading everything degrades reasoning through the gradual decay of a crowded context while costing more. The skill is choosing well, not fetching more.

Questions

Does the model learn from our conversations?

Not within a product session. Weights are fixed at inference time. Some providers use conversation data for future training, which is a separate question about data policy rather than about memory, and worth checking per vendor.

Why does it remember one thing and not another?

Because different mechanisms are in play with different rules. The remembered thing was probably in a memory file or matched a retrieval query. The forgotten thing fell off a transcript or lost a summarisation decision.

Can I make it forget something?

Only by removing the record. Delete the line from the memory file, clear the conversation, or remove the entry from the store. There is nothing in the model to unlearn, which is the useful consequence of it being stateless in the first place. The broader picture of what happens inside a single call is in how AI models work.