The rules my AI coding agents work under, and why validators detect but never prevent

Agent platform field notes, eight of eight. The previous seven described a platform for governing agents. This one is about governing the agents that help build it, because a governance platform assembled by ungoverned agents would be a joke I did not want to tell.

The question

Thousands of commits in three months, most of them authored with AI coding agents working in lanes. That is how the platform got built, and it raises the obvious question: who decided what those agents were allowed to do, and how would anyone know if they exceeded it?

The answer is a short operating contract that every agent reads before writing anything, and a set of validators that check the result. The contract has five rules. The validators have one honest limitation. Both are worth stating plainly.

The five rules

1. Stay inside the declared write set. Every task names exactly which paths an agent may create or modify: the task’s own allowed paths, a draft directory for that task, and its own result record. Nothing else. The accepted architecture seed, the frozen contracts, the governance registers, the decision records, the validators and the build plan are on a forbidden list that no agent may touch, however obviously useful the change looks. Changing any of them is a human act, recorded as a decision.

2. Never author a decision field. A list of field names may not appear as keys in anything an agent writes: priority, rank, roadmap, funding, owner, sourcing, implementation state, first-party state, and their variants. Those are decisions. Decisions belong to named humans. An agent that writes “priority: high” has not helped; it has forged a signature.

3. Never invent a fact. If a number, a date, an owner or an outcome is not established in the repository, the agent writes “not established” and moves on. The phrase is required vocabulary, not a failure. Everything an agent drafts carries an explicit marker that it is not authoritative.

4. Stop at the human sign-off boundary. The work is organised as packages with decision gates, and most packages end at a point where a named person must sign. The agent does the package, proves it with validators, writes a result record, and stops. It does not proceed to the next package on the assumption that the signature will come. Twenty-five of the thirty-four packages in the strict track end this way.

5. Your result record is a claim, not authority. The task runner derives the state of the work from the repository each time: signed decisions, dependency results, and whether the artefacts a result claims to have produced actually exist. An agent’s own result record is one input to that. If it writes one while the task was still blocked, the claim is void and the validators say so.

The house style that makes the rules checkable

Rules that cannot be checked are wishes. So the repository is built fail-closed. Every schema forbids additional properties. Every artefact must pass its schema and a deterministic validator. Inputs are bound by hash. Generators avoid reading the clock, so output is reproducible. The generated views re-hash their embedded data and render nothing on a mismatch. The generators, validators, schemas and decision records are themselves hashed into an integrity manifest, so a change to any of them shows up as a failed check rather than a quiet pass.

In the platform repository the same spirit applies with different mechanics: agents work in lanes, every pull request is independently verified at its exact commit by a separate verifier, a secrets-on-read scanner runs on everything an agent touches, and “prove once” means a verification is not repeated by hand once it has been recorded.

Odysseus had himself tied to the mast before the sirens, not during. The write set, the forbidden fields and the sign-off gate are the rope. The validators are the crew who check the knots. The crew cannot stop a captain who brought a knife.

The limitation, stated by the contract itself

Here is the sentence I am proudest of, because it is the one most such documents leave out. The contract says, in effect: these checks catch an agent that drifts, misreads, or makes a mistake. They cannot stop one that sets out to defeat them. An agent with write access to the repository can, in principle, edit the validator it is being checked by.

That is why the real controls live outside the repository: restricted write access, diff review by a person, branch protection, and human sealing of anything that becomes authoritative. The validators are detection. The humans are prevention. Pretending otherwise would be the exact failure mode note one warned about, a rule living inside the thing it governs.

What surprised me

Two things.

The rules made the agents more useful, not less. An agent that knows it may not invent an owner stops producing confident nonsense in that field and starts producing a precise list of what is missing. “Not established” turned out to be the most valuable output in the repository, because it is a to-do list written by something that has read everything.

And the binding constraint was never the agents. It was human review capacity. Agents can scale as fast as the people who verify their work, and no faster. Every acceleration I tried that did not also accelerate verification produced backlog, not progress. The operating model, not the model, sets the ceiling.

What I cannot prove yet

Same grade as the rest: this is how one platform was built, by one person and his agents, over a few months. There is no second team, no adversarial red-team of the contract, and no incident where an agent deliberately tried to defeat the integrity checks and was caught by the outer controls. The contract has held against mistakes. It has not been tested against intent.

What to do with this

If you are letting AI agents write code or documents in your organisation, write down the three lists before you write anything else: what they may touch, what fields they may never author, and where they must stop for a person. Then make those three lists checkable by something that is not the agent. Then accept that the check detects and the person prevents, and staff accordingly.

That ends the series. The eight notes together are the argument for one idea: governance is not a layer you add to an agent platform. It is the platform, and everything else is sourced.

The contract reads like a David Brent memo in reverse: no inspirational language, every sentence something you may not do, and for once the staff are grateful.

References

The allusions and quotations in this piece, with their origin:

• Homer, Odyssey, book XII: Odysseus bound to the mast to hear the Sirens.
• The Office (BBC, 2001-2003): David Brent, Ricky Gervais’s manager at Wernham Hogg.