Most AI coding tools are still discussed as if the unit of productivity is one engineer paired with one agent. That is useful for demos, but it is not where the workflow is going.
The interesting question is whether you can keep several agents moving without losing terminal state or control of the diff.
That is why Herdr caught me.
Herdr describes itself as an agent multiplexer. That distinction matters. It is not trying to be the app where all work happens. It is closer to tmux for coding agents, with agent awareness added to the terminal persistence model.
You run it where the work lives, a server, a Mac Mini, a VM, or a remote dev machine. The agents run in real terminal panes. The session keeps going when your laptop closes. You can reattach over ssh, including from a phone.
That is where I think agentic development is moving. Less "one magical app" and more "a runtime for supervised parallel work."
Throughput comes from parallelism
The obvious gain is multiple agents side by side. One pane can fix a bug. Another can write tests. A third can explore a dependency upgrade. Each agent has its own PTY, working context, and terminal process.
You can already open three terminal tabs and do this manually. The problem is attention. After the second or third agent, the bottleneck stops being model speed and becomes supervision. Which one is blocked? Which one finished? Which one is waiting?
Herdr's useful addition is semantic state. It tracks agents as blocked, working, done, or idle. That turns terminal panes into something closer to an operational dashboard, without turning it into a browser dashboard. You scan the session, jump to the pane that needs you, approve or redirect, then move on.
This is the real throughput model:
- more agents can be active at the same time
- the human only pays attention when attention is needed
- terminal state survives disconnects
- agents can coordinate through the Herdr control surface
The compounding part is the last one.
Herdr exposes a CLI and a JSON socket API. The docs show commands for creating workspaces, tabs, and panes, running commands, reading output, and waiting for an agent. The socket API exposes similar control over workspaces, tabs, panes, agents, events, and state.
That means the multiplexer is not only for humans. An agent can use it too.
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
You should not read that as a cute automation trick. Read it as a new shape of engineering workflow. The supervisor agent can create panes, start helper agents, wait on status, read their output, and summarize what needs human review.
A concrete workflow
Imagine a service migration with three independent pieces of work.
Agent 1 owns the API change, request validation, response serialization, and contract tests.
Agent 2 owns the database side, migration, seed data, and local integration suite.
Agent 3 owns the client and documentation changes, SDK, examples, and changelog.
A fourth agent acts as supervisor. It starts the other three in separate panes, waits for state changes, reads recent output when a pane becomes blocked or done, and keeps a short coordination note. When Agent 2 finishes but Agent 1 is blocked on a failing contract test, the supervisor surfaces that problem.
The human still reviews every diff. The human still decides whether the migration is acceptable. The human still owns the merge.
But the waiting time changes. Instead of doing these tasks sequentially, three streams move while a supervisor watches for interrupts. If each task takes 25 minutes of agent time and 5 minutes of human review, the win is not "AI wrote code." The win is that the 75 minutes of agent time overlaps.
That is a practical productivity multiplier. Not magic. Scheduling.
How it compares
The closest mental model is tmux or Zellij. They give you persistent terminal sessions, panes, detach and reattach. They are excellent tools. I still like tmux. But they do not know what an agent is. They cannot tell you that a coding agent is blocked, done, idle, or still working.
Desktop agent apps have the opposite tradeoff. They are often agent aware, with nicer task views and more explicit review flows. The cost is location. If the app lives on the machine with the GUI, the work is tied to that machine. That is awkward when the real environment is a server, a Mac Mini, or a VM. Herdr's pitch is that the runtime lives where the work lives.
Worktree orchestrators can be powerful because they own the workflow: branches, worktrees, checks, and review surfaces. The tradeoff is structure. That can be good for teams with a standard process and annoying when you want a flexible terminal runtime for whichever agent, repo, or task shape you are using today.
Herdr is not automatically better. It is narrower and more Unix flavored. You need to be comfortable with terminals, panes, ssh, and reviewing diffs. If you want a polished desktop cockpit, this may feel too low level. If you want a product that owns ticket to PR, Herdr may feel too flexible.
That is fine. I prefer tools that know what they are.
The blast radius gets parallel too
The warning is obvious but worth saying plainly.
Parallel agents mean parallel blast radius.
If you run three agents with broad permissions in three repositories, you have not only multiplied output. You have multiplied the number of places where a bad instruction or reckless shell command can do damage.
Herdr does not remove the need for engineering judgment. It increases the need for it. Review diffs. Keep tasks scoped. Do not hand bypass permissions to agents casually. Be careful with secrets and production access.
This is why I think experienced engineers get the most out of Herdr. Anyone can run it, but the leverage comes from knowing how to split work safely, what to delegate, when to interrupt, and how to verify. The API is especially interesting if you already think in automation boundaries and failure modes.
Herdr is not a replacement for judgment. It is a way to spend judgment on the right pane at the right time.
For me, that is the more honest story about AI coding throughput. The future is not one agent perfectly doing your job. It is multiple imperfect agents running in parallel, with persistence, state, and supervision good enough that the human can stay above the noise.
That sounds less magical than the usual AI productivity pitch. It also sounds much closer to real engineering work.
References
To test my projects, I use Railway. If you want $20 USD to get started, use this link.
Top comments (0)