GitHub announced on October 28, 2026 that Copilot Memory is generally available on paid Copilot plans. It lets Copilot retain personal preferences and repository conventions across supported sessions and clients. GitHub also introduced Dreaming in public preview: an opt-in capability that reflects on prior work and can propose updates to memories, repository guidance, and code-review customization.

What changed

According to GitHub, memories can be created across the Copilot app, Copilot CLI, VS Code, cloud agent, code review, Slack, Teams, and GitHub Mobile. A repository memory can capture useful working context such as the right test command or a team convention for how an agent checks its work. Personal memories can be viewed or deleted in Copilot settings; repository memories are subject to repository-access controls.

Dreaming adds a separate, opt-in loop. GitHub says its repository customization can manage repository-scoped memories and propose changes to existing skills and custom-instruction files. Changes to checked-in guidance are proposed in pull requests for team review. Dream runs consume AI credits, and availability and settings vary by capability.

Why this matters for QA engineers

Persistent context can reduce repeated setup and make agent behavior more consistent, especially for test commands, environment constraints, and release rules. But it also creates a new configuration surface: outdated or overly broad memory can silently steer test selection, tooling, and conclusions. Treat memory as versioned test infrastructure, not as an unquestioned convenience feature.

  • Use repository memory for stable, reviewable facts: canonical test commands, supported environments, and explicit release gates.
  • Do not store secrets, temporary incident workarounds, or unverified assumptions as durable context.
  • Confirm that the agent still runs the intended checks when its memory is present, absent, stale, or contradictory.
  • Review any Dreaming-proposed instruction or skill change like a production configuration change.

A focused QA validation plan

  1. Start with a narrow repository pilot. Add only a few durable conventions, such as the smoke-test command and required evidence artifacts. Verify that they improve repeatability without overriding task-specific instructions.
  2. Build context regression cases. Run the same representative bug-fix or test-authoring tasks with correct memory, no memory, and deliberately stale memory. Record whether the agent identifies the conflict and asks for confirmation.
  3. Audit scope and lifecycle. Review who can create, view, change, and delete personal and repository memories. Set an ownership and review cadence for repository guidance.
  4. Gate Dreaming proposals. GitHub says changes to checked-in skills and instructions are proposed through pull requests. Require test evidence, a human owner, and a rollback plan before merging one.
  5. Measure the right result. Track repeatable outcomes such as correct test-command selection, relevant test coverage, false-positive rate, and successful rollback—not only faster completion.

Keep the control boundary clear

Memory and Dreaming can make AI-assisted QA workflows more coherent over time, but neither replaces repository review or independent test execution. The safe operating model is simple: keep durable facts concise, make change proposals inspectable, and validate every behavior change against known cases before it reaches a wider set of repositories.

Bottom line

Copilot Memory gives QA teams a practical way to carry tested conventions across agent sessions. Adopt it deliberately: test for stale-context failure modes, keep repository guidance reviewable, and treat opt-in Dreaming proposals as changes that need the same QA evidence as any other delivery automation update.

Sources