Back to the work library

Rules, gates and deployment for a fleet of AI agents

I direct AI coding agents using shared operating rules, a tool registry, focused review checks and reviewed deployment procedures.

runningEvidence: measuredCase study
Where
independent
Built from
2026
Source copy reviewed
Evidence status
Source copy checked on 8 September 2026. These historical statements have not been independently re-verified for this website.
On this page

The systems on this site were built this way. This entry describes the method, what it costs, and the one number it measures week by week.

The problem

Directing several AI workers requires clear operating rules, checks that enforce specific boundaries, and a way to distribute reviewed changes across machines.

Earlier work

This followed an earlier attempt at an agent harness. The current system makes deployment, review and recovery part of the operating design.

My role

I wrote or ratified the rules and the gates and specified the deployment; AI agents wrote most of the code under those gates.

What was built

The system includes operating rules, a tool registry, checks and hooks, deployment from a reviewed main branch, scheduled recurring work, and recorded architecture decisions. Its release records describe use across the estate; individual mechanisms still need their own deployment and recovery evidence.

How it works

A proposed change starts with a scope and a named caller. Review and checks determine whether the change can proceed. Deployment and recovery procedures record the version and the operator action, while a handoff preserves unfinished work and the evidence still needed.

Figures and their status
Line chart of weekly rework share on the harness repository: nine readings from early August to early September, flat at zero for the first three, then rising to just under thirty percent.
Figure 1. Weekly rework share on the harness repository, read from the measurement table. Rework is watched because a rising share is the early sign of agents undoing each other's work./media/agent-fleet-operations/rework-share.svg.provenance.yaml

Evidence

The record: deployed, used, measured
EvidenceDated account
DeployedRunning across three machines.
UsedDaily, by me.
MeasuredA dated backup-source rehearsal and recovery-check implementation are recorded.

The source record describes daily operation across three machines. Reviewed configuration, deployment jobs, tool registries and scheduled checks are present in the repository.

A dated August 16 backup rehearsal exercised populated, empty and missing source cases. The recovery code restores a snapshot into a separate directory and distinguishes changed live files from missing or corrupted backup content. Those records establish the checks and the rehearsal; they are not a fresh audit of every machine or a guarantee that every backup restores.

Observed results

Rework is measured weekly. Of the files changed on the main branch in a week, the instrument counts the share touched by a fix or revert commit that had also been changed in the seven days before. That share read 0 percent for the three readings ending 8, 9 and 10 August 2026, when there was no earlier week to compare against. The readings since were 10.2, 6.4, 8.3, 16.3, 20.4 and 28.3 percent, for the weeks ending 17, 22, 24, 26 and 30 August and 6 September. Throughput, quality and cost are not measured, and neither is how often I have to correct an agent.

What this does not show

One operator’s system. No second user, no external audit of the gates, no evidence that the design transfers to a team. The gates catch what they were written to catch, which is not the same as catching everything.

Relevant next action

The personal workspace applies this development method to a product with an interface. For a business workflow, integration or custom tool, see the consulting scope and first engagement.