How Do You Run AI Coding Agents from Azure DevOps and Microsoft Teams?

To run AI coding agents from Azure DevOps and Microsoft Teams, connect both to a cloud software factory. Assigning or @mentioning the factory on an Azure DevOps work item or pull request, or @mentioning its app in a Teams channel, starts a governed cloud run. Agents work under the factory's own Microsoft Entra identity, open pull requests in Azure DevOps, and report back in the Teams thread.

What changes when agents start from Azure DevOps and Teams?

Most coding agents run on a developer's laptop and start when that developer types a prompt. In a Microsoft shop, the bug report lives in a Teams thread, the tracked work in Azure Boards, the code in Azure Repos, and the agent somewhere else, with whatever access its developer happened to be signed in with.

A cloud software factory closes that gap. It is an automation loop around the SDLC (triage, spec, implement, review, verify, ship, monitor) where cloud agents do the repeatable work and people approve the decisions that matter. Every trigger lands with the same orchestrating agent, the foreman, which decides whether a request needs triage, a spec, an implementation, or a review.

Connecting the Microsoft tools gives that factory two front doors with different jobs:

• Microsoft Teams is for conversation. Bug reports, "can someone look at this?" requests, and follow-up questions answered in the same thread.
• Azure DevOps is for tracked work and code. Work items that should leave an audit trail, and pull requests that need review or follow-up commits.

Which Microsoft surface should start which work?

Pick the trigger by the shape of the work, not by which tool is most popular on your team.

Two practical rules fall out of this. Use Teams when the request still needs a conversation to become a task. Use Azure DevOps when the task is already defined and someone should be able to audit it later.

How do identity and access work in a Microsoft tenant?

Intake access and code access are separate grants, and that is where Microsoft-stack teams should spend their security review.

Azure DevOps. Each factory gets a dedicated Microsoft Entra identity: a separate Entra application and service principal that authenticates its Git and pull request operations, with access only to the repositories you select. An Azure DevOps Manager identity, approved once, creates and maintains those factory identities in your tenant. The factory acts as its own principal instead of borrowing a developer's credentials.

Microsoft Teams. The app works only in the channels you configure (standard and shared channels; private channels and direct messages are not supported). A person can start work only after linking a Microsoft account that maps to an active member of the factory's Warp workspace.

Filters decide when work starts, not what an agent can reach. Narrowing an automation to one team, channel, work item type, or label controls which events start runs. Access comes from what you authorize: the repositories granted to the factory identity and the channels where the app is installed.

Who has to approve what?

Rollouts stall when the right administrator is not in the room. This is the approval sequence, so you can line people up before you start:

Steps 1 and 2 happen once per tenant and organization, and a setup link lets each administrator finish their step without an account on the platform. Budget licenses too: the Manager and every factory identity each use one Azure DevOps Basic seat.

What do most teams get wrong?

They assume Azure DevOps Server works like Azure DevOps Services. The first-class integration, with work item and pull request events and a per-factory identity, covers hosted Azure DevOps Services at dev.azure.com. A self-hosted Azure DevOps Server repository can still be connected with a personal access token for repository access, but it receives no provider events.

They stack triggers on one channel. An app mention is also a posted message. If one Teams channel has both an "app mentioned" and a "message posted" trigger, a single mention starts two runs. Give each channel one trigger.

They wire every door on day one. Teams, Boards, and Repos triggers into a factory with no reliable workflow only multiply the ways a half-finished loop starts. The broader trade-offs are covered in How Do You Send Work to a Software Factory from Slack, Linear, GitHub, or Your Terminal?

How Warp fits

Warp provides the control plane for operating a cloud software factory, not another coding agent alongside Claude Code, Codex, or Cursor. Warp Factories now supports Microsoft Teams and Azure DevOps Services natively, next to Slack, GitHub, GitLab, Linear, and Jira, so a team can run one factory across the tools it already uses.

Because factories are defined as code, the Microsoft integrations live in the same version-controlled definition as your agents, skills, and automations, as described in Terraform for agents: how we define our software factory in code. An automation that hands tagged Azure DevOps bugs to the factory looks like this:

---
enabled: true
agent: foreman
triggers:
  - provider: azure_devops
    event: work_item_labeled
    filter:
      work_item_types: [Bug]
      labels: [factory]
---

Triage the tagged bug. If it is in scope, fix it and open a pull request for human review.

Each agent can use a different model or harness, including Claude Code or Codex, and the control room shows every run, its cost, and its status. Warp reports that its own team automates 20–30% of its PRs through factories, per A guide to cloud software factories for engineering leaders, which is a reminder that the goal is a growing share of governed work, not full autonomy on day one.

Start with one workflow

Pick one workflow with a clear input, a measurable outcome, and a human fallback. A good first choice for Microsoft teams: route Azure DevOps bugs carrying one tag to the factory, require human review on every pull request it opens, and track acceptance rate and cost per merged pull request for a month. Add the Teams channel once that loop is reliable. The crawl, walk, run model describes how to expand from there.

To see the integration in practice, visit Warp Factories for Microsoft Teams and Azure DevOps.