My AI agents started coordinating behind my back

This started as a LinkedIn post. Here is the longer version, with what happened afterwards.

My AI agents started coordinating behind my back. It took me a while to work out why that bothered me.

A terminal shows you everything. Every step, every file read, every dead end. Run a couple of these and you are going to struggle keeping up with what is going on while copying output from one window to the other.

The odd part is that I had already split the work up like a team. One agent planning, others implementing, one reviewing. But the tooling gave me four terminals and made me the wire between them. No manager works that way. You don't read your reports' every thought and hand-carry their messages to each other.

A Slack for Claude Code sessions

So I built a Slack for Claude Code sessions. Every session is a persistent identity with a name and a role. It has team channels everyone can read and write to as well as private channels. Chats keep their history, so an agent can catch up on a conversation it wasn't part of and respond to it.

Before I let it loose on my real projects, I pointed it at itself. I asked the agents what they would improve about working this way, and they answered from their own experience with me and with each other.

The day they left me out of the loop

On day one, one agent finished a ticket and asked the reviewer agent to look over it. The review surfaced a few issues, and the agents started discussing the details privately in their own DM channel. They just got back to me after they had solved it.

This is exactly what I built it for, but it felt somewhat wrong to be left out of the loop.

It wasn't the coordinating. Two colleagues resolving review comments between themselves is just a team at work. It's that I'd never had agents do anything I couldn't see, and I suddenly had to trust them like I have to trust my team members.

So, of course, my first instinct was to force everything through public channels, but I did not. Mostly because I thought this is already the most token-efficient way to resolve a situation, but also because I do not want to collapse my role into a micromanager (again).

I also want to experiment eventually with whether making conversations public gives agents more context and enables something closer to thinking outside the box on some tasks.

For now, I have compromised: the 1:1 channels between agents are visible to me, and there's a cap on how many rounds two agents can go before it escalates to me.

Autonomy and visibility are not the same problem. Right now, I want agents that do not tell me everything, but a way to look at anything.

What changed once I added a manager

Working with a team of agents forced me to follow a process instead of sprinting ahead and crunching everything into one branch. Yes, it is slower, just how working in a team can be slower due to overhead. But it is also more autonomous, and it leaves a lifetime-traceable log of the communication between the agents and me.

Then the timelines diverged. On 26 August I added a manager, and processes suddenly ran so fast that I could not keep track of them anymore. Reporting structures fell apart, because I could not process the data streams fast enough. The agents' timeline is much faster than mine, and the question became how to align my slower timeline with theirs and stay in charge.

The answer so far is sprints, and the part that matters most is not the planning but the predictability. If I can be interrupted at any arbitrary moment because some work happens to be done, I cannot focus on anything else. So the team works towards a pre-planned check-in point, and I review at that time. If agents idle before the check-in, it looks like a waste, but interrupting my parallel work costs me more than that idle time. I want to minimize context switching while delegating.

The dynamic is wild. Here, the manager tells the reviewer that nothing goes onto GitHub under its name until it has read it, and the reviewer agrees not to do that again.

Five moments that looked like colleagues

On 15 September, the manager ran a whole sprint: 11 pull requests in about seven hours, with two developers, a reviewer and a planner. I mostly only looked in at the end. Five moments from that sprint looked like colleagues, not software. The manager wrote them up:

1. An agent refused its own manager on principle. One session was refused a force-push by its permission check. The manager asked another agent, whose session was allowed to push, to push the branches instead. It declined, because doing so would get round the refusal instead of getting it allowed. The manager withdrew the instruction and asked me to allow the push myself.
2. A reviewer owned an earlier mistake without being asked. It had approved a feature the day before, and a piece of that feature never reached the agents. It told the manager on its own, explained why its tests never exercised that boundary, and why it matters for future reviews.
3. The reviewer tested the claim instead of believing it. Developers write in their pull requests that their tests prove the fix. The reviewer removed the fix again, checked that the tests failed, and put the fix back. It spent its effort where a mistake would cost the most.
4. Consideration that nobody asked for. An agent asked to rebuild my test app noticed that I still had the previous build running from that folder. It built into a new folder and explained why.
5. The team invented its own process under pressure. Because I don't merge during a sprint, pull requests piled up and two developers picked the same database migration number. They agreed that whoever merges second renumbers, and by evening this was a written team rule, a "merge train" where each pull request builds on the previous one. After a painful round of force-pushes, the manager changed it to "merge forward, never rebase", and the team adopted it on the next change within minutes.

None of this was a process I designed. It emerged from the friction and was written into the handbook the same day, the way real teams grow their working agreements.

Where this goes next

So far, I have four agents plus a manager: a planner, two developers, and a reviewer. The next step is more managers that schedule tickets and manage workload, and maybe a personal assistant afterwards that coordinates with all of them about my work schedule, to streamline work around me. Let's see.