Graduated autonomy, with the levels named in code

The auto-execution policy is one exported function taking two arguments and returning one of three answers. The arguments are an action and an autonomy level. The answers are auto, approval required, and blocked.

That is the entire interface. Everything worth arguing about in graduated autonomy is in what the function does with those two inputs, and in the cases where it refuses to give you the answer you configured.

A level is a name, so the level cannot be the whole story

Most products express autonomy as a slider in a settings page. Move it right, the assistant does more. The problem is not that a slider is coarse. It is that the label is the only description anyone has of what changes, so the behaviour lives in whatever the implementation happens to do that week.

Naming the levels in source fixes that. The names are manual, assisted, supervised and autonomous, exported as one ascending-order array so no caller anywhere gets to hardcode a different ordering. A level is a value with a rank, not an adjective.

But the level is only half the input, and the other half is what makes this a ladder rather than a mood.

The action is not a string either

An action is not identified by its name for the purpose of this decision. It carries three properties beyond its type: a risk tier, which is one of low, medium, high or critical; whether the effect is reversible; and whether it has an external side effect. The last two are plain booleans.

Reversibility and risk are separate axes, and the catalog is worth reading because it does not collapse them. In the shipped catalog, applying a discount is high risk and reversible. Sending an email is only medium risk and irreversible, because you cannot unsend it. Updating the CRM is medium, reversible and external, because it writes to somebody else's system of record. Deleting a record and issuing a refund are critical, irreversible and external.

Any model that treats risk as one dimension gets the discount and the email in the wrong order relative to each other. A discount is a bigger number and a smaller mistake.

The third property, the external side effect, is the one people leave out. It marks whether the action touches the world outside the product: a prospect, a CRM of record, a phone line. Drafting is not sending. Summarising is not calling.

What each level actually permits and forbids

Read this as the contract, because it is:

Manual. Everything requires approval, including the reversible, internal, low-risk work. The agent drafts and proposes; a person acts.

Assisted. Auto-runs low-risk reversible actions only. Everything else returns approval required, and the signer escalates with the tier: high and critical route to a manager, the rest to a rep.

Supervised. Auto-runs low and medium risk actions that are reversible. High risk always requires manager approval. Critical requires manager approval. A critical action that is also irreversible and external is not merely held, it is blocked. And a low or medium risk action that happens to be irreversible falls through to a cautious approval rather than a silent auto-run, which is the branch most implementations forget.

Autonomous. Auto-runs low and medium risk unattended. Auto-runs high risk when it is either reversible or has no external side effect. Holds an irreversible high-risk action with an external side effect for a manager. Escalates every critical action to a human. And still blocks the critical, irreversible, external case outright.

Notice what the top rung does not buy you. Autonomous is not "the agent does everything". It is "the agent stops asking about the reversible middle of the catalog". Refunds and record deletions still stop at a person at the highest setting the product has.

The floor is a floor because of where it sits

A safety rule stated in a comment is a wish. A safety rule stated as a branch inside the level logic is a rule a future level can accidentally route around.

Two guards here are written before any level is consulted.

The first handles a malformed action. If the risk tier is not one of the four the gate recognises, or if the reversibility and external-side-effect fields are not real booleans, the action is blocked outright. The comment names the concrete failure it defends against: an action whose metadata never came from the catalog, such as a prototype key like constructor resolving off it with an undefined risk. A hallucinated action type must not fall through to auto because no level branch happened to match it.

That shape is worth stealing. An unrecognised input is not a low-risk input. Most gates fail open on unfamiliar data because the permissive branch is the default case at the bottom of the function.

The second guard is the safety floor proper: a critical, irreversible action with an external side effect can never auto-execute at any level. It is computed once near the top and checked in both the supervised and autonomous paths before anything else. The earned-autonomy module composes with this function rather than replacing it, so even a perfect track record that earns autonomous cannot reach past it.

Earned, not chosen

The second module is the autonomy ladder, and it exists because a static level has an obvious defect: somebody picks it once, and it never moves again in either direction.

The ladder computes the level a track record has earned, per workspace and per action type, from four counts: proposals a human accepted, proposals a human rejected, executed actions with a good outcome, and executed actions with a bad one. Acceptance rate is a trust signal, meaning how often the agent proposes something a human keeps. Success rate is a competence signal, meaning how often the executed thing actually worked.

Both must clear a rung, on separate sample minimums. The comment on the outcome minimum says why: without an outcome bar, a record of fifty approvals and one successful execution would clear the top rung, which is autonomy earned on approvals rather than on results. Rubber-stamping is not evidence.

The default thresholds are 5 decisions and 5 outcomes at 0.7 acceptance and 0.8 success for assisted; 20 and 20 at 0.85 and 0.9 for supervised; 50 and 50 at 0.95 and 0.97 for autonomous. Manual has zero bars, so it always clears, which means an empty or unproven record resolves to manual rather than to whatever an operator once typed.

Three details there are the difference between a ladder and a scoreboard.

Demotion is evaluated first. A window whose failure rate reaches 0.2, or whose rejection rate reaches 0.3, returns manual outright, regardless of sample size and of how good the history looked yesterday. Climbing is gradual and falling is immediate, which is the correct asymmetry for a control.

A rate with a zero denominator returns 0, not 1. No data never reads as a passing rate.

And a mis-ordered custom configuration throws, checked on every evaluation, rather than relying on a comment that says the array is sorted.

The part that matters if the signals come from strangers

The third module, the claim-risk precaution clamp, lets a signal the memory layer already holds tighten autonomy before a bad outcome rather than after it: a contact turning hostile, a competitor being named, a churn signal, a contested fact.

Its constraint is the interesting part, and the module states the reasoning rather than the rule. Those claims are extracted from customer-authored text. A prospect writes the words. So if a claim-derived signal could move the level in either direction, there would be a path from a prospect writing a sentence to the agent gaining authority to send unattended. That is privilege escalation driven by untrusted input.

The module closes it by construction. Every exported function returns a ceiling, applied with a helper that returns the more restrictive of two levels. No exported function returns anything other than the minimum of its inputs, so no code path exists by which a signal raises a level. An attacker's best case is to cost the workspace some autonomy, which is a denial of service and the correct direction to fail in.

The same module treats an unrecognised risk kind as the most restrictive tier, on the stated grounds that the memory flagging something nobody wrote a rule for is exactly when caution is warranted.

The honest edges

This article describes committed source at one commit. Three things it does not say.

It does not say what any running deployment is set to. The evidence base this was written from lists deployed flag values as unverified, settleable only by querying the deployed service, and that check was not run here.

It does not say the signals are flowing. The claim extraction that would produce them from email, transcripts and enrichment is not generally available yet.

And it does not say there is a fleet of agents running this loop unattended. The standing account-agent loop, the piece that would evaluate these decisions continuously with nobody present, has zero consumers by the repository's own reachability lint, and its loop variable is unset. What exists is the decision engine, its catalog, its ladder, its clamp, and a dashboard that renders the whole catalog against a chosen level.

That is the actual claim, and it is smaller and more checkable than the usual one. The levels are not a marketing vocabulary layered over an opaque runtime. They are four names, three verdicts, one function, and a floor that sits above all four names.

The question worth asking any vendor selling autonomy levels: which of your levels can send an irreversible message to my customer without a person, and where in your product can I read that answer rather than being told it?