GitHub's agent can now work in a shared Slack channel or a live Teams meeting, watched by everyone present rather than reported back to by one person. The framing is collaboration: the whole team sees the investigation unfold and can steer it together.
That framing is accurate and it skips a well-documented problem. A task five people watched is not the same as a task one person is accountable for, and the difference matters most exactly when something goes wrong.
Diffusion of responsibility is not hypothetical here
The effect is old and well studied outside software: a group present for an event is, on average, slower to act on it and less individually accountable for the outcome than a single person would be, because everyone assumes someone else has it covered.
A multiplayer agent session recreates the exact shape of that effect. Five people watching an agent work in a Teams meeting can each reasonably assume the other four are following closely, and the honest average outcome is that nobody is following as closely as any one person would if they were alone with it.
Watched is not the same as reviewed
Watching an agent narrate its own investigation is closer to entertainment than to review. Review means reading the actual diff, checking it against what you know about the system, and being willing to say "this is wrong" — not nodding along as an agent explains itself in a meeting.
A shared session can absolutely produce genuine collaborative review if the group actively engages with the output. It can just as easily produce a room full of people who watched something happen and assumed the review already occurred because everyone was present for it. Those look identical from the outside and are opposite in substance.
A pattern that keeps accountability real
The fix is not to ban multiplayer sessions — the collaboration benefit is real when it works. The fix is to name one person before the group watching becomes a substitute for anyone actually reviewing.
- Before the agent starts, name one person as the reviewer of record for this task — not "the team", a name
- Everyone else in the session can contribute, question and steer, and none of that substitutes for that one person reading the final diff line by line
- The reviewer of record approves the pull request. If the group disagrees with the reviewer, that disagreement gets resolved before merge, not silently overridden by group presence
- Record who that person was, the same way you would record any other reviewer — a meeting screen share is not an audit trail
Use the approval gate as the enforcement mechanism
GitHub's Slack and Teams integrations already let repository administrators require additional approval before an agent-created pull request merges. That control is exactly what turns "a group watched this" into "a specific person reviewed this" — it just has to actually be turned on.
Configure it to require approval from someone other than whoever happened to type the @GitHub mention. The person who started a task in a meeting, caught up in the moment, is not automatically the person who should be its sole reviewer thirty minutes later.
What to check before rolling this out broadly
Four things, cheap to verify now and expensive to discover after an incident.
- Is the required-approval setting actually configured for your Slack and Teams integrations, or just available?
- Does your team have a norm for naming a reviewer of record, or does "the group was watching" currently count as review?
- Can you reconstruct, after the fact, who was actually paying attention to a given session — not who was in the room, who reviewed the diff?
- Does your incident process know to ask "who was the reviewer of record" rather than "was anyone watching" when something an agent produced goes wrong?