Block runs its coding-agent fleet from Slack. The chat is the easy part.

The first time I watched an engineer trigger a fix on a service she did not own without leaving the Slack thread where the bug had been reported, I sat there a beat too long. No clone, no IDE switch, no ticket. She typed something into the channel, an AI coding agent went off to look at the repo, and a draft PR showed up some time later against a codebase her own team did not maintain. That is roughly the workflow The New Stack reported on this week, in a piece dated June 17 about how Block — formerly Square — runs and supervises a fleet of AI coding agents from Slack.

The framing the article opens with is the line I cannot get out of my head: "Most AI coding tools work well inside a single repository. But few of them can operate across hundreds of services." That is the shape of the problem. A lot of us have been thinking about AI coding agents the way we think about an IDE plugin — one engineer, one repo, one branch. Block is thinking about them the way a platform team thinks about runners.

Why a chat channel ends up being the right doorway

When a coding agent only touches one repository, an IDE is a fine home for it; you trust the engineer, the engineer trusts the agent, the diff lands in the same review tool everything else lands in. When the same agent has to reach across many services owned by many teams, the IDE stops being the right doorway. The interesting questions move outside the editor: who is allowed to ask for a change on a service they do not maintain, what permissions does the agent inherit when it does, and how does the team that does own that service find out it happened.

Slack quietly answers a few of those at once. It is where the incident channel already lives. It is where a bot can ask for confirmation in front of witnesses rather than in a private DM. It is auditable in a way a one-on-one between an engineer and an assistant is not. And it puts the trigger somewhere a platform team can actually instrument — a single dispatch surface they can rate-limit, gate behind approvals, or attach to identity, without rewriting every team's IDE setup.

What this means if you run the CI/CD plumbing

The interesting bit of the Block story is not "agents do code". It is the part it is tempting to skim past: the control plane around them. Once an agent fleet is dispatching changes across many services, the operational shape it takes on is the same shape your pipelines already have. You need an answer for who can dispatch, by identity, not by Slack handle. You need an answer for what the agent runs as when it touches a repo it did not write. And you need an answer for how a reviewer on the receiving team notices the PR before it gets lost in a Monday backlog.

Pipelines have had years to grow those answers; agent fleets are getting them now, mostly retrofitted. The promising thing about routing this through chat is that all three problems become a platform problem rather than a per-team one, and platform problems can at least be solved once.

The rough edge I keep poking at

There is a version of this that gets very dark very quickly, and it is the one where dispatch is cheap and review is not. A Slack-triggered agent that opens many PRs across many services in one afternoon will outpace the reviewers on the receiving end. The PRs will sit. People will eventually click "approve" without the level of attention they would give a colleague's diff, because the agent has been producing reasonable-looking code for a month. That is not a failure of the agent. It is a failure of the workflow around it, and it is exactly the failure a fleet of agents amplifies.

The Block writeup is a useful proof that the dispatch end of this can be built and run at scale. The honest question for the rest of us is whether we are building the receiving end — the review SLAs, the per-service maintainer pings, the diff budgets — at the same pace.

What I am taking away

I want to see the postmortems. Specifically, the first time a chat-dispatched agent fleet ships a regression to a service whose team did not realise an agent was even allowed to touch it. That is the moment that turns the control plane from a nice-to-have into an audit requirement, and it is when the practices around agent fleets — identity, blast radius, review SLAs — will get their shape.

Until then, I am borrowing the framing: a coding agent that works inside one repo is a feature. A coding agent that works across many services is an operations problem in a trench coat, and it is going to want a control plane whether you give it one on purpose or not.