Coding Agents: How I Run Several at Once with Herdr

I work with microservices, so my setup with coding agents grew one repo at a time. Each service got its own IDE window, and each window got its own Claude Code session. On a busy day I spent more time hopping between those windows than doing anything useful, checking on one session, then the next, then the next. The worst part was that I never knew which one actually needed me. A session could be waiting on my answer while I was busy staring at a different one.

If you run more than one coding agent at a time, you probably know the feeling. The Herdr site sums up the problem well. Agents often die when you close the window. You can't tell which agent needs your attention. And handing results from one agent to another means copying and pasting by hand.

I installed Herdr three days ago to fix exactly this. This post covers what it is and the ideas that make it work.

What Herdr is

The project describes itself as "the runtime your coding agents live on". Put more plainly, it's a terminal multiplexer built for coding agents. If you've used tmux, the basic shape will feel familiar. A background server keeps your terminals running, and a client attaches to show them. The difference is that Herdr is mouse-first and agent-aware.

It ships as a single Rust binary, with no Electron. It's free and open source under the Apache 2.0 license. Everything here is based on version 0.9.5 of the terminal app. It's early days, but I've been fascinated by how powerful it is, and I plan to keep testing it. The Herdr site now also promotes a desktop app. This post is about the original terminal version.

Idea one: a persistent server

The first thing Herdr fixes is the most basic one. Your panes live in a background server, not in the window you happen to be looking at. If you detach, close the terminal, or lose your SSH connection, the agents keep working. Run herdr again and you're right back where you left off.

Since version 0.9.4, closing the shell that started Herdr doesn't stop the server either, and sessions now survive a Mac restart. That's exactly the kind of safety net I want when several agents are mid-task.

Idea two: workspaces, tabs and panes

Herdr organizes everything into three layers.

• A workspace is a project-level container, one per repo or per task. With microservices, that maps neatly to one workspace per service.

• A tab is a layout inside a workspace. For example, I might have one tab for agents, one for logs and one for the dev server.

• A pane is a real terminal, split to the right or downward, and it survives the client detaching.

Every one of these gets a short, stable ID, such as w1 for a workspace, w1:t1 for a tab, and w1:p1 for a pane. IDs are never reused after something is closed, which matters a lot once scripts and agents start pointing at them.

You can drive all of this with the mouse: click to focus, drag split borders, right-click for menus. Keybindings are optional. If you prefer tmux habits, there's a prefix key, Control-B by default, followed by a single action. For example, prefix then v splits right, and prefix then c opens a new tab.

There's one more feature that caught my eye, and that's worktrees. The herdr worktree create command makes a git worktree, opens it as its own workspace, and groups it under the parent repo in the sidebar. That gives each agent its own branch and its own folder, so they can work in parallel without trampling each other's files.

Idea three: agents with states

This is the part that makes Herdr more than a nice tmux alternative, and the one that fixed my window-hopping problem. Herdr recognizes the coding agent running in each pane and gives it a state. It does this by finding the agent's process and reading the bottom of the live screen, then matching it against detection rules that update automatically.

The states are simple:

• Idle means the agent is at its prompt, ready for input.

• Working means it's busy.

• Blocked means it's showing an approval, question or permission prompt. This is the one I care about most. Herdr only knows the prompts it's been taught, so an unfamiliar question can still show as idle.

• Done means it finished, but I haven't looked yet. A done agent stays visible in the sidebar until I view it.

• Unknown means an agent is there, but Herdr can't tell what it's doing.

These states roll up per workspace in the sidebar, so one glance tells me which project has an agent waiting on me. Herdr can also send a notification when a background agent finishes or needs input, either inside Herdr, in the terminal, or as a system notification.

Detection covers a long list of agents, including Claude Code, Codex, GitHub Copilot CLI, Cursor Agent, OpenCode, Gemini CLI and more. For many of them there's also an optional integration, which reports the session identity so Herdr can resume the same conversation after a server restart.

The real trick: agents driving agents

Herdr has a command-line interface and a socket API, and they aren't just for me. Any script, or any agent, can use them too. That opens the door to orchestration, where one agent coordinates the others.

Picture asking one agent to handle a bigger job. It splits the work into roles, such as one agent to research, one to build and one to review. It starts each of them, gives each a name, and sends each one its instructions. Then it waits for each one to finish, reads what it wrote, and decides what happens next. Maybe it passes the result along to the next agent, or sends it back with fixes. There's no copy-paste in that loop, and you don't have to sit in the middle of it.

Even more interesting, the agent doesn't just use Herdr. It can rearrange it to fit the task. It can lay out its own workspace and split new panes right beside itself without stealing your focus. It can start exactly the agents it needs in those panes. It can even give each one its own worktree, the feature I mentioned earlier, so they never trip over each other's files. Herdr stops being a workspace only you arrange and becomes one the agent arranges too.

A couple of safeguards keep this from turning chaotic. A prompt won't be typed into an agent that's blocked on a question, so an instruction can't accidentally answer a permission prompt. And a timeout isn't proof that nothing was sent, so the rule is to read the agent before retrying.

To get Claude Code playing along, run herdr --skill and save what it prints as a Claude Code skill. That skill teaches Claude Code to use all of this politely, like never closing a pane it didn't create.

Getting started

On macOS or Linux, you can use the install script from herdr github repo, or Homebrew with brew install herdr.

There are also options for mise, Nix and Windows. Once it's installed:

1. Move into a project folder and run herdr.

2. Start claude, codex or another agent in a pane. Herdr detects it automatically.

3. Optionally run herdr integration install claude so sessions can resume after a restart.

To stay current, run herdr update . There are also eleven built-in themes if you want Herdr to look the part.

Wrapping up

Before Herdr, running several agents meant babysitting IDE windows. Now my agents keep running when I close things, the sidebar tells me who needs me, and the agents can pass work to each other without me in the middle.

If you're already juggling two or three coding agents, give it an afternoon. Start with a single workspace and a couple of panes, then try letting one agent prompt another. That's the moment it clicked for me.