Herdr is the throughput layer for coding agents

#ai #softwareengineering #opinion #devops

Most AI coding tool discussions still obsess over the agent: model, IDE extension, benchmark, demo.

That is useful, but incomplete. Once agents are good enough, the bottleneck moves to coordination.

If one agent can investigate a bug while I review the diff, three agents can investigate three different things. The challenge is keeping them alive, seeing which one needs attention, and not losing context when the terminal dies or the laptop sleeps.

That is the part of Herdr I find interesting.

Herdr is not another coding agent. It is an agent multiplexer. The short version is "tmux for coding agents", but the important word is multiplexer. It runs where the work happens, keeps real terminal panes alive, understands agent state, and exposes a CLI plus JSON socket API. That makes it less like an app and more like runtime infrastructure.

run it where the work lives

Herdr's homepage is explicit about the shape: it is a binary, not an app. It runs on any box with a terminal, including a server, Mac Mini, VM, or laptop. Each agent runs in its own real terminal. The Herdr server keeps panes alive when the terminal client goes away, and you can reattach locally, over SSH, or even from a phone-sized terminal.

Serious agent work is rarely just chat. It needs the repository, dependencies, test databases, logs, local services, scoped credentials, and sometimes a command you do not want killed because your laptop lid closed.

tmux solved that for human terminal work years ago. Herdr is applying the same basic idea to agent work, then adding the agent-specific bits tmux does not have.

The phone angle sounds cute until you are actually using agents. I do not want to review a payment migration from my phone. I do want to answer a blocked "run the dry-run command?" prompt.

the multiplier is parallelism plus no context loss

The naive AI coding loop is still serial: ask, wait, read, redirect, wait again. That is better than doing everything manually, but the human is still the scheduler.

Herdr is useful because it gives you the pieces for a different loop:

N agents in real PTYs, each on its own task, repo, or worktree
semantic state such as blocked, working, done, and idle
persistent sessions, so work is not lost when the terminal disappears
CLI and socket APIs for creating panes, sending input, reading output, and waiting on state
an agent skill file, so an agent running inside Herdr can learn how to control Herdr itself

The performance gain is not magic. It is ordinary parallelism with less attention waste.

If three tasks are independent, running them one after another is self-inflicted latency. People still do it because supervising multiple agents in plain terminals is annoying. Semantic state changes that. If the multiplexer can tell me "this agent is blocked", "this one is working", and "this one is done", I can spend attention where it matters.

The API is where this starts compounding. Herdr's socket API exposes panes, agents, events, waits, and session snapshots. The CLI wraps common operations, and recent releases added a live-agent CLI facade with named start, prompt, send-keys, and server-owned wait workflows. The supervisor does not have to be a human staring at a terminal.

Here is the concrete workflow I would use.

One human starts a Herdr session inside a repo, then creates three agent panes:

herdr workspace create --cwd ~/work/billing --label billing
herdr pane split w1:p1 --direction right
herdr pane split w1:p2 --direction down

herdr pane run w1:p1 "codex"
herdr pane run w1:p2 "claude"
herdr pane run w1:p3 "opencode"

Then a supervisor, human or agent, assigns narrow work:

herdr agent prompt w1:p1 "Find why refund_webhook_test is flaky. Report evidence only."
herdr agent prompt w1:p2 "Upgrade the Stripe SDK. Run unit tests. Stop before config changes."
herdr agent prompt w1:p3 "Review pending migrations and propose a backfill plan."

Now the supervisor waits on state instead of watching three screens:

herdr agent wait w1:p1 --until done
herdr pane read w1:p1 --source recent --lines 80

Some examples around the project use the shape herdr wait agent-status. Current release notes say wait workflows moved under agent wait, so follow the installed version's CLI reference. The design point is the same: wait for semantic state, then read the relevant pane.

The human still reviews everything. The improvement is that the human is no longer spending brain cycles remembering which terminal was doing what.

where it fits against other tools

tmux and Zellij are the obvious comparison. They are excellent terminal multiplexers. They persist panes, support detach and reattach, and work naturally over SSH. Their limit is that they are terminal-aware, not agent-aware. A tmux pane can keep Claude or Codex alive, but tmux does not know whether that agent is blocked, done, idle, or waiting for approval.

Desktop agent apps usually have the opposite tradeoff. They know more about the agent experience and can provide polished review screens, notifications, and onboarding. The cost is that they tend to live where the GUI lives. If the work happens on a server, Mac Mini, or VM, the app-centered model gets awkward.

Worktree orchestrators are another category. Tools like Conductor, Emdash, and Superset are closer to workflow managers. They can own branch creation, task assignment, diff collection, and review flow. Herdr sits lower. It gives you persistent live terminals, agent state, and a control surface. You can use it with worktrees, scripts, review tools, and whatever coding agents you already trust.

That flexibility is the upside. The downside is that Herdr is still a terminal-native tool. If your team wants dashboards, hosted history, and executive-friendly reporting, Herdr is not trying to be that.

the blast radius goes up too

Parallel agents multiply output. They also multiply mistakes.

This is why I think experienced engineers get the most out of Herdr. Anyone can run it, but the API and parallel supervision are sharp tools. If one agent can produce a bad diff, three agents can produce three bad diffs fast.

The right workflow is boring: narrow tasks, isolated branches or worktrees when needed, explicit verification, and real human review. Treat bypass-permissions mode with respect. Convenience is not a security model.

I like tools that increase throughput without pretending accountability disappeared. Herdr appears to be in that category. It gives the engineering lead a better control plane for terminal-based agents. It does not make the review burden go away.

That is a good thing. The future I want is a runtime where I can run multiple agents close to the code, keep work alive, see state at a glance, and automate the boring coordination. Herdr is aiming at that layer.