The Agent Can Push to Main on the Website. On the Consensus Code, It Can't Even Try.

The question I get most often from CTOs in banking, health and public administration is not whether to let AI agents write code. It is how far to let them go before somebody in compliance asks who signed off on that commit.

I'm answering from the builder's seat. Over the last six months my team has shipped two products with AI agents in the loop from the first card to the last deploy: MintID, a KYC-backed identity chain where the hard parts are consensus and cryptography, and ZadQ, an accountability layer for machine payments that sells itself to payment and regulated entities. Full disclosure, because it matters for what follows: I founded MintID and I own the group that builds both. If you want the independent view, it isn't this post.

What I can give you is the mechanism. We don't have one policy for AI-assisted code. We have one per blast radius. The same agents, the same model, the same JIRA board — and a leash whose length is set by what breaks if the agent is wrong.

The leash is set by the blast radius, not by the model

Here is the concrete spread, with the two extremes side by side.

On the MintID public website — pure HTML and CSS, prerendered, no backend, no runtime JavaScript — the agent develops directly on main, and a push to main deploys to production. No branches, no worktrees. The gate is mechanical: lint, tests, a locale check, and an audit script that fails the build if a stray <script> survives or a required artefact is missing. If the agent is wrong, a page looks odd for the minutes it takes to push again. Blast radius: cosmetic.

On the MintID protocol — Go on Cosmos SDK for consensus-visible state, Rust for the cryptographic core — the shared contract every agent loads before touching a file opens with a hard rule in capitals: no agent, under any circumstance, may run git push targeting main. All work lives on feat/MINT-xxx branches. I merge by hand. Blast radius: a determinism bug in a block-execution path, which on a chain is not a bug but a fork.

Between those two poles sits everything else, and the rule that places each repository on the scale is simple to state: the more expensive the rollback, the shorter the leash. A static site rolls back with a push. A consensus rule rolls back with a governance vote and an apology.

Four agents, one human, and a state machine the board enforces

The part people underestimate is that «AI writes the code» is not one role. On the protocol we run four.

• A CTO agent reads the spec and turns a card into an execution brief. It runs on the heaviest reasoning model we have, because a bad spec is the most expensive artefact in the pipeline.
• A Dev agent implements exactly the brief — smallest safe change, test-covered, no speculative rewrites. Opus or Sonnet depending on the card.
• A QA agent validates acceptance criteria, determinism and the privacy invariants, and produces a report with one of three verdicts: PASS, FAIL, CONDITIONAL — and, when not PASS, a routing field: back to Dev, back to the CTO agent, or to me.
• A PM agent is the only one that talks to a human. It moves the JIRA card, dispatches the others, and stops after two failed retry loops with a full summary on my desk.

Every state transition is a card transition on board 166: To Do → In Progress → REVIEW → Done, and Done is the only state I own. The agent never decides it is finished; the board does, and the board's last column has a human name on it. This is not ceremony. It is the difference between «the model wrote most of the code» and «a named person is accountable for every merged line».

The Definition of Done is where the regulation lives

Regulated engineering has a habit of writing compliance into a document nobody opens. We wrote it into the checklist the QA agent cannot skip. Two lines from the protocol's Definition of Done carry most of the weight:

1. Determinism. No network, clock, random, HSM, RPC or FFI call may enter a block-execution path without an explicit, flagged audit item. A new Rust FFI on that path is not a code-review comment; it is a launch-blocking audit item by definition.
2. Privacy invariants. No raw KYC, PII, credential payload, credential serial or presentation log is ever written to chain state — requirements R2, R8 and R18 of the frozen spec, checked on every card.

And the escalation rule that sits above both: anything touching cryptography in the consensus path, or the privacy invariants, escalates to me by default. These are not autonomous decisions. The agents can propose; they cannot dispose.

One more line from the contract that regulated readers will care about: all model inference runs through our own AWS Bedrock account, and the agents are forbidden from introducing dependencies on any public model API. Code that touches identity data is drafted by a model running inside a perimeter we control. It is the same discipline I argued for in the perimeter post: residency is a purchase order; the perimeter is engineering.

Red lines in CI catch the sentence the lawyer would have caught, a week earlier

ZadQ taught us something MintID's code did not: in a regulated product, the copy is code.

ZadQ's marketing surface is built by agents too, and the risk there is not a fork — it is a claim. A savings percentage. The phrase «zero-knowledge» on a v0 surface that hasn't earned it. The word «token» where a payments regulator reads a crypto-asset. So the banned vocabulary is a file in the repo, versioned, changed only by card, and npm run verify fails the build on any match. The list is blunt on purpose: no cost or ROI claims, no cryptography vocabulary the product cannot yet stand behind, no «requires a live…» dependency phrasing (the service degrades to «unknown» and blocks nothing — the copy must say so in the positive form), and no borrowed proof — no «testimonial», «certified» or «uptime» until there is a real one to point at.

Then there is the gate itself. ZadQ's site carried a PUBLICATION_GATE constant that stayed closed — pages de-indexed, build asserting it — until a dated brand-clearance attestation flipped it to open on 20 August 2026. Same mechanism as a feature flag; the feature was «being allowed to exist in public».

I'd concede the obvious objection here: a wordlist is a crude compliance reviewer. It is. It also runs on every commit, at zero marginal cost, and it caught in CI the exact sentences a human reviewer would have flagged a week later on a call. The lawyer still reads the final text. She reads it once.

MintID's own design says the same thing about AI: evidence, never verdicts

There is a pleasing symmetry in this, and it is not an accident. MintID's issuer plane accepts input from AI screeners — document classifiers, liveness checks, the whole KYC tooling market — and structurally refuses any «grade» field a screener asserts. A screener produces evidence, enumerated and provenanced. The issuing authority decides, including the assurance grade, and the type system does not let it be otherwise.

That is the same posture we run on our own engineering: the model produces the diff, the tests, the report. The verdict — merge, publish, ship — is a human's, and the tooling is built so it cannot be delegated by accident. I wrote in June that the model is the commodity and the harness is the moat. Six months of shipping regulated code with agents has only sharpened the claim: the harness is also the compliance story.

What it produced

I'll keep the numbers to the ones I can defend. The protocol's first end-to-end network bring-up — chain node plus verifier service, reproducible from a package in minutes — found zero defects in protocol code; everything that broke was deployment tooling, fixed on the spot. The embedded squad that built the core and the three verifier SDKs delivered every milestone on date with zero bugs, and the client renewed at twice the original budget — that story is public. ZadQ went from first commit to a live site in ten days, and to a developer portal, full terms and a blog inside three weeks, with every one of its 51 commits carrying a card number.

None of that is a mainnet, an audit or a customer count, and I won't dress it as one. It is evidence that agents can carry a regulated codebase at speed when the leash is engineered, not assumed.

What I'd do this quarter if I were your CTO

1. Classify every repository by rollback cost, not by team. Three tiers are enough: «push to deploy», «branch and human merge», «branch, human merge and audit item».
2. Write the agent contract as a file the agent loads first, not as a Confluence page. Mission, source of truth, hard rules, non-goals, required output format. If it isn't in the context window, it isn't a rule.
3. Split the roles. One agent that specs, one that implements, one that reviews with a three-state verdict and a routing field. The reviewer must not be the author.
4. Put the regulation in the Definition of Done as checkable lines — the invariants your auditor will ask about, phrased so a reviewer can answer yes or no.
5. Make escalation the default for the dangerous path. Cryptography, consent, money movement: the agent proposes, a named human disposes.
6. Treat copy as code where claims are regulated. A versioned wordlist and a build that fails on a match.
7. Keep inference inside your perimeter for anything that reads regulated data. Bedrock, a private endpoint, your own hardware — the point is that the model runs where your data already lives.

Six months ago the honest answer to «how far do we let the agent go» was «we're finding out». Now it is: exactly as far as the rollback is cheap, and not one commit further. The agent can push to main on the website. On the consensus code it cannot even try — and that sentence, not the model behind it, is what I'd show your regulator.

If you're standing up an AI-assisted team inside a perimeter like this, tell me what the perimeter looks like. The leash design is the part worth getting right first.