Two weeks ago, starting a coding agent meant opening an editor or a terminal. As of 21 August, when GitHub brought Copilot's agent into Slack and Microsoft Teams, that list is at least six items long — and every item arrived through a separate announcement, governed by a separate control, reviewed by whoever happened to read that week's changelog.
Nobody sat down and decided an agent should be startable from six places. It became true one reasonable feature at a time. This is the exercise to catch up: list every entry point, and ask the same question of each one.
The six entry points, as of this week
Write down which of these are live in your organisation, because the honest answer is usually "more than whoever asks expects."
- The editor — VS Code, JetBrains, and the rest, where an agent runs because a developer typed a prompt
- The CLI — the same capability, invoked from a terminal, often the easiest to script and therefore the easiest to embed somewhere nobody remembers
- The cloud agent — runs unattended once started, and now includes Cursor's Subscriptions, which start it without a person invoking anything at all
- A chat mention — @GitHub in Slack, live since 21 August, startable by anyone in a channel who can type
- A meeting — Teams, live the same day, startable mid-conversation and continuing after the meeting ends
- An event — a pull request comment, a scheduled task, or another automation trigger, which is what Cursor's Subscriptions and GitHub's cloud agent both increasingly run on
Why each one got governed separately
This is not a criticism — it is how software actually ships. Each entry point solved a real, specific problem: the editor for in-flow work, the CLI for scripting, the cloud agent for long unattended tasks, chat for bringing the whole team into a decision, events for removing the need for a person to notice something needs doing.
The consequence is that governance followed the same path. MCP allowlists shipped for Copilot clients, then separately for JetBrains. Plugin controls shipped for editors. The Slack and Teams integrations ship with their own approval gate, phrased as a feature of that integration rather than as an instance of a general policy. Six good decisions, made independently, do not automatically add up to one coherent policy — they add up to six policies with six different owners, none of whom has seen the full list.
The question that is the same for all six
Do not write six different policies. Write one question and answer it six times: what can start unattended work here, and who reviews what it produces?
For the editor and CLI, the answer has always been simple — a person is present, and review happens because a person asked for the change and is looking at it. For the cloud agent, chat, meetings, and events, the answer is no longer simple, because the thing that started the work and the thing that reviews it can now be different people, or no deliberate person at all.
What to actually check this week
A short audit, not a project.
- For each entry point, confirm the approval gate on merges is actually configured, not just available. GitHub's Slack and Teams integrations both offer a required-approval control for agent-created pull requests — offered is not the same as on
- Check who can trigger each entry point. A Slack mention is startable by anyone in the channel; the CLI is startable by anyone with repository access. Those are very different populations and probably deserve different trust levels
- Check whether a task started in one entry point is visible from the others. A pull request opened from a Teams meeting should be exactly as reviewable as one opened from the CLI — if it is not, that is a gap worth fixing before it is a gap worth discovering during an incident
- Name one person who owns "agent entry points" as a whole, not per-tool. Six owners for six pieces of the same system is how a gap survives six separate reviews
This list will keep growing
Nothing about this pattern suggests it stops at six. Every one of these entry points shipped because it solved a real problem, and the next one will too. The realistic goal is not a static inventory — it is a habit of adding to the list whenever a changelog entry introduces a new way to start agent work, and asking the same two questions each time rather than treating it as a one-off feature announcement.