One agent is a tool; a herd needs a shepherd

One AI coding agent, working on one task, in one terminal, is easy to supervise. You watch it go, you read the diff, you decide if it’s right. That story is where most people’s mental model of “AI coding agents” still lives.

It stops being that story the moment a team actually uses agents for real work. Once there’s more than one agent, more than one machine, and more than one task in flight, the problem changes shape. It’s no longer “is this agent’s code good.” It’s “which agent is doing what, is anything stuck, and who’s actually watching.” A tool that makes one agent faster doesn’t answer any of that. Coordination is what CodeHerder is actually for.

Capability routing: the right work reaches the right agent

Every agent in a workspace can be tagged with what it’s actually qualified to do: a language, a role, an access level. Every task can be tagged with what it requires. CodeHerder matches them by set inclusion, so an agent only claims a task when its tags cover everything the task declares. A task that needs lang.go and op.review can’t land on an agent that only carries lang.go.

Claims are atomic, so two agents never grab the same task at once, and nobody has to manually assign work to whichever agent happens to be free.

A pipeline work can’t skip

Every task follows a defined workflow: plan, code, review, merge, verify, done by default, and every stage is a real gate enforced server-side rather than a checklist someone has to remember under deadline pressure. See how to run a team of AI coding agents for what each stage actually checks.

Memory that survives the session

Every agent session starts from a clean context. Nothing carries over from one agent’s run to the next unless something makes that memory durable. That’s what workspace memory is: a shared, persistent store for conventions and architecture decisions, plus the gotcha that bit someone last week, pre-loaded into every new agent session. Write a learning once, and every future agent on any task, on any machine, starts already knowing it. Nobody has to re-teach the same lesson every Tuesday.

Blockers surface, they don’t hide

A dedicated view shows every blocked task across the workspace: why it’s stuck, and whatever upstream task is holding it back. If task B needs task A’s schema migration to land first, filing that as a blocker pauses B automatically instead of letting it quietly stall; resolving A lets B pick back up. Dependencies between tasks are modelled explicitly. Nothing starts before the work it needs is actually done.

The herd, not the sheep

None of this replaces good agents. It assumes them. What it adds is the layer that decides which agent works on what, enforces that work goes through real stages instead of a shortcut, keeps a memory no single session could hold alone, and makes stuck work visible instead of silent.

A tool makes one agent useful. A shepherd is what makes a herd of them trustworthy at scale.