The annoyance of multiple agents

One agent is a helper. Several agents are a system.

The annoying thing about multiple agents is that the impressive demo is not the hard part. Getting one model to write code, inspect a page, or summarise a plan is useful, but it is not the thing that breaks first.

The thing that breaks is orchestration.

Who owns the task? Which context is current? Which branch is safe to edit? What has already been tested? What happens when one agent finishes late, another has stale assumptions, and a third confidently works from yesterday's plan?

That is why I built Mercury. I wanted a control plane rather than a pile of chats. Kanban as state. Agents with roles. A dashboard. Audit trails. Telegram, Slack, and CLI entry points. A place where the work could be routed, paused, resumed, and checked.

Mercury taught me that agent work needs boring operational machinery around it. Queues, limits, status, memory, review, and a clear idea of who is allowed to do what.

I tried to take that lesson further by rebuilding Mercury into a product-shaped version: multi-tenant, permissioned, running agents for someone other than me. What I actually learned rebuilding it was different from what I expected going in. The custom agent SDK layer I'd built for Mercury wasn't the load-bearing part. Portable coding agents had gotten good enough on their own that a bespoke orchestration runtime underneath them was overhead, not infrastructure.

I killed the rebuild and kept only the piece that was actually earning its keep: the task tracker. That became Cockpit - a standalone, tool-agnostic API any agent can talk to, with none of Mercury's runtime underneath it. It's now the shared task home across everything I'm building, including itself.

The more I use agents, the less interested I am in magic. The interesting work is making them accountable, and knowing which parts of your own infrastructure are actually worth keeping.