Your Copilot Studio Agent Remembers the User. Your Scheduled Runs Still Wake Up Blank.

There is a Memory toggle in Copilot Studio's Build tab, and it does what it says. Flip it on, and your agent starts recalling things about the people it talks to: their preferences, the patterns it notices, the corrections they make. A week later, it greets a returning user with context instead of a blank stare. That part is real, documented, and worth using.

But here is the sentence nobody puts in the launch announcement: the toggle remembers people. It does not remember runs. And if your automation strategy leans on autonomous agents — the kind that fire on schedules and events while everyone sleeps — that distinction decides whether your 2am agent is competent or clueless.

How the Memory feature works, precisely

Microsoft's Memory for Copilot Studio is currently in preview and enabled per agent. Every memory-enabled agent follows the same three-step lifecycle:

• Capture. During interaction, the agent records signals: user preferences, observed patterns, notes about its own work.
• Store. Those signals land as files in a memory folder that belongs to that user, for that agent, inside a tenant-scoped store.
• Apply. On subsequent interactions, the agent reads the folder and personalizes its responses.

Three properties of that design matter more than the feature list suggests:

1. It is per user, per agent. Every person gets a separate memory folder per agent. Nothing crosses between users, and nothing crosses between agents.
2. It expires. A user with no activity for 28 days loses their memories for that agent. (Turning the toggle off merely pauses use; it doesn't delete what's stored.)
3. It stores signals, not history. Preferences and patterns, not the full transcript of what happened or the complete reasoning behind a decision.

For a conversational agent serving humans, this is a sensible design. Personalization without cross-contamination. The official documentation lays it out plainly.

Where it falls apart: the autonomous run

Copilot Studio also builds autonomous agents — agents that run without any end-user input, triggered by events like an email arriving or a table row changing, or by a schedule. Microsoft documents these automated copilots as background workers for business processes.

Now put the two features together and watch the seam split:

• A scheduled run has no interactive user. The memory folder is keyed to a user. So the run has no folder to read from and no folder to write to. It executes with instructions, knowledge, and tools — and zero recollection of its previous runs.
• Corrections made in chat never reach the schedule. When your analyst corrects the agent's lead-scoring rule in a conversation, that correction is stored in their folder. Tonight's autonomous scoring run can't see it, so it scores leads with the old rule.
• Two agents can't pool what they learn. The triage agent's folder and the escalation agent's folder are separate by design.

None of this is a malfunction. The feature was built to personalize conversations, and it does that. The problem is purely one of expectations: operators hear "Memory" and assume it covers the agent's working life. It covers the user's preferences.

If you want proof that the gap is real and recognized, look at what Microsoft's own people build. The FastTrack repository — Microsoft's official sample collection — includes PowerClawAgent, a round-the-clock assistant running on a scheduled heartbeat in Copilot Studio. Its memory isn't the Memory feature. It's SharePoint lists (a Memory Log list, a PowerClaw_Memory list) plus a memory-journal.md file, loaded by the heartbeat flow on every run. The setup doc is public. When the vendor's reference implementation hand-rolls memory from lists and markdown, the platform is showing you exactly what it doesn't provide.

The three ways operators close the gap

Option one: tables you own. Dataverse or SharePoint, the PowerClaw pattern. Everything stays in your tenant. You also own the entire design: the schema, the write timing, the retrieval query at run start, the expiry logic. It works, and every team rebuilds it slightly differently.

Option two: transcripts as knowledge. Feed run transcripts into a knowledge source and let retrieval sort it out. Cheap to start, but transcripts are unstructured noise, retrieval quality varies, and there's no first-class place for corrections, decisions, or task state.

Option three: a memory layer outside the platform. Copilot Studio agents can call MCP servers as tools. That opens the door to a memory store with none of the platform's scoping limits: not keyed to a user, not fenced to one agent, not a table you designed and maintain. The scheduled run reads what the previous run wrote. A correction lands once and every future run — chat or scheduled — applies it.

Vilix AI is built as that third option: a cloud-hosted memory layer agents reach over MCP, with zero infrastructure on your side. Connect each tool once and the same memory follows everywhere. It keeps full conversation exchanges rather than just extracted preferences, alongside projects, tasks, and rules, and retrieves semantically so the agent finds what it meant instead of keyword-matching. The free plan never expires, the 7-day Pro trial asks for no credit card, and your data stays portable — export it all or delete it outright whenever you want. Your 2am run wakes up with yesterday's context instead of a blank slate.

The question to ask before your next autonomous build

Don't ask "does my agent have memory on." Ask "whose memory does my scheduled run get?" If the answer is "nobody's, because there's no user at 2am," you have the gap — and now you know the three ways to close it. The toggle handles the humans. The runs need something of their own.