Orchestrating Agents Without Becoming a Manager Again

I left team coordination to work alone. Then I spun up four agents and caught myself running a status meeting with robots.

That’s the trap this post is about. The whole promise of solo plus AI is escaping coordination overhead, and the moment you run multiple agents you risk rebuilding it, badly. Divergent context, clobbered files, integration hell, “wait, why did agent two refactor that.” You’re a team lead again, except the reports don’t get tired and don’t push back, which makes the failure mode quieter and easier to miss.

The way out starts with reframing the goal. You don’t want to eliminate coordination. That’s impossible for parallel work of any kind, human or machine. You want to keep the architectural layer, decomposing into bounded components and defining interfaces, and kill the social layer: no meetings, no syncing, no consensus-building. You just decide. I laid out that two-layer split in Components, Not Features; this is what it looks like in practice.

The working principles, in prose rather than a checklist, because that’s how they operate in my head.

Decompose by component, not feature, so agents can’t collide. This is the load-bearing one. Almost every multi-agent disaster I’ve had traces back to two agents with overlapping write access.

Make the interfaces explicit and stable. The written contract is the coordination. That’s what makes the meeting unnecessary: the agreement already exists, in the repo, where both agents can read it.

Accept that you are the integration layer and the reviewer. Judgment at the seams is the one job you can’t delegate, and rubber-stamping agent output is the real failure mode, not agent error. The agents will be wrong sometimes. You waving the wrongness through is the part that turns into an incident.

Keep the boundaries in your head. The working-memory advantage that makes solo fast is the same thing that keeps orchestration sane. The day the component map only exists in a document I’d have to look up, I’ve fragmented past my own limit.

Serialize what’s truly shared. Parallelize only what’s truly independent. Trying to parallelize shared state is how you end up mediating a merge conflict between two processes with infinite patience and no shame.

The objection that deserves a straight answer: isn’t this just management with extra steps? Only if you let the social layer creep back. The expensive part of management was never the decomposition. It was the human synchronization stacked on top: the meetings to agree, the re-meetings when things moved, the politics at the boundaries. Agents need the architecture. They don’t need the diplomacy. If your orchestration involves persuading anyone, the boundary wasn’t clear enough to begin with.

But the honest limit is that there’s a ceiling. Past some number of agents and components, you are a manager again, and the overhead you fled returns wearing a different hat. The failure isn’t gradual, either. It’s the week you notice you’re spending more time routing and reviewing than deciding and building. Know your ceiling and don’t fragment past what one mind can hold. Mine is lower than I’d like to admit on a bad week.

A note that will date this post, on purpose: the tooling is racing to make orchestration feel like one stream instead of many, and some of it is getting close. Until it gets there, the bottleneck is your ability to hold boundaries and review at the seams. Which is, once again, taste.

The dream was never no coordination. It’s coordination with no calendar. The day I’m scheduling my agents, I’ve lost the plot.