Risk owners

The case for earned autonomy

Every agentic system your team ships sits at some point on an informal autonomy spectrum. Most were placed there by judgment, not evidence.

The problem: informal promotion

Teams give their agent more autonomy when it feels ready. No gate was declared. No evidence was collected. The promotion happened because a demo looked good, or enough time passed without an incident, or someone trusted the model's confidence score. That is a guess with a UI.

When the agent produces a bad output, there is no signal. No evaluator fired. No log captured what changed. The incident report is a postmortem over artifacts that were never instrumented.

The problem is not the autonomy. The problem is that the autonomy was not earned.

The argument: earned, scoped, and revocable

Progressive Autonomy Architecture (PAA) is a vendor-neutral way to make autonomy something a team earns from evidence rather than something assigned by preference.

The central claim is that autonomy needs an accountable decision record. Before a task can operate with less human oversight, the team should know what evidence justified the move, what risk it applies to, and what condition sends the task back to a safer mode.

Earned means the team can point to the evidence behind the change. Scoped means the decision applies to a specific domain, not to the system at large. Revocable means regression has a declared response before the incident.

The goal is not maximum autonomy. It is appropriate autonomy: the level the evidence supports given the risk and the domain. Many tasks should stay partially governed permanently, and a system designed to allow that is more trustworthy than one that treats full automation as the objective.

PAA is not a novelty claim. The same pattern — discrete autonomy levels, evidence-gated transitions, safety boundaries — appears independently in vehicle automation (SAE J3016), safety-critical facility control (Osprey), self-driving laboratories (Safe-SDL), and hyperscale network operations (Malik). PAA is the domain-general, vendor-neutral specification of a mechanism already proven in production. PAA's contribution is the domain-general operating model for applying that mechanism to agentic work. See Grounding for the full prior-art basis.

Gate economics and the maturity curve

Evaluator cost is high at cold start and falls as evidence accumulates. The curve resolves the objection that eval-gating everything is too expensive.

Cold start

Human review or LLM judge as the evaluator. High per-unit cost, low volume. Affordable because throughput is still low and the stakes of each decision are high.

HITL / blocking

Growing evidence

Review labels accumulate. A smaller classifier begins to replace the judge. Oracle shifts toward automated signals. Position policy can loosen as trust builds.

HOTL / async

Mature volume

Cheap classifier on the hot path. Verdict quality checked against downstream outcomes. Expensive reviewers reserved for edge cases and calibration.

Autonomous / offline

Regression

Agreement or calibration drift exceeds the threshold. Automatic demotion. The more expensive evaluator resumes. Task re-qualifies before advancing again.

Demotion / tighten

At cold start the evaluator is expensive, but that is acceptable because volume is low. As review labels accumulate, a learned classifier can take over the routine cases. By the time volume is high, the evaluator runs cheaply on the hot path. The expensive reviewers are freed for edge cases, calibration, and governing the classifier itself.

When agreement degrades — when the classifier starts diverging from what human reviewers or downstream outcomes would decide — demotion fires automatically. The task returns to a more expensive evaluator until it re-qualifies. The curve does not run in only one direction.

What adoption actually requires

PAA is not configuration. It is a discipline. Here is what you are committing to.

Instrumentation
Teams need enough visibility into each governed action to explain what was attempted, what happened, and what evidence was available at the time. Without that record, promotion is only opinion.
Declared thresholds
The bar for more autonomy, and the condition for taking autonomy back, must be written before the system is operating at volume. "When it feels ready" is not a threshold.
Review discipline
Early review has to be consistent and recorded, not one-off judgment. The discipline is what turns expensive oversight into the evidence base for cheaper oversight later.
Evidence retention
The records behind promotion and regression decisions must persist long enough to be audited. A promotion decision without evidence is a guess. A regression trigger without records is a manual process.

These are operational asks on the team running the task. They are non-trivial. They are also the minimum required to make any claim about autonomous operation credible.

Five questions before your next autonomy decision

Use these before promoting any agentic workflow to less human oversight. Download as a one-page brief.

  1. 1

    Can you produce the autonomy record?

    For each autonomous action, can the team show when autonomy was granted, what evidence justified it, and which risk it covered?

  2. 2

    What evidence earns less review?

    What signal, over what period, is strong enough to move the workflow toward more autonomy? A good demo is not evidence.

  3. 3

    Who owns the review discipline?

    At cold start, are review decisions consistent, retained, and usable as labels? If not, the maturity curve never gets funded.

  4. 4

    What sends autonomy backward?

    What degradation, incident, or drift condition tightens oversight again, and who gets alerted when that happens?

  5. 5

    Should this task ever reach full autonomy?

    Some tasks should stay at human-on-the-loop permanently. High-stakes, irreversible, or regulatory actions may warrant a permanent blocking gate. Appropriate autonomy is not the same as maximum autonomy.