Slack Put the Approval Where the Conversation Is. It Did Not Put the Enforcement There.

The most quoted sentence from the Slack Code launch is the one about production. It is worth putting on the page exactly as Slack wrote it, because almost every summary of it since has quietly upgraded the verb.

The agent packages its work. It does not say the agent is stopped, blocked, held, gated or prevented. It says the agent finishes preparing something and hands it over. Whether anything in the world compels the handover is a separate question, and Slack does not answer it.

What actually shipped

Slack, a Salesforce company, launched Slack Code on 20 August 2026. It is available on any Slack plan from the day of launch, and Slack charges nothing additional for creating or operating code channels, though a customer still needs its own access to whichever partner agent it wants to use.

The mechanism is a new channel type. Tag a supported coding agent from an ordinary conversation, and if the agent judges the request a fit it opens a code channel scoped to that task. The channel is not a normal channel with a bot in it. It has dedicated tabs: a Conversation feed, a Plan showing the agent's task breakdown, Code Diffs showing the lines it changed, and a Live Preview rendering HTML output as it goes. It carries the repository and branch the agent is working in and the pull request information. When the task ends, the channel archives itself and stays searchable.

The founding partner agents reported consistently across the launch material are Claude Code from Anthropic, Devin from Cognition, GitHub Copilot and the Vercel agent. Some accounts of the launch add OpenAI's ChatGPT to that list and others do not, so we are recording the four consistent names and leaving the fifth open rather than resolving a discrepancy we cannot check. Access to the code channel APIs is limited to the launch partners for now, with Slack saying it intends to open them more widely later.

Three controls Slack does document

It would be unfair to read this launch as marketing with nothing behind it. Three things Slack states are concrete, checkable claims about product behaviour, and they matter.

The first is interruption. Anyone in a code channel can pause, redirect or stop an agent mid task. That is a real control and it is unusually broad: not the person who started the task, not an admin, anyone in the channel.

The second is identity. Agents in code channels inherit Slack's permissions and admin controls, and Slack's framing is that IT provisions no new identities. Whatever else is true, the agent is not arriving with a fresh credential nobody has inventoried, which is a genuinely better default than most agent deployments manage.

The third is the record. The channel archives itself when the work is done and the record survives as an audit log. The plan, the diffs, the conversation and the sign off, if one happened, all sit in one searchable place afterwards.

Slack is not where the code runs

This is the part that decides the whole question, and Slack says it plainly itself: Slack Code is not a coding model, a harness or an agent runtime. What Slack built is an API that lets partner agents create and manage the new channel type.

Follow that through. The agent executes somewhere else, on Anthropic's or Cognition's or GitHub's or Vercel's infrastructure. The repository lives somewhere else. The deployment, when it happens, is performed by the partner agent's own systems or the customer's own pipeline. Slack is the surface where the work is shown and discussed. It is not the thing that runs the deploy, which means it is not positioned to refuse one.

So when Slack says an expert signs off in the channel, the sign off is a message in Slack and the consequential action is an event in a system Slack does not operate. For that message to function as an authorization rather than a courtesy, something on the far side has to be listening for it, has to require it, and has to refuse to proceed without it. Slack publishes no such mechanism. Neither, as far as we can find, does any partner. That does not prove the link is absent. It means nobody has shown it exists.

What an expert is not

One trap is worth flagging because it is easy to fall into. Slack separately ships a product called Channel Expert, which is a prebuilt AI agent that answers questions in a channel. The expert in the Slack Code sentence is not that. It reads as an ordinary English word meaning a person who knows the system, and Slack defines no role, permission, group or designation to go with it.

That leaves the eligibility question completely open. In a code channel where anyone can pause the agent, can anyone also sign off? Is it the person who assigned the task? A repository owner? Somebody who happens to be in the channel at the time? Nothing published says. An approval whose approver is undefined is a workflow convention, not an access control.

What the sign off is not bound to

The other half of the question is binding. A meaningful authorization answers: approval of what, exactly, and good for how long.

Nothing in the launch material states whether a sign off attaches to a specific diff, so that a later change to the same branch would need a fresh one. Nothing states whether it attaches to a specific commit. Nothing states whether it attaches to a specific deployment, or whether one approval covers everything the agent does afterwards in that channel. Nothing states whether an agent that receives no answer waits indefinitely, times out, or proceeds. Nothing states whether an agent can reach production by any path that does not pass through the channel at all.

Each of those is the difference between an approval and the appearance of one, and all of them are currently unanswered.

Where the evidence actually sits

Four levels are worth keeping apart here, because collapsing them is how a launch post becomes a security claim.

Documented product behaviour. The channel type, the tabs, the diffs and preview, pause, redirect and stop, permission inheritance, self archiving into an audit log, availability on all plans. Described by the vendor, consistent across the launch material, and specific enough to be checked by anyone with a Slack workspace.

Public implementation. Thin. The code channel API exists, because partner agents are using it, but it is restricted to launch partners and we found no public technical documentation of it. There is nothing published for an outside engineer to read and evaluate.

Demonstrated enforcement. None. No artifact shows a deployment being refused for want of a sign off, and Slack does not operate the systems where a deployment would be refused.

Production adoption. Not established. Slack's account is that its launch partners run code channels internally, and there is a launch day claim that some of them do most of their coding in Slack. That is the vendor's characterisation of its own partners on the day the product shipped. It is not adoption evidence and one day is not a track record.

A different vendor answers part of the question

One week after Slack Code shipped, AlpacaX, which sells an AI native privileged access product called Alpacon, published an article dated 28 August 2026 arguing for a specific design rule: an approval channel has to be structurally separate from whatever channel an agent used to request the action, so the credential doing the asking is never also the credential that can clear the hold. Moona Intelligence could not fetch that article directly. alpacax.com sits behind the same kind of egress block that already affects other sources in this record, and repeated search retrieval returned only fragments rather than text reliable enough to quote in full, so its argument is recorded here as a vendor position rather than an independently confirmed one.

What we could verify directly, by reading Alpacon's own open source command line client on GitHub rather than its marketing, is narrower and does not depend on trusting that article. The client, which is what an engineer, an AI coding agent or a CI pipeline uses to execute commands against a managed server, ships no approve or reject subcommand. Its own documentation states that approving or rejecting a session happens in the Alpacon console, described as web or Slack, not in the command line client, and a held privileged command returns a distinct pending approval exit code rather than a refusal. A session's own requester can cancel a pending request, which withdraws it, but nothing in the same documentation gives that requester a path to approve it. Taken together, that is channel separation built into the tool rather than only claimed about it: the surface an execution credential runs through structurally lacks the operation a hold requires.

The same documentation records that a pending approval can settle without being granted in several distinct ways, listed as rejected, expired, revoked, cancelled or completed, evidence that an approval request is not a standing grant, though nothing found states whether a granted approval is single use or can be replayed against a command other than the one shown. It also documents that gated commands run inside a work session carrying a declared purpose, and that a command can be refused for reading as off purpose for that session, a pattern this record treats the same way it treats Slack's own permission inheritance: a real default, not proof that the declared purpose itself was legitimate. A service or personal API token bypasses the work session gate entirely and is instead checked against that token's own access rules, a separate containment mechanism rather than an approval path.

None of that closes the questions this record opened about Slack Code. Alpacon is a different product with a console rather than a group chat channel, and nothing found here establishes who is eligible to approve inside that console, whether an approval binds to the exact command a person saw, or whether the same separation holds between two channels controlled by the same person rather than between two classes of credential; that question is outside what we independently confirmed here. What the client's code and documentation establish on their own, independent of any marketing language, is that at least one vendor has shipped a tool where the credential used to ask cannot also be the thing used to answer. Slack's own launch material, a week earlier, still does not say whether the same is true of Slack Code.

Why this is still worth recording

Moona Intelligence's read is not that Slack overpromised. It is that Slack has moved something interesting, and the interesting thing is location rather than strength.

The agent is allowed to do the whole job. It plans, writes, opens the branch, produces the diff, renders the preview and assembles the change into something a person could ship. All of that is preparation, and preparation is where agent capability has been heading for a year. What Slack has done is put the moment where that preparation is supposed to become a real production effect onto the surface where the team already talks, in front of everyone, with the diff and the plan and the history attached to it.

That is a genuine structural claim about agent authority: an agent may be permitted to prepare a consequential production change while the decision to make it real is reserved for a person. It is the same distinction we have drawn between what an agent can reach and what it should be authorized to do with it, and the same one AWS drew when it separated permission to call a submission tool from authority to submit the decision.

What Slack has not done is make that reservation binding. The distinction between an action you can see and an action you can still prevent is exactly the one a control assessment of frontier developers was built around, and a code channel is a very good instrument for seeing. Where an approval is actually enforced turns out to be a question about which boundary the request has to pass through, and Slack is not on the path between the agent and production. And once approval is a message rather than a mechanism, the question of who is authorized to give it becomes load bearing, which is the problem a GitHub experiment ran into from the other direction when it let an agent request approvals of its own.

None of that makes Slack Code a weaker product. It makes it a collaboration surface that has taken on the vocabulary of an authorization system. The two converge only if something outside Slack is built to honour the sign off, and on 21 August 2026 nobody has published evidence that anything is.