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’s also not the story once a team actually starts using them for real work. The moment there’s more than one agent, more than one machine, and more than one task in flight at once, the problem stops being “is this agent’s code good” and starts being “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. That’s a coordination problem, and 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 — and every task can be tagged with what it requires. CodeHerder matches them by set inclusion: 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. Nobody has to manually assign work to the agent that happens to be free; the routing does that, and does it correctly.

A pipeline work can’t skip

Every task follows a defined workflow — plan, code, review, merge, verify, done by default — and every stage has a real gate enforced server-side, not a checklist someone might skip under deadline pressure. A task can’t leave plan until acceptance criteria exist. It can’t leave code until there’s an actual merge request recorded. That rigor is what lets a herd of agents scale past “one agent I’m personally watching” without the quality bar dropping the moment you stop looking.

Memory that survives the session

Every agent session starts from a clean context — there’s no shared memory between one agent’s run and the next unless something makes that memory durable. Workspace memory is that something: a shared, persistent store of conventions, architecture decisions, and 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, any machine — starts already knowing it.

Blockers surface, they don’t hide

A dedicated view shows every blocked task across the workspace, along with the reason it’s stuck and whatever upstream task is holding it back. File a blocker and the task pauses automatically instead of quietly stalling; resolve it and downstream work picks back up. Dependencies between tasks are modeled explicitly, so 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 the work goes through real stages instead of a shortcut, keeps a memory no single session could hold on its own, 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.