Copilot Memory is GA, and Dreaming rewrites it overnight. Which parts of an agent's memory does anyone review?

When a coding agent learns that your team runs tests with a particular command, or that a reviewer always rejects a certain pattern, where does that knowledge go, and who can read it?

GitHub answered part of that question on October 28. Copilot Memory is now generally available on paid Copilot plans, and a new capability called Dreaming, in public preview, reviews past work to improve future sessions. Together they make agent memory a maintained part of the development environment rather than a side effect of a long chat.

What each piece does

Copilot Memory stores personal preferences and repository conventions, such as test commands or how Copilot should check its work. GitHub says Copilot “autonomously generate[s] and curate[s] memories” from interactions, at two scopes: personal and repository. Users can view and delete their personal preferences; access to repository memories follows Copilot Memory’s repository access settings.

Dreaming works in three ways. It curates personal memories from agent conversations. It manages repository memories and proposes updates to skills and custom instruction files. And it turns recurring code-review feedback that developers accepted into guidance for future reviews. It is opt-in: organizations enable it by policy, users enable it for themselves, and its runs consume AI credits.

GitHub reports that, in preview Copilot CLI sessions where the agent used memory, 93% showed better adherence to developer preferences and 42% showed more efficient workflows. Those are GitHub’s observations from its own preview, without a published method; read them as a signal that memory changes behavior, which is exactly why it needs attention.

Two kinds of memory, two levels of review

The most important design choice in the release is easy to miss. Dreaming proposes changes to checked-in skills and instruction files through pull requests, so a team reviews them like any other change. Changes to memories themselves, personal and repository, are made by Copilot directly.

That split is reasonable, and it leaves a gap. Repository memories shape how the agent works for everyone with access, and they are written by the agent from what it observed. If a wrong convention gets remembered (an outdated command, a workaround someone used once, a pattern a single reviewer preferred), it applies quietly to later sessions until someone notices.

We argued that agent memory is enterprise data storage, even when nobody calls it a database, and that the hard problem is what agents should forget. GitHub’s release makes those questions concrete for every repository with Copilot.

What to set before enabling Dreaming

1. Read repository memories periodically. Assign the repository owner to review what Copilot has remembered at the repository scope, the way someone reviews a CODEOWNERS file. Delete what is wrong or stale.
2. Keep durable rules in files, not in memory. A convention that matters (how to run tests, which libraries are banned, what a release requires) belongs in a checked-in instruction file or skill, where changes are reviewed. Memory should hold what is useful but cheap to lose.
3. Check what memory may contain. Make sure memories cannot capture secrets, customer data or internal URLs that should not persist; ask GitHub how memories are scoped across forks and private repositories in your organization.
4. Review Dreaming’s pull requests as policy changes. A proposal turning accepted review comments into permanent guidance is a team rule being written by observation. Ask whether the comments it learned from reflect the team or one prolific reviewer.

The shift is that context is no longer something you write once and retrieve. It is maintained continuously, partly by the agent. The parts that pass through review will stay trustworthy. The parts that do not will need an owner who reads them.