A Work Queue Three AI Agents Share

Context

Most “AI agent” demos show one agent doing one task. Running several agents against a real codebase is a different problem: they have different strengths, different costs, and no shared idea of what is already being worked on.

The setup here is three agents with genuinely different economics. One is strong at diagnosis and architecture but metered. One does self-contained build work at no marginal cost. One is a local assistant on free models with a hard 8,000-token-per-minute ceiling. Assigning work well means knowing what each can actually do — and knowing what is already in flight.

Before this existed, each repository tracked its own work fine in isolation. What nobody had was a cross-repo view. A written-but-unassigned task could sit quietly in one repo while everything else moved on, discoverable only if someone happened to remember it. That is not a hypothetical: one directive needed a personal note written somewhere else purely so it would not be forgotten.

The approach

The work items are the source of truth. The server derives every status by reading the task documents themselves — already version-controlled, already the thing a human edits. Writes touch only a marked block inside that document. There is no second database to drift out of sync, and no “the tracker says X but the repo says Y” reconciliation problem.

Every dispatch runs in its own git worktree, on its own branch. An agent cannot touch the working checkout, cannot reach another agent’s work, and cannot commit to the main branch. Isolation is structural, not a rule anyone has to remember.

A human approves every dispatch, and only the human marks work done. The state machine enforces it: an agent can move a task to “in review” but not past it. The approval gate is the design, not a setting.

The evidence requirement is enforced in the prompt each agent receives. Never report something as fixed from memory; paste the output that proves it. A report that says “ok” without evidence is treated as worse than no report.

What it caught

The instrumentation earned itself in one evening.

Eight consecutive dispatches failed. The queue recorded each as “run pid is gone and the directive never moved” — which reads as an agent giving up. It was not. Three separate causes, none of them the agent’s judgement:

• The dispatcher launched agents in a permission mode that auto-approves read-only tools. Every task asked the agent to edit files and run tests, so every run stalled on a confirmation nobody could answer and died mid-task.
• A fresh git worktree carries tracked files only, so it had no installed dependencies. The test tool then tried to download them, which also needs a confirmation.
• A task document written but not committed is invisible inside the worktree. Three runs died looking for their own instructions.

None of those are visible from “the agent stopped.” All three were found by reading the dispatch logs the server keeps, and each fix is now a test: the permission mode, the dependency linking, and the pre-dispatch check that the instructions are actually readable.

Result

Work moves between three agents across more than thirty repositories with one queue and no second tracker. A dispatch that dies is detected rather than mistaken for one still thinking. And the failure modes that cost an evening are now regression tests — 173 of them — rather than folklore.

The transferable part is not the agent count. It is that an automation you cannot audit is an automation you cannot trust: the difference between a demo and something you leave running is whether a silent failure looks different from success.