Agentic Slack
Originally posted on X.
The terminal is where most coding agents live, but it’s also where they get stuck.
Terminals and even IDEs are Single-player, single-context, disconnected from the rest of the team. Powerful for one engineer. Inaccessible to everyone else.
Put the agent where the team already is
The best interface for a coding agent is the one your team already uses. Every team already uses Slack.
A designer can report a broken layout, a support engineer can flag a typo, a PM can request a copy change, and none of them need Git installed or CLI syntax. They’re already in Slack, and the agent is already there too.
Tag the agent in a channel, describe the fix, and walk away. A cloud agent doesn’t need your terminal. It has its own environment, connects to your repos, and ships the PR independently.
Literally everyone in the organization has the ability to contribute.
The power of async is quietly being realized
Terminal and IDE sessions are also synchronous. You’re watching, steering, approving. This is right for complex architectural work where your judgment is the bottleneck.
But most engineering work isn’t that. Bug fixes. Minor enhancements. Test coverage. Documentation. Dependency updates. The bottleneck isn’t figuring out what to do. It’s the ceremony around shipping it.
Slack makes these tasks fire-and-forget. Describe ten fixes in ten messages. Come back to ten PRs. The constraint shifts from engineer hours to review capacity.
This is already becoming the default. First quietly, now obviously. The teams that ship the most are treating agents like teammates, not tools.
Slack is truly multiplayer
A terminal knows about you. Slack knows about your team.
Threads have history. When someone asks “can we also handle the edge case mentioned yesterday,” the agent can see what was mentioned yesterday. The organizational graph is already there.
The coding agent stops being a tool one person uses. It becomes a teammate everyone can talk to.
Why you don’t go back
Once you’ve tagged an agent in Slack and come back to a ready and polished PR, opening a terminal feels like sending a fax.
The work happens where the team already is. Once you experience this, you won’t want to go back.
More on cloud agents here. To see how this looks in action, watch this video.
The fire-and-forget pattern is interesting. Describe ten fixes, come back to ten PRs. That's genuinely different from the terminal flow where you're watching every step.
I'd push back a tiny bit though. For complex architectural work you still want that terminal-level control, and there's more flexibility there than people realise. I've been running different models inside Claude Code depending on the task complexity. Quick bug fixes get a cheaper model, architectural decisions get Opus. Covered the whole setup here https://reading.sh/claude-code-how-to-run-any-model-gpt-5x-gemini-3-1-stealth-inside-it-e67e957e53c3
The Slack approach makes total sense for the async tier though. Different interface for different work. Curious how you handle the PRs that need architectural context the Slack thread doesn't capture?