The four layers that make autonomy safe.

When I tell people a fleet of agents builds my product, the next question is always the same: what about when it gets it wrong? That's the right question. The answer isn't that it doesn't get things wrong — it does, sometimes with admirable confidence — it's that four layers sit between its mistake and my production. None of the four is a prompt.

I'll go from cheapest to most expensive, which is also from most deterministic to most human. That direction isn't incidental: each layer exists so the next one has less to do.

01 · The contract

Before an agent touches anything, I write three things: which files and interfaces it may touch, what is explicitly out of scope, and how you verify end to end that it works. Three fields. It takes two minutes.

What makes the contract work is not its length — I had eight-field versions and they were worse — it's that the third field is executable. "Make it good" is not a verification. "This test goes from red to green" is. The difference is that the second one can be checked without me, and a verification that needs me is not a safety layer: it's a meeting.

The second field — what's out of scope — looks like filler and is the one that has saved me most often. An agent with no explicit boundary does not stop at the edge of your intent: it fixes three other things along the way, and suddenly you're reviewing a forty-file diff for a one-line fix.

02 · The gate

Every job goes through a binary classification before it starts: the agent can do this, or a person is required. Two states. Auth, payments, the database, secrets and migrations always land on the human side — not because a model can't write a migration (it can) but because the cost of getting it wrong there isn't a bug, it's a phone call telling someone their data is gone.

The permanent temptation is to add a third state. "It depends," "with light supervision," "probably fine." Don't. A three-state gate is a gate that negotiates with itself at eleven on a Friday night, and the one negotiating is you — tired, wanting to be done. The rigidity is the feature, not the side effect.

03 · The pull request

The agent implements, opens a pull request, and stops. It does not merge. Ever. It's the one rule in the system with no exceptions, not even for trivial changes — because an exception for the trivial requires a definition of trivial, and that definition ends up being applied by the agent.

Here I have to be honest, because the pretty version of that sentence is a lie. At this volume I do not read every diff line by line. Claiming I do would be exactly the kind of claim this article is trying to take apart. What I review are the receipts: that CI is green, that the verification contract shows up in the history going red to green, that the automated review flagged nothing. If a pull request is missing a receipt, then I do read the whole thing.

The distinction matters. I am not claiming I read everything. I am claiming that everything that lands arrives with the means to check it. And what this layer buys is not perfection: it's that degradation shows up as "a pull request I reject" instead of as bad code in production. That change of shape is what turns "we'll revert if it gets worse" into a sentence with meaning rather than a wish.

04 · Behavior regression

The first three layers assume something nobody verifies: that today's agent is as good as last week's. It doesn't have to be. You change a rule, the model updates, you rewrite an instruction to clarify it and make it worse. None of that breaks a test — the code still compiles — and yet the work comes out worse.

The fourth layer watches for that. You freeze a set of already-solved jobs, change the rules, ask the agent to solve them again from scratch, and check whether the tests it wrote still pass. Regression — but of the model's behavior instead of the code's.

That layer is not running today. It's written, its methodology is documented, its architecture decision is on the record — and it has never produced a single scored run. I could leave that out: the piece is called "the four layers" and four sounds better than three and a half. But then it would be exactly the hype I'm trying to distinguish myself from.

"A safety system you can't verify isn't a safety system. It's an intention."

That's why the most autonomous mode in my system is still switched off. Not because the first three layers don't work: because the test that would tell me they had stopped working doesn't exist yet. Turning it on anyway would mean having three layers and calling them four — the most common accident in any redundant system: believing in a backup that was never actually wired up.

None of the four layers is clever. They are a contract, a two-state classification, a button the agent cannot press, and a repeated exam. It's the same instinct I brought from civil engineering, where I learned you don't design the bridge for the good day. You design it for the day the material isn't what you specified, and it stays up.