From recorded experience to useful recall
- An event is recorded, not certified. A transcript can contain evidence, guesses or quoted instructions. Keep enough provenance to tell those apart later.
- Admission is an explicit decision. Check whether keeping this material is useful and permitted. Do not retain sensitive content just because storage is available.
- Preserve the owner and source. Distinguish a confirmed fact from an assertion or model inference. Retain source references and correction status under the retention policy.
- Make retained evidence findable. Index the material without losing links to its original record. An index helps retrieval; it does not establish truth.
- A later query starts a different path. Retrieve within the reader's authorised scope and check the source. A similar old statement can still be stale or superseded.
- Only selected evidence enters context. Return relevant passages with provenance and unresolved conflicts. Recalled text cannot broaden tool permissions or override instructions.
Context alone is not persistent memory
A model’s context window has finite capacity. The model can attend to the information supplied within that context on a given call; prior information omitted from it is unavailable as input until something outside the model supplies it again. Supplying recent turns is context management. Keeping useful information available after those turns leave the window requires storage and a way to bring it back, not just a larger prompt.
The concepts most relevant here, context window and context compaction, describe managing what is in a single call’s context. This page is about the different problem: what survives outside it, across calls, sessions, and tasks.
Sources for the September additions were checked on 14 September 2026. The retained human-review date does not certify this revision; editorial review is pending.
Research patterns, not mandatory storage tiers
MemGPT, Generative Agents and Reflexion separate immediate model input from information available later, but they do not establish a mandatory three-tier architecture. Working and archival memory describe where information lives; episodic memory describes the kind of information being kept. Those are useful distinctions, not interchangeable storage products.
Working memory is information directly available for the current model call. Information outside the context must be retrieved and supplied before the model can use it as input.
Long-term / archival memory is external storage (a database, a vector store) that the agent does not automatically see but can query. MemGPT’s contribution is treating movement between these two tiers as something the model itself manages. The paper’s core analogy is virtual memory paging in an operating system, where a program gets the illusion of more memory than physically exists because the OS pages data between fast RAM and slow disk on demand. MemGPT gives the LLM function calls to do the equivalent: read from archival storage, write to it, evict from the working set. The model can direct memory edits and searches, but an automatic queue manager also records, evicts and summarises messages. Model-directed memory and fixed context-management policies coexist.
Table 2 in the paper’s February 2024 revision reports 93.4% LLM-judged answer correctness for MemGPT with GPT-4 Turbo versus 35.3% for its GPT-4 Turbo baseline on deep-memory questions. These are not retrieval precision or recall. The baseline receives a lossy conversation summary intended to mimic recursive summarisation; MemGPT can search the full history. The result supports the value of accessible history in that setup, not a universal claim that model-directed memory beats every summarisation policy.
Episodic / reflective memory describes records of experience and conclusions derived from them, not an extra storage tier on top of MemGPT. Generative Agents uses a memory stream that records experiences as they happen, a retrieval step that surfaces relevant records by combining relevance, recency and importance instead of recency alone, and a reflection step that periodically synthesises raw records into higher-level conclusions. Those conclusions are written back into the same stream with links to supporting memories. Reflexion’s episodic memory buffer stores an agent’s own verbal self-critique after a failed attempt. It is a narrower instance of the same idea: memory that keeps not just what happened, but what the agent concluded from it, to change behaviour on the next attempt without retraining the model.
Retrieval needs reliable records
Useful memory depends on what is admitted, stored, retrieved and kept current. Retrieval selects which retained records enter the limited working context; it cannot compensate for missing records or make an unreliable record true. Generative Agents’ retrieval function uses a weighted combination of relevance to the current situation, recency (time since last access), and importance (a separately scored measure of how significant the record is). That is a concrete, published answer to “which memories matter right now” for that simulation. Its reported ablations remove observations, plans and reflections, not each retrieval-scoring factor independently. Similarity alone does not establish importance or freshness; recent access does not establish relevance.
Checkpoints, archives and long-term memory solve different problems
| Record | Question | Example | Limitation |
|---|---|---|---|
| Working context | What does this model call receive? | Instructions, recent messages and retrieved passages | Anything omitted is unavailable on this call |
| Checkpoint | Where can execution resume? | Saved graph state and pending work associated with a thread | Durability depends on the backend; it does not prove a remote write happened |
| Execution archive | What was actually recorded? | Messages, calls, tool results and source references | Storage alone does not make old evidence retrievable or true |
| Long-term memory | What should another interaction be able to recall? | A user-confirmed preference or a past investigation with provenance | Needs selection, access checks, correction and retention rules |
LangGraph separates thread-scoped state saved by a checkpointer from a store holding application-defined information across threads. A thread can contain several runs; “short-term” refers to scope rather than a promise of short retention. Adding a store does not decide which statements are worth remembering. Its namespaces organise data; the application still needs to enforce authorisation.
An archive can support both retrieval and incident investigation, but a selected memory should not silently become the only surviving evidence. A summary such as “the ticket was created” loses the distinction between a proposed call, an attempted write and a confirmed external result. Keep the operation and source references needed for diagnosis.
A memory lifecycle with an owner
The following is a recommended design, not an automatic feature of the cited systems. Consider an illustrative correction: a user says a project now uses a different document repository. The agent must not keep retrieving the old address as though it were current.
| Stage | Decision | Evidence to retain | Trade-off |
|---|---|---|---|
| Admit | Is this useful beyond the current task, and is storage permitted? | Owner, purpose, source turn and whether the statement is observed or inferred | Selective storage can miss useful details; indiscriminate storage keeps noise and sensitive data |
| Store | Is it a confirmed fact, an unverified assertion or a tentative inference? | Subject, scope, source revision, recorded time and status | More metadata and review work |
| Retrieve | Is the reader authorised, and does the record apply to this task? | Matched source and why it is relevant | Filtering may reduce recall; similarity alone is not permission |
| Revalidate | Has the authority or underlying document changed? | Current source check or an explicit unresolved conflict | Freshness checks add latency |
| Correct | Does the new statement replace or merely disagree with the old one? | Supersession link or competing evidence, according to retention policy | Silent overwrites lose history; keeping every version adds privacy obligations |
| Delete | Which copies and indexes must stop supplying it? | Deletion scope and confirmation appropriate to the system | Derived summaries, caches and backups require separate handling |
A memory is not an instruction merely because it is old. Retrieved sessions can contain quoted web pages, guesses and malicious instructions. Keep their provenance and trust level when assembling the next context. A recalled project preference cannot authorise a payment or broaden document access. See prompt injection for the underlying boundary.
Recent example: retrievable session archives
The September 2026 funes project account describes turning coding-agent transcripts into retrievable evidence. Supported sessions are normalised into turns and blocks, split into chunks and indexed. Lexical search matches query words; vector search looks for passages with similar meaning. The pipeline combines their candidate lists, then reranks the candidates by reassessing each passage against the query. Results include neighbouring text and references identifying the session, timestamp and turn. A follow-up lookup can open the underlying turn rather than relying solely on the returned excerpt.
That is different from distilling every transcript into verified facts at ingestion. The archive retains what was recorded; the consuming agent still has to interpret it and check whether it applies. The author’s narrow recommendation-task experiments are evidence about that setup, not proof of perfect recall or universal superiority over handoff notes.
The project’s security policy warns about prompt injection in retrieved third-party memories and credentials surviving in published repository history. Local indexing also does not imply that a hosted model receiving recalled passages keeps those passages on the local machine. Decide what may leave the machine separately from where the index is stored.
Failure modes
- Treating context stuffing as memory. Re-injecting recent turns into the prompt provides no persistence mechanism for information omitted from the window. It supplies context for the current call, not a policy for storing and recalling information later.
- Retrieval that only ranks by similarity. A pure vector-similarity retrieval over a memory store surfaces what reads similarly to the current query, not necessarily what is important or recent enough to matter. That is the same failure mode documented on the general RAG pages in this section, applied here to an agent’s own memory instead of a document corpus.
- Treating reflection as established fact. A model-generated lesson can be wrong. Inspect its supporting evidence and evaluate whether it improves later tasks; Reflexion does not show uniform benefits across all tasks and feedback conditions.
- Memory with no retention or correction policy. An unbounded archive can return stale or conflicting records, causing incorrect recall immediately as well as increasing storage and retrieval costs. Evicting information from working context is separate from deciding which archival records to retain, correct or delete.
Tests that reveal memory failures
| Test case | Expected behaviour | Failure exposed |
|---|---|---|
| A confirmed correction contradicts an older preference | Retrieve the current preference with its source; do not blend incompatible values | Stale recall or uncontrolled summarisation |
| A different user asks about the same project name | Apply permissions before exposing recalled material | Similarity search crossing an access boundary |
| The source passage has been deleted | Follow the deletion policy for chunks, summaries and cached recalls | Deletion in the source but continued retrieval elsewhere |
| An old transcript contains an instruction to expand permissions | Treat it as untrusted recorded content | Memory-based prompt injection |
| A write was attempted but no outcome was recorded | Preserve uncertainty and reconcile with the target | Turning a remembered attempt into an invented success |
When not to add persistent memory
A stateless document question may need only RAG over authoritative material. A workflow interrupted for approval may need a checkpoint rather than a cross-session knowledge store. A support investigation may need a trace archive without feeding that archive into future prompts.
Persistent memory is justified when useful information needs to survive its original interaction and there is a defined policy for who may recall, correct and delete it. Storage and retrieval add latency and cost; retained sensitive information adds an obligation that outlives the task. Test whether the agent actually uses the right evidence before expanding what it is allowed to keep.