Microsoft’s Azure DevOps AI Agents: Continuous Planning, Data Hygiene and MCP

The core idea: continuous planning, not a magic chatbot​

The team frames its work as a "Continuous Planning" model, not a single AI product. Planning is treated as an ongoing view of work in progress, upcoming priorities, engineering investment and strategic alignment. It isn't a periodic exercise. According to Microsoft's write-up, these pieces form one operating model:

• planning dashboards
• engineering-capacity visibility
• Azure DevOps (ADO) data quality
• recurring leadership reviews
• monthly delivery reporting
• AI-generated summaries

Martin O'Flaherty, a principal PM manager in IES, says the pressure point is that engineers are scarce. His team has to prioritize incoming work, make trade-offs constantly, and show senior leaders that finite capacity is going to the right places.

Two agents, one feedback loop​

The reporting agent​

O'Flaherty's team built an AI-assisted capability that reviews scenarios completed in the previous month. It groups them under established strategic priorities and produces leadership-ready summaries and visualizations. The source data mostly already lived in systems such as Azure DevOps. The hard part was gathering it and turning it into something digestible.

Early output wasn't always accurate or complete. The team didn't just swap models. It refined the reporting logic, strengthened the planning data, and changed how the tool weighs documented evidence of what was actually delivered. Human review stays in the loop, but Microsoft says manual effort has dropped significantly.

O'Flaherty's headline claim is about cycle time. A report that used to take weeks, with July's results arriving around the end of August, can now go out on the first day of August. Treat that as company testimony. The article gives no methodology and no labor figures.

The "hygiene" agent​

The more interesting piece is a second agent. It continuously checks in-scope scenarios against a defined set of rules, spots data gaps, and prompts team members with specific guidance on fixing them in Azure DevOps.

The lesson O'Flaherty draws is blunt: the AI can only be as accurate as the data in front of it. He says the team was potentially making bad decisions on that data. Fixing quality at the source mattered more than tuning the model that consumed it. Better data produces better summaries, and the summaries expose where data is weak.

That is a familiar pattern for anyone who has run a BI project. Garbage in, polished garbage out, now with nicer formatting.

The source doesn't enumerate the rules, define "in-scope," or give error or review rates. So you can copy the pattern, but not the exact ruleset.

Getting non-experts building agents​

O'Flaherty set out to remove the "you must be an AI expert" barrier. His team made short how-to videos that assume nothing. The examples he gives are installing Visual Studio Code, signing in to GitHub Copilot, and then accessing an MCP server.

Success created a new problem: PMs built multiple agents for similar jobs. The team's answer was a repository where people can upload skills, reuse them, or customize them for their own organization. Microsoft doesn't say what platform hosts it, who can access it, or how contributions are reviewed. Admins will want answers to those questions before copying the idea.

What individual PMs report​

• Astha Sinha (senior PM): She uses Copilot to summarize documents, meeting notes and team tooling. She also built skills that generate reports for different partners on their own schedules. She says she created a custom skill for a business need in under five minutes.
• Owais Khan (senior PM): He gave an agent awareness of the code base and incident reporting, and stitched together logs and data models. He uses it to analyze usage, such as clicks, API use and call patterns, without spending engineering time.
• Nevedita Mallick (principal PM): She uses Copilot Studio to turn rough sketches into clickable mockups, including HTML, CSS and JavaScript. She says this takes minutes or under an hour, where a one-pager plus manual Figma work took a day or two. She also says that asking Copilot to think like a network engineer produced more tailored troubleshooting answers than a generic prompt.

These are personal anecdotes, not benchmarks. The article doesn't claim the generated prototypes are production-ready, and nothing in it validates the accuracy of the usage analysis.

The practical tooling: how the Azure DevOps and Copilot pieces fit​

The Microsoft case study mentions an MCP server in passing. It doesn't say which one the team used. Microsoft's public documentation shows how the same pattern works for any organization.

• The Azure DevOps MCP Server lets AI agents reach Azure DevOps through the Model Context Protocol. According to the project's GitHub page, Microsoft recommends the Remote MCP Server over the local one.
• The Azure DevOps blog says the remote server is hosted, so you don't need to install or host anything yourself. It lists Visual Studio Code with GitHub Copilot as a supported client, and Copilot Studio, Microsoft's low-code platform for building AI agents, can now connect to it too.
• Authentication matters. During the preview, Microsoft said the remote server uses Microsoft Entra for authentication, so your Azure DevOps organization must be backed by Entra. Standalone Microsoft-account organizations aren't supported.
• For the local server, the getting-started guide lists Node.js 20 or later and access to an Azure DevOps organization as prerequisites. Visual Studio users need Visual Studio 2022 version 17.14 or later.
• The documented VS Code flow is short. Start the server from the MCP view, open GitHub Copilot Chat in Agent mode, then try a prompt such as "List ADO projects." You'll be asked to sign in with a Microsoft account that has access to the Azure DevOps organization.

If you run this kind of setup, expect friction. Comments on the Azure DevOps remote-server announcement include a user reporting problems with the MCP server after publishing a Copilot Studio agent to Teams. Anecdotal, but a reminder to pilot before promising anything.

Microsoft's own takeaways​

The article closes with advice that is generic but sensible:

1. Start with repetitive workflows such as reporting, status updates and context gathering.
2. Use existing systems instead of creating new data.
3. Be specific in prompts: audience, formatting and sources of truth.
4. Reuse skills other people have built.
5. Set up governance and sharing practices early, to avoid duplication and errors.
6. Expect a learning curve.

Analysis: what to believe, and what to ask​

What's solid: the structural lesson. Pairing a reporting agent with a data-quality agent is a sound design. It targets the usual failure point, which is inconsistent source records, and not the model.

What's unproven: every number comes from the people running the program. There are no accuracy rates, no review-rate figures, no costs and no comparisons with a control group. The article also says nothing about security, privacy or data-permission controls. That is a notable gap when agents read code bases, incident reports and logs.

Governance: O'Flaherty calls PMs "agent bosses" and a "governance layer." That is an honest admission that the agents' estimates, such as hours per scenario, still need human context about who does the work and how fast. It matters most when outputs influence resource allocation.

For admins: if PMs in your organization start building agents on Azure DevOps data, plan for three things:

• a shared skills repository with ownership and review
• clear Entra-based access scoping
• data-hygiene rules before automated reporting

The Microsoft story is a Customer Zero showcase, and it is promotional by nature. Even so, the data-hygiene and reuse lessons stand on their own, and you can test them in a pilot without buying into the marketing.