GitHub Copilot Memory Is Generally Available. Evaluate Dreaming Separately.

The October 28 announcement says Copilot Memory can carry personal preferences and repository conventions across sessions and clients. GitHub lists creation surfaces including the Copilot app, CLI, VS Code, cloud agent, code review, Slack, Teams, and GitHub Mobile. Actual use still depends on the surface and applicable availability conditions.

Memory learns during ordinary interactions. Dreaming is a separate, opt-in background process that analyzes eligible sessions and review feedback to maintain context. GitHub's documentation explicitly says Memory can work while dreaming is off, and dreaming updates context rather than the underlying AI model.

This distinction gives small teams a useful adoption sequence. First establish whether remembered context helps with repeated work. Consider background curation only after you can recognize useful guidance and identify mistakes. Neither capability establishes that the resulting code is correct.

The Memory documentation distinguishes repository facts, such as test commands and architectural conventions, from personal preferences about how someone works. Repository facts apply to that repository and can be shared with collaborators. Personal preferences can follow a user across repositories.

For example, a preference for concise explanations belongs to the developer. A rule about which test suite covers a module belongs to the project. When asking Copilot to remember something, state that scope explicitly. Otherwise, a useful local convention could be confused with a preference that should travel between projects.

Client differences also matter. The documentation says Copilot code review uses repository facts but does not apply user-level preferences. It also distinguishes the Copilot app's project Memory setting from the shared repository facts and user preferences discussed here. A remembered preference in one context therefore does not prove that every Copilot interaction will use it.

GitHub says Copilot checks a repository memory's citations against the current branch to judge whether the fact still applies. The documentation also warns that this is a model judgment, not an enforced guarantee. Memories may originate from pull requests that closed without merging, and Copilot may fail to recognize outdated information.

Our editorial recommendation is to keep important, stable project guidance in reviewed instruction files. Let memories supplement those files with useful context. GitHub likewise recommends custom instructions for important rules, while noting that neither instructions nor memories guarantee compliance.

A remembered test command is a useful shortcut only if it still exercises the intended behavior. Reviewers should inspect the command and its actual output when assessing a change. Our AI code review workflow provides a separate process for evaluating generated work, regardless of how well the agent appears to remember the project.

The dreaming documentation describes three capabilities: personal memory curation, repository customization, and code review customization. Their outputs have different review paths. Understanding those paths is essential before treating dreaming as an instruction-maintenance assistant.

Dreaming adds, updates, and deletes memories automatically, without approval for each change. Changes to checked-in instructions and skills are proposed through pull requests; those files remain unchanged until a person merges the proposal. Code review customization updates internal review guidance without a pull request. Reviewing proposed file changes therefore covers only part of dreaming's output.

Repository customization can examine tracked guidance such as .github/copilot-instructions.md, AGENTS.md, and files under .github/skills/. Personal curation updates personal memories but does not change personal instruction or skill files. Not every run produces a change or opens a pull request, so an empty pull-request queue is insufficient evidence that nothing happened.

GitHub reports that, among reviewed Copilot CLI preview sessions where the agent used memory, 93% showed better adherence to developer preferences and 42% showed more efficient workflows attributed to memories in context. These are GitHub's findings about that selected set of sessions.

The announcement does not supply a sample size or enough methodological detail to translate those percentages into an expected outcome for a particular team. They do not establish a measured improvement for your repository, other clients, or the separate dreaming preview. We have not independently tested either capability.

A practical evaluation should measure something narrower: whether developers repeat fewer corrections, whether remembered commands remain accurate, and whether reviewers can trace guidance to current project evidence. Those observations would be more useful for an adoption decision than assuming the announcement's percentages predict local results.

Our proposed pilot uses one repository and a recurring, bounded task. Choose a convention that is easy to verify, such as the correct unit-test command. Record the current instruction file and expected behavior, then observe whether Copilot uses accurate context in later sessions. If you work across clients, evaluate each relevant client rather than assuming identical behavior.

If dreaming is available to your account, evaluate its output separately. For an instruction-change pull request, inspect whether the proposed rule matches current code and whether it generalizes beyond the conversation that prompted it. Also inspect available memory and run outputs; a file diff alone cannot account for automatic memory changes.

Stop expanding the experiment if stale guidance repeatedly survives or reviewing proposed guidance creates more work than it removes. Use our regression-testing guide to check resulting code behavior. Adoption should depend on repeatable, observable usefulness: accurate context, understandable instruction changes, and code that passes the relevant checks.