Copilot Memory with Azure DevOps: What Carries Over
GitHub Copilot can read Azure DevOps work items through a connected MCP server, but that connection is not the same as memory between sessions. Here is what actually carries over, what does not and how to keep the project context that matters in a durable record outside Copilot.
Updated 6 min read
GitHub Copilot can read Azure DevOps work items through a connected MCP server, which means it can look up a work item during a session when you ask it to. That is not the same as memory: when the session ends, Copilot does not retain what it read, and the next session starts fresh. The distinction matters because many developers expect that connecting Copilot to Azure DevOps means Copilot now knows their backlog. A tool like fenbs fills a different gap: it keeps the agreed decisions, task context and source links that should inform every session, not just the ones where you remember to ask.
What GitHub Copilot can read from Azure DevOps
GitHub Copilot supports MCP server connections in its chat interface. Microsoft has made an Azure DevOps MCP server available that exposes work items, sprints, repositories and pipelines as tools Copilot can call. When you connect this server, Copilot can look up a specific work item by ID, list items in a sprint or search the backlog during a session.
This is a read-and-query capability, not a background sync. Copilot does not automatically load your Azure DevOps backlog when you open a chat. It reads what you ask it to read, during the session where you ask. Check GitHub's Copilot documentation (opens in a new tab) for current instructions on adding MCP servers, and Microsoft's Azure DevOps documentation (opens in a new tab) for the MCP server setup.
How the connection works in practice
Once you have configured the Azure DevOps MCP server in Copilot, a session with access to the server can call the server's tools when you reference a work item or ask a question about the backlog. Say you ask Copilot to help you implement the feature described in work item 4521: Copilot calls the server, reads the work item, and uses its content as context for its response.
The call happens within the session. The work item content is part of that session's context window. When the session ends and you open a new chat, that content is gone from Copilot's context. You can ask Copilot to look it up again in the new session, but it will not know you already discussed it unless you tell it or it reads the work item history.
For related Copilot and Azure DevOps setup details, see the guide on GitHub Copilot with Azure Boards and the broader Azure DevOps MCP server guide.
What Copilot does not retain between sessions
Copilot does not store what it discussed in previous sessions by default. The context window is cleared between conversations. This means that decisions you discussed with Copilot, the reasoning behind a technical choice or the agreed approach to a problem do not carry forward automatically.
Work items in Azure DevOps do carry forward, because they live in Azure DevOps, not in Copilot. If a developer updates a work item description or adds a comment during a session, that update is in Azure DevOps for the next session to read. But the decisions made in conversation, the approach Copilot suggested, and the constraints discussed in the chat are gone unless someone records them elsewhere.
GitHub Copilot has introduced memory features in some contexts. Check GitHub's Copilot documentation (opens in a new tab) for the current state of what Copilot retains, because the feature set changes frequently. Even where memory features exist, they are typically personal to one user and stored within Copilot, not accessible to a colleague or a different AI tool.
Project knowledge versus tool connections
It helps to separate two things that often get conflated. A tool connection gives Copilot access to query a system during a session. Project knowledge is the accumulated context that should inform every session: what was agreed, what the team decided, what the approach is and why.
A tool connection to Azure DevOps makes the backlog queryable. It does not supply project knowledge. The decision to use a particular architecture, the reason a certain dependency was avoided, the rule about which work items require design review — none of those live in the work item titles and descriptions in a way Copilot will automatically surface.
For project knowledge to be available, someone has to record it somewhere the assistant reads at the start of a session, and maintain it as decisions change. For a broader view of what it means to give Copilot access to project context, see the guide on GitHub Copilot memory and Microsoft Copilot memory.
Keep agreed decisions and source links across Copilot sessions
Connect fenbs to Copilot over MCP from Integrations. At the start of each session, Copilot reads the project rules, Where we left off and the current tasks. It can also read source links — the Azure DevOps work items, documentation pages and decisions that matter to this project. At the end of a session, it saves what was completed and what comes next. The project knowledge survives the session boundary, regardless of whether the next session uses Copilot, Claude or another connected tool.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
What to keep in fenbs alongside Azure DevOps
Azure DevOps holds the work items, sprints, code and pipelines. fenbs holds the decisions and context that explain how to work with them correctly. Keep these kinds of things in fenbs, linked to the Azure DevOps work items they relate to:
- Architecture decisions: what was chosen, the alternatives considered, the reason and who approved it.
- Standing rules: items that must always be reviewed before merge, dependencies the team has agreed to avoid, mandatory test steps.
- Lessons learned: problems that occurred in a past sprint and what should be done differently next time.
- Where we left off: what is in progress at the end of a sprint or work session, what is blocked and what needs a decision.
How to do this with fenbs
- Create a free account and add a project for the Azure DevOps work area you want to support.
- Write the architecture decisions, standing rules and constraints as Decisions and rules. Link to the Azure DevOps work items or wiki pages where the technical detail lives.
- Connect GitHub Copilot or another supported AI assistant to fenbs over MCP from Integrations. Ask the assistant to read the project context at the start of each session.
- After a sprint or a significant session, update Where we left off with the current task status and what the next session needs to address.
- Add a Lesson learned when a problem occurs that should change how the team approaches similar work items in the future.
fenbs does not replace Azure DevOps for tracking work items, code or pipelines. It holds the human-approved context that makes an AI assistant effective across sessions. For DevOps tool comparisons that include AI assistant support, see DevOps tools.