Herdr and the throughput argument for coding agents

#ai #softwareengineering #opinion #devops

Most conversations about coding agents are still trapped in a one-agent mental model.

You give the agent a task. It edits files. You review the diff. Maybe it works, maybe it does not. Useful, but still serial work.

The interesting question is throughput.

What happens when you can run several agents at once, keep their sessions alive, know which one needs attention, and let another agent coordinate the whole thing?

That is the angle where Herdr is worth looking at. Herdr is not trying to be another coding app. It is an agent multiplexer. The closest mental model is tmux for coding agents, with enough agent awareness that it becomes more than a pile of terminal panes.

it runs where the work happens

Herdr is a binary, not a desktop app. You run it on the machine where the actual work lives: a dev server, a Mac Mini, a sandbox VM, or your laptop if that is where the repo and credentials are.

If the work is on a server, Herdr runs on the server. If your laptop closes, the panes keep running. If your SSH connection drops, the agents do not disappear with it. You reattach later from a normal terminal, from another machine, or even from a phone SSH client.

ssh you@workbox
herdr

This is the old tmux promise, applied to AI coding work: detach, reattach, keep the process alive. The difference is that Herdr knows more about what is happening inside those panes: real PTYs, persistent sessions, blocked, working, done, and idle state, plus CLI and socket APIs.

That combination is the product.

the multiplier is not magic, it is queueing

The performance argument for Herdr is simple: parallelism plus zero context loss.

If I have one agent fixing a backend bug, one updating docs, and one investigating a flaky test, I do not want three fragile terminal windows. I want three durable workers with visible state.

Herdr gives each agent a real terminal pane. It is not rebuilding the agent UI into a web dashboard. Your shell, keybindings, terminal, and command-line agents stay in play. On top of that, Herdr tracks semantic state, so the human does not need to poll every pane.

The operational loop changes from:

stare at terminal A
alt-tab to terminal B
wonder if terminal C is blocked
lose the whole run when a session dies

to:

start independent work
watch for blocked or done states
review only the pane that needs intervention
detach when life happens, reattach when ready

That is basic throughput. The human supervisor becomes less of a babysitter and more of a scheduler.

the API is where it compounds

Herdr has a CLI and a JSON socket API. The docs split the integration layers sensibly: use the agent skill to teach coding agents how to operate Herdr from inside a pane, use CLI wrappers for scripts and debugging, and use the raw socket API for custom tools or event subscribers.

The socket API covers workspaces, tabs, panes, agents, events, reads, prompts, waits, and state changes. The CLI prints the schema that matches the installed binary:

herdr api schema --json

The docs show:

herdr workspace create --cwd ~/src/payments --label payments
herdr pane split w1:p1 --direction right
herdr pane run w1:p2 "npm test"
herdr agent wait w1:p1 --until done
herdr pane read w1:p2 --source recent --lines 50

The important part is not the syntax. The important part is that a supervisor can wait on meaning, not just process exit. Another process can subscribe to state, read recent output, and decide what to do next.

Herdr also ships an agent skill file. When an agent is running inside a Herdr-managed pane, HERDR_ENV=1 is set, and the skill tells the agent how to inspect neighboring panes, split panes, run commands, read output, wait for tests, and start helper agents.

That is the compounding moment. Once agents can drive the thing that hosts agents, you can move beyond "human starts three prompts" into supervised orchestration.

a concrete three-agent workflow

Here is the workflow I would actually use.

A supervisor agent owns the plan. It splits the work and monitors the other panes.

Agent 1 takes the product code change in the API repo.

Agent 2 updates tests and runs the relevant suite.

Agent 3 updates docs or migration notes in a separate worktree or repo.

The supervisor starts the panes, prompts each agent with a narrow task, then waits.

herdr workspace create --cwd ~/src/platform --label platform

herdr pane split w1:p1 --direction right
herdr pane run w1:p2 "codex"

herdr pane split w1:p1 --direction down
herdr pane run w1:p3 "claude"

herdr pane split w1:p2 --direction down
herdr pane run w1:p4 "opencode"

Then the supervisor watches state. If Agent 2 is blocked because the fixture changed, it reads that pane and asks Agent 1 for the new contract. If Agent 3 finishes early, it checks whether the documentation matches the implementation. When all three are done, the human reviews the combined changes.

This does not remove judgment. It moves judgment to task boundaries, dependency management, diff review, and final integration.

where Herdr fits

The comparison with tmux and Zellij is straightforward. They already solve persistence, pane management, and SSH workflows. They do not understand agents. You can script them, but they do not know whether a pane is waiting for approval, still thinking, or finished.

Desktop agent apps have the opposite shape. They can be agent-aware, and some are pleasant to use, but they tend to live on the GUI machine. That is fine locally, less fine when the serious work is on a server, a VM, or a machine you want to reattach to from anywhere.

Worktree orchestrators are useful too. They can manage branches, tasks, and review flow. The tradeoff is that they often own the workflow. Herdr feels lower-level. You bring your own agent, terminal, repo layout, and process. That flexibility is the appeal, but it rewards people who already know how they like to work.

The honest recommendation is this: Herdr is best for experienced engineers. Anyone can run it, but the people who get the most out of it will be the ones who can design small tasks, supervise parallel work, read diffs quickly, and use APIs without turning every workflow into an accidental platform.

Parallel agents also mean parallel blast radius. If you run three agents with broad permissions, you can get three bad diffs at once. Review changes. Keep tasks scoped. Be careful with bypass permissions modes.

That is why I like the "multiplexer, not app" framing. Herdr does not pretend to solve engineering judgment. It gives you a better control plane for applying it.