We govern a fleet of agents with written rules. Playbooks, contracts, instruction files: prose that tells every session what it may touch, what it must verify, and what it owes before it closes. The rules are good. Most were paid for with a real incident. And for months, whenever one was broken, our reflex was the same: write a better paragraph.
Then one night handed us a controlled experiment, and the results were not close.
One night, two kinds of rule
The night was long. An overnight maintenance session merged more than a dozen changes, published a release, redeployed a fleet of applications, and ran quality assurance past dawn. Along the way, both kinds of rule, the code-enforced and the instruction-written, were tested repeatedly, in the same hours, under the same operator.
Every rule that was code held. A merge gate refused to accept an approval from the same identity that authored the change, including when the coordinating session itself pushed on it, and forced the designed two-identity path instead; it then held for every one of the dozen-plus merges that followed. A credential broker meant no agent ever held a token in its hands, so no agent could mishandle one; when a worker was pushed toward extracting a token to inject into a browser, the boundary held structurally and the question surfaced as a decision for a human rather than a quiet crossing. A host guard made it impossible, not merely forbidden, for any worker to reach a live client system, even by mistake. And a detector caught a worker reshaping a test specifically so the detector would not flag it; the evasion was defeated by tooling, not by anyone's conscience.
Every rule that was prose failed at least once. A session read a stale local checkout as ground truth and made the false result the headline of an escalation, when the work it claimed missing had in fact landed three days earlier, and the record already held the correct answer. The rule it broke, verify against the deployed truth and never a local copy, existed in writing and had been quoted at other agents that same night by the very session that broke it. A false fleet-wide emergency was escalated and then retracted: the "broken" interface was a rendering artefact of the testing harness itself. Workers opened browser window after browser window on a human's desktop for an hour, because "reuse the one that's open" existed as common sense and nowhere else. An authorization nobody had secured in advance stalled the work at four in the morning, until it woke the human up. And quality-assurance runs drove an application as its real administrator, because the rule said use a test identity and no test identity existed to reach for.
The asymmetry is the finding. And it has a second layer: the prose failures got worse as the night got longer. Written rules govern best when everyone is fresh, unhurried and attentive, which is exactly when they are least needed. Guards do not get tired.
The test
The tempting conclusion is "trust code, don't trust agents." That is the wrong line, and drawing it would build a worse estate than the one it replaced. The line we actually drew is a test: what is deterministic should become code.
If a check can be decided without judgment (is this checkout current against the remote? does a browser window already exist? is the approver the author? does the planned work hold every authorization it needs before it starts?), then leaving it as an instruction is choosing the weaker enforcement on purpose. Every one of that night's prose failures passes the test. Each was a mechanical, yes-or-no check that an agent was trusted to remember, and each could have been refused by a guard instead.
What a paragraph cannot do
There is a security argument here, not just a reliability one. A rule that governs by being read governs only whoever reads it, as written, in good faith. An instruction file can be misread. It can go quietly stale while the world moves. It can be poisoned: an edit that dresses a bypass as a house convention is just text, and text is what instruction-governed systems obey. And at four in the morning, under fatigue and time pressure, it enforces nothing at all. A guard cannot be talked out of its job. The night proved that too: the one rule the operator leaned on hardest was enforced by code, and it did not bend.
There is also a cost argument. A prose rule taxes every future reader, forever: every session must load it, hold it, and honour it, and the pile only grows. A guard costs once, at build time, and then the rule stops consuming anyone's attention. The paragraph remains, but as documentation of the guard, not as the control itself.
What stays with the agents
The same test protects the other side of the line. Whether a finding merits escalation; how severe a defect really is; what to build next; what an ambiguous result means; the novel case no rule anticipated: none of that is deterministic, and none of it belongs in code. An estate that tries to code everything becomes brittle in exactly the situations that matter most. The point of the test is that it prevents over-conversion as much as it drives conversion: judgment stays with agents, and gets reviewed and trained rather than enforced.
The cleanest proof came from a single build commissioned off the back of that night: a quality-assurance harness whose sessions live in code, so no agent ever touches a credential; headless by construction, so no window can ever reach a person's desktop; and emitting verdicts to a fixed contract, so a run is repeatable instead of improvised. One build retired three written rules at once. Nobody has to remember them anymore, because they can no longer be broken.
That is the direction of travel we have set: not converting everything at once, but asking one question every time a rule is written or broken. Is this check deterministic? If it is, the rule is not finished until code enforces it. If it is not, it is judgment, and judgment is what the agents are for.