Slack Code: Coding Agents Just Moved Into the Team Channel
Slack Code puts coding agents like Claude Code and Devin into shared project channels where anyone can watch, review and approve their work. The interesting shift isn't code quality, it's supervision, shared context, attribution and review.
On this page
- What happened
- Supervision moves out of the private session
- Shared context cuts both ways
- Attribution and review, the unglamorous wins
- What to do now
- FAQ
- What is Slack Code?
- Do I need a paid Slack plan?
- Does Slack Code replace code review?
- Is it safe to let an agent read a whole channel?
- The bottom line
- Sources
The most important thing about a coding agent is no longer how well it writes code. It's who can see what it's doing. Until this month, the honest answer for most teams was: one developer, in a private terminal or browser tab, hoping to remember later what the agent actually did. Slack Code, launched on 20 August, is the biggest attempt yet to change that answer to "everyone on the project, by default."
I've read the launch announcement, Slack's own follow-up post and the coverage. The model underneath is the same Claude Code, Devin or Copilot you already know. What changes is the room the work happens in, and that turns out to matter more than most of the coverage suggests.
Key Takeaways - Slack Code adds "code channels": shared project spaces where a tagged coding agent (Claude Code, Devin, GitHub Copilot, Vercel, with ChatGPT coming) does its work in the open, with diffs, live previews and a human approval step before anything ships. - It runs on any Slack plan from day one, though access to each agent is bought separately. Channels auto-archive when the work completes and keep an audit log. - The real shift is supervisory: agent work moves from a private session one person watches to a shared artefact a team watches. That fixes attribution and review gaps, and creates new ones (bystander apathy, approval theatre, channel context as an attack surface). - This is a distribution move too. Slack spent a year building agent plumbing (MCP server, real-time search, Slackbot MCP client), and code channels are the surface that makes it visible. - Treat "a person approves the work before it ships" as a design goal, not a guarantee. Your review process still has to be real.
What happened
On 20 August, Slack launched Slack Code across all its plans, free workspaces included. The mechanics, per the launch coverage and TechRepublic's write-up:
You tag a coding agent in any Slack conversation. The agent spins up a dedicated code channel for the task, whether that's fixing a bug, updating a page or building a feature.
Everyone in the channel sees the same conversation the agent is working from, reviews code diffs as they're proposed, checks live HTML previews, leaves feedback the agent incorporates, and approves the finished work. Nothing ships without a human sign-off.
When the work completes, the channel archives itself and keeps an audit log for the record.
Launch partners are Anthropic's Claude, Cognition's Devin, GitHub Copilot and Vercel, with OpenAI's ChatGPT announced as coming soon. Slack's plan is to open the code channel APIs to the wider developer community so any custom agent can join.
Who lands in a channel is configurable. Katie Steigman, Slack's VP of product, told Reworked: "You could have the agent just bring in the user who tagged the agent to make the code channel or you could configure the agent to make inferences on its own as to who should be in the channel based on the context it has." Rob Seaman, Slack's EVP and general manager, framed the intent: "AI only creates value when it's part of how a team actually works."
Slack Code, launched 20 August 2026 on all Slack plans, puts partner coding agents (Claude, Devin, Copilot, Vercel; ChatGPT announced) into shared "code channels" where the whole team sees the agent's conversation, diffs and live previews, approves work before it ships, and inherits an audit log when the channel auto-archives, per Slack's announcement.
Supervision moves out of the private session
Here's the thing the feature list hides. Most agent supervision today is a fiction maintained by one tired person. The agent runs in someone's IDE or a cloud sandbox, the diff arrives as a pull request, and the "review" is whatever that one developer had the appetite for at 5pm. The reasoning, the dead ends, the three attempts before the one that worked: all of it evaporates. I've reviewed enough agent output to know the diff is the least informative part of the process.
Slack Code's actual proposal is to make the process the artefact. The channel holds the conversation the agent worked from, the intermediate steps, the feedback it took and the approvals it got, and then archives the lot as a searchable record. That's a genuinely different supervision model, and it's closer to how good teams already review junior engineers than how they currently review agents: watch the work, not just the output.
It also changes who supervises. The pitch is explicitly that PMs, designers and non-technical teammates can follow along. I'm cautiously for this, with one reservation I'll come back to: a room full of watchers is not the same as a reviewer. Diff literacy doesn't arrive by osmosis, and "the team can see it" can quietly become "nobody checked it." The governance questions this raises (who is accountable when ten people watched and nobody owned the approval) are exactly the ones I work through in the agent governance framework, and Slack Code doesn't answer them for you. It makes them visible, which is the honest first step.
Slack Code moves agent supervision from a private session to a shared, archived channel record: the conversation, intermediate steps, feedback and approvals all persist as a searchable artefact, per Slack's product post. The accountability question of who owns the approval in a room of watchers remains the customer's to answer.
Shared context cuts both ways
The second big claim is about context. Slack's argument is that the context for a task already lives in channels (the bug report, the spec discussion, the customer complaint), so the agent should work where the context is instead of having it copy-pasted into a private prompt. That's right, and it builds on plumbing Slack has been shipping all year: its MCP server and real-time search API went generally available in February, giving agents governed access to workspace messages and files, and the Slackbot MCP client followed in June. I've covered why MCP access to team tools is the useful half of agent context in the MCP servers roundup; the channel model is that idea taken to its conclusion.
But shared context is also shared exposure. An agent that reads a channel reads everything in it, including the message where someone pasted a credential "just for a minute" and the external content forwarded from a customer. Every security researcher I know will tell you the same thing: content an agent can read is content that can instruct it. A shared channel is a bigger prompt-injection surface than a private session, full stop. Before pointing an agent with write access at a busy channel, it's worth being deliberate about which channels it reads and what its tools can touch. That's architecture work, not settings work, and it's the same trade-off I describe in agentic architecture: capability and blast radius grow together.
Slack Code's context advantage (the agent works where the task context already lives) rests on MCP-based workspace access Slack made generally available in February 2026, per Unite.AI's report. The same shared context widens the prompt-injection and credential-exposure surface, a trade-off the launch materials do not address.
Attribution and review, the unglamorous wins
The least flashy parts of this launch are the ones I'd actually buy. Attribution first: in a code channel, every agent action sits under the agent's identity, in a workspace that already knows who everyone is, with an audit log that survives the project. That sounds basic. It is basic. It's also more attribution infrastructure than most teams currently have for agent work, where "the agent did it" and "I did it" blur into the same git history. Regulated industries have been asking for exactly this boring thing for a year.
Review second. Diffs and live previews in the channel, feedback the agent incorporates, and a hard approval gate before shipping. Note what's missing, though: Slack's materials describe a person approving the work, but nothing I've seen specifies who that person must be, what they're shown, or what happens when the configured reviewer is on holiday. Approval as a checkbox is how you get approval theatre: a green button everyone learns to click. The teams that get value here will be the ones that wire the approval to a real code owner with real diff review, and keep the agent's channel output as evidence rather than as the review itself.
The competitive context matters too. Microsoft put a Copilot coding agent into Teams threads back in September 2025, and Block shipped its open-source Buzz in July, as Reworked's coverage notes. The chat window is becoming a contested surface for agent work, and Slack's advantage is unglamorous: it's where the team already is. Distribution beats cleverness in collaboration software, every time.
Slack Code gives each agent its own identity in channels and keeps an audit log per archived project, per TechRepublic, but its approval gate ("a person approves the work before it ships") does not specify reviewer identity or review standards. Microsoft's Teams Copilot agent (September 2025) and Block's open-source Buzz (July 2026) are the direct comparables, per Reworked.
What to do now
If your team runs on Slack and uses coding agents, three steps.
This week: pick one low-stakes, well-specified task (a copy change, a small bug with a clear reproduction) and run it in a code channel with two or three people watching. You're not testing the agent; you're testing your team's review behaviour. Watch whether anyone actually reads the diff.
Before anything real ships: decide, in writing, who the approver is for agent work in each repo, and what they're required to check. If your answer is "whoever's in the channel," you don't have a review process, you have a button.
Before broad rollout: scope which channels the agent can read and which credentials its environment holds. Channel history is context, and context is an attack surface. Start narrow and widen on evidence.
FAQ
What is Slack Code?
A Slack feature, launched 20 August 2026, that lets teams tag partner coding agents (Claude Code, Devin, GitHub Copilot, Vercel, with ChatGPT coming) into a conversation. The agent opens a dedicated "code channel" for the task, where the team watches the work, reviews diffs and previews, and approves the result before it ships. The channel archives automatically when done.
Do I need a paid Slack plan?
No. Slack Code is available on every plan, including free workspaces. But access to each coding agent is bought separately from that agent's vendor, so the practical cost depends on which agents you already pay for.
Does Slack Code replace code review?
No, and treating it that way is the main risk. It relocates review into a shared, archived channel and adds an approval gate, but the quality of review still depends on a named human reading the diff. A visible process with no owner is worse than a private one with a conscientious reviewer, because it looks supervised.
Is it safe to let an agent read a whole channel?
It depends what's in the channel. Anything the agent can read can influence it, including pasted credentials and forwarded external content. Scope read access narrowly, keep agent credentials least-privilege, and treat channel content as untrusted input, because from the agent's perspective it is.
The bottom line
Slack Code won't make agents write better code. That's not what it's for. It makes agent work visible, attributable and reviewable by default, in the place the team already lives, and those are the three things most agent deployments are quietly missing. The catch is that visibility is not supervision. The channel gives you the record and the gate; whether anyone is actually watching is still your problem to solve. Watch how teams configure the approver, not the agent. That's where this either works or becomes theatre.
If you're working out how to put agents into team workflows without losing control of review, that's a conversation I have with clients regularly. Get in touch.
Sources
Salesforce, "Introducing Slack Code: Agentic Coding for Teams": https://www.salesforce.com/introducing-slack-code/ (published 2026-08-19, retrieved 2026-08-29)
Slack, "Slack Code: Where Your Team and Agents Build Together": https://slack.com/blog/news/slack-code-channels-for-agents (published 2026-08-28, retrieved 2026-08-29)
Unite.AI, "Slack Code Puts AI Coding Agents in Dedicated Project Channels": https://www.unite.ai/slack-code-puts-ai-coding-agents-in-dedicated-project-channels/ (published 2026-08-20, retrieved 2026-08-29)
TechRepublic, "Slack Code: AI Coding Agents Get Shared Channels for Review and Oversight": https://www.techrepublic.com/article/news-slack-code-ai-coding-agents/ (published 2026-08-21, retrieved 2026-08-29)
Reworked, "Slack Code Puts AI Coding Agents in Shared Channels": https://www.reworked.co/collaboration-productivity/slack-code-brings-collaborative-ai-coding-into-channels/ (published 2026-08-20, retrieved 2026-08-29)
Keep reading
Agent Field Notes
Get the next issue.
Agent harnesses, runtimes, security and governance, explained for the people who have to operate them.
Facing a decision like this?
We run architecture reviews, governance assessments and version-pinned framework evaluations for teams making consequential agent decisions.