What Does an AI Agent Actually Remember Between Sessions?

Only what it writes down. A language model retains nothing once a run ends, so everything an agent still knows tomorrow is something it deliberately wrote to storage and deliberately read back. Agent memory is not a model feature you switch on, it is a storage design you own, and the quality of that design decides whether the agent gets better over months or repeats the same mistake forever.

This trips up almost everyone the first time, because conversation inside a single session feels like memory. It is not. Within one run, earlier messages are still in the context window, so the agent appears to remember. End the run and that context is gone. The next run starts from nothing except what is on disk.

The three things people call memory

Lumping them together is where most bad designs start, because they have different lifespans, different costs and different retrieval patterns.

The running log. A dated record of what happened: what the agent did, what it was asked, what it decided, what broke. This is append-only and it can grow without limit, because it is almost never read in full. It exists for reconstruction, for audit and for the occasional targeted search.

The rule set. The small, curated body of standing facts and instructions the agent loads on every single run. Who the people are, what the constraints are, what the agent is never allowed to do, how this business names things. This is the expensive one, because every line in it is paid for on every run, and it is the one that requires editorial discipline rather than storage.

The retrieval layer. Everything else: documents, past threads, prior outputs, reference material. Not loaded by default. Searched when relevant and pulled in for the run that needs it.

An agent that works well has all three and keeps them separate. An agent that gets expensive and vague usually has one giant file doing all three jobs at once.

Why the rule set is the hard part

Storage is easy. Deciding what deserves to be loaded every run is not, and it is the decision that shapes both cost and behaviour.

Every line in the always-loaded set is read by the model on every run, which means it is a recurring charge and a recurring claim on the model’s attention. Add a hundred lines of nice-to-know context and you have made every run more expensive and, counterintuitively, often worse, because the instruction that actually mattered is now one of four hundred competing for attention.

The discipline that works is to treat the always-loaded set like a constitution rather than a notebook. One current rule per topic. When the rule changes, rewrite it in place and move the old wording to an archive, rather than appending a new section that contradicts the old one further down. Agents follow contradictory instructions badly, and so do people.

A useful test: if you cannot read the always-loaded set end to end in a few minutes and say what it tells the agent to do, neither can the agent.

What should be written to memory, and when

Not everything. The filter is whether a future run would behave differently for knowing it.

Write it down when:

• A human corrected the agent. The correction is a specification, and it is the single highest value thing to record. An agent that is corrected the same way twice has a memory bug, not a judgment problem.
• A decision was made that future runs must respect. Not the discussion, the decision, with the date and who made it.
• Something failed and the cause was found. The failure mode plus the fix. This is how an operation stops relitigating the same incident.
• A durable fact was established. A contact, an account identifier, a convention, a preference.

Do not write it down when it is restatable from a system of record. Memory that duplicates the source of truth goes stale and then competes with it, and the agent has no way to know which one to believe.

The rule we hold to internally is that a correction, a resolved failure or a decision gets written in the same run it happens, not at the end of the day. A mental note does not survive a restart. A file does.

Where memory should live

Next to the agent, inside an account you control, in a format a person can open.

Plain text and structured files have a property that fancier stores do not: anyone can read them, diff them, correct them by hand and copy them elsewhere. When memory is a proprietary blob inside a vendor’s platform, you cannot audit what the agent believes, you cannot correct a wrong entry directly, and you cannot take it with you. The practical consequences of that difference are set out in migrating off a SaaS AI platform.

Ownership also settles the deletion question. If somebody asks you to remove information about them, you can only honour that properly when the memory is in storage you control. Otherwise it is a support ticket and a promise.

Four ways agent memory goes wrong

Everything in one file. The log, the rules and the reference material in one growing document that gets loaded every run. Cost climbs, behaviour degrades, and nobody notices until the bill does something interesting.

Contradictions left in place. A rule changed in March and the January version is still there, three sections down. The agent will sometimes follow the old one. Rewrite in place; archive the old wording somewhere the agent does not load.

Memory that duplicates a system of record. A copy of the customer list in a memory file, slowly diverging from the actual customer list. Query the real system; store the pointer, not the data.

Nothing written at all. The most common failure by far. The agent does good work for a month, is corrected a dozen times, restarts, and is exactly as naive as it was on day one. Everything it learned lived in a context window that no longer exists.

How this connects to everything else

Memory design is the quiet reason some agent deployments compound and others plateau. An agent with a disciplined rule set, an honest log and a retrieval layer gets measurably better at a business over months, because every correction becomes permanent. An agent without them is a fresh hire every morning.

It is also a cost control, which is not obvious until you see the invoice. The always-loaded set is the one thing every run pays for, and the arithmetic behind that line is in what it costs to run an AI agent. If you are still deciding whether the job needs an agent and its memory at all, or a fixed pipeline that needs neither, the flowchart test is the faster question to answer first, and Sovereign Agent covers what a deployment ships, memory included.