GitHub Copilot in Teams: Shared Agentic Work Guide

The short answer

GitHub Copilot in Microsoft Teams is now in public preview, letting teams start a shared Copilot cloud-agent session by mentioning @GitHub in a channel, thread, meeting chat, group chat, or direct message. The agent can use the conversation and repository context to investigate a problem, implement a change, expand tests or documentation, and open a pull request for review.

The important change is not simply that Copilot has another chat surface. It moves agent work into the conversation where requirements and decisions already exist. Everyone in that conversation can add context, correct assumptions, and steer the task while Copilot works asynchronously in a secure cloud sandbox.

This guide explains the workflow, permissions, costs, review controls, and a practical rollout pattern for engineering teams.

What GitHub Copilot in Teams actually does

GitHub’s August 21 announcement describes a collaborative session rather than a private assistant. A participant mentions @GitHub, supplies a task, and Copilot can work from the existing discussion alongside permitted repository context.

Typical tasks include:

• turning a meeting decision into an implementation task;
• investigating a bug while the team discusses its symptoms;
• implementing a small feature from requirements in the chat;
• expanding test coverage or improving documentation; and
• creating or updating a pull request for human review.

The session can continue across GitHub Copilot surfaces. A team can start in Teams, follow progress in the thread, and then inspect the resulting branch, pull request, or artifacts in a terminal, IDE, or the Copilot app.

Microsoft’s Teams announcement and walkthrough independently confirms the public-preview workflow and lists channels, group chats, meeting chats, and one-to-one chats as supported conversation locations.

The request-to-pull-request flow

The useful mental model is a shared control loop: conversation supplies intent, Copilot performs bounded repository work, and normal GitHub review policies decide whether the result ships.

diagram

Visual: original request-to-review workflow based on GitHub’s public-preview documentation. The agent is useful inside the loop, but merge authority remains with people and repository policy.

The sequence matters. A vague request in a busy channel can produce a vague plan, so teams should state the repository, expected behavior, constraints, and acceptance checks. Participants can then refine the task in the same thread instead of reconstructing the entire context in a separate coding-agent prompt.

How to start a session

Before the first request, an administrator needs to enable the relevant Copilot cloud-agent policy. The user then installs the GitHub app for Microsoft Teams and links their GitHub account. In a Teams conversation, mention @GitHub followed by a concrete task. GitHub’s integration documentation is the authoritative setup reference and should be checked for plan and policy changes.

A good first request looks like this:

@GitHub In repository checkout-service, investigate the timeout in OrderClient, add a regression test for the retry path, and open a pull request. Do not change retry limits. Include the test command and any assumptions in the PR description.

That prompt gives the agent a target, a boundary, and a definition of done. Teammates can add logs, links, or product constraints in follow-up messages. Participants with write access can trigger changes; read-only discussion should not be treated as permission to merge code.

Teams versus Slack: what is different?

GitHub announced related public previews for Slack and Microsoft Teams on the same day. The core pattern is similar, but the collaboration context differs. Teams is especially relevant when engineering work begins in meeting chats or Microsoft 365 collaboration spaces; Slack’s experience emphasizes channels and the new Slack Code agent-oriented channel.

Visual: comparison table compiled from the official Teams changelog and Slack changelog. It describes product surfaces, not a performance ranking.

This is complementary to the site’s earlier Slack Code multiplayer AI-coding guide: the Teams angle is the handoff from meetings and operational discussions into a reviewable repository change.

Permissions, sandboxing, and the human review gate

The Teams integration does not replace GitHub authorization. GitHub says actions remain bounded by existing repository permissions and policies. Cloud-agent work runs asynchronously in a secure cloud sandbox, while branch protections and required reviews continue to apply.

Repository administrators can require an additional approval for pull requests attributed to the Microsoft Teams Copilot integration identity. This is a practical control for teams that want agent-authored changes to receive an explicit human sign-off before merge. It is stronger than relying on a prompt such as “never merge risky code,” because the control is enforced by the repository workflow.

Teams should still treat the agent as an untrusted implementation partner:

1. keep production credentials out of prompts and repositories;
2. use least-privilege repository and organization permissions;
3. review dependency changes, generated scripts, and workflow files carefully;
4. require tests that exercise the reported failure, not only a green build; and
5. configure budgets and audit visibility before broad rollout.

For a broader security perspective, compare this workflow with the site’s harness-engineering guide for AI coding agents and GitHub Copilot SDK guide, which cover controls around agent execution and programmatic integration.

Cost and availability

GitHub’s changelog says the public preview is available with paid GitHub Copilot plans. Sessions consume AI credits, and organizational usage is governed by usage-based billing budgets. Cloud sandbox usage is billed separately and can be controlled with product-level or SKU-level budgets.

Because preview entitlements and pricing can change, do not copy a fixed per-task estimate into an internal policy without checking the current GitHub Copilot billing documentation. Instead, measure a pilot by repository, task type, credit consumption, review time, rework, and merged pull requests.

A simple rollout scorecard is:

Visual: original rollout scorecard. These are measurement categories, not claimed benchmark results.

A safe pilot plan

Start with one repository and low-blast-radius tasks: tests, documentation, small bug fixes, and well-specified maintenance. Keep branch protection enabled and require a human reviewer for every pull request. Use a dedicated Teams channel or meeting-chat convention so agent sessions are easy to audit.

For each task, record:

• the original conversation and acceptance criteria;
• the repository and branch involved;
• files changed and tests run;
• reviewer findings and rework; and
• AI-credit and sandbox usage.

After ten to twenty tasks, compare the scorecard with the team’s normal workflow. Expand only if review effort and defect rates remain acceptable. Do not interpret a successful demo as evidence that the agent is safe for unrestricted production changes.

Common failure modes

The agent misunderstood a meeting decision

Restate the decision as explicit acceptance criteria and ask the agent to summarize its plan before implementation. Have a domain owner correct the plan in the thread.

The request lacks repository context

Name the repository, relevant path, expected behavior, and test command. If the task spans repositories, explain the dependency and ownership rather than assuming the agent can infer it.

The PR is technically correct but operationally unsafe

Inspect permissions, secrets, CI workflows, dependency updates, migrations, and generated files separately. A passing unit test does not validate deployment safety.

The feature is unavailable

Check the organization’s Copilot plan, cloud-agent policy, cloud-sandbox policy, GitHub app installation, repository permissions, and the current Teams integration docs. Preview availability can change independently of the chat client.

FAQ

Does Copilot in Teams merge code automatically?

No. It can create or update a pull request, but branch protections, required reviews, and repository administrators remain responsible for the merge decision.

Can multiple developers steer one session?

Yes. The feature is designed as shared agentic work: participants in the conversation can add context and help direct the session.

Is this the same as the Copilot SDK?

No. The Teams integration is a GitHub-managed collaboration surface. The Copilot SDK is for embedding Copilot’s agent runtime into applications and developer tools.

Should teams use it for production migrations first?

No. Begin with reversible, reviewable tasks. Move to higher-impact changes only after measuring defect rate, review burden, permissions, and cost.

Conclusion

GitHub Copilot in Microsoft Teams makes the conversation itself part of the coding-agent workflow. That can reduce context reconstruction and make agent work visible to the whole team, especially when requirements emerge in meetings or operational discussions.

The safe interpretation is narrower than “Teams can now run your engineering department.” It is a public-preview collaboration layer around a cloud coding agent. Treat the agent as an untrusted contributor, keep GitHub’s permission and branch controls in force, require human review, and measure both productivity and review debt before expanding the pilot.

Sources and visual credits

• GitHub Changelog: Shared agentic work with GitHub Copilot in Microsoft Teams — primary source.
• Microsoft Teams Blog: Turn conversations into code with GitHub Copilot — independent Microsoft product-team coverage and walkthrough.
• GitHub Docs: Integrating Copilot cloud agent with Teams — setup and permissions reference.
• GitHub Changelog: The new GitHub Copilot experience in Slack — comparison source.
• Mermaid workflow, comparison table, and rollout scorecard are original editorial visuals by Essam Amdani; product claims are attributed to the linked sources.