Four Vendors' Agents, One Channel, One Approval Gate

Gizmodo reported on 20 August 2026 that Slack shipped a feature letting a team tag AI coding agents inside a group chat. The supported agents come from four companies that compete with each other: Anthropic, GitHub, Cognition and Vercel, with Claude Code, GitHub Copilot and Devin among the named ones. One conversation, several vendors, one set of rules about what any of them may do.

Two controls ship with it, according to Slack. Merging code to production requires human sign-off. And once the team approves the work, the agent archives the channel.

The archival is the control worth reading closely.

Several vendors arriving through one door

Every agent harness carries its own approval model. They disagree on what counts as a dangerous action, on how long a granted permission persists, and on what a user sees before saying yes. Putting them in the same channel does not reconcile those models. It puts one gate above them, which per the announcement is human sign-off before a production merge.

The boundary moves. The vendor stops owning the last checkpoint and the channel owns it. A team standardised on a single agent has one vendor’s judgement to audit. A team using Slack Code has several vendors’ behaviour arriving through one door, which is easier to watch at the point of merge and harder to reason about upstream, because each agent still decides on its own what to propose before the gate ever sees a proposal.

There is an identity question underneath this. Each of those agents acts inside a workspace built for people, with a member list, channel memberships and message history that were designed around human accounts. We have argued that an agent operating with employee-level reach is a non-human insider and needs isolation to match. A group chat is the surface where that distinction is hardest to hold, because the agent looks like another participant in the thread and reads everything the thread contains.

Gizmodo notes the feature is available on all Slack plans. Procurement review of a coding agent stops being the control point when the agents arrive inside a tool the company already bought. Nobody signs a new contract. Nobody files a new vendor risk assessment. The agents are simply there, in a workspace that already contains most of the company.

The archive keeps the argument

Per the Gizmodo report, the agent archives the channel after the team approves the work, and people can review an HTML preview before approving.

Archiving a working channel is a governance control that arrived without being labelled as one. Consider what a code review normally discards. The alternative approach someone floated and dropped. The reason a test was skipped this once. Who asked for the change, in what words. A pull request retains the diff and the comments attached to the diff. A channel retains the deliberation that produced the diff, including the parts that never made it into a formal artifact.

That record is more useful than the commit history when you want to know why a system behaves the way it does. It is also discoverable material sitting in a system whose retention schedule your organisation set for conversations, not for engineering decisions. Most legal hold procedures name email, ticket systems and document stores. An archived channel holding the full argument behind a production change is a new category, and the team that produced it usually cannot say how long it survives or who can read it in two years.

We have written before about writing the escalation boundary down as an artifact. Slack Code produces that artifact whether or not anyone intended to, which raises a different question than the one we asked there: not whether the handoff is recorded, but who governs the recording.

Read the gate as vendor description

Slack spokesperson Gianna Dimick describes “human sign-off on high-stakes actions like merging code to production.” Katie Steigman, VP of product, describes the working model as one where “the whole team and the agent work together on the build.”

Both statements come from Slack, about Slack. This is the same pattern we tracked when governance itself became a product feature across three vendors: the control is announced as a capability, described by the company selling it, and adopted by customers who then treat the description as an assurance. Gizmodo publishes no adoption figures, no usage data and no independent test of the gate. What we know is what the vendor says ships, which is a claim about the feature set and not a measurement of the control.

Our own position on approval prompts is on record: a per-action permission prompt is not a control, because it depends on an attentive reviewer and the design guarantees inattention. A merge gate in a chat channel inherits that weakness and adds a new one. In a pull request, the approver is a named reviewer holding a role and a review obligation. In a channel, the approver is whoever happens to be present and responsive. Presence is not a permission model. If the person who approves a production merge at 6pm on a Friday is the one who had the app open, the gate records a name without recording accountability.

The HTML preview cuts in the other direction. Something reviewable before approval is a real improvement over reading a diff in a terminal. Whether the archive records who actually opened it is a question for the vendor.

What a chat governance policy has to answer

Most organisations have a policy for code review, a policy for production access, and no policy at all for the chat surface as a place where production decisions get made and stored. Four questions are now live.

Who is allowed to approve a production merge from a channel, and is that the same list as the people who can approve in the repository? If the two lists differ, the chat surface is a bypass.

What is the retention period on an archived Slack Code channel, and does it match the retention period on the pull request it corresponds to? Deliberation that outlives the code, or dies before it, produces an incoherent record either way.

Which agents are permitted in a channel that touches production code, and who decides? Several vendors under one gate means several sets of upstream behaviour you did not evaluate.

Does the archive enter legal hold when the repository does? A regulator or an opposing counsel will not accept that the reasoning lived in a system nobody thought to preserve.

Do this now

Open your Slack admin settings and find out whether Slack Code is enabled for your workspace. It is available on every plan, so the default answer is probably yes, and nobody on your team had to ask for it.

Then take one recent production merge and write down where its reasoning lives today. If the answer is a pull request thread, ask what your retention period is on it. If part of the answer is already a Slack conversation, you have the governance problem before the feature even arrives, and Slack Code only makes the record complete enough to be worth arguing about.

Last, pick the list of people who may approve a production merge and reconcile it across both surfaces. That is a single afternoon of work and it is the one control here that does not depend on trusting a vendor’s description of its own gate.

---

This analysis synthesizes Slack Has (of Course) Launched a Vibe Coding Tool (Gizmodo, August 2026).

Victorino Group helps engineering organizations write governance policy for the surfaces where agent work actually happens. Let’s talk.