25 coding agents across 5 harnesses run as a team from one terminal

Andrei Rebrov@andrebrov

My biggest recent discovery - @herdrdev.

This is wow I run 25 AI coding agents like a team, not a chatroom.

1/ I run ~25 coding agents across 5 harnesses (Claude Code, Codex, opencode/GLM, Grok, agy) from one terminal console (herdr). Each agent has a role — coder, reviewer, judge, design, PM, SRE, architect — and its own git worktree on fleet/<name>. No agent ever pushes. One lead lands.

2/ Work is a file, not a chat. Issues are beans (t.co/YkAH1VHCq9): markdown files committed on main. A bean that isn't on main doesn't exist — agents in worktrees can't see it. I learned that the hard way: 23 bean files deleted on one branch, invisible for hours.

3/ Prompts don't scale. Long prompts silently don't land. So every assignment is a brief file on disk plus a one-line pointer: "read this file and do it." The brief carries the evidence, the rules, and the exact announce command.

4/ Nobody polls. When an agent finishes it runs fleet-done <agent> <bean> DONE|BLOCKED|CHANGES "<one line>" <report>. That drops a message in an inbox. A watcher loop (60 s tick) does the rest. The lead reads headlines, never logs.

5/ The watcher's rules, all written from incidents:
— coder DONE → review on a different harness (a model never reviews itself)
— reviewer CHANGES → a followup lane the coder gets before anything from the queue
— an unrouted DONE goes to a retry lane, not the void
— a bean not on main, not open, or already in flight is never dispatched
— an announcement for a bean you're not on is logged STALE and ignored
— a harness that's out of credits is never dispatched to (GLM ran dry twice; the first time it idled 10 seats for 40 min unseen)

6/ Status is a lie. Fleet status says "done" while an agent is mid-turn, and a pane can show an empty prompt next to 13 minutes of real work. I judge by artifacts only: code commits since dispatch, last-commit age, report file mtime. A coder with no code commit and no report after 15 min gets flagged.

7/ Landing is the lead's job and it's mechanical: cherry-pick the approved commit into a verify worktree, build + suite, merge --no-ff, push. The pre-push hook runs build + related tests again. A push is the deploy. Today: 8 landings, each one reviewed on another model and built twice.

8/ Reviews are gated, not vibes. Every verdict ends BEAN: MET|UNMET / LANDABLE: YES|NO / VERDICT: APPROVE|CHANGES. Reviewers cherry-pick the named commit onto main and build it — a green branch that only flipped a status field is CHANGES.

9/ Quality has a definition. For marketing emails (at @FinsiAI we run automated marketing for commerce brands, including email marketing) output the judge grades renders against 20 named checks (contrast ratio, palette membership, CTA radius vs the harvested brand value, section fills, images resolving at send time, one primary CTA, vision scores at 600 and 390 px…). 9/10 = all 20 pass, no averaging. The bench re-runs after every landing.

10/ Retros are counted, not discussed. The session is fully recorded, so the retro mines artifacts: 4 of 13 verdicts today were CHANGES for branch location only; 4 of 63 announcements had no consequence before the lanes existed. Each class gets a metric that can fail next sprint.

11/ The lead makes mistakes too, and they're counted the same way: a queue entry with newlines in it, a race between clearing a task file and the watcher, three beans to one agent. Every one became a guard in the watcher, not a reminder in prose.

12/ Biggest lesson: prose rules don't survive contact with a shell. "Agents never apply migrations" held until an unquoted heredoc executed one. Now the migration runner refuses production without a lead-only flag. If a rule can't fire, it isn't a rule.

13/ Cost of all this: one 16-core box at load 350, and a lead whose job is routing, landing, and counting — not coding. That's the trade: agents do the work; the system makes the work visible.