I Installed Herdr to Fix My Agents. The Second Week Was Slower.

The first week after I set up Herdr, my parallel agent runs got calmer. The second week, they got slower. The tool that fixed visibility had exposed a deeper problem it could not solve.

The visibility problem

Before Herdr, my agents were panes I switched between. Some were stuck. Some were looping. Some were done and waiting for me. I found out by checking. The checking was the bottleneck.

Herdr fixed that. agent list shows the fleet. agent read shows what each one is doing. The checking time collapsed. I could see all of them at once.

This felt like solving parallel agents. It was not. It was making the actual problem visible.

The orchestration problem

Once I could see all my agents, I noticed how often they were waiting on each other without knowing it.

Agent A finishes a schema change and opens a PR. Agent B has been building against the old schema in parallel. Both worktrees compiled clean. Both PRs passed review in isolation. When A merged, B's branch went stale. When B rebased, half its tests failed.

This is not a visibility problem. I could see both agents the whole time. This is a coordination problem. The agents did not know they depended on each other, because the dependency was not in their prompts.

Why visibility tools cannot fix this

A visibility tool shows state. Coordination requires planning. The plan lives outside the agents, in the task breakdown, in the dependency graph, in the order in which branches should merge.

Herdr can tell me that agent A is done and agent B is blocked. It cannot tell me that B is blocked because A has not merged yet. The causal link is in the work, not in the runtime state.

What actually fixes coordination

Three things, none of them tools.

One: tasks are broken down so that dependencies are explicit. If A must merge before B can finish, that fact goes in the plan.

Two: agents are spawned in dependency order. B does not start until A's PR is merged, or B starts with a clear instruction that A is in flight and B's merge will need a rebase.

Three: review happens at the merge boundary, not at the PR boundary. A PR that passes review in isolation can still break the merge. The merge boundary is where the coordination cost shows up.

Herdr does none of those. It shows you the agents. The plan is yours.

The trap of mistaking visibility for coordination

The trap is that visibility feels like progress. You install a tool, you see your agents, the runs feel calmer. You think the problem is solved. The problem is not solved. It has been exposed.

The slow second week was the exposure. I could finally see how often my agents were blocked on each other. Before Herdr, I could not see it, so I assumed it was not happening. After Herdr, I could not ignore it.

Run this check

Open your last three parallel runs. For each, count the agents that finished without rework after merge. If that number is below the total, your bottleneck is not visibility. You already have the visibility. The bottleneck is the plan.