Adding a Coding Agent to a Microsoft Teams Channel

Adding a coding agent to a Microsoft Teams channel solves a specific, recurring problem: the gap between where developers talk about work and where that work gets written. A developer flags a bug or sketches a feature in a Teams channel, and until recently, turning that conversation into code meant opening a separate IDE or chat tool and typing the same context in again. That round trip wastes time and loses detail every time it happens, since a conversation thread rarely survives translation into a terse prompt.

The fix is to put the coding agent where the conversation already happens. Coding agents can now work asynchronously across multiple files and multiple steps without a developer walking them through each one, and Teams already functions as the place where decisions about that work get made. GitHub, Atlassian, Cursor, and Linear have each built integrations that let a person @mention an agent directly from a channel, a group chat, or even a meeting, so the pattern of agents sitting inside everyday team chat is already running in production, not something still being tested. Once the agent sits in the channel, it reads the same discussion the team is having and acts on it without anyone needing to restate a word of it.

The three integration paths available

No single setup process covers every team, because the right approach depends on which tools a team already runs, how much control over the agent's behavior it needs, and how much time it can spend building something from scratch. Three paths exist today, and each solves the problem differently.

The first is a first-party integration: GitHub Copilot, installed straight into Teams and tied to repositories a team already works in. The second is a partner agent, installed from the Teams app ecosystem and built by a company other than Microsoft, among them Cursor, Linear, and Atlassian's Rovo. The third is a custom agent, built in-house with Microsoft's own developer tools and shaped around whatever internal systems or workflows a team runs that no off-the-shelf agent touches.

GitHub Copilot fits teams that already keep their code in GitHub and want channel conversations to turn directly into pull requests without adding a new vendor or a new codebase relationship. Partner agents fit teams whose work already runs through a particular tool, Jira and Confluence for project tracking, or Cursor's own IDE environment for writing code, and who want an agent that understands that tool without anyone writing a line of integration code. A custom agent fits teams whose coding workflow touches internal systems, proprietary codebases, or processes specific enough that no marketplace agent handles them, and who have engineering time to spend building one. None of these three paths is a lesser version of another; they answer different questions about what a team already has and what it's willing to build.

Setting up GitHub Copilot as a coding agent in a Teams channel

Getting GitHub Copilot running as a coding agent inside a Teams channel takes a short installation process, but getting it running safely depends on two things a team has to get right: who has write access to the repository, and a clear understanding of what the agent is and isn't allowed to do once it's in the channel.

Start by installing the GitHub app for Teams from the Teams app store. This is the newer, coding-agent-capable integration, a separate app from "GitHub Notifications," the name GitHub gave its older Teams app once the new one shipped; teams running the old app need to install the new app alongside it, since it won't upgrade in place. After installing the app, authenticate it and connect it to the GitHub organization and repository the team actually works in. From there, add the app to the specific Teams channel where the work happens, which gives the agent access to that channel's conversation history and context going forward.

Using the agent day to day is as simple as @mentioning @GitHub in a channel message or a thread, which starts a Copilot session. Anyone in that conversation, regardless of their GitHub permissions, can ask the agent questions, add context, or help steer what it works on next. Code changes are a separate matter: only participants with write access to the connected repository can trigger Copilot to actually make a change, so a read-only participant can shape the discussion but can't set the agent loose on the codebase.

The agent's output has a built-in limit that matters for how a team plans its review process. When Copilot isn't already working on an existing pull request branch, it creates a new one named with a copilot/ prefix. It cannot mark its own pull request "Ready for review," approve it, or merge it. A human with write access has to take that last step every time. No code the agent touches reaches production without a person deliberately signing off on it.

Setting up a partner coding agent (Cursor or Atlassian Rovo) in a Teams channel

Partner agents install the same way GitHub Copilot does, through the Teams app store, and they're triggered the same way, through an @mention in a channel. What differs between them is the scope of work each one is actually built to do once it's installed.

Cursor's agent is built for writing and fixing code directly from a Teams conversation: fixing bugs, investigating how existing code behaves, and shipping features without a developer leaving the channel to open an IDE. Setting it up follows the same three steps as GitHub Copilot: install it from the Teams app store, connect it to the relevant codebase, and add it to the channel where the team wants it working. Once installed, it takes on the identity of that channel, pulling in context from the conversations, shared files, meeting notes, and project plans already sitting there.

Atlassian's Rovo works differently, and teams evaluating it should be clear about what it is before deciding whether it's the right fit. Rovo brings Jira and Confluence context into a Teams conversation, letting users update issues and draft content without switching tools. Rovo doesn't write or commit code like GitHub Copilot or Cursor do; its value for a team whose coding work runs through Jira tickets is that it connects the Teams conversation to those work items, to Confluence documentation, and to other sources a team has linked in, so a channel discussion about a bug can update the Jira ticket tracking it without anyone leaving the chat. Atlassian has also opened its Teamwork Graph, the system underlying Jira and Confluence context, to third-party AI agents through a standard, compatible interface. In practice, that means a coding agent other than Rovo could, in principle, query that same Jira and Confluence context directly, rather than requiring Rovo to sit in the middle of every exchange.

Building a custom coding agent for Teams with the Microsoft 365 Agents Toolkit

Building a custom coding agent is a path for development teams, not for IT admins or end users looking for something off the shelf, and it only makes sense when a team's needs genuinely outstrip what GitHub Copilot, Cursor, or Rovo already offer. The tool for this job is the Microsoft 365 Agents Toolkit, which grew out of the earlier Teams Toolkit and gives developers two different kinds of agents to build.

A Declarative Agent tailors Microsoft Copilot by declaring instructions, actions, and knowledge pulled from specified APIs, without requiring a team to build or run its own language model. A Custom Engine Agent goes further: it can run on any large language model a team chooses, with its own orchestration logic and business rules built around it. Which type a team picks depends on whether it wants to extend Copilot's existing behavior or build something closer to a standalone system.

The toolkit removes a lot of the setup work that used to sit between an idea and a working prototype. Instead of juggling separate tools for app registration, credential management, manifest creation, and deployment, a developer building through the Agents Toolkit gets that work handled through a "zero-configuration" approach that wires up Microsoft 365 identity, cloud storage access, and data from Microsoft Graph automatically. The Teams developer CLI handles routine setup tasks like app registration directly, cutting down on the repetitive back-and-forth that used to eat time before any actual agent logic got written. The underlying Teams SDK is generally available in Python, JavaScript, and C#, so teams can build in whichever language their existing codebase already uses.

Once built, a custom agent in Teams can do more than answer questions in a channel. It can send a targeted message to one person in a group channel without cluttering the conversation for everyone else. It holds onto context across a session and tracks progress over time, contributing to a thread as work moves forward. It can use quoted replies to ask for clarification or flag something for approval, putting a human decision directly into its workflow. It can also be invoked through slash commands or respond to emoji reactions, small interaction patterns that make it feel like another participant in the channel.

Getting started requires a Microsoft 365 work or organization account where the app can be registered and deployed, an Azure account and subscription to run the underlying resources, and Node.js as the runtime environment the toolkit depends on.

For teams without developers to spend on this, Microsoft Copilot Studio offers a no-code alternative. It gives non-developers a graphical interface with built-in natural language processing to create, test, and publish an agent directly to Teams, no code required. One date matters here: after the end of June 2026, the Copilot Studio for Teams app will no longer support creating classic chatbots, and the app will redirect to the Copilot Studio web app instead. Copilot Studio fits teams that need a Q&A or workflow agent, something for HR questions or IT helpdesk requests. It does not reproduce the code-execution ability built into GitHub Copilot or Cursor, so a team evaluating it for development work should treat it as a different category of tool.

Security and permission decisions that must be made before the agent goes live

Installing any of these three paths takes well under an hour. Deciding how the agent should be scoped and governed takes considerably longer, and skipping that step is the most common way a team ends up with an agent it can't fully trust in a live channel.

For GitHub Copilot specifically, the decision that matters most is which repositories the Teams app can actually see. The connection should be limited to the repositories relevant to that channel's work rather than opened up to an entire GitHub organization, since every repository the app can reach is a repository the agent could potentially touch once someone with write access triggers it. A team running several channels for several projects should resist the shortcut of connecting everything once and sorting out scope later.

The agent's own behavior offers a second layer of protection, but it isn't a substitute for a team's existing controls. Copilot's habit of creating a new copilot/ branch rather than committing to an existing one, combined with its inability to approve or merge its own pull requests, means a human always stands between the agent's work and production code. That built-in constraint only holds if a team's branch protection rules actually apply to those agent-created branches the same way they apply to a human developer's branch. A team that assumes the agent's limitations alone are enough protection, without confirming its existing review and protection rules cover the branches Copilot creates, is leaving a gap that has nothing to do with the agent's capability and everything to do with configuration a person has to check.