Thirty Agents, One Board

One piece of work, end to end

Thirty seats, three vendors, one roster

A seat is a long-running agent session in its own terminal. A seat exists only if it has a line in the roster file in the handbook. Four documents once disagreed about how many seats there were (19, 25, 25 and 26), so now the roster is the only place a seat is defined, and every tool reads it from there. Three more seats on a second machine use the same board.

The board is Postgres, and a row is the brief

Every piece of work is a row in one table: features, fixes, reviews, research tasks, questions for the operator and jobs that need root. A seat that has just been cleared knows nothing except the row id it was handed, so the row's body has to be enough to act on. If the brief isn't written in the row, the row isn't ready to hand out.

inbox→ready→in_review→done·orblockedwith a reason ·cancelled

On 1 October 2026 the board held 2,816 done rows, 128 cancelled, 45 in the inbox, 39 blocked, 26 in review and 2 ready. Rows span 17 repositories. A row is created only after work-task ls has been checked for an existing one, because most work that looks missing already has a row.

A lease, not a lock

Before its first edit, a seat runs work-task take. That one command claims the rows, records the lease, and creates a git worktree on a fresh branch from main. Seats never edit the shared clones. The same instruction can go to every idle seat at once: the take is an atomic compare-and-swap, so exactly one seat wins each row and the rest are refused.

• Refused is a successexit 1: a sibling won

  A seat that loses the race doesn't retry or force the claim. It picks a different row, or stops if nothing is free.

• Leases expire on readno sweeper process

  A lease has a fixed term, usually two hours. Any reader treats an expired lease as free, so a dead seat holds nothing for long. A seat extends its lease at about half-life; 829 extensions are on record.

• Release says how it endedwith evidence

  For a code change, done needs a merged pull request; while the pull request is open the work is in_review, and the release names it. Work with no pull request, such as research or a ruling, closes on other recorded evidence. The release runs as its own command, after the seat has read the output of its work.

• One identity, one claimcollisions are refused

  Two shells once reported the same agent id, and one released the other's live lease with no trace. A second claim under a shared id is now refused, and every forced release is logged: 64 so far.

Eleven checks before work is sent

Work reaches a seat through one dispatcher. It clears the seat's context, checks that the clear was accepted, then sends the row id. Most of its eleven checks run before any seat is touched, and a dispatch they refuse changes nothing. The rest run seat by seat and can stop the work after a seat has been cleared. Whether a clear really reset the session can be confirmed on some vendors' terminals, not all. The tools that relaunch seats share several of these checks.

Counts are from the dispatcher's audit log of live dispatches, 22 September to 1 October. "Before any seat" refusals stopped the whole dispatch. "Per seat" stops left the work unsent on that seat; for the clear and effort stops, the seat may already have been cleared. The two checks marked "not logged" don't write an audit row when they refuse.

• Prompts on screen are respectedone sender per seat

  A keypress that lands on a prompt can answer it, and two seats were once lost that way. The dispatcher looks at each seat's screen before it sends anything, leaves a seat alone while a prompt is showing, and lets only one sender work on a seat at a time.

• Sent is not submittednever prints a tick

  Of 1,841 sends, the dispatcher saw 1,144 start work. It classed 648 as not yet started when it looked, a reading that includes known misreads of the screen, and couldn't tell for 49. It reports each one as it saw it and claims nothing more, and the coordinator follows up the rest.

• A false idle costs a sessionso ambiguity refuses

  The tool that relaunches idle seats weighs two errors. Wrongly reading a seat as busy costs one missed relaunch. Wrongly reading it as idle destroys a live session and whatever is uncommitted. Every signal it can't read counts as busy.

Review, merge and deploy

All the agents push to GitHub under one account, so GitHub's own review approvals can't tell them apart. An approval is a pull-request comment instead, naming the reviewing agent, the verdict and the full 40-character commit it read. An approval of any other commit doesn't count.

How each change gets only the tests it needs, and how the batch lane works: The Nexus CI system.

What a session keeps, and where

An agent's context is cleared between tasks, and a cleared session remembers nothing. So anything worth keeping has to live somewhere that survives a clear and can be read by any vendor's agents.

• The coordinator clears toothe board carries the campaign

  One coordinating session ran 9,636 turns across six leases because it kept a whole campaign in its context. Now the coordinator writes every next step to the board before a clear, and checks that it can rebuild the campaign from two board commands alone.

• The host comes firstmemory load stops new work

  Three agent sessions once exhausted the host's memory. Now, under memory load nothing new is dispatched. Past a high-water mark, a governor freezes agent jobs and thaws them one at a time once the pressure has stayed normal. Heavy runs go through a memory-capped launcher.

Lessons written down along the way

• A clear is a send, and sent is not submitted. One vendor's terminal took a clear command as pasted text and left it in the input box, so the session was never cleared. The dispatcher now sends each vendor its own clear command, checks that it left the input box, retries once, and then refuses.
• Idle seats are not spare capacity. Five tasks were once handed to idle Grok seats because they were idle, and they used up that vendor's quota for the week. The budget gate exists because of that day.
• Verify the outcome, not the text on screen. A relaunch tool reported seven successful restarts and had restarted none. It had checked for a footer that the old, still-running session was printing. Restarts are now verified from the new process's start time.
• Release after reading the result. A release chained onto the end of an edit closed a row as done when the edit had failed. A release is now its own command, run after the seat has read the output.
• One copy of each rule. The dispatcher gained a sixth gate, and three skills that each restated the list still said five. The rules now live on one page and everything links to it.
• A recent reading is not fresh data. For three and a half days the quota meter reported Codex at 91% left, when the real figure had fallen to 22%. The Codex sessions had started writing their usage logs somewhere new, and the meter kept reading the old place. The budget check passed it because the reading itself was recent. The operator caught it by doubting the number, and the fix is on the board.

What I would change

• Make the check that a row is ready to hand out test whether its brief is usable, not just its shape.
• Have each vendor's terminal report that it received the work, so delivery no longer depends on reading the screen.
• Make every control that relies on a reading also check the age of the data behind it.
• Add a human reviewer. Agents from different vendors review each other, but no human other than me reviews the code, so the bus factor is one.