GitHub moved its coding agent into the two places engineering teams already spend their day talking: Slack and Microsoft Teams. Mention @GitHub in either one, and the same agent that runs in the CLI and the cloud starts working — in front of everyone in the channel, not just the person who typed it.
Both integrations are public preview, both are Business and Enterprise only, and both build directly on capability GitHub shipped earlier this month: the cloud agent, the secure sandbox, and the human-approval gate on pull requests.
What the agent actually does from chat
The capability list matches what the cloud agent does elsewhere — chat is a new entry point, not a reduced feature set.
- Answer questions about your code and GitHub activity
- Triage bugs, create and update issues, apply labels
- Investigate failures, implement changes, and validate the work in a secure sandbox
- Open pull requests, with a link back to the conversation that started them
Shared sessions are the actual news
The feature that matters more than the channel it lives in is that sessions are multiplayer. In Slack, the agent can create a dedicated code channel so teammates inspect diffs and review output together rather than one person relaying screenshots. In Teams, GitHub's own framing is direct: a team can hand an action item to the agent mid-meeting and watch the investigation unfold together, asking questions and steering it as it works.
That is a genuine change to how a task starts. Until now, invoking an agent was something one person did, in one tool, and reported back on. A shared session makes the agent's work visible in the same place the decision to do it was made — which is either a real improvement to how teams collaborate on agent-assisted work, or a much wider audience for whatever the agent gets wrong, depending on how well the review step around it holds up.
It does not stay in the chat app
Work continues asynchronously in a secure cloud sandbox after the conversation ends, and the resulting artifacts are reachable from the terminal, the IDE, or the Copilot app. A task assigned during a Teams meeting is still running after the meeting ends, and whoever picks it up next does not need to have been in the room.
That persistence is what makes this more than a chatbot wrapper. It also means a task started casually in a meeting has the same lifecycle as one started deliberately from the CLI — including the same governance controls.
The approval gate is doing real work here
Repository administrators can require additional approval before an agent-created pull request merges. That control existed already, and it is the thing that keeps a mention in a Slack channel from becoming a merge to production.
It is worth confirming this is actually configured before you roll either integration out broadly. A chat mention is a much lower-friction way to start an agent than opening the CLI, and lower friction to start means the review step at the end is carrying more weight than it used to.
What it costs, and what is unstated
Cloud agent and sandbox usage bill separately, and organisations can set usage-based billing budgets at the product or SKU level. GitHub does not publish a specific rate for a Slack or Teams session, so treat the cost as unmeasured until you have run it for a fortnight and checked the per-model token report that shipped on 11 August.
Also unstated: whether this reaches any plan below Business. Both entries name Business and Enterprise only, and both are public preview, so expect the usual gradual rollout and the usual requirement that an administrator turn on the underlying cloud agent policy first.