Copilot Studio Memory: Off Does Not Mean Deleted

Supported byAdvertisement

I opened the Build page of my Copilot Studio demo agent and looked at the Memory switch.

It was off. That is a useful observation, but it does not answer every data-handling question.

Microsoft documents that turning Memory off prevents the agent from using stored memories. It does not delete those memories. If your change record says “memory disabled and all stored information removed,” one toggle is not enough evidence. Copilot Studio Memory documentation.

That distinction is worth understanding before adding memory to a production agent. Here is how I would review the feature, using an existing policy-assistant draft in my ModernDevMgmt tenant.

What the live portal shows#

Fresh portal capture from 28 September 2026. Memory is marked Preview and the switch is off. I did not turn it on, save a change or inspect anyone’s stored memories.

The broader Build page shows a deliberately narrow scenario: the JR Demo – Rollout Coach – New UI Draft is configured to explain a fictional rollout policy. It has a knowledge file named rollout-policy-v1.txt. Its instructions say not to deploy applications, change devices or claim that it applied a change.

That is the context for my review. It is not evidence that the agent has passed security tests, and it is not a statement that no memories have ever existed for it. I can verify the visible configuration. Historical data needs a different check.

Start with a reason for remembering#

I would not enable memory merely because the switch is available. I would first finish this sentence:

“This agent needs to remember ___ between conversations because ___.”

A preference for concise answers may be useful. A temporary deployment exception is a very different kind of information. In a policy assistant, I want current, approved policy to remain the source of authority. An earlier conversation should not quietly turn into an approval record.

For the Rollout Coach, my starting recommendation is therefore conservative: keep the first pilot stateless unless a specific user need justifies persistence. That makes it easier to understand why the agent answered a question and to compare runs using the same source material.

This is a design recommendation for this scenario, not a rule that all agent memory is unsafe. A personal assistant and a policy explainer have different jobs.

Memory, knowledge and permissions are different things#

The configuration panel puts several components close together. I would still review them separately.

Component	Question I would ask	Example in this pilot
Knowledge	Which reviewed material should support an answer?	The current fictional rollout-policy file
Memory	Which user context should persist between conversations?	Possibly a presentation preference, if justified
Tools	Which external operations can the agent attempt?	None needed for the initial policy-explanation task
Permissions	Which operations are technically allowed?	Must be checked in the connected systems if tools are added

An instruction such as “do not make changes” describes intended behavior. It is not a substitute for restricting a tool’s permissions. Microsoft describes tools as the mechanism for calling APIs, accessing external services and taking actions. If I later add a device-management tool, I need to review the actual operation and authorization, not only rewrite the prompt. Tools in the GitHub Copilot harness.

For a broader view of where these agents fit, see my Copilot, Cowork and agents guide.

Understand the documented memory boundary#

Microsoft describes a separate memory store for each user and agent. Makers cannot read users’ memories. Users can review or remove their own memories through the supported chat and memory-portal experiences. The current documentation also describes deletion after 28 days without interaction and says user memory is disabled in group chats and Teams channels. These are preview behaviors, so recheck them before rollout. Memory scope and lifecycle.

I would not use inactivity-based cleanup as my incident-response procedure. If someone needs information removed now, the operating process should identify the supported deletion action and the person who can perform it. “Wait for the retention period” and “delete this information” are different requests.

I would also avoid an administrator support process that asks people to paste their entire private memory store into a ticket. Start with a synthetic reproduction and the minimum evidence needed to understand the issue.

Write a short memory decision record#

Before enabling memory for this kind of assistant, I would want the owner to answer six questions:

1. Purpose: What becomes materially better when context persists?
2. Scope: What types of information are appropriate for that purpose?
3. Authority: Which source wins if a remembered preference conflicts with the current policy?
4. User control: Can a pilot user find and understand the review and deletion experience?
5. Support: Who handles a report that the agent remembers something it should not?
6. Exit: How will the team disable use and separately address stored data when retiring the pilot?

The record should describe an operational decision. A checkbox saying “governance completed” does not help a user who asks what the agent remembers about them.

For my policy-assistant example, I would keep approved policy updates in the source-management process. Personal memory should not become a second, unofficial policy repository.

Test the uncomfortable cases, not only personalization#

The following tests are proposed, not executed in this walkthrough. They should use synthetic data, an approved allowance and a dedicated pilot user. I did not enable memory or spend credits to manufacture a successful demo.

Test case	What to check	Evidence to keep
Harmless preference	A preference behaves as intended across new conversations	Prompt, conversation boundary and observed result
Conflicting policy request	Remembered context does not become an unsupported policy exception	Source version and reviewer explanation
Second pilot user	User-specific context does not appear for another user	Separate identities and sanitized results
Disable memory	The behavior after disabling matches the intended change	Configuration state and controlled follow-up
Delete synthetic memory	The supported deletion flow works for the pilot user	User-visible confirmation and a follow-up test
Change the source policy	Current approved content remains authoritative	Old and new source versions plus acceptance decision

I would keep the test questions consistent and change one variable at a time. If the model, instructions, source document and memory state all change together, a different answer tells me very little about which change caused it.

For each result, record what you observed rather than what you hoped the setting would do. A user-visible confirmation is useful evidence; it is not a claim that you inspected Microsoft’s underlying storage.

Separate the test plan from the test results#

Copilot Studio exposes Build, Preview, Evaluate and Monitor as separate parts of the agent lifecycle. In this draft, Monitor was not available. I would not create a dashboard illustration to fill that gap. The current agent authoring experience.

That separation matters in an article too. The screenshot proves that the Memory control exists and was off in the inspected configuration. The Microsoft reference explains documented behavior. The test table describes what I recommend doing next. None of those should be presented as a completed production validation.

Decide what happens when someone reports a problem#

My proposed support flow is straightforward:

• Identify the affected agent and user without collecting unnecessary conversation content.
• Determine whether the concern is source knowledge, current conversation context, persistent memory or an external tool action.
• Use the supported user controls where deletion is required.
• Review whether the agent should stop using memory while the issue is investigated.
• Re-run the relevant synthetic test before broadening access again.

The diagnosis comes first. Re-uploading a knowledge file will not necessarily address a memory concern. Turning off memory will not fix a tool with excessive permissions. A single “reset the agent” instruction hides those differences.

My recommendation for a first policy-assistant pilot#

Keep the scope small: one reviewed source, a clear task and no unnecessary execution capability. Add memory only when you can explain the benefit and test the associated behavior.

For the current Rollout Coach, the useful outcome is a supported explanation of a rollout rule. Remembering more is not automatically an improvement to that outcome.

Is Memory off proof that nothing is stored?#

No. Treat the visible switch as configuration evidence, not a storage audit. Verify the appropriate user-facing controls when stored information is the concern.

Should a maker inspect every user’s memories?#

That is not the model described by Microsoft. Build a support process around user control and minimal, consented evidence rather than assuming maker access.

Do I need memory for the agent to use a knowledge file?#

These are separate components in the Build experience. My inspected draft has a knowledge file while Memory is off. Whether its answers meet the acceptance criteria still needs testing.

My takeaway#

Before enabling agent memory, decide what deserves to persist. Before disabling it, decide whether your task is to stop use, remove stored information or both.

Those are small distinctions in the UI, but important ones in a real operating process.

Stay healthy, Cheers Jannik