A Fleet of Coding Agents Needs a Manager, Not a Bigger Model

One coding agent in a terminal is a tool. Five of them running in parallel is an organization, and organizations fail for organizational reasons.

I built engineering-manager-for-agents after watching the same three failures repeat: agents duplicating each other's work, agents quietly burning budget on a task that was never going to converge, and agents producing changes nobody could review because there was no record of what any of them had been asked to do.

None of those are model capability problems. Every one of them is a management problem.

The shape of the harness

The design is deliberately unoriginal, because the pattern it copies works:

One planner, many ICs. A single agent decomposes the work and delegates. The workers never talk to each other, only to the planner. Fan-out with a single point of coordination.
One task, one workspace, one branch. Each worker gets an isolated checkout and pushes through git and the GitHub CLI. If two agents touch the same file, that conflict surfaces as a merge conflict, where humans already know how to resolve it.
Sessions you can look at. Workers run in tmux panes. When something goes sideways you attach and read the transcript, rather than reconstructing it from logs after the fact.
A budget per task. Every delegation carries a hard ceiling. Hitting it ends the task and reports back.

Budgets are the load-bearing part

The budget is the piece I would keep if I had to throw everything else away.

An autonomous agent has no sense of sunk cost. It will happily spend an hour and a large pile of tokens circling a problem it cannot solve, and because it is producing plausible intermediate output the whole time, nothing looks wrong from outside. A wall-clock or token ceiling converts that silent failure into a loud one.

# A worker that exceeds its ceiling is stopped and reported, not left running.
delegate --task "migrate the auth middleware" --max-tokens 400000 --timeout 25m

The number matters less than the fact that there is one. What a ceiling buys you is not savings. It is the guarantee that every task terminates, which is what makes the whole fleet observable.

Autonomy without a termination condition isn't autonomy. It's an unbounded loop with better prose.

What delegation has to carry

The quality of a delegated task tracks almost entirely with how well the boundary is specified. The prompts that worked shared a structure:

The goal, in one sentence.
The files or directories the task is allowed to touch.
The definition of done, expressed as a command that either passes or fails.
What to do when blocked, which is always "stop and report", never "improvise".

Point four is the one that gets left out. An agent that improvises past a blocker produces work that looks finished and isn't, and you will not find out until review.

What this does not fix

Being honest about the limits:

Review does not scale for free. Five agents produce five pull requests, and a human still reads them. The harness makes work parallel, not weightless.
Decomposition is still the hard part. A badly split task fails no matter how well it is supervised. The planner is the bottleneck, and improving it is mostly prompt work.
It rewards well-factored codebases. Parallel agents on a tangled repo mostly generate merge conflicts.

The takeaway

The instinct when a fleet of agents underperforms is to reach for a better model. Usually the better return is on the boring parts: clear task boundaries, isolated workspaces, hard budgets, and a transcript you can read.

The code is MIT licensed. If you try it, the piece I would most like feedback on is the delegation format, since that is where most of the leverage lives.