Progressive Autonomy Architecture

An open, vendor-neutral standard for autonomy that is earned, scoped, and reversible.

Progressive Autonomy Architecture

Autonomy should be earned, scoped, and reversible.

A vendor-neutral architecture for moving agentic tasks from human review to monitored autonomy, through explicit evaluators, evidence logs, promotion rules, demotion rules, and fallback paths. Model-agnostic by construction. Buildable by design.

The problem is the middle

Agentic systems fail in the middle

Too much autonomy for anyone to trust them; too much human review for them to scale. The two easy ends, a tool that only suggests and a fully autonomous agent, are not where real work lives. Real work lives in the long stretch between, where a task has earned some autonomy but not all of it, and where the hard question is never "can the agent act" but "can we trust it to act this time, without a human."

Most teams answer that question by vibes. They promote an agent because the demo worked, or because its confidence score was high, or because it has not broken anything lately. None of those is an evaluation. When the agent later fails, nobody can say why it was trusted, when it should escalate, or whether it has quietly been getting worse.

PAA is the discipline that replaces the vibe with a gate.

Why PAA exists

Teams everywhere are already doing this informally. They escalate to a human when a model is unsure. They let an agent read freely but gate every write. They start by approving each step and quietly remove that human once it stops catching anything. They expand automation "as they learn what works." They do it without a shared standard, and often without any way to know whether a given step was safe to take.

Progressive Web Apps did not invent offline caching or home-screen install; those practices already existed, reinvented inconsistently on every project. PWA's contribution was to name the target, define what qualifies, and give people a standard to build toward. PAA is that move for progressive autonomy, and the pattern it standardizes is converging from two directions at once.

From industry, the levels are everywhere: audit/assist/automate ladders, trust-benchmark phases, and draft-to-monitored progressions. They get the shape of the destination right, but usually leave the implementation contract implicit. From research, the mechanism is becoming precise: Osprey shows plan-first gated execution in production safety-critical infrastructure, while Safe-SDL formalizes safety boundaries and regression mechanisms for self-driving laboratories.

What remains underbuilt is the bridge between the two: a standard general enough for real product teams and rigorous enough to make autonomy accountable. That is the thing PAA is built to be: provider-neutral, model-agnostic, and buildable.

The level tells you where a task sits. The evaluator is what lets the task prove it belongs there.

The evaluator is the primitive

Here is what makes the neutrality claim true instead of a slogan.

PAA is model-agnostic and tech-agnostic because the thing behind the gate can be anything, whether an LLM, a smaller model, or deterministic code, and still be measured against the same bar. The primitive that makes this work is not the agent and not the level. It is the evaluator: the object that decides whether a task has earned more autonomy, must stay gated, or should be demoted.

Most "we added evals" efforts only make one decision, which technique to use, and leave the rest implicit. A real evaluator declares four:

  • Target: what you evaluate: input, process, output, or outcome.
  • Technique: what produces the verdict: rule, metric, classifier, LLM judge, or human.
  • Oracle: what the verdict is measured against: an invariant, a reference, a rubric, human gold, or a downstream result.
  • Position: where it runs: blocking gate, async monitor, or offline promotion evidence.

A score with no oracle is a vibe with a threshold. An evaluator nobody has validated is not a gate. It is a guess with a UI. The evaluator is what PAA makes you design, and it is why the framework outlives whichever model is fashionable.

A PAA task declares eight things

This is the contract: the buildable checklist most maturity models leave implicit.

Task contract

refund_approval

A compact task declaration for a selective autonomy classifier.

Typed boundary
Refund request in, decision out.
Evidence log
The signal that funds every promotion and demotion decision.
Evaluator
The four evaluator choices: target, technique, oracle, and position.
Oracle
Human gold for escalation decisions.
Gate position
Blocking, then selective autonomy for cases that have earned it.
Promotion rule
recall_on_should_escalate >= threshold
Demotion rule
chargebacks_or_complaints_exceed_threshold
Fallback implementation
human_review
refund_approval YAML example
task: refund_approval
boundary: refund_request -> decision
evaluator:
  target: output
  technique: escalation_classifier
  oracle: human_gold
  position: blocking_then_selective
promotion_rule: recall_on_should_escalate >= threshold
demotion_rule: chargebacks_or_complaints_exceed_threshold
fallback: human_review

A task is not eligible for the spectrum at all until it is instrumented at its boundary. If you cannot observe it, you cannot measure it; if you cannot measure it, you cannot gate it; if you cannot gate it, you cannot responsibly automate it.

Start here