Most AI coding tools are still designed around the idea of one human watching one agent do one thing.
That is useful, but it is not the interesting part anymore.
The interesting part starts when you stop treating the agent as autocomplete and start treating it as a worker process. Long-running, interruptible, sometimes wrong, usually useful when the task boundary is clear.
That changes the bottleneck.
The bottleneck is no longer whether an agent can edit files. It can. The bottleneck is whether you can supervise several pieces of agent work without losing state or missing questions.
This is why Herdr caught my attention.
Herdr is not another coding app. It is an agent multiplexer. The shortest description is probably: tmux for coding agents.
the important bit is where it runs
Herdr runs where the work happens.
That can be your laptop, a Mac Mini, a development server, or a VM with the right credentials and dependencies. You start Herdr there, run agents inside real terminal panes, detach, and come back later.
The panes keep running because Herdr has a background session server. The client is just the thing rendering the session. Close the laptop, lose the terminal window, switch machines, SSH back in, run herdr, and the session is still there.
The Herdr docs describe this pretty directly:
ssh you@server
herdr
That matters more than it sounds.
Desktop agent apps can feel polished, but they are usually tied to the machine running the GUI. Classic terminal multiplexers survive SSH disconnects, but they do not know that pane three is blocked while pane five is done.
Herdr sits in the middle: real PTYs, terminal-native persistence, and agent awareness.
throughput comes from parallelism plus zero context loss
The productivity story with agents is often told badly.
People show a prompt, the agent writes code, and everyone argues about whether the output was impressive. That is the wrong unit of analysis. A single agent doing one task is still serial work.
The multiplier is parallel supervision.
Herdr gives you:
- N agents in real PTYs, each working on its own task or repo
- semantic state like blocked, working, done, and idle
- persistent sessions, so a terminal crash does not erase a run
- CLI and socket APIs, so agents and scripts can operate the multiplexer too
That last point is where it gets spicy.
Herdr is not just a pane manager with a nicer sidebar. Its socket API exposes workspaces, tabs, panes, agents, events, and waits. The CLI makes those useful from scripts and from agents.
For example:
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 detail is that agent wait observes agent state, not just whether a shell command exited. A supervisor can wait until an agent is done or blocked, read the output, and decide the next action.
This is the difference between "I have many terminals open" and "I have a small execution fabric for coding work."
a concrete workflow
Imagine a normal platform engineering morning. Not magical. Just three small pieces of work that are annoying to run sequentially.
Agent 1 works on a bug in the API service.
Agent 2 updates Terraform for a staging environment.
Agent 3 investigates a flaky test in a different repo.
A supervisor agent sits in a fourth pane. Its job is to coordinate the herd.
It can split panes, start agents, wait for state changes, and read outputs:
herdr pane split w1:p1 --direction right
herdr pane run w1:p2 "codex 'fix the pagination bug and run the API tests'"
herdr pane split w1:p1 --direction down
herdr pane run w1:p3 "codex 'update staging Terraform for the new Redis size'"
herdr pane split w1:p2 --direction down
herdr pane run w1:p4 "codex 'investigate the flaky checkout test and report the root cause'"
Then the supervisor waits:
herdr agent wait w1:p2 --until blocked
herdr agent wait w1:p3 --until done
herdr agent wait w1:p4 --until done
This is not about pretending review disappears. Review becomes more important. But your attention is not trapped in the slowest task.
If Agent 2 finishes Terraform first, you inspect the diff. If Agent 1 blocks on ambiguous API behavior, you answer that pane. If Agent 3 finds a race in test setup, you decide whether to let it fix the test or stop and file the finding.
The gain is not "three agents write perfect code."
The gain is that you do not pay context loss tax every time one of them pauses.
how it compares
Herdr is closest to tmux or Zellij in spirit. It preserves terminal sessions, panes, tabs, and remote attach. If all you need is persistent shells, tmux is proven and probably enough.
But tmux and Zellij do not understand agents. They cannot tell you which pane is blocked, working, done, or idle. They are terminal multiplexers, not agent multiplexers.
Desktop agent apps solve a different problem. They can be agent-aware and pleasant to use, especially when the workflow is centered on one repo and one machine. The tradeoff is location. If the GUI machine is not where the work lives, you end up pulling the workflow back to your desktop.
Worktree orchestrators are useful too. Some own the branch, diff, PR, and review flow end to end. That can be excellent when you want a managed workflow. It is less attractive when you already have your own repo layout, scripts, terminals, SSH habits, and weird local conventions. Herdr can pair with worktrees, but it does not need to own the whole process.
The tradeoff is that Herdr assumes you are comfortable supervising real processes. That is a feature for experienced engineers and a footgun for careless ones.
who should use it
Experienced engineers will get the most out of Herdr.
Not because beginners cannot run it. They can:
curl -fsSL https://herdr.dev/install.sh | sh
herdr
Senior people benefit more because parallelism only helps when you can decompose work, define boundaries, evaluate diffs, and notice when an agent is confidently wrong.
Parallel agents also mean parallel blast radius.
If you run three agents with broad filesystem access and permission bypasses, you created three fast ways to modify things you may not have inspected. That can be fine in a disposable repo, clean worktree, or container. It is not fine in production infrastructure with ambient credentials.
My practical rule: Herdr makes sense when each agent has a crisp task, a bounded working directory, and a verification command. Review every diff. Keep dangerous permissions boring. Treat blocked states as useful signals, not annoyances to bulldoze.
references
To test my projects, I use Railway. If you want $20 USD to get started, use this link.
Top comments (0)