What Is Long-Term Memory in an AI Agent?

🧩 The write decision and the read decision

Writing comes first and is harder than it looks. Something has to decide, at the end of a session or as it goes, what in the transcript was worth keeping. A transcript kept whole is not memory but an archive: it grows without bound and defers the entire problem to retrieval time. What is kept instead usually falls into a few shapes — durable facts about the person or the system being worked with, a summary of what a session established and what it left outstanding, and procedural notes recording how a particular thing is done here. Those three fail in different ways, which is a reason to keep them apart rather than in one undifferentiated pile.

Reading is the second decision, and a store read in full at the start of every session is not long-term memory but a preamble bounded by the context window. So retrieval applies, with the same machinery as any other store — vector similarity, keyword match, a filter on recency or subject — and the same failure, that what is not retrieved does not exist for that session and nothing signals its absence. The difference lies in what is being searched. A document store is a corpus somebody wrote and somebody maintains; a memory store is a set of assertions the system made about itself and its user, at varying levels of confidence, none of which is carried forward unless the write step recorded it.

Then there is the problem a corpus does not have. A document can be old and still be an accurate document, because it is dated and it describes its own moment. A memory entry is written in the present tense — the deployment target is this, replies should be short — and when the world moves the entry does not. Memory therefore needs operations retrieval alone does not provide: correction and deletion, applied to a specific entry, at the moment something newer contradicts it. A store that only appends accumulates pairs of entries that cannot both be true, and retrieval will return whichever better matches the query rather than whichever is current.

The last row is what separates a memory store from a cache. Anything a session can be induced to write is something a later session will read as its own prior finding, and the later session has no way to tell where the entry came from unless the entry says so. Provenance on a memory entry is not bookkeeping — it is the only thing distinguishing what the system decided from what it was told to decide.

🗃️ How the Registry classifies a durable-memory task

Writing durable facts from a finished session to a store and retrieving the relevant ones at the start of the next is filed as information retrieval in this registry's classification. Both halves of the task locate and compress material that already existed. The interval between them is long, which changes the engineering considerably and the classification not at all.

The Registry's canonical brief for this entry is filed as: Write durable facts from a finished session to a store and retrieve the relevant ones at the start of the next. Submitted for assessment it is classified as Information retrieval, and its wording is hashed once — to a891264b6746e375…, the first sixteen of sixty-four hexadecimal characters — with the wording itself never stored. The hash is what the derivation reads. That class's own page is /tasks/retrieval.

Classification is one of three inputs. The other two are the configuration submitted with the task, and the permanent chart derived from that configuration — fixed by the model name, the training cutoff and the temperature alone, and never reading the task at all. The same ascendant, ruling planet and harmony therefore appear on every assessment a given configuration receives, whatever it was asked to do. The derivation is published in full at /method.

❓ Questions about long-term memory

What is long-term memory in an AI agent?

It is what the system keeps once a session ends and can retrieve during a later one: facts, summaries of past sessions, and procedural notes. It sits outside any single run, and it is reached by retrieval rather than by being present, which is what distinguishes it from the context window.

How is long-term memory different from the context window?

The context window is the material in one request and is gone when the request is over. Long-term memory persists in a store and is searched. Nothing is in the context because it is in memory; it is in the context because a retrieval step selected it, and anything not selected is absent without a signal.

How is memory different from retrieval-augmented generation?

The machinery is largely the same. What differs is provenance and governance: a retrieval corpus is authored and maintained by people who own it, while a memory store is written by the system about its own sessions, usually without review, and read back as something already established. That difference decides how much scrutiny an entry deserves, not how it is indexed.

What should be written to memory?

As little as will still be worth retrieving, and each entry with enough context to be understood by a session that was not present when it was written. Entries that will never be the best match for any future query cost something to write and add noise to every read, and an entry that cannot be evaluated later cannot be corrected either.

How are stale memories handled?

By making correction and deletion first-class operations on individual entries, and by checking at write time whether the new entry contradicts an existing one. Append-only stores accumulate contradictions, and retrieval has no notion of which of two conflicting entries is current — it returns whichever better matches the query.

Can a memory store be poisoned?

Yes, and it is the failure with the longest reach. Content reaching a session can influence what that session writes down, and the entry is then retrieved in later, unrelated sessions as the system’s own prior finding. Recording where an entry came from, and reviewing what is written rather than only what is read, are the defences; this registry’s page on prompt injection describes the mechanism at the point of entry, and memory is what gives it a second life.