Oct 2026 · By Somesh Motupally · 5 min read

From Teams Chat to ADO Work Item: Letting a Copilot Agent Run the Backlog

The problem

The details of what needed doing never lived in Azure DevOps. They lived in three other places: a Teams chat thread where someone typed "we should…", meeting notes that captured a decision nobody transcribed, and an Outlook email with the actual requirements buried in paragraph three. ADO was where work items went to go stale.

Someone had to do the translation — read the conversation, create the work item, fill in the fields, and keep it updated as the discussion evolved. Done by hand, that step happened inconsistently or not at all. The result was a backlog full of incomplete tasks and user stories: titles with no details, details with no owner, decisions from last week's call that never became a work item in the first place. The manual transcription step was the bottleneck, and it never scaled.

Why the manual path couldn't keep up

The manual path breaks down for structural reasons, not lack of effort. Transcription is slow, so it gets deferred; deferred, it gets skipped; and details decay between the conversation and the write-up — by the time someone sits down to create the user story, half the context from the Teams thread is forgotten and the email with the requirements is three scrolls away. The information existed — it was all written down, in the chat, the notes, the inbox. There was simply no bridge between where the work was discussed and where the work was tracked.

The solution: a Copilot agent wired to ADO through MCP

We set up an MCP server exposing Azure DevOps and connected a Copilot agent to it. This isn't a brittle custom integration: MCP is the open standard for connecting agents to tools, and adding an MCP server as a tool in a Copilot agent is a supported path — so the agent gets real ADO operations (search, create, and update work items) through the protocol instead of a one-off custom integration. The agent watches the three places where work actually gets decided — Teams chat conversations, meeting notes, and Outlook emails — and turns what it finds into ADO work items: creating new ones in the dashboard and updating the info and details on existing ones as new information comes in.

The design decision that makes the whole thing work: before creating anything, the agent checks whether a matching user story or task already exists. Only when there is genuinely nothing there does it create a new work item; otherwise the update goes onto the existing item instead of spawning a near-duplicate. That single check is what keeps the backlog organized instead of turning it into a hall of mirrors — and it is the reason the agent has never produced a duplicate.

Results

• A large chunk of manual backlog transcription work simply disappeared — no more end-of-day sessions turning chat threads into work items.
• Tasks and user stories are complete, with the details filled in from the actual conversations instead of from fading memory.
• The backlog stays organized: no duplicates, because the check-before-create runs every single time.

Lessons learned

• Check-before-create is the load-bearing decision. An agent that creates work items without first searching for existing ones will bury you in duplicates. Make the existence check part of the creation path, not an afterthought.
• Feed the agent every source, not just one. Decisions scatter across chat, notes, and email — that is exactly why the manual process failed, and watching only one source would leave the same gaps.
• Let the agent own the details. The value isn't just creating the work item; it's that the info and fields stay complete and current as the conversation evolves. A work item with a title and nothing else is barely better than no work item.

What's next

The backlog now updates itself from the places where the work is actually discussed. The manual transcription step is gone, and work items stay complete because the agent reads the same sources the team already writes in — the discussion is the input, so nothing gets lost between the conversation and the tracker.

If you've wired an agent into your backlog tooling, I'd like to hear what guardrails you put around it — get in touch.