Earned, Not Configured
You don't hand a new hire production keys on day one. Somewhere in your company, a YAML file just did. Agent trust needs a promotion process, not a config file.
Every organization I know runs two trust systems side by side and never notices the contradiction.
For people, trust is a process. A new hire gets a probation period, small assignments, review, gradually widening scope. Nobody decides on day one what an employee will be allowed to do in year two; the track record decides, and everyone understands this so deeply it doesn’t need saying.
For agents, trust is a config file. Somebody — usually whoever did the integration, usually under deadline — decides at deployment what the system may do, writes it down in YAML, and moves on. The permissions are a snapshot of one person’s guess on one afternoon. Then the agent runs for months, producing thousands of data points about what it can actually be trusted with, and the config file reads none of them.
Trust that is configured is a guess. Trust that is earned is a record. The solo operator runs the earned version instinctively — recalibrating daily what their AI handles unsupervised, without ever noticing they’re doing it. That calibration is the implicit thing. Here is what it takes to make it infrastructure.
The axis: reversibility, not confidence
First, tiers need an objective axis, and the wrong one is seductive: how confident the system sounds. Confidence is a property of the output’s tone; risk is a property of the action’s consequences. The axis that works is reversibility — how hard the action is to undo. My working version has four rungs: read-only actions run free; reversible ones run with logging; costly-to-undo ones want a human on the loop; irreversible ones want a human in it. The pricing test: if the undo is a command, it’s reversible; if the undo is an apology, it isn’t.
I published that ladder some time ago, and last week an engineer I’d never met implemented it in his own incident-response agent. His sharpest finding deserves repeating: the fail-safe default — untagged actions require human approval — has to live in code, not config, so a risky new tool can’t slip through by omitting a field. The floor of the ladder, compiled into the runtime.
The price moves — and only upward
When we compared notes on the implementation, he took the pricing metaphor one step further than I had, and his version is better. The undo’s price isn’t fixed: clearing a cache on a calm afternoon is cheap to undo — it repopulates; the same command mid-incident can deepen the outage. Same action, higher price right now, so it climbs a rung for the duration. And the rule that governs it is exactly right: the moment can only raise the price, never lower it. Context is a one-way ratchet on risk. No emergency makes an irreversible action reversible; no calm makes it safe to skip the human on one that isn’t. A ladder whose rungs can bend downward under pressure isn’t a ladder — it’s the pressure, with extra steps.
Configuration sets the ceiling. Evidence sets the level.
There’s an obvious objection here: somebody still has to configure something. The reversibility tags, the starting rungs, the highest an action class is ever allowed to reach — a person writes all of that down at deployment. Haven’t we just moved the config file, not removed it?
No, and the distinction is the whole point. Configuration should set the ceiling, never the level. The organization decides, deliberately and visibly, the most autonomy an action class may ever earn — the point past which no track record is enough, because the consequences are too severe to delegate however clean the record looks. That is a policy decision, and it belongs in a governed, audited place. But within that ceiling the actual level is earned, not assigned. Configuration bounds the maximum; evidence fills it in.
This dissolves the false rivalry between “configured” and “earned”. A ceiling with no earning underneath it is still just the deployment guess — now with a ceremony. Earning with no ceiling above it is how a clean month talks you into delegating something you never should have. You need both: a bound set by policy, a level set by record — and the only change that should ever be quick is the one that moves a ceiling down.
Which still leaves the ladder incomplete, because a ladder you can’t climb is just a fence.
Promotion: how an action class earns a rung
Here’s the part almost nobody builds. An action class should be able to earn more autonomy — and “earn” has to mean something evidentiary, not vibes after a good month.
The evidence already exists if you’re running the review economy properly: every accept, edit, and reject is recorded. Promotion criteria then write themselves as thresholds on the record — say, N consecutive clean runs, an unedited-acceptance rate above a bar, across a minimum sample and a minimum time window, with zero incidents. When an action class clears the bar, it becomes a candidate for promotion — proposed by the system, decided by a human, logged as a decision. (The implementer landed on the identical constraint from his own side: every approval with no revert is evidence the undo really is cheap in practice — and the rung change is always granted by a person, never taken by the system. Two builds, one rule.)
Notice what this does to the economics of review, because it’s the whole trick: review stops being a tax and becomes a promotion file. Every reviewed artifact is simultaneously quality control and evidence in the case for autonomy. Producers — human and machine — have a reason to want the record kept, because the record is how the work gets faster. That’s the same evidence-buys-freedom deal I described for people; agents get the identical contract.
Demotion: trust that can’t go down isn’t trust
The half nobody wants to build is the half that makes the system honest. Trust must be able to fall, automatically, faster than it rose.
An incident in an action class drops that class a rung, immediately, pending review — not after the postmortem, not at the next quarterly config pass. A repeat pattern loses privileges structurally (we built exactly this for spend: repeat offenders lose auto-resume; the generalisation is obvious). Asymmetry is the point: promotion is slow, evidentiary, human-approved; demotion is fast, automatic, reviewed afterwards. Any system where trust only ratchets upward isn’t a trust system — it’s negligence with a delay timer.
The ladder needs an owner
A tier change is a governance event, not a configuration edit. It should carry the same ceremony as giving an employee production access: a named decider, a recorded rationale, an audit entry. If autonomy can go up because someone edited a file on a Tuesday afternoon, then your real trust policy is “whoever has write access to the repo, under whatever deadline they’re under” — which is to say, the exact failure mode enforcement rows exist to prevent, one layer up. (Downward is the one direction that should be fast for anyone — lowering a ceiling or a rung in an emergency needs no committee, only a log entry afterwards. The same asymmetry as demotion, applied to the ladder itself.)
This also answers the question courts have started asking. England’s judicial statement on AI liability made “the level of autonomy granted and the supervision exercised” the operative facts. A ladder with owners, evidence, and audit entries is the paper trail of autonomy granted — the difference between “here is the documented history of what this system was allowed to do and why” and a shrug.
Trust portability: what survives a model swap
One more design question, because it’s about to be everyone’s question: when you swap the underlying model, does earned trust reset?
The lazy answers are both wrong. “Yes, reset everything” burns months of evidence and makes model upgrades organizationally impossible. “No, keep everything” pretends the thing you measured was the harness alone, when it was the harness with that model in it. The answer that holds: trust attaches to the tuple — the task, the harness, and the evidence — and a model swap invalidates the evidence until re-certification, which is cheap because the evidence machinery already exists: re-run the record’s greatest hits against the new model and diff.
I didn’t invent that pattern; I watched a database-operations builder publish it. His platform scopes stability certificates to the playbook–model pair — swap the model, re-run the cert suite, get the regression diff before promotion. Different domain, same conclusion, independently reached — which, as this series keeps finding, is what a law looks like.
The diagnostic
Three questions for any organization running agents:
When did an agent’s permissions last change because of evidence? If the honest answer is “at deployment,” you have a guess with uptime.
Can a tier go down automatically? If trust only ratchets up, it isn’t trust.
Who owns the ladder? A name, with tier changes in the audit log. If it’s “whoever edits the config,” that’s your real answer to question one as well.
The solo operator does all of this by instinct, invisibly, for free. A team gets none of it for free. Like everything else in this series: what was implicit must become infrastructure — and trust is the row where pretending otherwise costs the most.