Skip to content
  1. Home
  2. AI agents
  3. Agent memory and context
  4. Memory privacy and retention

Build · Agent memory and context

How long should an AI agent remember, and how do you delete it?

Memory privacy and retention are the rules for what an AI agent may remember about people, how long each copy of a memory is kept, and how it is found and deleted on request. They cover the memory store and every copy around it: conversation threads, summaries, embeddings, traces and the model provider’s own retention.

Mahesh TatiparthyFounder and CEO, QueryNow
Last reviewed 2 November 2026Product names and statuses as of that date
In this guide: 83 pages

Key takeaways

  1. One memory is copied more often than teams expect: the raw conversation, the extracted record, summaries and reflections, the embedding, the trace and sometimes the model provider’s log. Retention and deletion have to reach each copy.
  2. Defaults differ widely. AgentCore long-term records never expire unless you set a TTL of at least 31 days, OpenAI keeps responses chained with previous_response_id for 30 days by default, and Microsoft 365 Copilot memory sits outside Purview retention.
  3. Give every memory a person key from the first day. Per-user namespaces or scopes are what make a deletion request answerable at all.
  4. Remember less. Screen out special-category data, credentials and anything the user would not expect the agent to keep before it is written.
Where one agent memory is written, and the controls on each copyA conversation is stored as raw events or a thread. An extraction model picks facts and preferences to keep. The memory store holds the records and their embeddings under one user key. Recall searches the store filtered to the same user and puts the result back into context. Four controls apply to every copy: screen what is written, set an expiry per copy, delete by the person's key in every store, and remember the copies outside the store, such as traces, exports and the model provider's own retention.How a memory is madeConversationRaw turns kept asevents or a threadExtractionA model picks the factsand preferences to keepMemory storeRecords and embeddingsunder one user keyRecallSearch filtered to thesame user, back intocontextControls on every copyScreen writesDrop special-categorydata and injected textExpireA TTL per copy, set whenthe store is createdDelete by keyFind one person’srecords in every storeCopies outsideTraces, exports andprovider retentionWhere one agent memory is written, and the controls on each copyA conversation is stored as raw events or a thread. An extraction model picks facts and preferences to keep. The memory store holds the records and their embeddings under one user key. Recall searches the store filtered to the same user and puts the result back into context. Four controls apply to every copy: screen what is written, set an expiry per copy, delete by the person's key in every store, and remember the copies outside the store, such as traces, exports and the model provider's own retention.How a memory is madeConversationRaw turns kept as events or a threadExtractionA model picks the facts and preferences to keepMemory storeRecords and embeddings under one user keyRecallSearch filtered to the same user, back into contextControls on every copyScreen writesDrop special-category data and injected textExpireA TTL per copy, set when the store is createdDelete by keyFind one person’s records in every storeCopies outsideTraces, exports and provider retention
A memory starts as a conversation, passes through an extraction model and lands in a store under one user key. The four controls underneath apply to every copy, including the ones outside the store.

Where does an agent’s memory get copied?

With managed memory, one remembered fact usually exists in several places. A single preference typically leaves a raw conversation event, an extracted record, an embedding of that record and a trace of the call that wrote it, and the model provider may keep the prompt that carried it.

The copies of one memory and who controls their retention, as the vendor pages documented on 2 Nov 2026.

CopyExamplesRetention controlWho deletes it
Conversation threadOpenAI responses chained with previous_response_id or a Conversations API object; AgentCore short-term events; a LangGraph checkpointOpenAI keeps chained responses 30 days by default, conversation objects without that limit; AgentCore events expire after up to 365 days, fixed at write timeYour application, through each API
Extracted long-term recordAgentCore semantic or user preference records; Foundry user profile memories; Memory Bank memoriesAgentCore record TTL of 31 days or more, otherwise no expiry; Foundry store default TTL in preview; Memory Bank revision historyYour application or an admin, by user key
Summaries and reflectionsAgentCore summary and episodic reflections; Foundry chat summaryAs for the store; AWS warns that episodic reflections can span several usersHard to attribute to one person once they mix users
Assistant memory in a SaaS productMicrosoft 365 Copilot saved memories and details inferred from chat history, kept in a hidden folder of the user’s mailboxOutside Purview retention policies and labels; memory actions write no Purview audit entriesAdmins through eDiscovery and Graph Explorer
Client-side memory filesFiles Claude writes under /memories through Anthropic’s memory toolWhatever your storage doesYou, entirely
Traces and logsOpenTelemetry spans with captured prompt content; audit recordsYour observability retentionYour platform team
Model providerAmazon Bedrock data retention modes; Gemini caching; Grounding with Google SearchBedrock none, default or aws_review (up to 30 days, possible human review); Gemini caches up to 24 hours by default; search grounding keeps queries up to three daysThe provider, under the mode you choose

Shortening a setting rarely reaches what is already stored. AgentCore fixes an event’s expiry when it is written, so a shorter setting applies only to new events, and a Purview policy that deletes Copilot interactions after one day can take up to about 16 days to purge them fully. On Bedrock, some newer models, Claude Fable 5 and 5.1 among them, require the aws_review mode, so check a model’s mode before an agent that recalls personal data uses it.

How long should each kind of memory be kept?

As long as its purpose needs, set per copy when the store is created. Session context can usually go within days, preferences should lapse unless the user confirms them again, and episodic records deserve the shortest period because they hold the most detail about what people did.

GDPR’s storage limitation principle applies to memory as to any other personal data. The EU AI Act points the same way: Articles 19 and 26(6) make providers and deployers of high-risk systems keep automatically generated logs for at least six months unless Union or national law, in particular data protection law, provides otherwise, and after the AI Omnibus those duties apply to Annex III systems from 2 Dec 2027. Treat memory and logs as separate records with separate purposes, and never let a log floor become the retention period for what an agent remembers about people.

Starting points to agree with your data protection officer. The product settings are as documented on 2 Nov 2026.

Kind of memoryPurposeStarting pointProduct setting
Session contextFinish the current taskDays, ending when the task closesAgentCore event expiry; delete OpenAI conversation objects; Agents SDK encrypted sessions with a TTL
User preferencesPersonalise later sessionsMonths, renewed when the user confirms themAgentCore record TTL (31 days minimum); Foundry store default TTL (preview); Memory Bank memory profiles
Episodic records and reflectionsLearn from past runsShort, and kept per userAgentCore episodic strategy with reflections at actor level, or leave it off
Procedural memoryBetter instructions for every userUntil replaced, after reviewFoundry procedural memory (preview); version it like a prompt
Traces with contentDebugging and auditYour log policy, with content capture off by defaultThe content-capture setting of your OpenTelemetry instrumentation

How do you answer a deletion request for agent memory?

Check what the law lets you delete, find every copy by the person’s key, delete it in each store, then record that you did. The work is quick when each memory was written under a user key and slow when it was not, so the decision that matters is made long before the first request arrives.

  1. Assess the request first. Confirm the requester’s identity and check whether a legal obligation, such as a litigation hold or a statutory retention duty, requires keeping some records; GDPR Article 17 lists exceptions to erasure.
  2. Resolve the person to the keys your agents used: the AgentCore actorId and namespaces, the Foundry memory scope, thread or conversation IDs, and the mailbox for Microsoft 365 Copilot. AWS suggests per-user namespaces such as /users/{actorId}/preferences/ for exactly this reason.
  3. Delete long-term records before the threads they came from, and pause extraction for that user while you work. AgentCore extracts long-term memory asynchronously, which AWS says can take a minute or more, so a pending job could recreate a record from an event you have not yet removed.
  4. Handle derived items. A summary or reflection that mixes several users cannot be deleted for one person without losing the others, which is why AWS recommends keeping episodic reflections at the actor level.
  5. For Microsoft 365 Copilot, search the mailbox with eDiscovery for item class IPM.Contact in the CopilotMemory folder and purge through Graph Explorer. Purges run 10 items per mailbox at a time, an active hold blocks the purge and should be released only when your legal team confirms it no longer applies, and deleting the user’s conversations leaves these memories in place. Custom instructions are not discoverable this way.
  6. Check the copies outside the store: traces that captured content, exports, and anything the model provider kept under the retention mode you chose.
  7. Record what you deleted and when, without recording the deleted content, and answer the requester.

Client-side memory, such as files written through Anthropic’s memory tool, has no vendor delete API; your storage is the system of record, and the same runbook applies to it. Anthropic also recommends deleting memory files that nobody has accessed for a long time.

Which design choices keep memory privacy risk low?

Decide what the agent may never remember, scope every record to one person, and tell people what the agent keeps about them. The products give you the switches; choosing which to use is your job.

Screen what gets written. The extraction model chooses what to keep. Anthropic says Claude usually refuses to write sensitive information to its memory tool and still recommends your own validation, and Microsoft’s guidance for Foundry memory is to screen what enters and leaves memory with Azure AI Content Safety prompt-injection detection. Add a rule of your own for special-category data, credentials and payment details: drop them before the write.

Make isolation an explicit key. Foundry’s low-level memory APIs need a scope on every request and resolve it from the caller only when the memory search tool uses {{$userId}}, so a missing scope is an isolation bug. AgentCore’s strictly consistent metadata (15 Jun 2026) copies tenant or department keys unchanged from events to long-term records and never merges records whose values differ.

Be open with the people concerned. Admins can switch Microsoft 365 Copilot personalisation off for the tenant with the Enhanced personalization control, and Foundry’s latest preview adds explicit remember and forget commands. Name memory and its retention in the privacy notice and in the agent’s data protection impact assessment, and call embeddings or summaries anonymous only if they meet the EDPB’s draft criteria of no singling out, no linkage and no inference (Guidelines 02/2026, 8 Jul 2026).

Keep regulated data off preview services. Foundry memory is still public preview with no VNet support, and the Microsoft 365 Copilot memory page (2 Sep 2026) still labels the feature preview. AgentCore Memory and Memory Bank are generally available, both with customer-managed encryption keys.

How do Microsoft, AWS and Google implement it?

Retention and privacy controls in each cloud’s memory service, with statuses as the vendor pages showed on 2 Nov 2026.

Capability, Microsoft, AWS, Google

CapabilityMicrosoftAWSGoogle
Memory service and statusMemory in Foundry Agent Service, public preview; Microsoft 365 Copilot memory, labelled previewAgentCore Memory, generally available since 13 Oct 2025Agent Platform Memory Bank (formerly Vertex AI Agent Engine Memory Bank), generally available since Dec 2025
ExpiryStore-level default TTL in the latest Foundry preview; Copilot memory has no admin retention controlEvents expire after up to 365 days; long-term record TTL of 31 days or more, added in Oct 2026Consolidation and revision history; check expiry options for your configuration before launch
Isolation keyA scope per user, required on low-level API callsactorId, sessionId and namespaces; strictly consistent metadata for tenant keysIAM Conditions on Memory Bank access
Encryption and networkFoundry memory has no VNet support during previewCustomer-managed KMS keys; VPC and PrivateLink across AgentCoreCustomer-managed encryption keys and VPC Service Controls

Outside the clouds: OpenAI’s Conversations API objects have no 30-day limit, unlike chained responses; Anthropic’s memory tool is client-side and stable, while memory stores for Claude Managed Agents are in beta.

Frequently asked questions

Does deleting a chat delete what the agent remembered from it?

Usually not. In Microsoft 365 Copilot, deleting a conversation leaves the memories created from it, and in AgentCore long-term records outlive their source events unless they carry their own TTL. Delete the records and the threads as separate steps.

Is agent memory personal data under GDPR?

Whenever it relates to an identifiable person, and most useful memory does: preferences, past requests, details about colleagues or customers. Storage limitation and the right to erasure in Article 17 apply in full, and summarising or embedding the text does not make it anonymous by default.

Can admins stop Microsoft 365 Copilot from remembering things?

They can switch the feature off for the whole tenant through the Enhanced personalization control, exposed in Microsoft Graph as enhancedPersonalizationSetting, but they cannot restrict what Copilot remembers while it is on. Memory actions also write no Purview audit entries, so plan reviews through eDiscovery.

Should every agent have long-term memory?

No. An agent that finishes its task in one session, or one that serves many people through a shared identity, gains little from long-term memory and adds a store you must govern. Start with session context and add per-user memory when a measured task needs it.

More in Agent memory and context

Types of agent memoryRead Context engineeringRead

Sources

Each source was read on 2 November 2026. The date shown is the date on the page, or the page’s ms.date for Microsoft Learn; an undated page shows the date it was read.

  1. What is memory in Foundry Agent Service? Microsoft Learn, 2 June 2026
  2. Introducing memory in Foundry Agent Service Microsoft Foundry blog, 25 November 2025
  3. What’s new in Microsoft Foundry, Build 2026 Microsoft Foundry blog, 2 June 2026
  4. Microsoft 365 Copilot personalization and memory Microsoft Learn, 2 September 2026
  5. Search for and delete Copilot and AI app data with eDiscovery Microsoft Learn, 19 June 2026
  6. Retention policies for Copilot and AI apps Microsoft Learn, 25 June 2026
  7. AgentCore Memory AWS documentation, undated page, read 2 November 2026
  8. Create an AgentCore Memory store AWS documentation, undated page, read 2 November 2026
  9. Configure built-in long-term memory strategies AWS documentation, undated page, read 2 November 2026
  10. Episodic memory strategy AWS documentation, undated page, read 2 November 2026
  11. Memory in the AgentCore managed harness AWS documentation, undated page, read 2 November 2026
  12. AgentCore Memory adds strictly consistent metadata AWS What’s New, 15 June 2026
  13. AgentCore release notes AWS documentation, undated page, read 2 November 2026
  14. Data retention in Amazon Bedrock AWS documentation, undated page, read 2 November 2026
  15. Memory Bank overview Google Cloud, undated page, read 2 November 2026
  16. Gemini Enterprise Agent Platform release notes Google Cloud, 28 October 2026
  17. Generative AI data governance Google Cloud, undated page, read 2 November 2026
  18. Conversation state OpenAI developer documentation, undated page, read 2 November 2026
  19. Sessions, OpenAI Agents SDK OpenAI Agents SDK documentation, undated page, read 2 November 2026
  20. Memory tool Anthropic Claude documentation, undated page, read 2 November 2026
  21. Regulation (EU) 2016/679 (GDPR) EUR-Lex, 27 April 2016
  22. EDPB sheds light on anonymisation and web scraping for generative AI European Data Protection Board, 8 July 2026
  23. AI Act, Article 19: automatically generated logs artificialintelligenceact.eu, undated page, read 2 November 2026. Secondary transcription of the Regulation.
  24. AI Act regulatory framework European Commission, 19 October 2026

Planning an AI program?

Talk to the team that builds it and runs it after launch.

Talk to our team See our workTell us the workflow
  • Built to SOC 2, HIPAA and GDPR standards
  • EU AI Act-aligned delivery
  • Microsoft Solutions Partner