Slack Code went live today: 5 agents, one channel, and the rules files that keep them aligned

Slack announced Slack Code this morning. Mention a coding agent in a project channel and a code channel spins up around the work: it pulls in your teammates, fills itself with the actual artifacts (code diffs, planning docs, live HTML previews), and archives itself when the work lands. The archive stays behind as an audit log. Launch partners are Anthropic, Cognition, GitHub, OpenAI, and Vercel, with Claude, Devin, Copilot, and Vercel agents live today and ChatGPT listed as "available soon".

Most coverage will focus on the collaboration story. I care about a different angle: five coding agents from five vendors now share one workspace, and they do not share one rulebook.

What actually shipped

The mechanics, from the announcement:

• You mention an agent in a channel. It creates a dedicated code channel for the task instead of flooding the original thread.
• The channel is built for output, not just chat: diffs, planning docs, live previews show up as first-class objects.
• Everyone in the channel can review, give feedback, and approve before anything ships.
• When the work is done the channel archives itself and remains searchable.

Under the hood this rides on the existing channel model. The developer API post from August describes code channels as agent-created spaces that carry context forward from an existing conversation. Those APIs are in beta and limited to select partners for now, so custom agents are not a this-week thing.

The Agents tab adds the operations layer: every agent session gets a home base with status, the ability to flag a blocked thread, and a stop button for mid-run termination. That last one matters more than it sounds. Killing a runaway agent from a shared surface, where a teammate can do it and everyone sees it happen, is a small but real improvement over everyone hunting for the right terminal.

The part that matters for your config

Here is the detail that got my attention. The channel gives all five agents the same conversation context, the same planning doc, the same diff under review. But behavior rules still come from the repo, and each agent reads a different file:

• Claude Code reads CLAUDE.md
• Codex and ChatGPT agents read AGENTS.md
• Copilot reads .github/copilot-instructions.md
• Cursor reads .cursor/rules/

Your instruction files used to be a personal preference, the thing each developer tuned for their own tool. The moment your team's work moves into a shared channel with multiple agents, those files become the only contract the agents share. The conversation context is common. The rulebook is forked five ways.

One rule, four files

Say your team has one hard rule: never touch migrations on a branch that is not yours. In a multi-agent channel that rule needs to exist everywhere:

# CLAUDE.md
- Never edit files in db/migrate. Propose a new migration instead.

# AGENTS.md
- Never edit files in db/migrate. Propose a new migration instead.

# .github/copilot-instructions.md
- Never edit files in db/migrate. Propose a new migration instead.

Three copies, one semantic rule. The failure mode is quiet drift: someone updates CLAUDE.md after an incident, forgets the other two, and now Claude refuses an edit that Copilot makes happily. In a shared channel that inconsistency reads as flakiness in the agents rather than what it is, a config fork. I have watched teams lose an afternoon to exactly this, except with two tools instead of five.

A quick drift check, if your rule files are short:

grep -c "db/migrate" CLAUDE.md AGENTS.md .github/copilot-instructions.md

Same count everywhere, or you have a fork. For anything longer than a few rules, keep one canonical source and generate the rest, the same way you would handle any other generated artifact.

What belongs in the channel, what belongs in files

Slack's pitch is that context compounds when work happens in the open. That is true for task context and wrong for rules.

Task context (what are we building, who asked, what broke yesterday) genuinely belongs in the channel. It is conversational, it expires, and the next person benefits from reading it in order.

Rules do not belong there. Rules want version control, code review, and blame. A rule that lives in a pinned message or a channel description has none of that. My heuristic: if you would want the rule enforced next quarter, it goes in a file that gets a PR. If it describes this task, it goes in the channel.

This is also why I would keep rules files version-pinned and generated from one source rather than hand-maintained per tool. It is the same discipline as a lockfile. (This is the problem space our AgentConfig Studio kits exist for, and there is a free Next.js sample if you want to see the structure without paying anything.)

The audit story is good, with one gap

The auto-archiving channel is a genuinely nice compliance artifact. The whole conversation, every diff, every decision, searchable after the work ships.

The gap: the approval click happens in Slack, not in git. Your merge commit records that someone merged. It does not record who approved in the channel, or what they saw when they did. If your process needs "who signed off on this", the Slack archive is now part of your audit pipeline, which means Slack retention settings are too. Worth checking before you rely on it, not after.

Governance: someone now owns the agent list

Workspace admins control which apps and agents are available, and the announcement is explicit that underlying app permissions stay admin-managed. In practice, the set of mentionable agents is a new config surface. Every agent you enable brings its own rulebook, its own auth scope, and its own failure modes into a shared room.

If your team enables five agents because each is best at one thing, you have inherited five config formats to keep aligned. That is manageable with one canonical rules source. It is not manageable with five hand-edited files that only one person on the team understands.

What I would do this week

1. Inventory which instruction files actually exist in your repo. ls the usual suspects and see what is real versus aspirational.
2. Pick one canonical source of truth for rules and make the others generated. Drift is the enemy, not duplication itself.
3. Decide the default agent your team mentions. One agent used well beats five used casually.
4. Check Slack workspace retention settings if the audit trail matters to you.

Limits worth stating plainly

The code channel APIs are beta and partner-only, so building your own agent into this flow is not available yet. The ChatGPT agent is listed as coming soon. And if you are a solo dev or a two-person team in one repo, this launch changes little for you today. The underlying problem though, five rulebooks for one team, already exists in your repo whether Slack Code takes off or not. That is the part worth fixing this week regardless.