Before You @GitHub in Standup Chat — Teams Shared Agents and the Trust Boundary

A standup ends in meeting chat. An action item lands in the thread. Someone types @GitHub. Investigation starts before the call hangs up, and a PR link appears under the same conversation.

Core takeaway: Shared Copilot agent sessions in Microsoft Teams collapse “meeting context → coding work,” but the operational question is still trust: only write-access participants can trigger changes, and you can require an extra approval for PRs attributed to the Teams Copilot integration identity.

On 2026-08-21 GitHub shipped shared agentic work with GitHub Copilot in Microsoft Teams in public preview. The same day brought the new Slack Copilot experience. The pitch rhymes; the collaboration surface and the checklist do not.

Why it matters

Agents already live in IDEs, CLIs, and cloud VMs. The bottleneck is where decisions happen. Repro notes, scope calls, and “who owns the fix” still finish in Teams (or Slack). Waking a cloud agent from that thread cuts paste-back cost — and simultaneously exposes an old fact: chat participants are not the same set as repository writers.

GitHub’s changelog and docs describe a consistent pattern:

• Anyone in the conversation can ask questions, add context, and help plan or steer.
• Only participants with write access to the target repository can trigger Copilot to make changes.
• Work continues asynchronously in a secure cloud sandbox; follow the channel thread, then continue in the terminal, Copilot app, or IDE.
• For org/enterprise users, an admin must enable Copilot cloud agent and cloud sandboxes (docs say those policies share configuration).
• Cloud agent sessions consume AI credits (usage budgets apply). Cloud sandbox usage is billed separately and can be capped with product- or SKU-level budgets.

Meeting-chat handoff is the seductive part. If you assume “everyone on the call” equals “everyone who can merge,” the preview week will teach you otherwise.

How it compares (Slack Code vs Teams threads)

Slack’s same-day launch centers on Slack Code: a dedicated code channel where the session is steered. Teams’ announcement and docs lean on the existing channel / thread / DM / meeting chat surface.

Both products sell “summon the agent from chat.” Operators should care whether the session room is isolated (Slack Code) or whether meeting chat is a first-class summon surface (Teams). Teams-heavy orgs will treat “investigate during standup” as the default story — which means default repository and channel membership need a spreadsheet before the first @GitHub.

Code / config example

Docs show a straightforward mention pattern:

@GitHub Investigate the timeout path from standup,
open a repro PR against repo=acme/api branch=main

If the channel has a default repository, you can omit repo= / branch=. The changelog notes that direct messages do not use a default repository.

Pin an operational checklist in the repo rather than in someone’s head:

# teams-copilot-gate.md (team runbook excerpt)

## Before enabling @GitHub in a production channel
- [ ] Org/enterprise: Copilot cloud agent **and** cloud sandboxes enabled
- [ ] Teams client: Public Developer Preview as required by docs
- [ ] GitHub app for Microsoft Teams installed; accounts linked
- [ ] Public channels: default repository set deliberately (not “first mention wins” by accident)
- [ ] Channel membership ≠ repo write access — document who can trigger changes
- [ ] Repo rules: require **additional approval** for Teams Copilot integration identity PRs
- [ ] Budgets: AI credits + sandbox SKU budgets reviewed (sandbox is billed separately)
- [ ] Meeting-chat policy: which meetings may summon the agent (standup vs all-hands)

I almost waved through a “temporary” default repo on a public channel until I re-read the docs: if a channel has no default, the repository from the first session can become the channel default. The spreadsheet of channel → repo mappings belongs before the Settings UI click.

Practical use

1. Pick one pilot channel — not production all-hands. Prefer a team channel whose write members are already curated.
2. Have an admin enable cloud agent and cloud sandboxes, install the GitHub app for Teams, and confirm account linking.
3. For public channels, set the default repository on purpose. For DM experiments, always pass repo=.
4. Split playbooks: meeting chat may summon “investigate only,” while a write-holder later triggers “open the PR.”
5. Turn on additional approval for PRs attributed to the Teams Copilot integration identity. If the repo already needs two approvals, Copilot-authored PRs need three.
6. Review AI credit and sandbox budgets weekly; meeting-chat summons can burn both.

This is public preview — UI and policy text will move. What should not move is the triad: permission, identity, budget.

Senior-engineer perspective

Chat-agent failures are more often wrong triggers than wrong diffs. Guests and read-only stakeholders adding context in a standup thread is useful. Blocking them from triggering changes is the right default. The failure mode is the write-holder who opens an app-identity PR because the meeting mood said “just ship it.” Without the extra approval class, review culture collapses in a day.

The additional-approval toggle is not there to make you slow. It marks agent-authored PRs as a different class from human PRs. That is the same conclusion as the Slack draft: changing the surface does not automatically upgrade governance.

Using it in Cursor

When you use Cursor to adopt this policy, ship a runbook file before a feature demo.

1. Drop the checklist into docs/runbooks/teams-copilot.md and ask a Cloud Agent / subagent to draft an onboarding PR only from that file.
2. Use Subscriptions or /goal for bounded work (“open three setup tickets for the pilot channel”) with stop conditions. Do not let Cursor click Teams mentions for you — chat triggers stay human.
3. Add one AGENTS.md line: PRs from chat-agent identities require the extra approval ruleset; do not ask to bypass.

Cursor owns the IDE-side agent loop. Teams owns the room where decisions happen. Mixing both into one prompt erases accountability.

FAQ

Q. Is this Business/Enterprise only?
A. The Teams changelog frames public preview as available with paid GitHub Copilot plans. Org/enterprise members may need cloud agent and sandbox policies enabled. Check current policy UI and docs for eligibility.

Q. Does Teams create a Slack Code–style dedicated channel?
A. As of 2026-08-21, official Teams guidance emphasizes following progress in the existing channel/thread. A 1:1 Slack Code equivalent is not spelled out.

Q. Does a meeting-chat summon merge automatically?
A. No. Work runs in a cloud sandbox and produces artifacts (issues/PRs, etc.). Merge still follows branch protection and any extra approval rule you enable.

Q. What if we skip the default repository?
A. Docs describe that if a channel has no default, the repository used in the first session can become the channel default. Set it deliberately on public channels.

Q. Is sandbox usage included in the Copilot subscription?
A. The changelog separates cloud agent AI credits from separately billed sandbox usage (with its own budgets). Check both.

Sources

• Shared agentic work with GitHub Copilot in Microsoft Teams (2026-08-21)
• Integrate Copilot cloud agent with Microsoft Teams
• The new GitHub Copilot experience in Slack (2026-08-21)
• Integrate Copilot cloud agent with Slack
• Neowin secondary coverage (prefer changelog/docs wording over broad “deploy” paraphrases)

Closing

Summoning agents from chat is already here. Teams public preview asks a sharper question than “can we?” — who triggers, which identity opens the PR, and who watches the budget.

If meeting chat becomes the default handoff, “notes → ticket → human” compresses into “notes → @GitHub → app-identity PR.” Welcome that compression only after the extra approval rule and the channel→repo map exist. Speed comes second.