Running Many AI Agents Without Losing Track of Them

One AI agent is easy. You type, it works, you read the answer.

Five agents is where it falls apart. Five terminal windows, five chats, five projects. One is fixing a bug. One is writing tests. One stopped ten minutes ago to ask whether it may run a command, and you didn’t notice. Another two are editing the same file and about to overwrite each other.

An hour later you find the stuck one, still waiting on a yes or no. The agents weren’t slow. You were the bottleneck, and you couldn’t even see it.

The fix is a workspace built for this. I use one called herdr, and it does three things:

1. One place for every agent. Each project gets its own workspace, and you see all of them, with a live state on each: working, idle, blocked.
2. A rule for how agents report back. Every task ends with either a result or a single question for you. “Idle” alone tells you nothing, so we don’t accept it.
3. Sessions that don’t die. Close the laptop, lose the connection, walk away. The agents keep running and you reattach later, including from your phone.

That’s the whole article. The rest is how each one works.

What herdr is

herdr is a terminal workspace manager for coding agents. If you’ve used tmux, it’s in that family, but it knows what an AI agent is. It recognizes Claude Code, Codex, OpenCode, Copilot CLI, Cursor’s agent and a long list of others, and it tracks their state through hooks or by reading the screen.

The structure is simple, and it’s the same idea as browser windows and tabs:

• Workspace: one project. The top-level container.
• Tab: a layout inside it. Say agents, logs, server.
• Pane: a real terminal. An agent lives in one, or a dev server, or a test run.

flowchart TB
  you["You<br/>laptop or phone"]
  server["herdr session<br/>keeps running"]
  a["Workspace: website<br/>Claude Code: working"]
  b["Workspace: app<br/>Codex: blocked"]
  c["Workspace: research<br/>Claude Code: idle"]

  you -->|"attach / detach"| server
  server --> a
  server --> b
  server --> c

  classDef good stroke:#4ade80,color:#f5f5f5
  classDef bad stroke:#ef4726,color:#f5f5f5
  class a good
  class b bad

The states are the useful part: working, blocked (a permission or question dialog is waiting for you), done (finished, and you haven’t looked yet) and idle. You glance at a sidebar instead of opening five windows.

Point 1: one workspace per project

This sounds cosmetic. It isn’t.

An agent is only as good as the context it starts with. In my setup each project has a folder with its own instructions file, its own tools, its own skills. If the agent starts in the right folder, it loads all of that. If it starts in the wrong one, it’s a smart stranger guessing.

So one workspace per project, and each agent starts in that project’s folder. That’s it. No prompt gymnastics to explain where it is.

I also keep a home session that does no real work. It’s a dispatcher. I tell it what I want (“fix the footer on the studio site”), it works out which project that belongs to, opens or reuses that project’s workspace, and hands the task over. The rule I wrote for it: real work never happens from the home folder, because the wrong context is how you get confident, wrong output.

If a workspace already has an agent sitting idle, the dispatcher reuses it instead of starting a second one. Two agents in the same working tree is how files get overwritten.

Point 2: RESULT or GATE

Here’s the thing nobody tells you about running agents in parallel.

From outside, “idle” looks identical in three different situations. The agent finished. The agent asked you a question and stopped. The agent gave up. herdr catches the obvious case: when a permission or question dialog is on screen, the pane goes blocked. But an agent that ends its turn with a polite “which of these two designs do you prefer?” in plain text just sits there, looking exactly like a finished one.

That’s how an agent waits an hour for you without you knowing.

The fix is a rule, not a tool. Every task I hand to an agent ends in exactly one of two lines:

• RESULT: <summary>: the work landed, nothing needed from me.
• GATE: <one exact question>: I’m blocked on a decision only you can make.

Never both. Never neither. And never “waiting for owner”, because that doesn’t tell me what to decide.

It’s the same discipline as a good handoff between people. “Done” or “I need X from you.” Nothing in between.

Then I wrote a small helper script on top of herdr, hdel, that reads all of it back to me: hdel gates lists every open question across every tracked task. It answers “what’s waiting on me?” in one screen. I run it before I tell anyone something is finished.

flowchart TB
  you["You: one ask"]
  disp["Dispatcher<br/>picks the project"]
  coord["Coordinator agent<br/>in that workspace"]
  ex1["Executor: Claude<br/>builds"]
  ex2["Executor: Codex<br/>reviews"]
  out["RESULT: done<br/>or GATE: one question"]

  you --> disp
  disp --> coord
  coord --> ex1
  coord --> ex2
  ex1 --> out
  ex2 --> out
  out -->|"only what needs you"| you

  classDef good stroke:#4ade80,color:#f5f5f5
  class out good

Delegating inside a project

Inside one workspace, the main agent can hand sub-tasks to helper agents in sibling panes. I call the main one the coordinator and the helpers executors. The coordinator writes the brief. Executors do the hands-on work. I keep the decisions.

The part I like most: the executors don’t have to be the same model. One builds, the other reviews: Claude and Codex, either way round. A second opinion from a different model family catches things the first one is blind to, the same way asking a colleague from another team does. If you already pay for both, use both.

A rule of thumb for what to delegate: if writing the brief forces you to make the design decisions, keep the task. If the brief reads like a work order, hand it off.

And when several agents work on the same repo at once, each gets its own git worktree, a separate checkout of the same project. Two agents, two folders, no collisions. herdr has this built in.

Point 3: sessions that survive

herdr runs a background server. The panes, the agents and their processes live there, not in the window you’re looking at. Detach with ctrl+b q and everything keeps running. Reattach later and it’s all where you left it. You can also name sessions and keep separate ones for separate contexts.

It also works across machines. You can save a remote machine and attach to it over SSH. So the computer at home keeps its agents going while you’re on a train, and you check in from your phone. The network side of that is in the first article : one private network, no VPN toggling. The phone terminal side is in the third .

What this changes in practice: I start something long, close the lid, and the work continues. When I look again, the sidebar tells me who finished and who has a question.

Where it goes wrong

I’d be lying if I said it’s smooth. Things I’ve hit:

• Agents boot slowly. Send a prompt too early and it gets swallowed by a startup screen. The agent looks busy, does nothing, and never reports back. I wait for herdr to confirm the agent is ready before submitting.
• idle isn’t “done”. An idle pane is not proof the work finished. I check the result and the actual changed files. The files are the truth, not the status light.
• Strays cost money. Forgotten idle agents can hold onto quota. My helper lists the ones that have sat around for hours with no open question, and I clear them out.

None of these are herdr’s fault exactly. They’re what happens when you run a small team of very fast, very literal workers. You need rules for handoffs, and you need to check the work.

Try it yourself

You don’t need my whole setup to get the benefit. Start with the smallest version:

1. Install herdr and open one workspace per project you actually work on.
2. Start your agent in each, in the project’s own folder.
3. Add one line to your prompts: end every task with RESULT: or GATE:.

That third step costs nothing and fixes most of the “where did that agent go” problem, even if you never use a tool at all.

In the workshop we build this on your machine. Your projects, your agents, the dispatcher, the RESULT/GATE rule, and a session you can reach from your phone. You leave with it working, not with a slide deck about it.

Because the skill isn’t running one agent. It’s running five without becoming their assistant.