How I run a dozen AI agents at once

I work on eight projects in parallel, with as many as 17 agents running at peak.

I manage them in Herdr, a terminal workspace for coding agents. Each agent gets its own pane, and Herdr can tell whether it is working, blocked, done or idle. Agents can also read each other’s output and send each other messages.

But the tool only solves visibility. The real bottleneck is my attention: every switch to another pane means rebuilding that project’s context in my head. The more agents I run, the more I become the slowest part of the system.

My answer is a structure with two levels, plus one agent whose only job is to check on the others for me.

Deep conversations with main agents, shallow reads of everyone

Two kinds of conversation run at the same time:

• Me and the main agents: in depth. Each project has one main agent that holds the project’s full context. I align with it directly on the design, the plan and the open decisions.
• The orchestrator and every agent: shallow reads. The orchestrator owns no project. Every 5 minutes it reads the latest output of every agent, and it reports to me only what needs me.

So I see the whole picture without switching between projects. When I need to go deep, I enter one project and talk to one main agent.

Only two levels. A main agent may start subagents: a reviewer, the implementer of one PR, or a few groups working in parallel. A subagent never starts another level. Every agent is therefore at most one step from a main agent that holds the context, and that main agent accepts its work. Any deeper, and responsibility blurs while context leaks away at every level.

Four roles

• Me: I set the direction with each main agent, and I handle the decisions that need me, approval dialogs, and the steps only I can take in a web UI. Risky operations, such as writes to cloud resources or infrastructure changes, need my explicit OK.
• Main agent: owns one project: its context, its plan, its PRs, and a file that records its current state. It owns every PR it opens until merge, including CI, review comments and conflicts. It may start subagents, and it accepts their work.
• Subagent: does one well-bounded task for its main agent, such as implementing a PR, reviewing a design or making one cleanup pass. It reports to its main agent and is closed when it is done.
• Orchestrator: owns no project and no PR. Every 5 minutes it checks every agent, reports what needs me, notifies both sides of any overlap, and relays my answers word for word.

Every 5 minutes: overlaps first, then attention

Every run of the orchestrator follows the same order: the overlap check, the attention check, then the report.

These two checks are the core of the whole setup. With many agents, the usual problem is not one agent getting something wrong. It is two agents each doing the right thing and colliding, or an agent blocked and waiting for me while I have no idea.

Overlap check: one direction per area

Main agents cannot see each other’s context.

An overlap is one area that two agents are both changing or deciding on: a module, a document or architecture decision record (ADR), an interface contract, a PR, a deployment. The orchestrator matches by meaning, not only by path: services/foo and docs/spec/foo are the same area.

When it finds an overlap, the orchestrator notifies both sides at once. Before either one changes that area again, both must know the other’s plan and agree.

These are not overlaps:

• a main agent and its own subagents, which share one task brief;
• an agent that only reads or reviews;
• an area where one side’s change is already merged.

A pair that was notified in the last 24 hours, with no new change since, is not notified again.

Example: two frontend PRs touching the same files

Projects B and E are building separate apps in the same frontend repository.

• The day before, the orchestrator first told both about the shared parts of the repository (the component library, the mock backend, the interface contracts), and they agreed which shared files each one could change.
• 10:11: a PR from project E changed the developer guide and the lock file, and it was next in line to merge. Project B’s newly opened skeleton PR changed the same two files. The orchestrator’s read: aligned (separate apps), but whichever merged second would conflict. It notified both and recorded the pair.
• 10:12: the two agents talked directly and agreed that E merges first and B rebases after. Each wrote this into its state file.
• 10:16: E’s PR merged and was deployed to the development environment.
• 10:36: B finished its rebase. The guide kept both changes, the lock file was unchanged, and type checks, lint, tests and the build all passed.

Nobody came to me. My report gained only one line: “Notified … aligned”.

The notice to project B went roughly like this; project E got the mirror image:

Overlap check (from the orchestrator): you and project E are both changing shared files in the frontend repository: the developer guide and the lock file.
- You: your skeleton PR changes both files.
- Them: a PR that also changes both files is about to merge.
- My read: aligned (separate apps), but the second PR to merge will conflict.
Before you change these files again, send them one message with your plan, read their answer, agree who rebases, and write the agreement into your state file.
If you cannot agree, or the choice belongs to a human, stop changing these files and say so in your reply.

The last sentence is the important one. A conflict the two cannot settle, or a decision that should be mine, is never settled privately between agents. That work stops and shows up in my report as a conflict for me.

Attention check: what counts as “needs me”

After the overlap check, the orchestrator decides for each agent whether it is waiting for me. The key is a precise definition of “needs me”. Too broad, and the report fills with noise I soon stop reading. Too narrow, and a truly blocked agent slips through.

Needs me:

• It is blocked on an approval or question dialog. The report quotes the dialog.
• Its last reply asks me to decide, choose or do something, and nothing has answered it since. A step refused by a permission check counts.
• It reports a failure it cannot fix on its own.
• The host is in trouble: less than 30 GiB of disk left, or Docker not responding. Every agent’s builds and end-to-end tests depend on both.
• A hand-off watcher has not polled for more than 10 minutes.

Doesn’t need me:

• Waiting for a teammate’s approval or for CI. That goes under Waiting.
• Text in an agent’s input box. That is my own unsent input or a suggestion, not a question.
• A question that an answer I relayed has already closed.

Each agent that doesn’t need me appears on exactly one line: Working, Waiting or Idle. Idle agents note their last area of work, so I can decide whether to give them a new task or close them.

The report

The report always has the same shape: overlaps first, then what needs me, then one line each for Working, Waiting and Idle. Here is one from a morning, with the names replaced:

Overlaps: nothing needs you. Notified: developer guide and lock file in the frontend repository (project B ↔ project E, aligned).

Needs you:
1. Project B (new app skeleton): grant the frontend repository read access to an internal npm package.
2. Project A (performance): an infrastructure change that cuts a service to 1 vCPU. Keep it or close it?

Working: project B's implementer (app skeleton); project C's group c (16 end-to-end scenarios)
Waiting: project C's group a (1 of 2 approvals); project D (1 of 2 approvals)
Idle:    chores (Docker and disk cleanup); a test coverage audit
Host:    313 GiB free, Docker OK

It takes a few seconds to read, and then I go back to my own work.

That morning’s three alerts

• 09:45 Docker had stopped, so project C’s group c could not run its 16 end-to-end scenarios, and the main agent asked in a dialog. I chose “start Docker”; the orchestrator started it and answered the dialog. The scenarios ran, and group c opened a PR.
• 09:53 Project B needed a step only I could take in the GitHub web UI: granting the frontend repository read access to an internal package. Once I had, the orchestrator relayed “done”, and project B started on its first frontend PR right away.
• 09:53 Project A had measured the load burst at morning start-up, and asked whether to keep or close an infrastructure change that cuts a service to 1 vCPU. I answered “keep it and start”. A few minutes later it opened a PR whose Terraform plan showed only the expected change.

Without the orchestrator, I would have found out that Docker had stopped only when I happened to look at project C.

Attention goes to decisions

What matters here is not how many agents run, but where attention goes:

• Only I can set the direction and make the trade-offs, so I talk in depth with the main agents.
• “Who is waiting for me” and “who is colliding with whom” can be defined precisely and checked on a schedule, so they go to the orchestrator.
• Two levels mean that every agent’s work is accepted by a main agent that holds the context.

You can run many agents in parallel, but only one person makes the decisions. Keep that person’s attention for decisions, and leave the rest to the process.