The Memory switch on your Copilot Studio agent is off, and your change record says "memory disabled, data deleted." Yet Microsoft documents that turning Memory off does not erase stored memories: the agent simply stops using them. This tutorial walks you through stopping memory use, actually deleting the memories and keeping usable evidence.
Why "Memory: off" does not prove deletion
The Memory (preview) feature applies to agents powered by the GitHub Copilot harness. Microsoft Learn describes it as a "production-ready" preview subject to additional terms of use. Each agent has a separate memory space per user, in Microsoft-managed storage. Neither the maker (the person who designs the agent) nor other users can see these memories.
Memories are deleted after 28 days without interaction, and user memory is disabled in group conversations and Teams channels. The switch only affects usage: it empties nothing. The details are in the Microsoft Copilot Studio Memory documentation.
June 2026
Memory for GitHub Copilot harness agents
The Copilot Studio "What's new" page announces that memory is enabled for these agents.
August 2026
Harness generally available
The Microsoft blog post announces general availability of the harness itself, and specifies that Memory remains in preview.
28 days is not an incident procedure
If someone needs to see information disappear now, waiting for automatic retention does not meet the request. You need an explicit deletion action, with a named owner.
Prerequisites
Gather these items before touching any setting.
Before you start
- A Copilot Studio agent powered by the GitHub Copilot harness, since that is the documented scope of Memory (preview)
- Edit rights on that agent to access its Build page (check with your team which licence and role your tenant requires: the documentation consulted does not detail them here)
- A dedicated pilot user, distinct from the maker, who will be used to test deletion
- Synthetic test data only, never real content
- An individual conversation: user memory is disabled in groups and Teams channels
- Access to the up-to-date Memory documentation, since this is a preview whose behaviour may change
Procedure: stop use, then delete the memories
The goal is to handle two requests separately: stop the use of memory, and erase what has been stored. The exact order between the two should be validated on your pilot, as the documentation consulted does not prescribe it.
Record the current state of Memory
Open Copilot Studio, select your agent, then display the Build page and locate the Memory switch, marked Preview. Note its state (on or off) and the date of the check in your change record.
You should see the Memory switch next to the agent's other components: knowledge, tools, connected agents.
This state is evidence of configuration, not a storage audit: a switch set to off says nothing about memories already created.
State what must be forgotten, and why
Write one sentence: "This agent must remember ___ between conversations because ___." If you cannot complete it, memory has no reason to exist on this pilot.
Also specify which source is authoritative in case of conflict: an approved policy must always take precedence over a remembered preference.
Disable Memory use if necessary
On the Build page, switch Memory to off. In the test Preview tab, the effect is immediate from the next turn, without a new conversation.
You should see the switch set to off. At this point, the agent no longer uses memories, but they still exist.
Delete a specific memory from the chat
Sign in as the pilot user, open an individual conversation with the agent and ask it to modify or forget the targeted memory, naming it clearly.
The agent should confirm the change or the deletion. Keep this confirmation as user-visible evidence.
Erase everything via the memory portal
To delete everything at once, ask the agent to open the memory portal. It is offered in the conversation on the first interaction in a channel, then on request. Select View memories to review the content, then Delete all memories.
You should see the list empty out after deletion.
Record the decision in a short sheet
Document it in six lines: purpose, scope of permitted information, authoritative source, user control (does the user know how to find the portal?), support (who handles a report) and exit (how to stop use and then handle the data at the end of the pilot).
Verify the result
Deletion is proven by a test, not by a setting. Replay the same synthetic questions while changing only one variable at a time: if the model, instructions, source and memory state all move together, a different answer teaches you nothing.
| Test | What to observe | Evidence to keep |
|---|---|---|
| Harmless preference | It is recalled in a new conversation | Prompt, conversation limit, result |
| Request conflicting with the policy | The memory does not become an unfounded exception | Source version, reviewer opinion |
| Second pilot user | The first user's context does not appear | Two identities, anonymised results |
| Memory disabled | The agent no longer uses memories | Switch state, control test |
| Deletion of the synthetic memory | The deletion flow works for the pilot user | Visible confirmation, follow-up test |
| Policy update | The approved content remains the reference | Old and new versions, decision |
In the Preview tab, the activity trace shows what the agent consulted. Use it to understand an unexpected answer.
A Memory test can store data immediately
Enabling Memory in testing takes effect on the next turn. A test with real information therefore creates real memories. Use synthetic data and plan for the deletion of the test set.
A user-side confirmation remains a piece of functional evidence. It is not equivalent to an inspection of the Microsoft-managed storage: word it that way in your report.
Do not confuse it with Microsoft 365 Copilot Memory
This tutorial covers the memory of Copilot Studio agents. Microsoft 365 Copilot Memory is a distinct mechanism, presented in a Tech Community post.
| Criterion | Copilot Studio agent Memory | Microsoft 365 Copilot Memory |
|---|---|---|
| Administrator disabling for the whole organisation | Not mentioned in the documentation consulted | Possible |
| Discovery via Purview eDiscovery | Not mentioned in the documentation consulted | Discoverable data |
| Storage space | One space per agent and per user | Distinct mechanism |
Do not apply one's controls to the other without checking. For overall governance, our article on the three-zone model for Copilot agents provides a framework, and the one on memory and context attacks explains why persistent memory widens the risk surface.
Troubleshooting
For support, never ask a user to paste their entire memory into a ticket. Start from a synthetic reproduction and the minimum of evidence.
Frequently asked questions
Does disabling Memory delete existing memories?
No. According to Microsoft documentation, the agent merely stops using them. To erase them, the user must ask for a memory to be forgotten in the chat or use the memory portal.
Can the maker read users' memories?
No. Each user has a separate space for each agent, and neither the maker nor other users can see these memories. Build your support process around user control.
How long are memories kept?
They are deleted after 28 days without interaction. This delay is a preview behaviour to recheck before deployment, and it does not replace deletion on request.
Is agent memory the same as Microsoft 365 Copilot memory?
No, they are two distinct mechanisms. Microsoft 365 Copilot's can be disabled by the administrator for the whole organisation and its data is discoverable via Purview eDiscovery. The Copilot Studio documentation consulted does not mention Purview for agent memory.
Where to start
First take inventory of your GitHub Copilot harness agents with Memory enabled, then handle them one by one.
Next actions
- Record the state of the Memory switch on each agent
- Complete the sentence "must remember ___ because ___" or disable Memory
- Test deletion with a pilot user and synthetic data
- Fix your change records: separate "use stopped" from "data deleted"
- Name the person who handles a report of an unwanted memory
If your agent is a policy explainer, keep the first pilot without memory: answers remain comparable and the approved source keeps its authority. If it is a personal assistant, memory can be justified, provided the user knows how to consult and clear it. For the harness context, see our article on the new Copilot Studio harness and the one on Copilot Memory updates for users.
Going further
- Memory (preview) – Microsoft Copilot Studio: memory lifecycle, 28-day retention, memory portal and the difference between disabling and deleting
- What's new in Copilot Studio: timeline of new features, including harness agent memory in June 2026
- Agents powered by the GitHub Copilot Harness overview: the Build, Preview, Evaluate, Monitor framework in which memory fits
- Introducing Copilot Memory (Tech Community): Microsoft 365 Copilot memory, with its administrator and eDiscovery controls
