# When Memory Becomes Production State ## The reliability obligations created when AI agents remember across tasks Author: Jason Doyle First published: 28 August 2026 > Disclosure: These views are my own and do not represent my current or any former employers. ## Executive summary An agent that forgets can inconvenience a user. An agent that remembers the wrong thing can keep making the same mistake. Persistent memory changes the failure model of an AI system. A generated answer normally affects one interaction. A stored preference, business fact, summary, or procedure can influence many later interactions without the original source being visible. The effect can cross sessions, devices, users, agents, and software versions. Once persisted memory can influence later reasoning or actions, it becomes production state. It needs an owner, provenance, access boundaries, freshness rules, conflict handling, retention, deletion, observability, and recovery. Current agent platforms already expose many of these controls. Microsoft Foundry supports scoped memory stores, item-level create, read, update, and delete operations, default time to live, and separate user-profile, chat-summary, and procedural memory types.\[1\]\[2\] Google Memory Bank provides identity scoping, consolidation, automatic expiry, revision history, and restrictive IAM conditions.\[4\] LangGraph separates thread checkpoints from cross-thread stores and documents retention requirements for growing checkpoint histories.\[7\] Letta allows memory blocks to be shared across agents or made read-only.\[8\] These features show that memory is already being implemented as a data system, even when product language presents it as personalisation or continuity. The reliability risks are also visible. A Mem0 issue reports that partial embedding failures can silently drop extracted memories while returning a normal result to the caller.\[13\] Another describes old and new employment facts coexisting because an additive extraction path does not automatically supersede the earlier fact.\[12\] A Claude Code issue describes concurrent sessions racing on a shared memory file and losing an update.\[15\] Cisco research demonstrated persistent memory poisoning that influenced Claude Code across projects, sessions, and reboots before Anthropic changed the affected trust path.\[16\] Research benchmarks show a more general quality problem. LoCoMo found that long-context and retrieval-based approaches still lagged human performance on long-range conversational memory, while LongMemEval reported a substantial accuracy drop during sustained interactions and separated memory performance into indexing, retrieval, and reading stages.\[18\]\[19\] Security research adds a different concern: AgentPoison demonstrated in a controlled setting that a very small proportion of poisoned memory entries could influence later agent behaviour while leaving benign performance largely unchanged.\[20\] Controls should vary with consequence because universal retention and universal deletion are both poor defaults. Different memory classes create different obligations: 1. Temporary working context should be bounded to a task or session. 2. User preferences should be visible, correctable, and scoped to the right identity. 3. Business facts should carry provenance, observation time, and a freshness policy. 4. Procedural memory should be versioned, tested, approved, and reversible. 5. Memory used for consequential actions should never replace an authoritative system of record or deterministic policy check. This paper proposes a memory reliability lifecycle: capture, validate, classify, persist, consolidate, retrieve, apply, correct, expire, delete, and audit. Each stage has a different proof obligation. Write success confirms persistence, not the quality of the stored fact; retrieval relevance says nothing about freshness; and a deletion response may cover one copy while leaving summaries, logs, or downstream artifacts intact. Model-generated consolidation can remove duplication while also erasing a material distinction. Useful measures therefore focus on observable properties rather than claiming to measure truth directly. Examples include confirmed write durability, provenance coverage, cross-scope isolation tests, contradiction density, correction propagation time, expiry latency, deletion completeness within a declared scope, and the percentage of consequential actions with an inspectable record of which memories influenced them. Reliable memory remembers selectively through bounded, inspectable, and correctable state. The system should know where each memory came from, who it belongs to, when it should stop being trusted, and what must happen before it can influence a consequential action. ## 1. Memory changes the failure model Stateless systems have familiar limitations. They lose continuity, repeat questions, and force users to restore context. Memory improves that experience by carrying useful information forward. Persistence also carries mistakes forward. Suppose a user tells a travel agent that they prefer a window seat. Remembering that preference is convenient and low risk. If the user later needs an aisle seat for accessibility reasons, the original preference must stop controlling the result. The same pattern becomes more serious in business workflows: - a support agent remembers an entitlement that has expired; - a coding agent preserves an obsolete security exception; - an operations agent recalls a mitigation that is unsafe after an architecture change; - a procurement agent retains an old approval limit; - a multi-agent workflow shares a corrupted procedure; - an assistant associates one user's information with another user's scope. The immediate model output may be fluent and internally consistent. The failure began earlier, when the system wrote, retained, merged, retrieved, or trusted the wrong memory. This creates a delayed failure path: 1. an interaction produces a candidate memory; 2. the memory is persisted outside the active conversation; 3. later retrieval presents it as useful context; 4. the model treats it as evidence or instruction; 5. an output or action reflects the stored error. The original source may no longer be available to the user, reviewer, or operator. Without provenance and revision history, the system can explain what it remembered but not why it believed the memory deserved trust. Memory therefore changes more than personalisation. It changes where defects can live, how long they can persist, and how widely they can propagate. ## 2. Memory classes create different obligations Product documentation uses different names for memory, and the boundaries are not standardised. A practical reliability model still needs categories because the same controls do not fit every form of retained state. | Memory class | Typical content | Useful lifetime | Main reliability concern | | --- | --- | --- | --- | | Working context | Current messages, tool results, active plan | One task or session | Unbounded growth, compaction loss, stale intermediate state | | User preference | Language, format, accessibility need, product default | Until corrected or expired | Wrong identity, outdated preference, opaque correction | | Episodic memory | Prior interactions, events, summaries, outcomes | Task-dependent | Missing context, distorted summary, temporal confusion | | Semantic or business fact | Account status, project decision, ownership, environment detail | Until source changes | Staleness, contradiction, weak provenance | | Procedural memory | Steps, checks, tool sequence, learned operating pattern | Until process or system changes | Repeated unsafe behaviour, unreviewed drift | | Shared memory | State used by several agents, users, or services | Task- or system-dependent | Large blast radius, concurrent writes, scope leakage | ### Working context Working context supports the task in progress. LangGraph models this through thread-scoped checkpoints, while AWS describes short-term memory as turn-by-turn state within a session.\[5\]\[7\] It may be temporary, but it still needs lifecycle controls. Long sessions can grow without bound. Compaction can remove material details. A crash can leave the system uncertain about which step completed. Working context becomes durable state when it is checkpointed for recovery or resumption. At that point, retention and replay semantics matter. ### User preferences Preference memory creates continuity without asking the same questions again. Microsoft, AWS, OpenAI, Google, and other platforms all describe this as a central use case.\[1\]\[5\]\[10\]\[11\] Preferences are assertions with a source and a date, not timeless facts. "Prefers email" may be valid for one account, one workflow, or one period. Systems should preserve that context rather than reducing every statement to a permanent global attribute. ### Episodic memory Episodic memory records what happened. It may contain a conversation summary, incident outcome, prior task result, or model reflection. Summaries reduce context size, but they also compress evidence. A summary can omit an exception, turn uncertainty into certainty, or combine events that should remain separate. Keeping the source link and generation version allows later review. ### Semantic and business facts These memories represent durable knowledge such as a project decision, user role, service owner, or current account state. Dynamic business facts should usually remain in their authoritative systems. Memory can help locate or interpret them, but a consequential action should revalidate the current value at the source. Mem0's documentation illustrates the update problem. Its automatic extraction path is additive: a move from one city to another can create a new memory without rewriting the old one. Applications must use explicit update or delete operations when they need correction.\[9\] ### Procedural memory Procedural memory stores how work should be performed. Microsoft describes it as reusable routines inferred from earlier interactions, including when to use a procedure and which ordered actions and checks it contains.\[1\]\[3\] This memory has greater consequence than a preference. A wrong preference may produce an inconvenient answer. A wrong procedure can repeat an unsafe action across many tasks. Procedural memory should therefore resemble versioned operational policy. It needs an owner, tests, approval, rollout boundaries, and rollback. ### Shared memory AWS documents multi-agent memory as a way for agents to coordinate a shared workflow. Letta allows several agents to attach to the same persistent memory block, where one update becomes visible to all of them.\[5\]\[8\] Sharing can reduce duplicated state. It also expands the blast radius of a bad write and introduces concurrency questions that do not appear in private memory. ## 3. How memory becomes trusted Most long-term memory systems perform several operations between a conversation and a later action. Anthropic's memory tool makes one part of the responsibility explicit. Claude requests file operations, while the application owns storage, persistence, and the controls that keep access inside the intended memory path.\[6\] ### Extraction The system decides which parts of an interaction are worth retaining. This is often an LLM task. Microsoft describes extracting preferences, facts, and context from conversations. Mem0 extracts durable facts before embedding and storing them.\[1\]\[9\] Extraction is a policy decision. A system can store too little, too much, or the wrong abstraction. It may preserve an inference as though the user stated it directly. A memory record should distinguish: - direct user statement; - observation from an authoritative system; - tool result; - model inference; - summary or consolidation; - procedure learned from prior execution. These sources deserve different levels of trust. ### Consolidation New information may duplicate, refine, contradict, or supersede existing memory. Google and Microsoft document consolidation features intended to merge related information and evolve memories over time.\[1\]\[4\] Consolidation saves space and reduces retrieval noise. It can also destroy history. A statement that a user moved from Dublin to Seattle should update the current city without erasing when the move occurred or why older records mention Dublin. Systems need explicit outcomes: - append as a separate event; - merge compatible information; - supersede an older memory; - mark a contradiction for review; - reject the write; - quarantine untrusted content. Allowing the model to choose silently makes later audit difficult. ### Retrieval Retrieval selects memories for the current task. Similarity is useful, but it does not establish freshness, authority, or scope. Mem0 combines semantic, keyword, entity, and temporal signals, while warning applications to scope every search by user, agent, or run.\[9\] LongMemEval separates memory performance into indexing, retrieval, and reading because failure at any stage can produce the wrong answer.\[19\] A highly similar stale memory can outrank a current but differently worded record. Retrieval should consider status, recency, source authority, and the question's temporal intent. ### Application Retrieved memory enters the model's active context and can affect an answer, tool selection, or external action. This stage is often the least visible. Operators may log the prompt and tool call without recording which memory items were retrieved, which were actually used, or why one was preferred. Consequential workflows need an inspectable link between memory and action. The record can protect private content while preserving the memory identifiers, versions, source classes, and policy decisions needed for later investigation. ## 4. Failure modes Agent memory combines ordinary data-system risks with model-specific failure modes. ### Silent loss A memory service can acknowledge work without persisting every extracted item. Mem0 issue 5245 reports a path where batch embedding fails, individual fallback operations also fail, and the affected memory text is dropped after a warning without an exception reaching the caller.\[13\] The issue is a public report rather than a measured platform-wide failure rate. It demonstrates a familiar reliability problem: success at one stage does not prove durable completion at the next. Memory writes should support strict failure reporting or return a result that identifies partial success. High-value writes should be verified through read-back, version, or durable receipt. ### Stale and contradictory memory Mem0 issue 4956 describes a user first associated with one employer and later with another. The additive extraction path retained both records, while retrieval could return the older one because ranking did not reliably prefer recency.\[12\] Some apparent contradictions represent legitimate history or scope differences. A person can have two roles, an account can have historical states, and policies can differ by region. The system needs temporal and scope information before deciding that one record replaces another. ### Concurrent writes Multiple sessions or agents may update the same memory at once. A Claude Code issue describes concurrent sessions sharing one memory index without file locking or atomic append, allowing one update to be lost.\[15\] Shared memory needs the controls used for other concurrent state: version checks, atomic operations, conflict detection, and a defined merge policy. ### Scope leakage The memory key is part of the security boundary. User, tenant, workspace, agent, region, and environment must not be treated as optional metadata. Microsoft's memory documentation recommends a dedicated store per agent and explicit user scopes. Google exposes identity-scoped collections and IAM conditions. Mem0 warns callers to filter every search by identifiers such as user, agent, and run.\[2\]\[4\]\[9\] A missing or caller-controlled scope can expose one user's memory to another or allow a write into the wrong collection. Isolation should be enforced by authenticated identity and policy rather than model-generated identifiers. ### Poisoning Memory creates a delayed prompt-injection path. Malicious content can be stored during one interaction and activated later when the original untrusted source is no longer visible. Cisco demonstrated a persistent compromise path in Claude Code where a routine dependency installation could modify memory and hooks, influencing future behaviour across projects, sessions, and reboots. Anthropic changed the affected design in Claude Code 2.1.50 by removing user memories from the system prompt.\[16\] OWASP identifies memory and context poisoning as a major agentic security risk. Google's Memory Bank documentation also warns that false or malicious information stored in long-term memory can influence later responses and actions.\[4\]\[17\] AgentPoison demonstrated the broader mechanism in controlled experiments: poisoned entries were designed to remain quiet on benign queries and activate when a trigger caused retrieval.\[20\] Benchmark attack rates should not be treated as production prevalence, but the persistence mechanism is relevant. ### Deletion boundaries OpenAI documents that saved memories are stored separately from chat history. Deleting a chat does not remove saved memory, deleting a memory does not remove mentions from earlier chats, and logs of deleted memories may be retained for up to 30 days for safety and debugging.\[10\] These are disclosed product behaviours, not hidden failures. They show why a delete operation needs a declared scope. Users and operators should know whether deletion covers: - the active memory item; - prior versions; - source conversations; - derived summaries; - embeddings and indexes; - caches; - audit records; - model prompts already logged; - downstream artifacts created from the memory. Deletion can be correct within one boundary while leaving copies elsewhere. ### Lifecycle and replay defects Memory stores also depend on ordinary software lifecycle behaviour. LangGraph issue 8589 reports TTL sweeper tasks outliving the connection context that created them, undermining assumptions about expiry processing and cleanup.\[14\] Its persistence documentation separately warns that in-memory savers lose state on restart and that checkpoints can grow without bound unless operators apply a retention policy.\[7\] Recovery introduces lineage questions. When a workflow resumes from an earlier checkpoint, operators need to distinguish the original path from the replayed or forked path. Memory identifiers and versions must survive that distinction. ## 5. A memory reliability lifecycle Reliable memory requires controls from first capture through final removal. ### 1. Capture Record the candidate memory and its source before abstraction removes context. Preserve whether the content came from a user, tool, system of record, model inference, summary, or previous procedure. ### 2. Validate Check schema, scope, sensitivity, and source authority. Scan untrusted content for injection where the implementation supports it. Reject or quarantine memory that attempts to redefine system policy, expand permissions, or modify trusted instructions. Validation must consider both whether the text is plausible and whether the source is allowed to create that type of memory. ### 3. Classify Assign a memory class, owner, sensitivity, risk tier, and retention policy. Treat an accessibility preference differently from a payment entitlement or a learned deployment procedure. ### 4. Persist Use a durable write with an explicit scope and version. Surface partial failure. Apply atomic updates or optimistic concurrency where several writers can touch the same record. ### 5. Consolidate Compare new information with active memory. Preserve history where it matters. Mark old facts as superseded rather than leaving equally active contradictions. Require review before automatically replacing high-consequence procedures. ### 6. Retrieve Filter by authenticated scope before ranking. Include authority, status, recency, and temporal relevance alongside semantic similarity. Allow the agent to abstain when memories conflict or lack sufficient provenance. ### 7. Apply Record which memory versions influenced a material output or action. Revalidate dynamic business facts against their system of record. Apply deterministic policy checks after retrieval and before execution. ### 8. Correct Support explicit correction without requiring users to manipulate prompts until the model understands. Preserve the previous version for authorised audit while ensuring the superseded value no longer controls ordinary retrieval. Google's consumer guidance currently tells users to correct Gemini directly in chat, while enterprise products increasingly expose record-level operations and revision history.\[4\]\[11\] The difference matters when precision is required. ### 9. Expire Apply TTL and event-based expiry according to memory type. A project decision may expire when the project closes. A temporary preference may expire after a period of inactivity. A procedure may expire when its referenced system version changes. Expiry processing needs monitoring. A configured TTL is not evidence that the record was removed on time. ### 10. Delete Define the deletion boundary, complete the operation across indexes and caches, and verify that ordinary retrieval no longer returns the item. Where law or policy requires broader erasure, coordinate deletion across source, derivatives, logs, and backups according to the applicable retention model. ### 11. Audit and recover Retain a protected record of memory mutations, access, consolidation, and use. Google describes memory revisions that allow operators to inspect how a memory changed as new information arrived.\[4\] Recovery should support restoring a known-good memory set without reintroducing poisoned or superseded records. A backup preserves data; it does not decide which data still deserves trust. ## 6. Control memory according to consequence Uniform governance would make simple personalisation expensive. No governance would allow low-friction memory to influence high-impact actions. Risk tiers provide a practical middle ground. | Tier | Memory example | Required control | | --- | --- | --- | | 0: Working | Current task context, temporary tool output | Session boundary, size limit, safe compaction, no cross-user reuse | | 1: Preference | Output format, language, non-sensitive product default | User visibility, correction, identity scope, reasonable expiry | | 2: Operational fact | Service owner, project decision, environment detail | Provenance, freshness, conflict handling, source revalidation | | 3: Procedure | Release steps, incident mitigation, approval workflow | Versioning, tests, named owner, approval, rollback | | 4: Consequential state | Entitlement, financial status, access decision, regulated fact | Authoritative system lookup, deterministic policy, strict audit; memory may guide but must not decide alone | ### Tier 0: Working memory The system may discard this state at task completion. If it supports crash recovery, checkpoint integrity and replay safety become required. ### Tier 1: Preferences Users should be able to see and correct what the system remembers. Sensitive or highly dynamic attributes should not be inferred casually and stored without a clear reason. ### Tier 2: Operational facts The memory record should preserve when the fact was observed and from which source. The application should revalidate it when an action depends on current truth. ### Tier 3: Procedures Procedural memory should use a promotion path: 1. observe a successful trajectory; 2. extract a proposed procedure; 3. test it against representative and adversarial cases; 4. review and approve a version; 5. deploy within a bounded scope; 6. monitor outcomes and support rollback. An agent should not turn one successful execution into organisation-wide policy without review. ### Tier 4: Consequential state Memory can help locate evidence, explain history, or prepare a decision. The authoritative system and deterministic policy must control the action. An agent remembering that a customer is entitled to a refund does not establish the entitlement. It should query the current account and policy before acting. ## 7. What to measure Production measures should expose the health of each lifecycle stage rather than compress memory quality into one accuracy score. ### Write durability Measure the percentage of acknowledged writes that are confirmed durable within a defined time. Track partial failures separately from complete failures. Fault injection is useful here. A team can deliberately fail an embedding provider, database write, or index update and confirm that the caller receives an actionable failure rather than a success-shaped response. ### Provenance coverage Measure the percentage of active memory records with: - source type and identifier; - writer identity; - scope; - observation time; - memory class; - current status; - retention or review date. The measure supports later investigation without claiming that the memory is true. ### Scope isolation Continuously test that one user, tenant, agent, or environment cannot read or write another scope's memory. Include missing, malformed, and attacker-selected identifiers. ### Contradiction and staleness Sample active memory for conflicting records about the same entity and property. Measure how long superseded facts remain eligible for ordinary retrieval. Automated contradiction detection will be imperfect. The measure should support review rather than claim a complete inventory of false memory. ### Correction propagation Measure the time between an accepted correction and the point when retrieval returns the corrected record while excluding the superseded record from normal use. ### Expiry and deletion Measure whether expired items become unavailable within the declared TTL and sweep interval. For deletion, define the covered stores and verify removal from each one. ### Memory influence coverage For consequential actions, record the memory identifiers and versions supplied to the agent. Measure the proportion of actions where that evidence can be reconstructed. The record gives an incident reviewer a bounded set of retained state to inspect without claiming that every supplied memory caused the action. ### Outcome sampling Use representative tasks to test whether memory improves outcomes, creates unwanted persistence, or changes behaviour after correction. Include tests for: - current facts replacing stale ones; - conflicting evidence; - deliberate memory poisoning; - user switching; - shared-memory concurrency; - expired procedure versions; - missing source systems; - rollback to a known-good set. Microsoft's STATE-Bench is an example of the move from simple fact retrieval towards measuring whether memory helps an agent complete stateful tasks more consistently.\[3\] Vendor-reported benchmark gains should still be treated as vendor evidence until independently reproduced. ## 8. User control is part of reliability Memory is often described as a system feature, but users experience it as a claim about them. They need to know: - whether memory is enabled; - what information is stored; - where it came from; - which products or agents can use it; - how to correct it; - how long it remains active; - what deletion covers; - whether a temporary no-memory mode exists. OpenAI separates saved memories from chat history and provides controls to delete individual memories, clear them, disable memory, or use Temporary Chat. Its documentation also explains the limits of deletion.\[10\] Google allows users to ask whether past chats influenced a response and to correct Gemini in the conversation.\[11\] Enterprise Memory Bank provides a more structured revision and IAM model.\[4\] Consumer convenience and enterprise control need different interfaces, but both should make correction possible without requiring the user to understand retrieval architecture. A corrected memory should stop influencing future actions promptly. A deleted memory should have a clear declared boundary. A disabled memory feature should not continue injecting previously stored records into ordinary sessions. ## 9. Procedural and shared memory need stronger controls The highest-risk memory may not contain personal facts. It may contain instructions. A procedural memory can influence every future execution of a recurring task. If it omits a validation step or encodes an obsolete workaround, the agent can repeat the mistake consistently. Shared memory extends the effect further. Letta describes shared blocks as a coordination primitive where one update becomes visible to several agents.\[8\] That can keep a team aligned, but it also gives one bad write a wider audience. Procedural and shared memory should provide: - read-only modes for policy and approved reference material; - separate proposal and active states; - named ownership; - version history; - test evidence; - bounded rollout; - approval for material changes; - atomic or conflict-aware writes; - rollback to a reviewed version; - alerts for unexpected writers or out-of-band changes. Memory should never grant authority by describing authority. A stored procedure may say that an action is allowed, but the execution system must verify the current policy and caller permission. Cisco's MemoryTrap research is relevant because it reached persistent memory and higher-trust configuration through an ordinary development workflow.\[16\] The lesson extends beyond one coding tool: persistent instructions belong to the control surface and require stronger provenance than ordinary context. ## 10. Counterarguments ### Memory is only a convenience feature This is true for some low-risk preferences. The risk changes when stored information affects external actions, access, money, safety, customer communication, or repeated operating procedure. Risk tiers allow lightweight treatment for convenience while reserving stronger controls for consequential memory. ### The agent can check the source system when needed That is often the correct design. Memory can guide the lookup or preserve history, while the source system provides current truth. The design fails when the agent treats remembered state as sufficient and skips the revalidation. The execution path should enforce required lookups where the consequence warrants them. ### Consolidation models will resolve contradictions They can reduce duplicates and merge compatible facts. They can also erase history, prefer the wrong source, or turn ambiguity into certainty. High-consequence consolidation needs inspectable versions and a route to human review. Automatic merge remains useful for lower-risk memory. ### Vector databases already provide filters and TTL Those primitives help with storage, scope, and expiry. They do not determine whether a fact is authoritative, whether two records conflict, which procedure is approved, or what a deletion promise covers. Memory reliability includes semantic and policy decisions above the storage engine. ### More memory improves personalisation Additional relevant memory can improve continuity. More stored material also increases the chance of staleness, contradiction, privacy exposure, and irrelevant retrieval. LoCoMo and LongMemEval show that long-term memory remains difficult even when more history is technically available.\[18\]\[19\] Selection and lifecycle matter as much as capacity. ### Full audit creates unacceptable cost Not every memory read needs a permanent detailed record. Material actions do need enough evidence for investigation. Systems can retain identifiers, versions, decisions, and redacted metadata without copying every sensitive memory into a broadly accessible log. The audit model should follow consequence and data classification. ## 11. Limitations Agent memory terminology and implementations are changing quickly. The taxonomy in this paper is a practical synthesis rather than an industry standard. Vendor documentation describes intended controls, not proof that those controls work under every failure condition. GitHub issues are useful examples but do not establish platform-wide failure rates. LoCoMo, LongMemEval, and AgentPoison are controlled research benchmarks. They support the identified failure mechanisms without measuring production prevalence. This paper discusses retention and deletion as engineering properties. It does not provide legal advice or claim one deletion model satisfies every jurisdiction. Some memory systems may justify different controls because they contain only low-risk data or operate in tightly bounded environments. The proposed risk tiers should be adapted to the actual consequence. ## Conclusion Memory makes agents more useful by carrying context, preferences, facts, and procedures across time. Persistence also gives errors a longer life. When retained information can influence a later answer or action, it belongs inside the system's reliability model. Teams need to know who wrote it, which scope owns it, what source supports it, when it expires, how it is corrected, and where its influence appears. The strongest design keeps authoritative systems responsible for current entitlements, access, financial state, and other consequential facts. Memory can improve continuity and guide work without replacing those controls. Reliable memory is selective, attributable, scoped, reviewable, and reversible. Its value comes from carrying forward useful knowledge while preserving the ability to challenge what the agent thinks it knows. ## About the author Jason Doyle writes about reliable software, observability, incident leadership, and applied AI. He publishes at [jasondoyle.ie](https://jasondoyle.ie) and can be contacted at . ## References 1. Microsoft Learn, *Memory in Microsoft Foundry Agent Service (preview)*, 2 June 2026, . 2. Microsoft Learn, *Create and use memory in Foundry Agent Service*, updated 5 August 2026, . 3. Microsoft Foundry, *Making agent memory more reliable, transparent, and production-ready*, 2026, . 4. Google Cloud, *Agent Platform Memory Bank*, . 5. Amazon Web Services, *Add memory to your Amazon Bedrock AgentCore agent*, . 6. Anthropic, *Memory tool*, Claude Platform documentation, . 7. LangChain, *Persistence*, LangGraph documentation, . 8. Letta, *Memory blocks (core memory)*, . 9. Mem0, *How Mem0 Works*, . 10. OpenAI Help Center, *Memory FAQ*, . 11. Google Gemini Apps Help, *Get personalization with memory of your past Gemini chats*, . 12. Mem0 issue 4956, *ADD-only extraction in v3 may surface stale/contradictory facts for time-sensitive attributes*, 24 April 2026, . 13. Mem0 issue 5245, *Silent memory loss when batch embedding partially fails in V3 add pipeline*, 24 May 2026, . 14. LangGraph issue 8589, *checkpoint-sqlite: TTL sweepers outlive from_conn_string contexts*, 11 August 2026, . 15. Claude Code issue 58736, *Concurrent-write race on shared MEMORY.md across concurrent Claude Code sessions in the same git repo*, 13 May 2026, . 16. Cisco, *Identifying and Remediating a Persistent Memory Compromise in Claude Code*, 2026, . 17. OWASP GenAI Security Project, *Memory Is a Feature. It Is Also an Attack Surface*, 13 May 2026, . 18. Adyasha Maharana et al., *Evaluating Very Long-Term Conversational Memory of LLM Agents*, arXiv:2402.17753, 27 February 2024, . 19. Di Wu et al., *LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory*, ICLR 2025, arXiv:2410.10813, . 20. Zhaorun Chen, Zhen Xiang, Chaowei Xiao, Dawn Song, and Bo Li, *AgentPoison: Red-teaming LLM Agents via Poisoning Memory or Knowledge Bases*, arXiv:2407.12784, 17 July 2024, .