Stop Asking How Much Autonomy to Give Agents. Ask Where.
You have probably made this decision already, without quite noticing you made it. Most organisations set agent autonomy the way they set a thermostat: one dial, one number, applied to everything. Some are cautious and review every line, which throws away most of the benefit; some are permissive and merge on green, which works right up until it does not. Neither is really a decision; both are a default that arrived on its own.
The useful question is usually not how much autonomy to grant, but where. Autonomy belongs to a class of work rather than to an organisation, and what you want at the end is a short table: each class of change, the autonomy level it gets, and the reasoning behind it. Here is how to build one.
Name the levels
Three levels are enough to start with, and plainer words will do if they suit your organisation better; the words matter less than everyone using the same ones. Open means the agent works and merges, with human review a formality. Gated means the agent works and an independent check decides whether it merges. Proposed means the agent drafts and a named human decides.
Rate the verification, honestly
Every grant rests on two things: what it costs if a change is wrong, and how well you would know. Consequence is the easy one; most engineers can rank their estate in an hour, and most have never been asked to. Verification is where teams tend to deceive themselves, so it is worth rating explicitly.
Verification is strong when the check existed before the change and was not produced by whatever made the change: regression suites that predate the work, characterisation tests, contract tests at a boundary, etc.
It is moderate when the check was authored separately from the implementation: a human wrote the acceptance criteria before any code existed, or a second model generated the checks from the specification without sight of the code.
It is weak when the check was produced alongside the change by the same thing that made it. An agent that writes both the code and the tests for that code has not verified anything; it has marked its own homework. That last case is what quietly sinks programmes, because it looks like verification from the outside: coverage is high, CI is green, and almost nothing is being checked.
Build the table
The two variables together give you the level. Four rows from a fairly normal estate.
- Documentation and internal tooling. Consequence low, verification moderate, since a human tends to notice wrong documentation on first read. Open.
- A refactor under strong regression cover. Consequence moderate, but verification is strong; those tests predate the change and encode behaviour nobody is rewriting. Open. This is the row teams under-use, because the word refactor sounds risky while the verification story is excellent.
- A new feature on a customer-facing service. Consequence moderate, and verification depends entirely on where the acceptance criteria came from. Written by a human before implementation, it is moderate and the class is Gated; generated by the agent alongside the code, it is weak and the class drops to Proposed until that changes.
- Identity and access, or a data retention path. Consequence high, and verification is weak almost by nature, because these failures tend to surface months later in an audit rather than in a test run. Proposed, with no exception for changes that look small.
The pattern falls out fast. Autonomy rises where consequence is low or verification is strong and independent, and it contracts sharply where consequence is high and verification is weak, which is where most legacy systems sit; that quadrant deserves its own conversation, and I will come back to it.
Two tests for whether you have done it properly
First, can an engineer look up a class of change and know what autonomy applies without asking anyone? If not, the policy lives in individual heads and will usually be applied inconsistently under deadline pressure.
Second, can you explain any given grant in one sentence, in terms of consequence and verification? If the only explanation available is that someone senior felt uneasy, you have a preference rather than a policy, and preferences rarely survive contact with a team that wants to move faster.
The table also tells you what to fix. A class sitting at Proposed because verification is weak is not a permanent state; it is a backlog item, and once the independent check exists the class earns a higher grant. That is a better conversation than arguing about whether agents can be trusted, because it turns trust into something you can go and build.