AI assistants are turning memory into a product layer
Assistants can now carry preferences, project context and prior experience across sessions. The hard engineering problem is deciding what deserves to persist, when it is still true and whether it is safe to reuse.
What is happening?
AI memory is the layer that decides which parts of earlier conversations or work should influence a future answer. It may remember a food preference, a project decision, a recurring task or the way a website behaves. That can save time, but a remembered detail can also be outdated, belong to another project, reveal something private or push an agent toward the wrong action. A dependable system therefore needs more than a database. It needs rules for writing, updating, retrieving, explaining and deleting memory—and it must never treat remembered context as permission to perform a sensitive action.
Why this trend is moving
- 01Major assistants now retain saved preferences, infer context from past chats or search earlier conversations across sessions.
- 02Personalization is expanding from text responses into connected email, files, images, work applications and imported AI histories.
- 03Long-running agents need to preserve task state, environment knowledge and recurring failure lessons beyond one context window.
- 04New benchmarks test temporal updates, abstention, workflow memory and action use rather than only retrieving one old fact.
- 05Persistent sycophancy and memory-poisoning studies show that unsafe state can survive the conversation where it was introduced.
- 06User-facing source, correction, temporary-chat and deletion controls are becoming product differentiators rather than hidden implementation details.
What this means in practice
- Chat history, saved facts, project instructions, connected files and learned procedures should remain distinguishable even when the interface calls all of them memory.
- The write decision is a security and quality boundary because a mistaken or hostile claim can influence many later sessions.
- Every factual memory needs source, time, scope and update behavior rather than only an embedding and a sentence.
- Similarity search should generate candidates; authorization, freshness, sensitivity and purpose should decide admission to the prompt.
- Memory can personalize a response or prefill a workflow, but current permissions and transaction-specific confirmation must control consequential actions.
- Correction and deletion must reach summaries, indexes, caches and imported copies, not only the visible memory list.
- Evaluation should measure remembering, forgetting, contradiction handling, poisoning resistance and downstream task effects.
What the headline leaves out
This is the practical technical view: how the system is put together, where it can fail, and what a real deployment asks from the team running it.
How it is built
A production memory system starts with purpose, consent, data classes, scopes and retention. Approved conversations, files and tool events produce candidate facts, preferences, decisions, episodes and procedures with source and time. A write gate decides what may persist and at which user, project, team or tenant level. Consolidation merges duplicates while preserving versions, contradiction and supersession. Authoritative records, summaries and search indexes remain separate. Retrieval generates candidates, then a contextual admission layer checks permission, freshness, sensitivity and purpose before compact evidence enters the model context. Tool actions revalidate current state and authorization. User inspection, correction, deletion, temporary modes, telemetry and regression tests close the lifecycle.
How inference behaves
Memory systems combine extraction, summarization, structured records, vector or lexical search, temporal reasoning, graphs and prompt assembly. Some memories are explicitly saved; others are inferred from chat history or generated from task trajectories. A large context window can carry more raw history but does not decide which detail is current or appropriate. Retrieval-augmented systems reduce prompt size yet can miss, mis-rank or over-apply evidence. Agentic memory adds operations for storing, updating, reflecting and discarding state, which improves flexibility while creating a new durable control channel.
What the tests can miss
A credible evaluation follows the entire path from candidate write to downstream action. It reports write precision and recall, stale-memory reuse, contradiction resolution, provenance completeness, retrieval recall, contextual admission precision, abstention, action-parameter accuracy, poisoning success, deletion propagation, cross-scope leakage, latency and complete cost per improved task. Tests should include changed facts, project exceptions, requests that should not use memory, sensitive content, imported history and adversarial instructions delivered through chats, files, webpages and tools.
What deployment involves
Begin with explicit saved preferences or a project-scoped knowledge base before building autonomous cross-application memory. Keep raw evidence, durable records and generated summaries separate. Apply identity and tenant filters before search, and treat retrieved memories as evidence rather than commands. Add episodic and procedural learning only when intervention-free task improvement is measurable. Every change to extraction, consolidation, retrieval, ranking or prompt assembly should pass replay tests for stale facts, privacy, deletion and tool behavior.
Where the risks sit
Persistent memory turns ordinary prompt injection into a delayed attack surface. Untrusted messages, documents, webpages or tool output can plant a record that returns in another session after the original context is gone. Defences need write-time classification, provenance, source trust, contextual retrieval screening and independent authorization for tools. Tenant and project filters must run before semantic search. Derivative summaries and embeddings require the same access and deletion controls as their source. Audit systems should record state changes without exposing private memory content to unnecessary readers.
What it really costs
Memory adds extraction and consolidation calls, embeddings, structured storage, graph or vector indexes, reranking, context tokens, correction workflows, security review and deletion propagation. More storage can reduce repeated explanations yet increase retrieval noise and maintenance. The useful denominator is the number of accepted tasks whose correctness, continuity or user effort improved without a stale, private or unsafe result. For many products, a small explicit profile or project knowledge base will outperform a complex autonomous memory system on cost and trust.
What the evidence supports
The product direction is established. OpenAI documents saved memories, chat-history reference, memory summaries and source controls. Gemini and Microsoft Copilot now offer persistent personalization, connected context and management controls, while Claude provides account preferences, project knowledge and past-chat search. Research supports the need for dedicated architecture: MemGPT separates fast and slow context; LongMemEval and LoCoMo expose failures in updates, temporal reasoning and long histories; newer benchmarks cover workflow experience, forgetting and action use. Security studies in 2026 show that persistent sycophancy and poisoned memories can survive across sessions and influence later behavior. The evidence supports useful bounded memory with visible control—not an assistant that silently stores everything it hears.
How it works in practice
Persistent AI memory is not a larger chat transcript. It is a governed state layer that decides what may be written, how facts change over time, which source and scope travel with each memory, when retrieval is appropriate, what the user can inspect or delete, and whether remembered context may influence a sensitive action.
How the parts work together
The headline technology is only one part of the product. Reliability, security and cost are usually decided by the handoffs around it.
- 01
Purpose, scope and consent
Define why memory exists, which users and workspaces it serves, what data classes are excluded, how long information may persist and whether the user or administrator must opt in.
- 02
Event capture and provenance
Collect candidate facts, preferences, decisions, task state and outcomes from approved conversations, files, applications or tools while preserving source, author, time, tenant and confidence.
- 03
Write gate and classification
Decide whether an event is durable enough to store, whether it belongs to a user, project, organization or temporary session, and whether it is a fact, preference, instruction, episode or learned procedure.
- 04
Consolidation and versioning
Merge duplicates, retain history, mark superseded records, resolve contradictions and distinguish a changed fact from a second fact that applies in another context.
- 05
Protected storage and lifecycle
Store raw evidence, structured memory and derived summaries under separate access, retention, encryption, tenant and deletion controls. A vector index is an access path, not the authoritative record.
- 06
Retrieval and contextual admission
Generate candidates through time, keyword, graph or vector search, then admit only records whose source, scope, freshness, sensitivity and intended use fit the current request.
- 07
Context assembly and action boundary
Present compact evidence to the model with attribution and uncertainty. Remembered context may shape a response, but consequential tool calls still require current authorization and transaction-specific confirmation.
- 08
Inspection, correction and assurance
Expose memory sources, edits, deletion and temporary modes; measure stale reuse, harmful writes, leakage, latency and action effects; and replay regressions after model, policy or storage changes.
Estimate the limits before the demo
These equations are planning tools rather than substitutes for testing. They help expose a design that is unlikely to fit its hardware, budget, reliability or risk limits.
Durable memory needs write precision
memory write precision = valid durable records ÷ all records committed to durable memory A memory system that saves every plausible statement can achieve high recall and still become less useful over time. Valid means the record is supported, correctly scoped, appropriately persistent and safe to reuse.
- A stated dietary preference may be durable; a restaurant choice for one evening may not be.
- A project deadline belongs to the project and version, not automatically to the user profile.
- A guessed job title should not become a durable fact merely because the assistant repeated it.
Freshness depends on the type of memory
admission score = relevance × confidence × scope fit × freshness policy A universal time-decay rule is unsafe. A birth date may remain stable, a travel plan may expire next week, and a medical or employment status may need explicit revalidation. The score should filter candidates, not silently convert uncertainty into truth.
- A preference marked “current until changed” can remain active.
- A price, location or role may require a recent source.
- A superseded memory can remain in history while being excluded from active context.
Memory economics belong to improved outcomes
cost per useful recall = write, storage, retrieval and added inference cost ÷ accepted tasks materially improved by memory Token reduction or retrieval speed alone does not establish value. The denominator should count tasks where memory improved correctness, continuity or user effort without causing a stale, private or unsafe result.
- A project assistant that recalls the correct approval path can save repeated setup work.
- Retrieving ten irrelevant memories adds latency and context cost without value.
- A wrong remembered bank detail can create far more loss than many successful personalized replies create benefit.
A chat archive is evidence; memory is a decision about future use
Current assistants already separate several ideas that users often call memory. OpenAI describes saved memories and references to past chats. Microsoft distinguishes saved memories, chat-history inferences and custom instructions. Claude offers profile preferences, project instructions and past-chat search. Gemini can use prior conversations and connected Google services when the user enables those features.
Those products are not simply loading every old message into a larger context window. They select, summarize, search or infer information and then decide what to present to the model. The selection step changes a historical record into active state.
That distinction matters because active state can shape later recommendations, search queries, generated images, work plans and tool parameters. The design question is therefore not “How much can we remember?” It is “Which information deserves influence in this situation, and who can inspect that decision?”
- Keep raw history, durable memory and current prompt context as separate layers.
- State whether a memory was explicit, inferred or imported.
- Preserve the workspace and user boundary of every record.
- Do not describe search over old chats as perfect recall.
What the system commits can matter more than what the model says today
A conversational error usually disappears with the session. A memory write can persist for months and be reused in a different task. Recent research on persistent sycophancy and memory poisoning shows why the commit boundary deserves its own policy: a flattering, mistaken or adversarial claim can be promoted into durable state and later return without the original conversation around it.
A write gate should classify the candidate. Is it a stable preference, a time-bounded fact, a project decision, a procedure learned from successful work, or merely an observation? It should preserve who said it, what source supported it, when it applied and whether the user explicitly requested persistence.
Sensitive information needs a higher threshold or an outright block. An assistant may need temporary access to health, financial or legal context to answer one request without turning that material into a reusable personal profile.
- Use allow, confirm, temporary and deny outcomes at write time.
- Require source and timestamp for factual memories.
- Keep model inference distinct from user-confirmed information.
- Test repeated persuasion and indirect prompt-injection attempts.
A useful memory system must know when an old truth stopped being current
LongMemEval tests knowledge updates, temporal reasoning and abstention because factual recall alone is not enough. A user can change employer, cancel a trip, replace a preferred supplier or revise a project decision. A memory system that retrieves both versions without time and scope can produce a confident contradiction.
The safe structure is append-and-supersede rather than silent overwrite. The active record should point to evidence and effective dates, while previous versions remain available for audit. Some conflicts can be resolved automatically; others need the user or an authorized project owner.
Summaries need the same discipline. A compact profile may improve retrieval, but it can erase who made a claim, narrow conditions or the fact that a preference was temporary. Derived summaries should link back to source records and be regenerated after material corrections.
- Represent effective time, expiry and supersession.
- Separate global preferences from project-specific exceptions.
- Retain contradiction status instead of forcing a false merge.
- Rebuild derived summaries and indexes after corrections.
A related memory can still be wrong for the current request
Vector search is useful because a new request rarely repeats the wording of the old conversation. It is also dangerous when semantic closeness is treated as permission. Research on trustworthy memory search shows that a memory can be topically related while belonging to another person, project, time, sensitivity level or action type.
A stronger retrieval path combines lexical, temporal, graph and vector candidates, then applies an admission gate. The gate checks tenant, subject, source trust, freshness, purpose, sensitivity, contradiction status and whether the current task actually needs personalization.
The model should receive the smallest useful evidence set. Large context windows do not remove this requirement. Long histories increase cost and can bury decisive facts, while retrieval systems can omit or distort them. Context engineering remains an active selection problem.
- Filter tenant and authorization before semantic ranking.
- Use time-aware queries for changing facts.
- Score scope fit separately from similarity.
- Show the model source, date and uncertainty with the memory.
Remembered context must not silently approve a consequential action
A preference can safely influence tone or recipe suggestions. It should not silently become permission to send money, disclose records, change payroll, delete files or contact a person. The risk grows when an assistant combines persistent memory with email, calendars, browsers, code repositories or payment tools.
Tool parameters should be grounded in current system state and confirmed at the level of the transaction. A remembered address can prefill a form; the user should still see the destination before shipment. A remembered approval pattern can route a request; it cannot replace the current approver.
Procedural memory also needs boundaries. An agent may learn that one website requires a particular sequence, but a historical workaround should not override a changed interface, security warning or organizational policy.
- Treat memory as context, not an authorization token.
- Revalidate identities, balances, permissions and destinations.
- Bind confirmation to the actual action parameters.
- Require current state checks before reusing learned procedures.
Delete, correct and temporary modes need operational meaning
Major assistant products now expose combinations of memory controls, temporary conversations, source views and deletion. Those controls are useful only when their boundaries are clear. Removing a saved memory may not remove the original chat, a connected file, a derived summary, an embedding, an audit record or text already present in an earlier response.
A complete correction operation should identify authoritative records, derived state, indexes, caches and downstream replicas. Deletion may have legal or security exceptions, but those exceptions should be documented rather than hidden behind a simple interface label.
Portability is becoming a product issue as well. Google has introduced tools for importing memories and chat history from other AI services. A portable memory format needs provenance, scope, dates and user confirmation; otherwise it can transfer stale or falsely inferred claims into a new system.
- Publish what “forget,” “delete” and “temporary” each do.
- Propagate corrections to summaries, indexes and caches.
- Preserve required audit evidence separately from active personalization.
- Review imported memories before activation.
Enterprise memory needs tenant, role and records governance
A work assistant can remember project terminology, approval paths, interface behavior and recurring errors. That continuity is valuable, but the memory may contain company records, personal data, confidential strategy or regulated material. A departing employee should not carry the organization’s procedural memory into a personal account.
Scope should be explicit: personal, team, project, tenant or public. Each scope needs its own readers, writers, retention, legal hold and export rules. Microsoft documents enterprise memory within Microsoft 365 data controls, while Claude projects keep instructions and knowledge within a defined workspace. These are product-specific implementations of a broader requirement: memory must inherit the security boundary of its source.
Administrators also need observability without turning personal assistance into unrestricted surveillance. Aggregate quality and policy metrics can be separated from the private content used in an individual response.
- Map every memory type to an owner and tenant.
- Apply source permissions again at retrieval time.
- Define offboarding, export and legal-hold behavior.
- Separate operational metrics from readable personal content.
Measure remembering, forgetting and downstream consequences
LongMemEval, LoCoMo and newer agent benchmarks test extraction, multi-session reasoning, updates, temporal understanding, abstention, workflow knowledge and action use. The results consistently show that longer context or a memory database does not solve the problem by itself. Retrieval can miss evidence, and a model can misuse correct evidence after it is found.
Production evaluation should begin at the write gate and continue through action. Measure valid writes, harmful or stale commitments, retrieval recall, contextual admission precision, contradiction handling, deletion propagation, poisoning resistance and whether memory actually improves an accepted task.
Memory has a running cost: extraction models, embeddings, storage, graph updates, retrieval, reranking and extra prompt tokens. A small explicit profile may outperform an elaborate autonomous memory system for a bounded product. Complexity should follow the decision being improved, not the appeal of an assistant that “knows everything.”
- Evaluate write, store, retrieve, read and act stages separately.
- Include changed facts and requests that should not use memory.
- Test poisoning from messages, files, webpages and tool output.
- Compare against no-memory and explicit-profile baselines.
What a benchmark worth believing should report
A performance number means little unless the workload, system configuration and quality bar are fixed. This is the minimum record a team should keep.
| Metric | How to measure it | Why it matters |
|---|---|---|
| Write precision | Review committed records for support, correct scope, persistence and sensitivity policy. | Bad durable state compounds across later sessions. |
| Write recall | Measure whether approved durable facts, decisions and procedures were captured. | Overly strict gates can make memory appear safe by remembering nothing. |
| Stale-memory reuse rate | Count responses or actions influenced by superseded or expired records. | Remembering an old truth can be worse than abstaining. |
| Contradiction resolution | Test changed facts, project exceptions and mutually inconsistent sources. | A flat profile cannot represent time and scope reliably. |
| Provenance completeness | Check source, author, timestamp, scope and derivation links for active memories. | Correction and trust require knowing where a memory came from. |
| Candidate retrieval recall | Verify whether the necessary evidence appears before admission and generation. | The model cannot use a memory that retrieval omitted. |
| Contextual admission precision | Count retrieved records that were appropriate for the current person, project, time and purpose. | Semantic relevance does not establish permission or applicability. |
| Premise and abstention accuracy | Test requests whose assumed memory is missing, disputed or false. | A safe assistant should not invent continuity. |
| Memory-grounded action accuracy | Evaluate tool choice and parameters while requiring current authorization and state checks. | Correct recall can still produce an unsafe action. |
| Memory-poisoning success | Attempt direct, indirect, repeated and dormant injections through every writable channel. | Persistent compromise can survive the original session. |
| Deletion and correction propagation | Trace a change through authoritative records, summaries, indexes, caches and replicas. | A visible deletion control is incomplete when derived state remains active. |
| Cross-scope leakage | Probe across users, projects, teams and tenants with similar queries. | Memory often contains the most personal or confidential context in the system. |
| Latency and context overhead | Report write, retrieval, reranking and added-token p50, p95 and p99. | A memory feature can degrade the ordinary interaction even when unused. |
| Cost per improved accepted task | Divide full memory-system cost by tasks whose accepted outcome improved without a memory-related failure. | Storage volume and retrieval speed are not business value. |
Four sensible deployment patterns
Explicit saved preferences
- Where it fits
- Consumer assistants and low-risk personalization where users directly add or confirm a small profile.
- What you take on
- Easy to inspect and govern, but limited for evolving projects and implicit continuity.
Project-scoped retrieval memory
- Where it fits
- Defined workspaces containing instructions, documents, decisions and chat history.
- What you take on
- Strong context boundary, with ongoing work needed for source permissions, updates and deletion.
Governed enterprise memory service
- Where it fits
- Multiple applications sharing user, project and procedural memories under organizational policy.
- What you take on
- Reusable and auditable, but identity, tenancy, records management and integration complexity are high.
Agentic episodic and procedural memory
- Where it fits
- Long-running agents that learn environment state, successful workflows and recurring failures.
- What you take on
- Can improve autonomy, while creating the highest poisoning, stale-procedure and action-governance risk.
Where projects usually go wrong
Everything plausible is saved
What you see: Profiles fill with one-off choices, guesses and repeated paraphrases.
What to do: Use typed write policies, confirmation and minimum persistence thresholds.
A summary loses provenance
What you see: The assistant recalls a claim but cannot show who said it or when it applied.
What to do: Link every derived memory to versioned source records.
An old fact remains active
What you see: Past employers, locations, deadlines or preferences override current information.
What to do: Use effective dates, expiry, supersession and revalidation policies.
A project exception becomes a global preference
What you see: Instructions from one workspace affect unrelated conversations.
What to do: Enforce scope at write, retrieval and prompt assembly.
Similarity is treated as permission
What you see: Topically related private or inappropriate memories enter the prompt.
What to do: Apply authorization, sensitivity, time and purpose admission after retrieval.
Memory becomes authorization
What you see: A remembered destination, approver or workflow triggers a consequential action.
What to do: Require current state and transaction-bound confirmation outside memory.
Untrusted content poisons durable state
What you see: A message, file or webpage plants instructions that return in later sessions.
What to do: Separate observations from instructions and screen both writes and retrieval composition.
Deletion changes only the visible profile
What you see: Summaries, embeddings, caches or source chats continue to influence answers.
What to do: Maintain a deletion graph and verify propagation across derived stores.
Tenant boundaries fail
What you see: A similar query retrieves another user or organization’s memory.
What to do: Filter by tenant and subject before search and test adversarial cross-scope queries.
Personalization is invisible
What you see: A response changes because of memory but the user cannot identify or challenge the source.
What to do: Expose relevant memory sources and a direct correction path.
The assistant reinforces a mistaken profile
What you see: Its own prior inference is saved, retrieved and treated as stronger evidence each time.
What to do: Do not use generated summaries as independent corroboration and track derivation depth.
Memory complexity outruns value
What you see: Extraction, indexing and reranking add cost and latency without measurable task improvement.
What to do: Benchmark against explicit instructions, project files and no-memory baselines.
A checklist you can actually use
- Define the decisions memory is intended to improve.
- Separate raw history, durable records, summaries and prompt context.
- Name personal, project, team, tenant and temporary scopes.
- Classify facts, preferences, instructions, episodes and procedures.
- Set allow, confirm, temporary and deny write outcomes.
- Exclude or elevate review for sensitive data classes.
- Preserve source, author, time, confidence and derivation.
- Represent expiry, effective dates and superseded versions.
- Keep unresolved contradictions visible.
- Protect authoritative storage separately from search indexes.
- Apply tenant and authorization filters before semantic retrieval.
- Score freshness and scope fit separately from similarity.
- Provide the model with compact evidence and uncertainty.
- Prevent remembered content from granting tool authorization.
- Revalidate identities, permissions and transaction parameters.
- Expose which memories influenced a response where practical.
- Define correction, deletion, temporary-chat and import behavior.
- Propagate changes to summaries, indexes, caches and replicas.
- Test direct, indirect, repeated and dormant memory poisoning.
- Probe cross-user, cross-project and cross-tenant leakage.
- Measure stale reuse, abstention and downstream action quality.
- Calculate cost per accepted task improved by memory.
- Version memory policies and replay regressions after every material change.
Terms worth knowing
- Persistent memory
- Information retained beyond the current session for possible use in later interactions.
- Saved memory
- A durable detail explicitly stored or confirmed for future personalization.
- Episodic memory
- A record of a past interaction, event or task experience.
- Semantic memory
- A consolidated fact, concept or relationship derived from one or more sources.
- Procedural memory
- Stored knowledge about how to perform a workflow or operate in an environment.
- Memory write gate
- The policy and mechanism deciding whether candidate information becomes durable state.
- Consolidation
- Merging, summarizing and organizing related memory records while preserving their history.
- Supersession
- Marking an older record as no longer current without erasing its historical existence.
- Provenance
- Information describing a memory’s source, author, time, scope and derivation.
- Contextual admission
- The decision that a retrieved memory is appropriate for the current request and permitted use.
- Memory poisoning
- Planting durable content intended to distort future responses or actions.
- Temporary session
- An interaction designed not to read from or add to persistent personalization state.
- Cross-scope leakage
- A memory from one user, project or tenant influencing another unauthorized context.
- Deletion propagation
- Applying a removal or correction across source records, summaries, indexes, caches and replicas.
- Memory-grounded action
- A tool call or workflow decision that uses retrieved persistent context as one input.
Primary references and technical starting points
These sources support the architecture, runtime, benchmark and security claims. Vendor capabilities can change, so the article records the distinction between established evidence, measured product behavior and editorial interpretation.
- 01 OpenAI: Memory FAQhelp.openai.com
- 02 OpenAI: What is Memory?help.openai.com
- 03 OpenAI: Reference saved memorieshelp.openai.com
- 04 OpenAI: ChatGPT release notes for memory sourceshelp.openai.com
- 05 Google: Gemini Memories personalizationblog.google
- 06 Google: Import memories and chat history into Geminiblog.google
- 07 Google: Personal Intelligence and connected appsblog.google
- 08 Google: Gemini app updates, March 2026blog.google
- 09 Microsoft: Personalize what Microsoft 365 Copilot rememberssupport.microsoft.com
- 10 Microsoft: Manage Copilot Memorysupport.microsoft.com
- 11 Microsoft: Copilot privacy controlssupport.microsoft.com
- 12 Microsoft Learn: Manage Copilot personalization and memorylearn.microsoft.com
- 13 Anthropic: Claude personalization featuressupport.anthropic.com
- 14 Anthropic: Claude projects and project knowledgesupport.anthropic.com
- 15 Anthropic: Effective context engineering for AI agentsanthropic.com
- 16 Anthropic: Effective harnesses for long-running agentsanthropic.com
- 17 MemGPT: Towards LLMs as Operating Systemsarxiv.org
- 18 LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memoryarxiv.org
- 19 LongMemEval-V2: Long-term agent memory for environment experiencearxiv.org
- 20 LoCoMo: Evaluating Very Long-Term Conversational Memoryaclanthology.org
- 21 LoCoMo-Plus cognitive memory evaluationaclanthology.org
- 22 Memora: Benchmarking remembering, reasoning, recommending and forgettingarxiv.org
- 23 Mem2ActBench: Memory use in task-oriented agentsarxiv.org
- 24 Agentic Memory: Unified long- and short-term memory managementarxiv.org
- 25 SeCom: Memory construction and retrieval for personalized agentsarxiv.org
- 26 Zep: Temporal knowledge graph architecture for agent memoryarxiv.org
- 27 MemGate: Trustworthy memory search for personal agentsarxiv.org
- 28 Persistent sycophancy in stateful personal agentsarxiv.org
- 29 MemPoison: Persistent memory threats in LLM agentsarxiv.org
- 30 Memory Poisoning Attack and Defense on Memory-Based LLM Agentsarxiv.org
- 31 GhostWriter: When agents remember too mucharxiv.org
- 32 Sleeper memory poisoning in LLM agentsarxiv.org
- 33 NIST AI Risk Management Frameworknist.gov
- 34 NIST AI RMF privacy measurement guidanceairc.nist.gov