AI Agent Long-Term Memory: What We Store and How It Went Stale

Long-term memory for an AI agent is a store that lives outside the model’s context window and survives between sessions. The agent writes facts to it, reads them back later, and your team can inspect and correct it. The hard part is not storage. It is keeping what is stored true.

We built one for our own agents in October 2026 and it went stale within three days. This post covers the types of memory worth keeping, what we put in ours, how it drifted, and a check you can run on yours this week.

What long-term memory for an AI agent actually is

Long-term memory is information an agent can retrieve in a later session without the user repeating it. It is separate from the context window, which holds only the current conversation. Anthropic’s memory tool documentation (as read on October 27, 2026) describes a directory of files that persist between sessions, which Claude can create, read, update and delete.

Two details from that documentation shape every design choice. First, the memory tool runs client-side: the model requests a file operation and your application carries it out against storage you control. The memory lives in your infrastructure, not in the vendor’s.

Second, the same documentation tells you to cap file sizes and to periodically delete memory files that have not been accessed in a long time. Even the vendor page treats expiry as your job.

Three kinds of memory, and which one goes stale first

LangChain’s memory documentation (as read on October 27, 2026) splits long-term memory into three types. Semantic memory holds facts about users or entities. Episodic memory holds past experiences, often as examples. Procedural memory holds rules and instructions, which for most agents means the system prompt.

Type	What it holds	Our example	Staleness risk
Semantic	Facts about people, systems, accounts	Who owns which system, which environment is primary	High: facts change without notice
Episodic	What happened and what was decided	A past incident and the fix that held	Medium: true when written, misleading when reused
Procedural	Rules for how to behave	”Stage named files only”, “never merge without checks”	Low per rule, but old rules conflict with new ones

Semantic memory goes stale first because the world moves and the note does not. A note that says one machine is the primary host is a fact with a shelf life, and nothing in the file says when it expires.

What we store, and what we refuse to store

As of October 2026 our agents share one memory store, kept in a private git repository. We chose that over a vector database for one reason: every change is a diff a person can read.

What goes in:

• Rulings. A decision a person made, with the date and the reason. These are the most valuable entries.
• Environment facts. Which host is primary, where a given job runs, which tools lie to you in a known way.
• Lessons from incidents. A short note per failure: symptom, cause, fix, and how to check it again.
• Generated inventories. Lists of agents, apps and scheduled routines, produced by a script, never typed by hand.

What stays out: secrets, anything that can be recomputed from a live system, and status. “Shipped” and “done” are claims that decay, so we store the check that proves them instead. Our post on how to know an automation is still working covers that distinction in detail.

Anthropic made a point about volume in its September 29, 2025 announcement of the memory tool and context editing. On an internal agentic search evaluation, the combination improved performance by 39% over baseline, and context editing alone gave 29%. That is the vendor’s own test, not ours, but it supports the design: keep the active context small and put durable facts in the store.

How our memory went stale in three days

The store went live on October 5, 2026. By October 8 our CEO reported it was already out of date. We audited it and found four separate causes, none of them about the model.

The checkout was never refreshed. Agents read the store from a local copy of the repository. Nothing pulled new changes into it, so the copy drifted behind the shared version. Sessions then built their startup briefing from the old tree.

The nightly job never ran. A scheduled refresh had been installed from a path that does not survive a logout or reboot. It ran zero times. Worse, the freshness label read “fresh” because it was derived from when a build file was written, not from the age of the content.

Live memory was never backed up or promoted. New notes sat in one working directory, uncommitted. Answers given to the team in the task system never made it into the durable layer.

Hand-written status lines had no dates. The startup briefing carried a line saying one machine was the primary host. A person had since ruled that a different machine was primary. The line did not say when it was written, so nobody could see it was wrong.

The common thread: we counted plumbing as done. Hooks fired, files existed, the briefing printed. None of that proved the content was current.

The fixes that held, and the one still open

What we changed, merged on October 8, 2026:

1. The live copy is now a read-only mirror of the shared repository. All writes go through a temporary working copy and a pull request.
2. A sync step runs at every session start with a short time limit, and again nightly. Any unique local commit is rescued to a side branch instead of being discarded.
3. The scheduled refresh now lives where the operating system keeps it across restarts.
4. Freshness is read from the content, not from a build file. The briefing header shows the age of the oldest generated list and prints a warning line when anything is off.
5. Every project line in the briefing carries an “as of” date.
6. A health script exits non-zero when any of this is off, and a scheduled check runs it again days later.

One item is still open as of October 27, 2026: a read-only database role that lets the inventory scripts see two of their data sources. Until it is set up, two of the generated lists depend on a manual step. We have a task for it. We do not call it solved.

The unattended parts also deserve the same scepticism as any other automation. The earlier “done” on day one counted only that the pipeline existed. Our handover checklist makes the same point from the client side: if nobody can show you a fresh run, it is not running.

A check you can run this week

Pick any five facts your agents rely on. A primary system, an owner, a threshold, a supplier, a rule. For each one, answer three questions.

• Where is it written? One place, in a file a person can open.
• When was it written? If the entry has no date, treat it as unknown.
• What proves it is still true? A command or a query, not a status word.

Then ask for the oldest entry in the store. If your tooling cannot answer that in one command, you have found your first gap. Anthropic’s guidance to prune files that have not been accessed in a long time is the cheap version of the same idea.

One more test is worth running. Change a fact on purpose, such as which machine is primary, and see how long it takes for the agents’ startup context to say so. Ours took days the first time. That number is your real memory latency.

Where this fits

Memory is the part of an agent fleet that quietly decides whether every other part behaves. An agent that cannot recall a ruling will ask for it again, or worse, act on an old one. In an AI workforce sprint we set up the store, the write path, the freshness check and the people who own corrections, so memory stays an asset rather than a liability. The fleet it comes from is on the agent fleet proof page, with the failures we fixed listed beside the wins.

We are building a firm where AI runs the work end to end, and a memory that lies would sink that plan quickly. So we treat every stored fact as something with an age.

If you want to see how a memory store would look for your agents, start async. We reply within one business day, and there are no meetings.