An autonomy tier model sorts agent-authored change by how expensive it is to be wrong, with a named gate and owner per tier, written before the first bad merge forces the question.
By JP LeBlanc
An autonomy tier system sorts agent-authored change into a small number of classes by how expensive it is to be wrong, not by what kind of task it is, and gives each class a named gate and a named owner who can move work between classes. Build it before the first bad merge forces the question, because the version you write after an incident is a restriction, and the version you write before one is a policy.
At CircleCI, agents merged to main with no human approval, ramped through 2025. Not everywhere at once. The ramp went in a specific order: dependency bumps first, then documentation, then front-end code, with changes to the test suite itself a target the whole way through, and changes to database schema dead last. The gate at every step was the same validation suite, not a person: lint, style, security scans, end-to-end tests, a check that rollback instrumentation existed, a check that the change declared whether it was going out behind a canary, a feature flag, or blue-green. Tier decisions belonged to the principal and senior staff engineers who already owned that part of the platform. Not a council. Not a sign-off queue. A name, on each class, who could say yes.
The instinct almost every team reaches for first is to grant autonomy by how hard the work looks. Wide latitude on the interesting problems, because that's where the help feels most wanted. A short leash on anything that looks routine.
That gets the variable backwards, and it's worth being precise about why. A genuinely difficult refactor, run on a feature branch with tests and a human gate before merge, can afford real autonomy, because a bad attempt costs a discarded branch and an hour of somebody's afternoon. A schema migration against a live database is a different animal entirely, however mechanical it looks going in, because there may be no undo once it lands. Match the tier to reversibility, not to how hard the task looks: cost of a mistake doesn't scale with task difficulty. It scales with what happens after you find out you were wrong.
Which is why database schema sat at the bottom of the CircleCI ramp and dependency bumps sat at the top. Not because schema work is harder. Because a green build proves the least about a schema change of anything in the list, and the thing you're least sure the gate caught is exactly the thing that shouldn't be trusted to a gate alone yet.
A workable model rarely needs more than four positions on the dial. Suggest only, where the agent proposes a diff and a person applies it by hand. Apply and test, where the change lands and the full suite runs, so a human's first look is at something already partly verified rather than a raw guess. Commit or open a pull request unattended, with nobody present for the intermediate steps. Merge or deploy on its own judgment that the work is finished.
Most of the actual value sits in the middle two positions. Most of the risk concentrates from unattended commits upward, and very few organizations should be running production agents at the top rung today, the one where nobody has to approve the merge at all. The ones that are should be able to name, in one sentence, exactly why that specific class of task has earned it.
The part teams skip is attaching a real gate to each rung rather than a vague comfort level. "We trust the model more now" isn't a gate. "Tests pass, the diff declares its rollout mechanism, and rollback instrumentation is present" is one, because it's falsifiable. Somebody can check it without asking you what you meant, which is the same standard a trustworthy test suite already has to meet before any of this works at all.
The CircleCI ramp put tier decisions with the engineers who already owned the system in question, and that detail matters more than the order the tiers went in. A governance council, sitting apart from the code, evaluates a proposal instead of a track record. The person who's on call for the service the change touches evaluates something realer: has this class of change, at this volume, actually held up.
The evidence worth asking for is specific. A validated gate for the class of change being proposed. A run of instances at the tier below with no escapes. A name willing to be paged if the tier turns out wrong, the same named owner every merged change already needs regardless of who or what authored it. Anything short of those three is an opinion wearing a decision's clothes.
Something reaches production that shouldn't have. The reflex, and it's a strong one, is to pull the tier back. Narrow the permission, restore the human gate, feel like you did something.
That instinct is wrong, and it's wrong in a specific way worth naming rather than just flagging. The permission wasn't the defect. Something wasn't validated, and it's still not validated after you've shortened the leash, sitting there waiting for the next agent, or the next person, to find it again. Taking a permission away is an afternoon of work that looks decisive on a slide. Building the check that would have actually caught the problem takes longer and shows up on nobody's dashboard, which is exactly why the wrong response is the one that gets picked under pressure.
So a tier ratchets one way. At CircleCI we never walked a permission back. Every incident gets spent tightening the gate, not shrinking the grant. That's harder to hold to than it sounds, especially the first time it's your service and your week that just got worse.
Don't score this with an audit or a maturity model. Track two numbers: the distribution of change across tiers, and the incident rate by tier.
If everything sits in the bottom tier a year in, the model isn't wrong, it's just unused, and you've built ceremony instead of a policy. If incidents cluster at a tier that was supposed to be safe, you've found exactly which gate is lying to you, which is a far more useful outcome than it sounds like when it happens to your team.
Neither number is comfortable to look at some quarters. Both are more honest than "we feel good about where we've landed," which is the number most orgs are currently running on.