💬 Feedback wanted: GitHub Copilot cross-agent memory (public preview)

[ebndev]

We just launched Copilot memory, a new capability that lets Copilot agents learn from past interactions and share knowledge across your development workflow, starting with Copilot coding agent, Copilot code review, and Copilot CLI.

⭐ This Discussion is your space to try it, push it, and tell us what works and what doesn’t. You can read the technical deep dive on the blog, but we’re especially interested in how memory behaves in real repositories and real workflows.

🧠 What Copilot memory is

Copilot memory allows agents to persist useful knowledge about your repository (like conventions, dependencies, or architectural considerations) and reuse it later across tasks and agents.

Today, memory is available in public preview for all paid Copilot plans and is deployed in:

• Copilot coding agent
• Copilot code review
• Copilot CLI

There are two important characteristics:

• Cross-agent by design: Knowledge learned by one agent (for example, during code review) can be reused by another (like the coding agent).
• Verified in real time: Memories are stored with citations and checked against your code before being applied.

🔍 Where we’d love your feedback

We’re especially curious how memory shows up (or fails to show up) in everyday work. For example:

• Did Copilot correctly learn and reuse a convention in your repo?
• Did it not remember something you expected it to?
• Did memory ever surface something that felt outdated or incorrect?
• Did cross-agent behavior (e.g., code review to coding agent) actually save you time?

If you tried memory on a real pull request or task, we want to hear about it.

▶️ How to try Copilot memory

1. Enable memory in your Copilot settings
2. Use Copilot coding agent, Copilot code review, or Copilot CLI as you normally would
3. Look for moments where Copilot:

• Applies prior knowledge automatically
• Flags inconsistencies based on past context
• Improves over repeated interactions

Full setup details are available in our Docs and a blog about the engineering work behind this.

📣 How you can help

Please comment below with:

• Which agent you used (coding agent, code review)
• The type of repository or workflow
• What Copilot remembered that was helpful
• What it missed or got wrong
• Anything that surprised you (good or bad)
• Suggestions for what Copilot should remember next

Screenshots, prompts, or concrete examples are especially helpful.

🙏 Thank you

Cross-agent memory is a foundational step toward Copilot feeling less like a stateless tool and more like a teammate that actually learns your codebase over time. Your feedback directly shapes how this evolves as we expand memory to more agents and workflows.

We’re excited to hear how it behaves in the wild, and what you want it to learn next.

[beingminimal]

@ebndev This is really a great feature and congratulations on this achievement.

Can you please answer below questions to get some clarity and make this feature more useful?

1. Can we give few files into memory like PRD of repo or vision of repo or anything?
2. Copilot memory will also work with copilot sdk? if yes then how?
3. How we can use this to plan new issues for repo based on memory and current state of code and issues in repo? is there any way through which we can solve this?

[patniko]

Hi @beingminimal -

1. In the future we will move in that direction, but right now it is focused mostly on shared optimizations/learnings. Would be great to use it to drive down need for instruction files, but there is some debate around what should be in a repo since it is helpful to humans vs. what should be in something that is designed mostly for agents.
2. Not currently in the SDK, but we are looking at that right now. Our SDK should be close to the CLI capabilities, but some design goals are different.
3. Curious to know more about what you are looking for on this one. What workflow do you imagine?

Thanks for the questions!

[PureWeen]

I realize this is probably the opposite of why the memory feature exists :-) but it'd be neat if memories good be mined for improvements to Custom Agents/Skills/Instructions/Repository knowledge. It could even be used as a way to find inconsistencies against instructions. A memory could tag that it's out of sync with how instructions dictate knowledge.

Proposal: Provide a path for validated memories to graduate to permanent instruction files.

The Ask

1. Surface memories for review - Let teams see what Memory has learned
2. Graduate to instructions - Convert high-confidence memories into permanent instruction files (.github/copilot-instructions.md, path-specific .instructions.md)
3. Validate instructions against learnings - Flag when agents learn something that contradicts or extends existing instructions

Why Graduation Matters

The 28-day expiration works for evolving patterns. But some learnings should become permanent:

• Memory learns "always check both ISafeAreaView and ISafeAreaView2" repeatedly → should be an instruction
• Memory learns "Platform layer can't reference Controls layer types" → should be in ARCHITECTURE.md
• Memory keeps re-learning the same thing → signal that it's not documented

Without graduation, valuable learnings expire. With graduation, the repository accumulates knowledge permanently.

Why This Matters for Adoption

Instructions are powerful but underutilized. Teams don't iterate on them because:

• No visibility into what agents are learning
• No signal showing "this should be documented"
• Instructions feel like one-time setup, not a living system

Memory → Instructions graduation changes this:

Memory learns X → X persists/repeats → "X should be an instruction"
    ↓
Team reviews → Adds to instructions → Future agents succeed immediately

Every interaction becomes a feedback loop that improves repository context.

The Workflow We Want

Developer: "What has Memory learned that should become instructions?"

Copilot: "These patterns keep appearing:
  1. [repeated] SafeAreaView has v1 and v2 interfaces - always check both
  2. [repeated] Platform layer can't reference Controls layer types
  3. [recent] Specific pattern for this area - may not be general yet
  
  → Recommend adding #1 and #2 to handlers.instructions.md"

Or at the end of any session:

Developer: "Based on what you learned, how could we improve our instructions?"

Copilot: "I discovered that X isn't documented but I needed it. 
         Suggest adding to copilot-instructions.md."

The Gap

What Exists	What's Missing
Copilot Memory (28-day, auto-generated)	Visibility into what Memory has learned
Instruction files (permanent, manual)	Memory → instruction suggestions
Memories auto-expire	Graduation path for validated learnings

Minimal Version

Surface what Memory has learned and suggest which learnings should become instructions. We'll handle the actual file updates ourselves.

References

• Agentic memory public preview (Jan 2026)
• Copilot Memory docs

Related issues:

• CLI #667 - Persistent memory across sessions
• CLI #377 - Memory visibility and /memory command
• Community #162797 - Persistent memory for preferences

Our request extends Memory with: visibility, graduation path to instructions, feedback loop for instruction improvement.

[filip-be]

Hi @ebndev!

I love the memory feature, I believe this can greatly improve agentic behavior!

What worked well

Copilot Coding Agent was unable to restore packages from private feeds.
We have configured some secrets on copilot environment and was able to instruct the agent to use that when restoring packages.

Following sessions use that pattern consistently which proves the memory works well in such case!

What doesn't work well

Most of the time we cannot see memories in repository settings 😢

I was able to see them yesterday:

But today they are not available anymore:

Context

We are using GitHub Enterprise organization.
I have Copilot Business license managed by my organization.
Copilot Memory is enabled.
I am admin of mentioned repository.