Introduction
Software development often starts with a conversation. A developer reports a bug in a Teams channel, another developer explains the expected behavior, and someone eventually creates an issue before the work reaches the codebase.
GitHub Copilot's integration with Microsoft Teams changes that workflow. Teams conversations can now become the starting point for Copilot cloud agent sessions, allowing developers to move from discussion to investigation, planning, implementation, and pull requests without manually transferring all the context into another tool.
The important part is not simply that Copilot can generate code from Teams. The more interesting change is the connection between team discussion and agentic software development.
The GitHub integration for Teams is currently in public preview and supports initiating and steering Copilot cloud agent sessions from Teams conversations. GitHub documents the integration as available with paid Copilot plans, with cloud sandboxing required for Copilot cloud agent.
What Is the GitHub Copilot Teams Integration?
The integration connects Microsoft Teams conversations with GitHub Copilot cloud agent.
Instead of taking a conversation such as:
"We need to add retry handling to the payment API.
It should handle transient failures and include tests."
and manually converting it into a GitHub issue, a developer can mention @GitHub in a Teams conversation and ask Copilot to investigate or implement the task.
Copilot can use the Teams conversation as context, work asynchronously in a secure cloud environment, make changes, run tests and linters, and produce development artifacts such as pull requests.
A simplified workflow looks like this:
Teams Conversation
|
v
@GitHub Task
|
v
Copilot Cloud Agent
|
+----> Repository Analysis
|
+----> Implementation Plan
|
+----> Code Changes
|
+----> Tests / Linters
|
v
Pull Request
|
v
Developer Review
This is fundamentally different from treating an AI assistant as a simple code-completion tool.
How the Workflow Works
The workflow can be broken into several practical stages.
1. Start With the Team Conversation
Imagine a development team discussing an API issue in Teams:
Developer A:
The Orders API returns 500 when the inventory service times out.
Developer B:
We should probably add retry handling for transient failures.
Developer C:
Agreed. It should also have tests for timeout and successful retry.
Developer A:
Let's implement it in the Orders service.
Instead of creating a separate prompt containing all of this information, a developer can mention the GitHub app:
@GitHub Investigate this issue and implement retry handling
for transient inventory-service failures in the Orders API.
Add appropriate tests and create a pull request.
Copilot can use the conversation as part of its context. GitHub specifically notes that, when Copilot is invoked from a Teams thread, the conversation can become the decision-making context for the resulting work.
2. Copilot Investigates the Repository
Copilot cloud agent can research the repository before making changes.
For example, it may need to determine:
Where the Orders API is implemented
Which HTTP client is being used
Whether retry infrastructure already exists
Where integration tests are located
What coding conventions the repository follows
Which configuration files control retry behavior
This repository-aware step is important because production code changes rarely exist in isolation.
3. Copilot Implements the Change
After understanding the repository, the agent can modify the relevant files.
For a .NET application, a simplified implementation might look like:
builder.Services.AddHttpClient<IInventoryClient, InventoryClient>()
.AddStandardResilienceHandler();
The exact implementation depends on the application's architecture and the libraries already used by the repository. The important point is that the agent should adapt its changes to the existing codebase instead of blindly inserting a generic retry implementation.
4. Tests Should Be Part of the Request
A good agent request should explicitly include validation.
For example:
Implement the retry behavior and add tests covering:
1. Successful request without retry.
2. Transient failure followed by success.
3. Repeated transient failures.
4. Final failure after the retry policy is exhausted.
This gives the agent a much more concrete acceptance criterion.
Copilot cloud agent can use an ephemeral development environment to explore the code, make changes, execute automated tests and linters, and prepare the resulting work for review.
Starting a Copilot Session From Teams
The basic interaction is straightforward.
A developer can mention:
@GitHub
and provide a task.
GitHub's documentation also supports specifying a repository and branch when required:
@GitHub Create a pull request for the API retry changes
repo=contoso/orders-api
branch=main
The default repository can also be configured for a Teams channel. If a repository or branch is not specified, Copilot can use the channel's configured repository and its default branch.
After the session begins, developers can continue steering the work in the same Teams thread.
For example:
@GitHub
The retry policy should only apply to transient failures.
Do not retry validation errors. Add a test for this behavior.
This makes the Teams thread more than a notification surface. It becomes part of the development interaction.
Turning Conversations Into Pull Requests
One of the biggest advantages of this workflow is the reduced distance between a technical conversation and a code change.
A traditional workflow might look like:
| Stage | Traditional Workflow |
|---|
| Discussion | Teams |
| Requirement | Manually documented |
| Issue | Created in GitHub |
| Context | Copied into issue |
| Development | IDE |
| Testing | CI/local environment |
| Review | Pull request |
| Follow-up | Teams + GitHub |
With Copilot in Teams:
| Stage | Agentic Workflow |
|---|
| Discussion | Teams |
| Requirement | Teams conversation |
| Investigation | Copilot |
| Implementation | Copilot cloud agent |
| Testing | Agent environment |
| Pull request | GitHub |
| Iteration | Teams + GitHub |
The goal is not to eliminate GitHub or the developer's IDE. Instead, it removes unnecessary context switching during the early stages of development.
GitHub describes this as moving directly from discussion to investigation and implementation while allowing teammates to collaboratively steer the agent.
Security and Permission Considerations
This is where engineering teams should be careful.
Giving an AI agent access to a repository is fundamentally different from asking an AI assistant to explain a code snippet.
GitHub's Teams documentation states that only users with write access to a repository can trigger Copilot to make changes, although other conversation participants can provide input to the discussion.
The integration also requires permissions for repository content, issues, pull requests, actions, and workflows depending on the functionality being used.
A useful permission model is:
Teams User
|
| Has write access?
|---- No ----> Can provide discussion context
|
Yes
|
v
Copilot Session
|
v
Repository
|
v
Pull Request
|
v
Human Review
Teams administrators and repository owners should therefore establish clear rules around:
Which repositories can use coding agents
Who can trigger agent sessions
Whether cloud sandboxing is enabled
Which branches can receive changes
Required pull request reviews
Secrets and sensitive repository content
Repository rulesets and CI checks
For shared Teams contexts, GitHub notes that pull requests created by Copilot use the app's identity rather than an individual user's identity. Repository rulesets can therefore result in an additional approval requirement before merging.
Context Is Powerful, but It Can Also Become a Problem
The most useful feature of the integration can also become one of its biggest risks: conversation context.
When Copilot is invoked in a Teams thread, the conversation can be used as context for the task. GitHub specifically warns that the entire thread may be captured and that this context can be stored in generated artifacts.
Consider a large channel conversation:
Developer discussion
|
+-- Bug description
+-- Old assumptions
+-- Unrelated discussion
+-- Customer information
+-- Temporary workaround
+-- Final requirement
Sending the entire thread to an agent may introduce unnecessary information.
For sensitive or focused tasks, a direct conversation with the GitHub app or a clean thread can provide a tighter context boundary. GitHub explicitly recommends limiting context when appropriate by using a direct message rather than a large conversation thread.
Writing Better Agent Requests
The quality of the result still depends heavily on the quality of the task description.
A weak request:
@GitHub Fix the Orders API.
A better request:
@GitHub Investigate the Orders API timeout issue.
Requirements:
- Identify where inventory-service calls are made.
- Handle transient failures with the existing resilience approach.
- Do not retry validation or authentication failures.
- Add unit or integration tests for retry and final-failure behavior.
- Follow the existing project conventions.
- Run the relevant test suite.
- Create a pull request with a concise summary.
The second request provides:
Scope
Expected behavior
Constraints
Testing requirements
Repository conventions
Delivery expectations
That structure is much more useful for an autonomous coding agent.
Advantages
Reduced Context Switching
Developers can begin work from the conversation where the problem was originally discussed instead of manually copying requirements into another system.
Collaborative Agent Steering
Multiple team members can contribute context and corrections to an agent session. This is particularly useful when the original requirement is incomplete or evolves during implementation.
Asynchronous Development
The cloud agent can continue working while developers move on to other tasks. The result can then be reviewed in GitHub, a terminal, or an IDE.
Better Connection Between Discussion and Code
The Teams thread provides a record of the reasoning that led to the implementation request, while the pull request provides the actual engineering artifact.
Faster Issue-to-PR Transition
For well-defined maintenance tasks, the workflow can reduce the manual work involved in translating conversations into issues and implementation instructions.
Disadvantages and Limitations
Public Preview
The Teams integration is currently documented as being in public preview and is therefore subject to change.
Context Can Be Too Broad
A large Teams thread can contain irrelevant or sensitive information. Developers need to be deliberate about where they invoke the agent.
AI-Generated Changes Still Require Review
An agent can investigate code, modify files and run tests, but that does not make its implementation automatically correct.
Code review remains essential, particularly for:
Authentication
Authorization
Database migrations
Financial logic
Infrastructure
Security-sensitive code
Production configuration
Permission Complexity
Enterprise environments need to consider Teams permissions, GitHub permissions, Copilot policies, repository access, cloud sandbox policies, and branch protection.
Common Mistakes
Asking for Too Much in One Prompt
Avoid turning a large product requirement into one autonomous task.
Instead, break it into smaller deliverables:
1. Investigate
2. Create implementation plan
3. Implement
4. Add tests
5. Run validation
6. Create pull request
Skipping Acceptance Criteria
"Fix the bug" is not a useful engineering specification.
State the expected behavior and failure conditions.
Trusting Tests Too Much
Passing tests do not prove that the implementation is architecturally correct. Tests validate the scenarios they cover, not every possible production condition.
Allowing Unrestricted Repository Changes
Agentic workflows should still operate within normal repository controls such as protected branches, required reviews, CI validation, and security scanning.
Troubleshooting
If Copilot does not start from Teams, check the following:
| Problem | What to Check |
|---|
| GitHub app unavailable | Verify the Teams app is installed |
| Authentication failure | Connect the GitHub account |
| Agent cannot modify repository | Verify write access |
| Cloud agent unavailable | Check Copilot and cloud sandbox policies |
| Wrong repository selected | Configure or explicitly specify the repository |
| Poor implementation | Improve task context and acceptance criteria |
| Irrelevant output | Use a cleaner Teams thread or direct message |
| Pull request cannot merge | Check repository rulesets and required approvals |
GitHub's documented prerequisites include a GitHub account with a paid Copilot plan, a Teams account, Microsoft Teams Public Developer Preview, and enabled cloud sandboxing for Copilot cloud agent. Organization or enterprise administrators may also need to enable the relevant policies.
Best Practices for Production Teams
For teams experimenting with this workflow, a few practices can make a significant difference.
Start with low-risk maintenance tasks. Use documentation updates, tests, small bug fixes, and isolated refactoring before delegating critical production changes.
Keep prompts specific. Include the repository, expected behavior, constraints, tests, and definition of done.
Use clean conversation threads. Avoid mixing unrelated discussions with an agent task.
Keep human review mandatory. Treat the pull request as the normal engineering control point.
Use repository protections. Branch rules, required reviews, CI checks, and security scanning should continue to enforce organizational standards.
Measure the workflow. Instead of assuming that AI makes development faster, measure practical indicators such as time from discussion to PR, review iterations, failed CI runs, rework, and escaped defects.
Review permissions before rollout. Teams integration should be introduced with the same security discipline used for other developer automation.
Conclusion
GitHub Copilot in Microsoft Teams is interesting because it connects two activities that have traditionally been separated: team conversation and software implementation.
A developer can discuss a problem in Teams, bring Copilot into the conversation, provide additional requirements, let the cloud agent investigate and implement the task, and then review the resulting pull request in GitHub. The agent can work asynchronously and the team can continue steering the work from the same conversation.
The real value is therefore not simply "coding from Teams." It is the possibility of creating a more continuous workflow:
Conversation
↓
Context
↓
Investigation
↓
Implementation
↓
Testing
↓
Pull Request
↓
Human Review
For development teams, that makes Copilot in Teams worth evaluating as an agentic development workflow, not merely another AI coding assistant. The strongest implementations will still combine AI automation with clear requirements, repository controls, automated validation, and human engineering judgment.