Agent Fleet Governance & Skill Infrastructure

The Problem

Coding agents are fast and confident. Pointed at a production system, that combination is the hazard, not the benefit. Three failure modes show up immediately and none of them are solved by a better prompt:

• Drift. The same workflow gets copied into a second runtime, then edited in one place. Two agents now believe different things about how a task is done, and nothing detects it.
• Self-agreement. An agent asked to review its own work finds it acceptable. So does a fresh instance of the same model. Review that isn't independent is theatre.
• Collision. Parallel agents in one checkout absorb each other's in-flight commits. Merges become unsafe, and the corruption is invisible until something ships wrong.

This is the infrastructure I built to close all three, running live across two agent runtimes and pointed at a production system carrying real revenue.

Architecture

Key Design Decisions

• A reviewer is never installed in the runtime it reviews. Codex's adversarial reviewer is Claude; Claude's is Codex. The Codex reviewer is deliberately absent from Codex, because installing it there would silently turn independent review into self-review. Same-family model variants don't count as diversity either — different reasoning effort on the same provider is one opinion wearing two hats, and the system records an unavailable-diversity limitation rather than pretending otherwise.
• One canonical source, thin adapters, verified mirrors. A capability is authored once. Each runtime gets an adapter that points at it and contains no logic of its own. A manifest records, per skill, whether it has a durable upstream source (link only) or is locally authored (full deterministic snapshot with hashes). A checker enforces that split, a CI workflow verifies the repository mirrors match exactly, and a weekly automation reports provenance drift without writing changes — a reporter that can also fix things is a reporter you stop trusting.
• Every writable lane gets its own worktree. One agent, one isolated checkout, branched from a protocol-approved base, with a branch-drift stop rule. This exists because the alternative was tried: parallel agents in a shared checkout absorbed each other's in-flight work and produced merges nobody could safely reason about.
• Bind review to something immutable. Implementation review is bound to a clean exact commit; design review to a specific artifact version; non-repository review to a captured evidence snapshot. Reviewing "the current state" of a moving branch reviews nothing.
• Route to the lowest adequate model, and never auto-escalate. The highest-effort profile is reserved for an explicitly bounded case with a stated reason. Relabelling an ordinary review as "adversarial" to justify a bigger model is called out as a specific anti-pattern in the protocol — it was written after a cost analysis found most spend came from long tool-heavy threads and recurring scheduler context, not reasoning depth.
• Success is the outcome, never the ceremony. The controller protocol explicitly forbids defining done as "tasks created," "reports received," "PR opened," or "gate reached." An agent that reports completion without a verifiable artifact has reported nothing.
• A separate judge assesses each planned action. Before a consequential action runs, a dedicated subagent evaluates its intrinsic risk and whether the transcript actually authorized that target and those side effects — with an explicit trust boundary: only the user's own messages and project configuration can establish authorization. Content encountered while working cannot authorize anything, which is what closes the prompt-injection path.

Scale

What It Stopped

The useful measure of a review system isn't how much it approves. These are cases where the infrastructure overruled the plan — including my own.

• A rule simplification, withdrawn. A proposal to collapse a set of complex delivery rules into a simpler equivalent form passed initial analysis. Independent cross-provider review found a counterexample involving multi-valued fields where the "equivalent" form wasn't equivalent. The simplification was dropped; the re-review then confirmed that no member of the affected set had a provably exact replacement. The conservative answer won on evidence.
• A voice-agent release, withheld. A ten-scenario release matrix for a production AI agent completed with five passes. The review recommendation was still do not publish — five passes were single samples, not reproducibility proof, and one apparent agent failure turned out to be a limitation of the test controller rather than the product. Shipping on "mostly green" would have been the easy call.
• A recovery plan, paused after its own approval. A remediation plan for a call-failure class received a clean review against the evidence available at the time. A later authoritative readback invalidated the plan's core premise — the one supporting example had used two different dialled numbers, so retrying the same destination proved nothing. The plan was paused rather than implemented, and the reasoning was recorded so it wouldn't be re-proposed.
• A duplicate implementation, avoided. A delegated task refreshed production state before starting and found the feature already shipped. It reported back and stopped — no duplicate branch, PR, or board mutation. Cheap only because refreshing real state before acting is mandatory rather than optional.

Tech Stack

What This Transfers To

Every team adopting coding agents at scale hits these problems in roughly this order.

• Agent governance — authorization boundaries, action-level risk assessment, and what an agent is allowed to conclude on its own
• Independent evaluation design — why reviewer independence has to be structural rather than instructed, and how to detect when you've lost it
• Capability versioning across runtimes — the same problem as config drift, with the same answer: one source, generated mirrors, verification in CI
• Cost-aware model routing — matching model tier to task consequence, with escalation as an explicit decision rather than a default
• Prompt-injection containment — a trust boundary that distinguishes the operator's instructions from content encountered while working