Projects · Omnigent

  • An agent fleet that specs, builds, reviews, and ships my own software
  • operating
  • Builder and operator
  • seven weeks from the fork to this page
  • 2026
  • one operator, 20 cards in flight
  • Claude Code, OpenAI Codex, Python, React, SQLite, ArcadeDB, Grafana
  • Updated
  • 8 min read

Let code own every transition that carries its own proof, and spend the model only where judgment is needed.

What was on fire

An interactive agent could not carry the work I wanted done. I can sit with Claude Code all day and ship, and the moment I stand up, the shipping stops. So I built a board that keeps going: a card moves from idea to spec to build, then through review, fix, and verify until the work survives them, then it ships. The fleet is a hard fork of an open-source harness, Omnigent, and since July the fork has been mine to maintain.

Fig. 01 — The board the fleet runs on: six stage columns, one card per unit of work, the worker state on every card. — live board, main at bf1ee19, September 12, 2026

Fig. 01 · pinch or scroll to zoom · drag to pan

It worked, and it could not explain itself. Early on I went to bed with everything green and woke up to a fleet that had burned through the usage caps of four Claude Code accounts and a Codex account overnight, and the only record of the night was chat logs. Review was taking half of what the workers spent. Cycle time was not a number anyone could query, because the chain from card to PR to merge to deploy lived in prose. One hand audit found about 2,380 lines of merged-quality work stranded on open PRs behind cards the board called done.

The fix was not less autonomy. It was instrumentation: telemetry embedded in the platform, a lineage graph that stores what happened on every card, and the reads that followed. I’ve written up the doctrine before. This page is the system.

Constraint set

The accounts are subscription seats, not metered API. Every dollar on this page is notional API-rate accounting the fleet does for ranking, and the real budget is a usage cap that resets. Effort levels and the WIP cap are budget lines, not preferences.

It is a hard fork I maintain alone. On July 27 the options were track upstream, cherry-pick, hard-fork, or defer. The fork was already 397 commits ahead of upstream’s 88, across 382 files, and I chose to forgo upstream’s fixes from then on. Every bug in the harness is mine.

One operator, and a phone as the console. Models change under the prompts: when Opus 5 replaced 4.8, the prompt library written for the old one stopped landing, so a model swap is a migration, not a menu choice. And the runaway night set the rule for every cap that followed. No one gets full autonomy to do everything.

System diagram

Every card runs the same lane. What changed over 3 weeks is who owns each transition.

One card's lane, and who moves it reviewing → shipping · stored pass fixing → shipping · head-bound verify speccing building reviewing fixing verifying shipping admission verdict verdict into shipping DISPATCH SEAM launches workers from Python; no LLM beat (replaced a ~7-minute coordinator turn) STAGE EXECUTOR moves a card on stored proof: reviewing → shipping on a stored pass, verifying → shipping, fixing → shipping on a head-bound verify; never dispatches SAGA one durable conversation per card; wakes only to decide: admission, a verdict, a block stage executor moves the card on stored proof the saga decides unmarked arrows: the lane's order
Fig. 02 — One card, three owners. The saga is a durable conversation that wakes only to decide — admission, a verdict, a block. The stage executor moves the card on stored proof, never dispatching. The dispatch seam launches workers from Python with no LLM beat, where a coordinator turn used to take about seven minutes.

Fig. 02 · pinch or scroll to zoom · drag to pan

The saga is one durable conversation per card, woken by events, and it decides: admission, a verdict, a block. The stage executor moves a card only on proof it already holds, a stored review pass or a verify bound to the head commit, and it never dispatches anything. The dispatch seam launches workers from Python, where a coordinator model used to spend about 7 minutes deciding to do the same thing. Routing is a table: every dispatch returns a decision that names the rule that made it, and the floors on review of sensitive paths cannot be bypassed by a prompt.

Architecture decisions

  1. Hard-fork the harness. Tracking upstream meant one supervised merge every week against a tree that was diverging by 28 commits a day. Cherry-picking meant reading every upstream commit forever. I forked on July 27 and took the consequence: upstream’s fixes are forgone, and re-joining gets more expensive every week. What I got was a codebase I could change at the seams the fleet needed.
  2. Code owns the transitions that carry their own proof; the model decides the rest. On August 29 a read of the fleet’s telemetry put the orchestrator at 54% of tokens over 7 days, and 63% of its turns did nothing. The fix was not a cheaper model for the shepherd. It was removing the shepherd from every step where the evidence was already stored: a review pass in the database moves the card, a coordinator turn does not. By September 12 orchestration was 3% of the day’s notional spend. Rejected: a cheaper model in the same loop, and prompt trimming, whose effect sizes the design’s own three reviewers refuted before it shipped. The mechanism is in the first chapter.
  3. The reviewer is a different vendor, and the facts are computed once. For about 3 weeks one model built and reviewed, and the bugs arrived after the pass. Now Codex reviews what Claude builds, and before any model reads the diff a deterministic pre-pass computes the mechanical facts, blast radius, contract changes, test adequacy, with unknown as the default grade. A verdict has to be earned. The casting and what a pass proves each have their own note.

Not again: don’t compact a builder’s context on a threshold. Three of seven routine builders compacted in one afternoon on September 11, and one came back above 180k tokens with its tools disabled. The fleet now measures context and leaves it alone.

Recovery / operate path

September 11 was the storm. The timeouts had been sized for a quiet host. A 30-second spawn cap missed 368 spawns in one day: 188 saga carriers, 116 Codex workers, 64 Claude workers. The MCP relay handshake ran 7 seconds at the median and 20 at p90, and 18 of 94 connects timed out. Worker creates took 15 to 30 seconds, and one card collected 5 orphans in 40 minutes. Worst of all, a stalled worker held its slot for 4 hours before anyone reclaimed it: 82% of 204 occupied slot-hours were wedged.

Each fix landed the same day, from my own branches with Claude in the terminal, not from the board. The spawn cap went to 120 seconds, the connect bound to 180, the stall dwell to 30 minutes, which returned 124.5 of 186.4 capacity slot-hours and admitted 15 more cards. Then the cascade: the new 180-second bound sat above older 120-second cadence floors, so the settings page accepted values the gate discarded. That one was found and fixed the next morning.

Fig. 03 — What the operator sees: every gate the fleet must pass, its state, and the setting that opens it. A degraded gate names its own cause. — live board, main at bf1ee19, September 12, 2026

Fig. 03 · pinch or scroll to zoom · drag to pan

Since August 22 there have been 0 reverts on main and 15 commits titled “Fix review findings.” Broken things get repaired forward, with a reviewer. After a deploy that touches the server or the runner, a canary files a docs-only card and watches it to done, scoring cost, human interventions, duplicate dispatch, and wall time, because the merge gate proves the code imports, not that a card still flows.

What changed after

The three weeks between the first telemetry read and this page, in numbers I stand behind:

Measure Before After When
Review’s share of worker spend 50% 26% Jul 27 to Aug 2, then Aug 17 to 30
First stored verdict is a pass 13–14% 81% (13 of 16 cards) Aug 25
Orchestration’s share of daily spend 22% 3% Aug 29, then Sep 12
Cards merged in a day 40 246 Sep 11, then Sep 12
Building stage, median 117 min 23 min Sep 11, then Sep 12
cards entering merged per day 0 100 200 23 20 12 12 17 40 246 188 Sep 6 Sep 7 Sep 8 Sep 9 Sep 10 Sep 11 Sep 12 Sep 13 WIP cap 12 → 20
Fig. 04 — Distinct cards entering merged per day, Sep 6–13 2026, counted off the board's own stage table: between 12 and 40 a day all week, then 246 on Sep 12 and 188 the day after. Part of that jump is capacity, not speed — the WIP cap was raised from 12 to 20 on Sep 12.

Fig. 04 · pinch or scroll to zoom · drag to pan

Two caveats travel with the last three rows. September 12 was wider as well as faster: 166 of the 246 cards were children of one decomposed epic, 197 were routine, and I raised the WIP cap from 12 to 20 that morning because the fleet was not saturated at 12. A queue drained through a wider pipe: the median card took 5.7 hours from ready to merged against 5.4 the day before, and the slowest tenth took 29 hours instead of 16. The next day the board merged 188 more with the median down to 1.9 hours, one more point and not the comparison. Whether the loop got faster or the pipe got wider is the third chapter’s job to separate. It does not fully separate them yet.

And the plant fixes that day were mine. The scheduler starvation, the batched ship gate and its forwarding fix, the host updater that closed admission for three minutes of every five: all four came from my own branches with Claude in the terminal, not from the board. The fleet ran the plant. I fixed it. The fourth chapter has the split.

Anonymization notes

The repository is private and stays private; the upstream project is named because the fork is the first decision. Every number comes from the fleet’s own tables or from the commit that shipped the change, read on September 14, 2026 after the day had closed, and the chapters say which. This page first went out on the evening of September 12 with that day’s count at 202; the closed day is 246, and the chapters carry what moved with it. Withheld: session transcripts, account identities, hostnames, the names of other projects on the board, and card titles beyond the ones the chapters trace. Costs are notional API-rate figures on subscription seats and never a bill. The codebase includes upstream’s inherited harness, clients, and deploy targets, and this page claims none of that as mine. Stack footnote: Python server and scheduler, React web client, SQLite for the board and telemetry, ArcadeDB for lineage, Grafana on the local observability stack, Claude Code and OpenAI Codex as the workers.

Who this is for

  • A team with Claude Code and Codex seats and no system around them.
  • An agent pilot that burned budget nobody can attribute to a card.
  • A review stage that passes, and bugs that ship anyway.
  • A workflow that needs a person at one boundary the vendor tooling doesn’t have.

Chapters, in order

Start

Tell me what’s stuck

I’ll tell you in about a day whether I’m the right person. The first conversation is fit, not a free architecture review.