Herdr and the throughput argument for coding agents

<p>Most conversations about coding agents are still trapped in a one-agent mental model.</p> <p>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.</p> <p>The interesting question is throughput.</p> <p>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?</p> <p>That is the angle where <a href="https://herdr.dev/" rel="noopener noreferrer">Herdr</a> 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.</p> <h2> it runs where the work happens </h2> <p>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.</p> <p>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.<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code>ssh you@workbox herdr </code></pre> </div> <p>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.</p> <p>That combination is the product.</p> <h2> the multiplier is not magic, it is queueing </h2> <p>The performance argument for Herdr is simple: parallelism plus zero context loss.</p> <p>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.</p> <p>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.</p> <p>The operational loop changes from:</p> <ol> <li>stare at terminal A</li> <li>alt-tab to terminal B</li> <li>wonder if terminal C is blocked</li> <li>lose the whole run when a session dies</li> </ol> <p>to:</p> <ol> <li>start independent work</li> <li>watch for blocked or done states</li> <li>review only the pane that needs intervention</li> <li>detach when life happens, reattach when ready</li> </ol> <p>That is basic throughput. The human supervisor becomes less of a babysitter and more of a scheduler.</p> <h2> the API is where it compounds </h2> <p>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.</p> <p>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:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code>herdr api schema <span class="nt">--json</span> </code></pre> </div> <p>The docs show:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code>herdr workspace create <span class="nt">--cwd</span> ~/src/payments <span class="nt">--label</span> payments herdr pane <span class="nb">split </span>w1:p1 <span class="nt">--direction</span> right herdr pane run w1:p2 <span class="s2">"npm test"</span> herdr agent <span class="nb">wait </span>w1:p1 <span class="nt"