Omnigent · chapter 4 of 4

Eighty-five percent of one day's commits carried an agent's name, and the four fixes that mattered most carried mine.

On September 12, 2026 the board merged 200 branches that a card had opened, and 19 of my own came in beside them. Four of those were the fixes that made the day: a scheduler starvation, a batched ship gate, its forwarding fix, an updater that closed admission for three minutes of every five. They came from my branches with Claude Code in the terminal and a co-author trailer on each. The fleet ran the plant. I fixed it. That split is the honest version of “the platform builds itself,” and this note is the evidence for both halves.

The ratios

Since August 22, 55% of all commits on main and 80% of the non-merge commits carry a co-author trailer naming an agent. On September 12 it was 85% of the non-merge commits, 418 of 493. Six hundred and twenty-one merges since August 22 came from branches a card opened, no card twice, and 200 of them on September 12 alone.

Trailer Commits, Aug 22 to Sep 13
The fleet’s own worker identity 1,331
Claude Sonnet 5 457
Claude Fable 5.1 143
Claude Opus 5 79
Claude Fable 5 18
Grok 4.6 7
Claude Code, model unnamed 6
OpenAI Codex 1

Those are trailers, not a reading of the code. A trailer says which agent was in the session that produced the commit, and the fleet’s own identity is on most of them because the dispatched worker signs as the fleet. Codex reviews far more than it commits, so its one trailer understates it.

Two more numbers keep the ratios honest. A card branch carried a median of two non-merge commits on September 12, the mean 2.23, the most 7. Eight of the 200 carried a commit titled “Fix review findings,” one round each. That is the rate of a naming convention, not the rate of revision: two of the chains below carry a second corrective commit that never used the prefix.

Contract first

A dispatched worker does not start from a card title. It starts from a brief: the branch, the worktree, the prior commits on it, the PR if one exists, and a numbered acceptance contract with a file and line for every item the reviewer will check. The brief I keep as the example runs to 51 KB for a research card about model defaults, most of it the contract. The worker’s job is to make each numbered line true and the reviewer’s job is to check each line against the head commit, which is why a pass can be stored as a fact and an executor can act on it without a model.

Fig. 01 — The contract on one card of the chain: intent, acceptance criteria naming the components and tests, the child it depends on, the two files it may touch. — live board, main at bf1ee19, September 12, 2026

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

The reviewer-veto surface is a good day’s work to trace, because it crosses every layer and nothing in it was mine. A standing veto is a reviewer’s blocking finding that the repair loop must not retry past. On September 12 it went from a store predicate to a panel on the phone in five cards.

Link Layer Merged Commits
Shared veto scope and release predicates store 14:38 1
Scope the repair controller’s retry veto to its own signature controller 15:29 2, the second fails closed on an unsplittable signature
Expose standing vetoes on the fleet repair endpoint HTTP API 16:44 1
Type and normalize the veto rows TypeScript client 17:08 1
Render standing vetoes in the repair panel React 17:58 1

Three hours and twenty minutes, first merge to last. The first four carry the fleet’s worker trailer; the panel carries Sonnet 5. The controller’s second commit is the kind of revision the “Fix review findings” count misses: a hardening the worker added after its own first pass, without the prefix.

One card, end to end — the lineage the fleet records card cb869021 session worker Claude Sonnet 5 branch card-cb869021-render- standing-reviewer- vetoes-in-repai… PR #1965 merge 5af537f7d 17:58 deploy ba5cf7d5f 18:19 dispatched produced opened (merged) includes record lives in ~/.omnigent/deploy-on-merge/
Fig. 02 — One real card, end to end: card cb869021 was dispatched to a worker session on Claude Sonnet 5, which produced a branch, which opened PR #1965, merged as 5af537f7d at 17:58, and deployed at 18:19 as part of ba5cf7d5f, a batch of seven merges. The deploy node is dashed because its record lives on the host under ~/.omnigent/deploy-on-merge/, outside git. Read off the fleet's own lineage and deploy records.

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

The chain the lineage graph stores for the last card is the diagram: card to session, session to branch, branch to PR, PR to merge, merge to deploy. The deploy record is the one link the repository cannot show, because it lives on the host, one JSON per finished run, outside git. Read from the host, it says the merge at 17:58 went out at 18:19 in a deploy of seven merges, the server restarted and answered healthy six seconds later, and the host kept the build it had declared until its own updater cycle. Twenty-one minutes from merge to running code.

Fig. 03 — The same card's sheet: time in each stage, the labels the fleet stamped on it, and the epic it belongs to with all five links done. The dependency-graph panel between them is cropped out. — live board, main at bf1ee19, September 12, 2026

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

A card that waited for its dependency

The context-observability pair is the smaller chain and the better one, because it shows the review and the sequencing. The first card exported bounded per-worker context metrics from the local API. It merged at 10:55 after a real round: two reviewers, four blocking findings, one fix commit. The findings were the kind a builder cannot see from inside its own session. Session reads were pulling full item lists, so an 8 MiB response cap was silently discarding exactly the long-running sessions the metric was for. A malformed status was dropped instead of truncated. An invalid peak was being deduplicated into the ledger. The series cap was checked before ingest rather than after.

The second card provisioned the Grafana dashboard that reads those metrics. Its first commit is stamped 6 hours 48 minutes after the first card merged, and its body names the metric family the first shipped. Git cannot show me when the card was filed, only that no work on it predates the merge it depends on. Its own second commit fixed a real defect found only in the dashboard, a transformation order that stripped the labels before the table could read them.

The counterpoints

The batched ship gate merged at 16:02 and covered zero PRs. The production wrapper around the gate offered neither of the batch methods, so the batch never primed, and the log said so: “batch gate covers 0 of 2 shipping-stage PRs.” It took a second fix at 16:44, mine again, forty minutes later, to forward it through. A fleet that ships itself is not a fleet that verifies itself. That is what the canary is for, and the operator.

The canary’s own commits are the other counterpoint. After a deploy that touches the server or the runner, it files a docs-only card, watches it to done, and the card appends one dated line to a file. That commit carries no co-author trailer at all. It is the most boring commit on main and it is the one that proves the loop still closes.

What this note does not claim

It does not claim the fleet designed itself. Every card passes an admission gate I configured, and the four fixes that carried the day were mine. It does not claim the trailers measure authorship of ideas; they measure which session committed. It does not claim a review-round rate; it reports the rate of a prefix. And its deploy edge comes from the host’s own record, not from git, so it is the one link a reader cannot re-derive from the repository.

Underneath

Commit and merge counts, trailers, branch names, and timestamps come from the main branch of the fleet’s repository, read at its September 14, 2026 tip and cut by local day. This note first went out on the evening of September 12 reading the tip of that moment, 163 card branches and 92% of 359 commits; the closed day is 200 and 85% of 493, and the since-August ratios now run through September 13. The board-side count of cards entering merged on September 12, 246, is from the fleet’s stage-interval table: 200 are the card branches above, 43 were closed with no code change, and three I have not traced. The five-link chain and the context-observability pair are traced by PR number and merge time. The deploy record for the chain is the fleet’s own deploy-on-merge receipt for the batch that carried PR #1965, read from the host on September 14.

This project

This project, 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.