Can an orchestrating agent clear a repository's backlog of pull requests and issues using one runner per item, without a single false "done" claim?

Hypothesis

A large share of an open backlog needs nothing from the owner: stale pull requests, fixes that already landed, small agent-ready issues. If an orchestrator hands each item to its own short-lived runner and then re-checks every claim itself with the tools rather than trusting the report, the backlog could be cleared in one morning with the owner spending almost no time. The pass bar was set beforehand: at least 4 merged and verified, 0 false "done" claims, under 30 minutes of the owner's time.

What we built

• A runner brief. One short brief per item, with a collision guard: skip anything changed in the last two hours unless the orchestrator names the owner, because about twenty other agent sessions work the same repository.
• One runner per item, at most four live at a time, 24 in all, each stopped when finished.
• An orchestrator that re-checks every field. Each runner's verdict (merged, stale, needs-owner) was confirmed with gh or a host check before it counted, and a scorecard recorded runner verdict beside orchestrator check.
• A classification step for old work. Before rebasing a stale pull request, every file was labelled same, only-in-the-pull-request, or newer-on-main, so old work could not overwrite newer main.
• A review ladder. Hosted review, then local CLI review, then an independent subagent. The first two were rate limited all morning, so the subagent did the reviewing.

Learnings

• Result. 9 merged, 9 pull requests closed with evidence, 9 issues closed, 3 live deploys verified by a real run, backups taken before each, 0 open pull requests at the end, main CI green. One instruction miss: a runner failed to drop a file it was told to drop, and was caught and fixed.
• Most of the backlog was already done. 7 of 10 open pull requests were landed or superseded elsewhere. The cheapest win was closing them with proof.
• Merges serialise themselves. Every pull request regenerates a registry folder, so each merge made every other open pull request conflict. We merged strictly one at a time. Building the registry after merge would remove that limit, and is the largest lever we found.
• The smallest model was too small. A Haiku runner hit its context guard on a 4-line pull request, because the workflow instructions alone are large. Sonnet runners handled it.
• Independent review earned its keep. The subagent review of one fix found that the original change would have left a dead provider silent forever, and added an escalation plus a test.
• Servers drift from the repository. A live server script matched neither main nor the pull request, so a host-versus-main diff comes before any copy deploy.
• Some work stays human. Anything needing a service restart, a maintenance window, or a key rotation was listed for the owner, not done.

Log

• 2026-10-18: Sweep run in three rounds from about 09:25 to noon. Final count above. A later round added a merged fix for a boot grace window and a draft kernel pull request left for a maintenance window.