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.

Nido is the next version of that lesson. Mercury is my private workshop. Nido is the product-shaped version: agents that can run for real users, with permissions, spend controls, replay, tenancy, and enough structure that someone else can trust what happened.

The more I use agents, the less interested I am in magic. The interesting work is making them accountable.