Agent memory: what survives, what changes, and how to choose

Imagine a coding assistant that remembers Python 3.13. It even finds the conversation where the migration was approved. Then it prepares a deployment that should still use 3.11.

Its memory contains a relevant fact. The problem is what happened afterward.

Call the hypothetical project Atlas. Its maintainer established Python 3.11 as the deployment target. A colleague later suggested trying 3.13. The maintainer approved a future migration, corrected its date, then cancelled it. Meanwhile, an older mobile client still had to remain compatible. Another project, Boreal, used 3.10.

Open a fresh session. Ask the assistant to prepare Atlas’s next release. Which decision survives?

Saving every message preserves the material needed to reconstruct the answer. A current-state record can state it directly. A graph can connect the proposal, approval and cancellation. A search index can retrieve their source conversations. Each design makes some work easier and leaves other work for the application or the answering model [2, 4, 48].

Before choosing a product, write the next-session promise: use Atlas’s adopted target, preserve its binding compatibility rule and keep Boreal’s state separate. Then decide whether you also need historical beliefs, future plans, shared access or source erasure. Those requirements determine which memory operations are useful.

This guide follows that decision through a changing project. It ends with a proposed first design and a way to judge whether added machinery earns its place.

Evidence cutoff: 29 October 2026. Mutable documentation is tied to its capture or version. This is a researched guide; the narrow source-function probes are described in the evidence companion. No live product comparison was run.

Where could Atlas’s memory live?

The market becomes easier to read when you ask who should own the work. Does a memory service interpret the conversations? Does the application maintain an explicit record in its database? Does the assistant already have a useful project-memory interface?

These are orientation examples drawn from the documented interfaces, not a ranking. The complete market guide gives every surveyed label its own entry and preserves the surface/version distinctions. A framework adapter, a research implementation and a hosted service offer different divisions of responsibility [8, 10, 22, 24, 44, 46, 48, 49, 50, 51, 52, 53, 54, 55, 56, 58, 60].

For Atlas, the deployment target may already be authoritative in a versioned project file. That is a serious starting point. A custom application could instead maintain a scoped record in a store it already operates. A shared service becomes interesting when supported tools need the same maintained context, or when the service provides an interpretation or retrieval operation the application needs [48, 56, 60].

The family narrows the search. The exact interface decides what must be tested. Google ADK, for example, can use an in-memory implementation, managed Memory Bank or a transcript-retrieval backend. Naming ADK alone does not tell you what survives a restart. Naming Anthropic alone does not tell you whether you mean Claude.ai memory, Claude Code’s local files or an API tool backed by application storage [52, 59, 60, 61].

What must survive the next session?

Atlas has several things worth keeping: the current deployment target, the discussion that explains it, an unfinished migration run and perhaps a lesson for the next attempt. They have different lifetimes.

A checkpoint can resume an execution. A conversation store can preserve the messages. A current-state record can hold the adopted target. External memory can select retained information for later use. Pydantic AI’s documentation makes these distinctions concrete by separating conversations, settled execution-step information, searchable history and a cross-conversation notebook [8].

Prompt caching reuses eligible computation on repeated input. The application still has to supply the right input. Caching a migration discussion cannot determine that a later cancellation supersedes it; a well-chosen repeated source can nevertheless make a full-history baseline much cheaper than its ordinary-input price suggests [6, 7].

Follow the information through the system:

Observe → admit → retain → revise → select → assemble context → answer or act.

If the cancellation was never captured, improve capture. If it was captured but interpreted as an unrelated note, inspect admission and revision. If the right record exists but search misses it, inspect selection. If retrieval finds it but prompt assembly truncates it, repair assembly. If the final context contains the cancellation and the assistant still proposes the wrong deployment, investigate how the model uses the evidence [2, 4].

A useful debugging receipt therefore includes the observed source, completed write, stored version, selected evidence, final context and action. “The memory call succeeded” is too little information to locate the break.

Even the write has stages. A service may acknowledge queued processing before extraction finishes. Microsoft’s inspected integration says zero batching delay does not guarantee immediate recall. Decide when the system promises availability, and test after that completion condition as well as immediately after submission [10, 11].

These distinctions also protect the baseline. If one explicit record can meet the next-session promise, compare added interpretation against that record. If you need an archive, compare against a tuned retriever over dated sources. A no-memory arm is informative when later dependencies exist, but it cannot be the only alternative used to justify a more elaborate system.

The migration date changes

Here is Atlas’s proposed history. On 1 September, its maintainer records Python 3.11 as the target. On 10 September, a colleague proposes trying 3.13 if a dependency check succeeds. On 15 September, the maintainer schedules migration for 1 November. On 20 September, the date is corrected to 15 November. On 25 September, the approval is retracted. In this example, the established 3.11 target remains in place.

The messages perform different operations. A possible experiment is not an adopted deployment setting. Correcting a date is not evidence that migration happened. Cancelling the plan does not erase the fact that the team previously believed it would happen [4].

There are two clocks: when a change applies in the world, and when a version was recorded. Keeping both makes different views possible. The application still has to interpret intent and authority, then request the intended view. Revision history or timestamps alone do not establish that every historical and future question will be answered correctly [4, 45].

That distinction changed this investigation’s reading of Graphiti. A source-level probe initially suggested that an older assertion might disappear before a scheduled change. Checking the search path narrowed the finding: different queries can retrieve different views of the same stored history. A relevance search, a question about an effective date and a request for current records need different handling. The probes did not run the complete system and establish no managed Zep behavior; the evidence companion preserves the code-level details [4, 15, 16, 67].

For a buyer, the practical consequence is to ask for the view you need and test the returned evidence. A temporal field in a schema is useful machinery, but it is only part of the promise.

Carlos Tabosa’s discussion comment suggests a direct regression: correct a fact, return later in another context and see whether the stale version returns. For Atlas, demonstrate recall of the original plan, process the date correction, then open a fresh session and ask for a release checklist for 5 November. Ask a second task that prepares a deployment command. After cancellation, repeat both. Inspect what the model saw [120].

Reject an obsolete plan used as current guidance. Preserve the earlier plan for the question about what the team believed on 17 September. Run permission tests alongside these checks: an authorized action can still use stale information, while a correct date does not establish permission to deploy [4].

The next task needs enough evidence

A week later, the maintainer asks why the migration was cancelled. The current target is no longer enough. The assistant needs the decision history—and must notice what that history does not establish.

Our fixture records the cancellation but gives no reason for it. The useful answer is that the approval was retracted and the cause is unspecified. The assistant should not turn the earlier dependency condition or mobile-client requirement into an invented explanation. This is a proposed abstention check: retrieval should support both finding evidence and recognizing when the requested evidence is absent [2, 4].

Retrieval can fail by finding a relevant sentence that leaves out the rest. Lexical search helps with exact identifiers and versions. Embeddings find related meanings. Filters constrain scope, graphs follow represented relationships, and file tools let the agent inspect surrounding context. Hybrid approaches combine signals before ranking and truncation [6, 68].

For Atlas, the useful unit may be a small decision history rather than the single sentence closest to “Python 3.13.” Keep source evidence accessible where retention permits, then choose what the executor needs for its task.

LongMemEval offers a constructive example: adding facts to retrieval keys while retaining original values improves Recall@10 from 0.692 to 0.784 and the configured GPT-4o top-ten question-answering result from 0.670 to 0.720. Better indexing can help find original context without replacing it with an extracted assertion [2].

More context is not always better for the reader. In that study, an 8B reader degrades beyond roughly 3,000 retrieved tokens while GPT-4o continues improving beyond 20,000. These are results for those readers and reading conditions. An advertised context window does not guarantee that every included condition will affect the answer [2].

The next migration raises another question: should the assistant read the whole old execution trace or a lesson from it? The evidence supports testing both. Decocted Experience reports benefits from lessons on action workloads, with unequal source information between lesson and raw-trace arms. JITMEM benefits from task-conditioned guidance over retained experience in its setup, while a matched direct-raw executor comparison remains missing. Neither supports a universal rule that original transcripts or summaries always win [3, 66].

Use the task to choose. A disputed decision needs its source and authority. A familiar repair may benefit from a verified procedure. A setting may need one explicit value. Before turning a trace into standing advice, retain how its outcome was verified; a successful tool call alone does not establish that the task succeeded [9].

The impressive score needs a comparison

Suppose a candidate advertises a large improvement on a memory benchmark. Before treating it as a reason to migrate Atlas, ask what was compared: which dataset revision, source information, writer, reader, prompt, retrieval schedule, budget and scorer? Count unsuccessful attempts too [5, 76, 103].

The historical Mem0 paper illustrates a real tradeoff:

P95 is the 95th percentile of response time. In this experiment, compact memory uses less context and responds faster, while full context has the higher overall judge score. The paper’s roughly 26% relative improvement compares with a separately constructed OpenAI-memory arm scoring 52.90; it does not compare with full context or current ChatGPT. These are historical paper measurements [1].

That can still be a useful result. Atlas might need lower latency, a manageable context budget or a retention contract that full history cannot meet. The decision should name the benefit and the acceptable quality change.

Benchmark scores also have measurement limits. The audited LoCoMo materials contain reference errors, and prompts or judging conventions can change apparent rankings. The critique itself has aggregate claims that need narrowing. Positive architecture experiments and evaluator defects both deserve attention; neither settles every workload [5].

The evidence deep dive preserves those comparisons, including MemoryTax’s writer-dependent results, caption-access differences and accepted-run accounting. For a shortlist, reproduce the comparison that matters to Atlas: a serious baseline and a candidate under the same relevant evidence, reader, readiness and budget.

The smaller prompt arrives with a bill

Atlas’s assistant now receives a compact profile instead of a long conversation. Its input token count falls. Somewhere else, a model extracted the profile, another job updated it, retrieval selected it and perhaps a consolidated page was rebuilt.

Count that work. The complete comparison includes construction, writes, corrections, background maintenance, retrieval, reader usage, storage, retries and operations. Avoid counting internal work twice when a vendor bundles it in a service fee. Compare alternatives at the required quality [90].

Caching can change the result substantially. Let O be incremental memory overhead relative to the baseline, and d the net saving per useful read after retrieval and actual cache behavior. Savings require N × d > O. If the saving per read is nonpositive, more reads cannot repay nonnegative overhead. With changing facts, count useful reads before the affected representation changes [90].

Here is the existing illustrative calculation, using invented inputs: 20,000 source tokens; ordinary input at $1/million; one cache write at 1.25 times ordinary input and later cache reads at 0.1 times; $0.05 to construct memory; $0.0005 retrieval per read; and an uncached memory payload. Common question/output costs cancel. Other costs and quality differences are zero only within this model [90].

For the hot 500-token case, the baseline is 0.023 + 0.002N and memory is 0.05 + 0.001N. The strict crossing is N > 27; after the refresh, N > 77. A ten-read workload that repeatedly changes versions keeps missing that crossing. Partial updates, cacheable compact memory and different outputs can change the answer [90].

Use actual provider usage classes when measuring. The captured OpenAI and Anthropic counters treat cache reads/writes differently; adding similarly named token fields can double-count or omit cost. A service’s “unlimited reads” also does not make its returned context free to the answering model [7, 23, 89].

The market guide’s tariff reference keeps the vendor units separate. Episode-byte credits, processed tokens, retained tokens, record-months and query fees are not interchangeable. Hindsight’s documented refresh charges and an unresolved meter discrepancy are examples of why a small prompt cannot stand in for an invoice [25, 88].

The maintainer changes tools—and asks to remove a source

Atlas’s maintainer discussed the decision in one assistant and investigated the code in another. Each tool may remember its own sessions while the person still reconstructs the project between them. Carsten’s discussion comment identifies that fragmentation and proposes a user-side archive through Lingera; it is a builder’s observation and direction, not a verified absence of alternatives [120].

Decide what continuity means. A searchable archive helps the person find the old decision. Selected migration moves chosen material to a destination. Shared external memory lets supported tools query a maintained record. Synchronizing native stores requires actual read/write coverage and a policy for propagation, conflicts and revocation.

Existing documentation addresses parts of this space: Honcho advertises cross-tool integrations; Supermemory continues API/MCP/plugins; OpenMemory ports supported coding sessions; Claude offers experimental import/export that may omit or fail to incorporate information. Those are concrete routes with different promises [19, 23, 40, 109].

For Atlas, propose a demonstration: write the decision through tool A, retrieve it through B, correct it through C, then return to A with a new task. Revoke B afterward and inspect the access boundary and any copies already made. This is an unexecuted fixture, and it tests more than whether a plugin installs.

Authority matters within the shared store too. A colleague’s suggestion and a maintainer’s approval should retain their roles. Honcho explicitly distinguishes a named recall scope from workspace credentials that can access sessions outside it. Neo4j warns that a conversation identifier is not authorization. Enforce authenticated access below queries the agent can construct; separately define whose decision governs a conflict [22, 55].

Now suppose the source conversation must be erased. It may have produced a profile, lesson, vector entry, page, cached answer or unfinished consolidation job. Name the in-scope derivatives and the promised completion condition before testing deletion. AgentCore’s source-event and long-term-record APIs are separate; its expired records may remain readable during background deletion [43, 92].

Cognee’s pinned code makes another distinction concrete: memory-only forgetting can intentionally preserve sources for rebuilding, while session deletion can retain distilled lessons. A rebuild contract and source erasure require different behavior. The inspected coordination paths also have process and lineage limits; no resurrection race or authorization bypass was executed in this investigation [94, 95, 96, 97, 98, 99].

A useful proposed deletion test pauses a writer after it reads an old source, deletes the source, then lets that writer attempt to commit. Include restarts, retries and export/import where the promised workflow requires them. Check that unrelated retained information still works. Physical deletion, loss of access and semantic nondisclosure require their own evidence; a finite test establishes only its declared boundary [93, 99, 121].

What I would choose for Atlas first

My proposed first design is a versioned project record for the adopted deployment target and compatibility rule, dated source evidence for the migration discussion, and an explicit distinction between proposals and adopted decisions. Keep Boreal under its own authenticated project identity. Give the assistant current guidance and a route to inspect supporting evidence [4, 48, 60].

That is a design proposal, not a measured winner. It defines a baseline with an observable job. Then add only the operations the workload requires:

The market guide connects these jobs to documented interfaces. A bare store leaves interpretation to the application. An extraction or reasoning layer delegates more of it. A native assistant may already meet a personal continuity need. Choose candidates whose added operation addresses the requirement you can name.

Before comparing, freeze the chronology, source versions, reader/model, prompts, readiness and scorer. Keep an unanswerable control and the rare mobile-client rule. Include all attempted operations and inspect final context as well as the delivered answer. Predeclare a worthwhile gain and acceptable failure behavior; the sources establish no universal pass percentage or safe waiting time [2, 76, 103].

Keep a decision record a teammate can inspect:

For this guide, the fixtures remain unexecuted. The evidence companion gives the fuller specification. The receipt should connect the selected evidence to the final action; a confident answer or lower token count alone cannot fill its outcome field.

A higher score is useful when the experiment supports the choice you need to make. If the simpler baseline meets the contract, keep it. If a candidate fixes an important failure, keep the trace showing what improved. If neither meets the contract, revise the design.

Takeaways

• Define the next-session job before selecting a product. Current state, historical beliefs, procedures and a person’s cross-tool archive need different promises.
• Test corrections through a fresh session and a different task. Preserve legitimate historical answers while rejecting obsolete current guidance.
• Follow the information into the final action. Stored records, selected evidence and the assembled prompt expose different failures.
• Read the experiment behind the score. Source access, models, prompts, judges, budgets and unsuccessful attempts affect the comparison.
• Compare complete bills at the required quality. Caching and refresh frequency can change the economics of compact context.
• Make control and exit explicit. Scope, authority, access, derivative deletion and portability need observable behavior.

When the assistant prepares Atlas’s next release, the right result is Python 3.11 with the compatibility rule intact. The useful investigation explains why it got there—or locates the break when it did not. That is the evidence for keeping a memory mechanism.

Sources

Source numbers retain the same identities across the three v4 pieces; gaps in numbering reflect references used in a companion.

[1] Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory.

[2] LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory.

[3] Decocted Experience Improves Test-Time Inference in LLM Agents.

[4] Interim report — changing-fact-interval-and-authority-contract

Read retained audit.

[5] Interim report — benchmark-judge-validity-and-protocol-lineage

Read retained audit.

[6] Prior investigation: context-retrieval-findings

Read retained audit.

[7] Lifecycle official OpenAI prompt cache prefix retention and usage contract captured 2026-10-29.

[8] Persistence | Pydantic Docs.

[9] Prior investigation: storage-findings

Read retained audit.

[10] Mem0 hosted API reference.

[11] What’s new in Microsoft Agent Framework: Interactive experiences, memory, and resilient execution | Microsoft Agent Framework.

[15] Graphiti e9e4a48 pinned complete edge resolver.

[16] Graphiti e9e4a48 pinned temporal search filters and backend generation.

[19] An update to supermemory: discontinuing company brain and Nova — supermemory.

[22] Honcho V3 design patterns.

[23] One memory for every AI tool · Honcho.

[24] vectorize-io/hindsight: Hindsight: Agent Memory That Learns.

[25] Billing | Hindsight Docs.

[40] OpenMemory current README.

[43] AgentCore DeleteEvent source-event deletion contract October 2026.

[44] Agent Platform Memory Bank API quickstart | Gemini Enterprise Agent Platform | Google Cloud Documentation.

[45] Google Memory Bank revision history documented contract.

[46] What is Memory? - Microsoft Foundry | Microsoft Learn.

[48] Memory - Docs by LangChain.

[49] Memory in LlamaIndex | Developer Documentation.

[50] Memory | Mastra Docs.

[51] Memory - CrewAI.

[52] adk-docs/docs/sessions/memory.md at main · google/adk-docs.

[53] Getting Started with Redis Iris: Context & Memory for AI Agents.

[54] Agent memory on Elasticsearch: hybrid retrieval and DLS | Elasticsearch Labs.

[55] Neo4j Agent Memory - Neo4j Agent Memory.

[56] Integrate MongoDB with LangGraph - Atlas - MongoDB Docs.

[58] Memories | ChatGPT Learn.

[59] Use Claude’s chat search and memory to build on previous context | Claude Help Center.

[60] How Claude remembers your project - Claude Code Docs.

[61] Memory tool - Claude Platform Docs.

[66] Just-in-Time Memory: Learning to Curate Task-Adaptive Memory for LLM Agents.

[67] Graphiti e9e4a48 pinned public search and lifecycle API complete.

[68] Prior investigation: sql-findings

Read retained audit.

[76] MemDelta: Controlled Baselines and Hidden Confounds in Agent Memory Evaluation.

[88] MCP Integration | Hindsight Docs.

[89] Lifecycle official Anthropic cache writes reads TTL invalidation captured 2026-10-29.

[90] Interim report — lifecycle-cost-break-even-under-churn

Read retained audit.

[92] Set a time-to-live for long-term memory records - Amazon Bedrock AgentCore.

[93] AfterDeleteBench: Auditing Post-Deletion Information Persistence.

[94] Cognee v1.6.6 pinned forget orchestration and history scope.

[95] Cognee v1.6.6 pinned session deletion and locking.

[96] Cognee v166 session locks process boundary.

[97] Cognee v166 dataset lock backend boundary.

[98] Cognee v166 memify runner lock participation.

[99] Interim report — deletion-closure-and-reingestion

Read retained audit.

[103] Interim report — baseline-insufficiency-and-transfer

Read retained audit.

[109] Import and export your memory from Claude.

[120] Reader-supplied discussion screenshots: correction across later contexts and continuity across assistants.

Discussion notes and retained screenshots. Editorial prompts, not a vendor benchmark or exhaustive market claim.

[121] A Survey on Long-Term Memory Security in LLM Agents, retained v4. Lifecycle taxonomy and proposed Verifiable Memory Governance criteria.