The Progression: Assisted, Delegated, Owned

Three stages of organizational autonomy, the evidence each requires, and the quadrant most organizations occupy by accident.

Autonomy expands along one axis and discipline along another, and most organizations today are further along the first than the second. That is the dangerous quadrant, and it usually arrives by accretion rather than by decision—a scope widened here, a bypass actor configured there to unblock a deadline.

This framework’s central structural claim

An organization cannot safely occupy a stage its verification and absorption capacity does not support, and stage advancement should be gated on evidence rather than ambition.

Figure 4The progression

Verification and absorption capacity must precede each step →

Stage 1Assisted

Author, with acceleration

Unit: the keystroke or prompt

Stage 2Delegated

Specify, architect, verify

Unit: the task, then the work class

Stage 3Owned

Set intent, arbitrate, own outcomes

Unit: the scope — a service, a domain

Most organizations sit between Stage 1 and Stage 2, with pockets of Stage 3 behavior nobody authorized.

Height indicates the discipline required, not the autonomy granted.

4.1 The Three Stages #

	Stage 1 — Assisted	Stage 2 — Delegated	Stage 3 — Owned
Humans do	Author, with acceleration	Specify, architect, verify, review high-risk change	Set intent and constraints, arbitrate escalations, own outcomes
Agents do	Complete, suggest, draft under direct supervision	Produce within declared work classes, dispatched per task or queue	Hold standing scope, work continuously, escalate rather than await dispatch
Unit of delegation	The keystroke or the prompt	The task, then the work class	The scope: a service, a domain, a maintenance surface
Unit of governance	The individual	The work class and the deployment	The fleet
Oracle	Human judgment at acceptance	Machine-checkable per work class, human review at merge	Layered, immutable, independent of the agent; human review sampled by risk
Review posture	Every change, as for any contributor	Risk-tiered; mandatory on high-risk paths	Auto-merge what is provably safe; human attention concentrated at the boundary
Platform	Licenses and guidance	Agent runtime, context substrate, tool gateway, evaluation infrastructure	All of the above plus fleet identity, cost control, and continuous validation
What breaks it	Nothing structural; gains are individual	Review saturation	Undetected oracle gaming; comprehension debt

Most enterprises today sit somewhere between Stage 1 and Stage 2, with pockets of Stage 3 behavior that nobody authorized. The published Stage 3 exemplars are few and specific: fleet-wide automated maintenance where the transformation is well specified and the oracle is strong.¹⁰⁰^,¹⁰¹

4.2 Entry Criteria #

Stage advancement is a decision with owners, evidence, and a date. These are the minimum conditions.

To enter Stage 2—Delegated

Controls

Every agent deployment has a unique identity, a named accountable human, and no standing credentials
The merge boundary holds: agents cannot self-approve or self-authorize CI execution, verified by demonstration
At least one machine-checkable oracle exists for every work class being delegated
Review integrity is instrumented—approval rate, review duration, diff size at approval—and reported
Absorption capacity is modeled from actual telemetry and governs the merge rate
Provenance is emitted at authorship and survives into the release record
Agent runtime is isolated with default-deny egress
Control maturity is at Level 2 or above across all dimensions in Section 18

To enter Stage 3—Owned

Controls + evidence they worked

Operating evidence at Stage 2 for at least two quarters: merge rate, defect escape rate, revert rate, scope adherence, conflict rate, incident involvement—all trended, all within threshold
Oracles are immutable from the agent’s perspective, with test and specification artifacts outside agent write scope
Layered verification per Section 7, including at least one oracle the agent cannot observe
Continuous validation running against production, alerting on distribution shift
Fleet-level identity, cost attribution, and kill switches, all tested with measured time-to-effect
Auto-merge policy defined by change class, with a measured false-negative rate
Comprehension and maintainability monitored, with consolidation work funded from the signal
Named human ownership of every subsystem, with a stated expectation that the owner can explain it
Control maturity at Level 3 or above across all dimensions

The asymmetry is deliberate. Entering Stage 2 requires controls. Entering Stage 3 requires controls plus evidence that they worked. There is no path to Stage 3 that skips operating at Stage 2 long enough to measure.

4.3 Deployment Autonomy Tiers #

Organizational stage sets what the company is prepared to run. Tier sets what a specific deployment is granted. They are different decisions and both are needed.

Tier	Description	Human involvement	Permitted scope	Approval authority
A0Advisory	Generates output; no write capability	Human performs every action	Read access the invoking human already has	Team lead
A1Supervised authoring	Writes to a working branch; every change reaches trunk through human review	Review at merge	Non-protected branches; no CI credentials; no production data	Engineering manager
A2Bounded autonomous	Executes multi-step tasks and opens changes independently within a declared envelope	Review at merge mandatory; exception approval for envelope breaches	Declared repositories, paths, and tool set; no secrets in context	Architecture review with security consultation
A3Delegated autonomous	Operates continuously on a defined scope; may merge low-risk change classes under policy	Post-hoc review with sampling; automated halt on anomaly	Enumerated repositories and change classes; non-production infrastructure; ephemeral credentials	CTO or delegate, with security sign-off
A4Privileged autonomous	Acts on production systems, release pipelines, security controls, identity, or financial paths	Dual control; monitoring independent of the agent’s control plane	Explicitly enumerated, time-boxed, with a termination condition	CTO plus business executive; documented risk acceptance

Rules across tiers. Tier attaches to a deployment, not a product—the same agent may run at A1 against a customer-facing service and A3 against internal tooling, and those are two registrations with two owners. There is no automatic promotion; demonstrated good behavior is evidence supporting a decision, not a decision. Every A2-and-above deployment requires a named accountable human, not a rotation. A4 deployments require a monitoring and halt path the agent cannot reach or modify. Any agent given elevated credentials for a migration, extended tool access for an investigation, or reduced guardrails for any purpose is A4 for the duration.

Tier ceilings by stage

Stage 1

Organization should not run anything above A1.

Stage 2

Organization can support A2 broadly and A3 in work classes with strong oracles.

Stage 3

A3 as a default, and anything in A4.

4.4 The Failure Mode This Section Exists To Prevent #

Expansion by accretion. Nobody approves Stage 3; a scope widens, a bypass actor is added, an agent is pointed at a second repository, an auto-merge rule is relaxed to clear a backlog. Six months later the organization is operating at Stage 3 autonomy on Stage 1 controls, and the first person to notice is an incident responder.

The single best leading indicator is in Section 20: agent population growth rate against registry coverage growth rate. When the first exceeds the second, the organization is advancing stage without deciding to.