- 23 of 23close items with a current passing verdict from an independent reviewer
- 14 daysfrom opening the work order to closing it on evidence
- 4,297state transitions across 13 agent seats
I built an API integration platform, about 20,000 lines of Rust across five crates, almost entirely through AI agent teams working under my governance system. When the agents reported it done, I did not close it. I required a passing, current verdict from an independent reviewer on every close item, and the system closed the work order only when the last one was in. In the meantime the close machinery had bugs of its own, and I fixed those under the same rules.
The challenge
An agent that says "done" is making a claim, and agents make that claim early and often. For a platform I intended to depend on, "done" had to mean something I could verify afterwards: every acceptance criterion with its own evidence, every close item with a reviewer's verdict, and a close that happened over all of them or not at all.
Constraints
A mixed team, with implementation seats from two model vendors and reviewers drawn from a different family than the builders. Acceptance criteria and close items fixed before implementation started. And a young governance system whose close path had defects, closers that silently stalled and closers that ran away, which had to be fixed without lowering the bar for the work they were judging.
My approach
I authored the reference architecture and a phased plan with gates from B0 to B9, each gate with its own acceptance script and transcript. The close rule was simple: the work order closes only when every close item has a current passing verdict from an independent reviewer. If the platform underneath could not deliver that, the platform was fixed first.
What I built
The API integration platform itself: a Rust runtime that serves multiple integration profiles per server, with release images and a user guide.
An evidence-gated close in which the work order closes only when every close item carries an independent passing verdict.
Contract-carrying review packets, a same-day fix to the governance system so that quality-assurance and gate packets carried their own acceptance contract.
Thirty-five acceptance artefacts across the gates, each a script and a transcript that can be re-run.
Numbered design decisions for the changes that happened in flight, such as moving from one profile per server to many, so the architecture document and the code never silently diverged.
Difficult decisions
Holding the work open. The agents' reports said done. The close items said otherwise.
An override on day one of a governance system is the end of that system.
Fixing the governance machinery mid-delivery, as governed work under the same rules, so the fix itself had evidence.
Writing down divergence. When the implementation needed multiple profiles per server, which the architecture document did not describe, the change became a numbered decision and the document was updated.
Results
about USD 1,500
model usage attributed to the work order, at list price
228
commits over the build
Technologies used
Rust · PostgreSQL · Frontier coding models from two vendors · Shell-based conformance suites · git with witness, task and decision commits
What this demonstrates
I let evidence decide when work is done. I can direct AI implementers through a substantial build while keeping architectural control, and when the tooling I govern with has defects, I fix the tooling rather than relax the standard.
The platform's recovery design is one of my filed inventions, described on the research page.