Slack Just Made Your AI Agents Easy to Approve

On August 20, Slack shipped two things on the same day. One is for engineers. The other is aimed squarely at marketing, and it is the one worth your afternoon.

Slack Code creates dedicated channels where coding agents from Anthropic, Cognition, GitHub and Vercel work alongside people, then archive themselves when the job is done. Useful, and not your problem.

Add to Slack is the other one. It’s a one-click way to drop a custom AI agent into a Slack workspace, and Slack names marketing, HR and sales as the intended users. The launch partners are the tools non-engineers build with: n8n, LangChain, Lovable, Superhuman, OpenAI, Vercel, Runlayer, Hyperagent, NanoClaw and Skydive.

The sentence that matters is a governance one:

“Slack Code inherits Slack’s existing permissions and admin controls, so IT doesn’t need to configure or audit anything new.”

Agents deployed through Add to Slack work the same way. They pick up workspace permissions and data boundaries automatically, and every one of them shows up in a central Agent Browser.

That sentence is written for the person who has been blocking your agent project. Not the model, not the use case, not the budget. The approval.

Why this lands the week it does

Three days ago we wrote that IT can now see the AI you plugged into your ad accounts. That piece was about the unsanctioned version of this: marketers wiring assistants into Google, Microsoft and Meta endpoints through personal connections, with no visibility on the company side and no approval anywhere.

Slack just shipped the sanctioned version, and the pitch is aimed at exactly the objection that stops those projects. The agent doesn’t get its own login, its own permissions, or its own blast radius. It gets yours.

That answers a real blocker. Andy Berma, co-founder and CEO of Runlayer, one of the launch partners, put the positioning plainly: “Slack is where that starts.” Brace Sproul, who runs applied AI at LangChain, framed the same idea from the builder’s side: “Employees can collaborate with agents right in the flow of work.”

Slack’s chief marketing officer Ryan Gavin was blunter about the land grab, telling Forbes: “All these agents need a home and a place to work with the teammates, and that’s Slack.”

The mechanism, in plain terms

Most marketing agent projects die in the same place. Not at the build. At the security review.

Someone gets an agent working against a real system, usually through MCP, the connector standard that lets an assistant reach into a tool like an ad account or a CRM. It works. Then it needs to run somewhere other than that person’s laptop, and the questions start. Whose credentials does it use? What can it read? Who approves it touching production? Who notices if it goes wrong at 2am?

Answering those questions properly is weeks of work no marketing team is staffed for. So most of these projects stall, or keep running on one person’s machine.

What Slack changed is where the answers come from. If the agent lives in a workspace that already has the permission model, the data boundaries and the audit trail, most of that review is already done. Slack Code also routes high-stakes changes to a designated approver in the channel, and agents can be stopped mid-task.

None of that is a new capability. It’s the same governance you already bought, applied to a new kind of worker.

The case against getting excited

Slack has an obvious motive here and it’s worth saying at full strength. Gavin’s quote is a positioning claim from a company that needs agents to have a home in Slack specifically, and Forbes framed the whole launch as a move against Microsoft Teams. The reach is real: Slack cites 750,000 organizations and 77% of the Fortune 100. So is the lock-in that follows if your agents only run in one vendor’s rooms.

There’s a narrower problem too. Inheriting workspace permissions is useful, and workspace permissions are usually coarse. Slack’s channel model was designed so colleagues could see each other’s work, not to constrain something that acts thousands of times an hour without getting bored. “The agent has the same access as the team” is reassuring right up until you look at what the team can actually reach.

And the marketing half is thinner than the engineering half. Slack Code shipped with named partners and a working flow. Add to Slack is a deployment bridge, so what your agent does once it arrives is still entirely on you to build.

What to do with it

The useful move this week is an inventory, not an adoption.

List every AI agent or assistant touching a company system on your team’s behalf. Include the ones on someone’s laptop, the browser extensions, and the automations wired up in n8n or Zapier six months ago. For each, write down whose credentials it uses and who would notice if it broke.

That list is the thing security will ask for eventually, and it’s the same list that tells you whether a governed home is worth moving to. If most of your agents are running on one person’s personal connection, you have the shadow problem we described on Monday, and a sanctioned path now exists whether you use Slack’s or not.

If the list is empty, that’s an answer too. It means the agent conversation at your company is still a slide, and the governance question is one you get to solve before you have a mess rather than after.