Autonomy levels

Introduction

Autonomy is not binary. Levels are theoretically unbounded; this ladder gives a meaningful, testable progression for governed agent execution. Each level is defined by its unit of autonomous delivery, what stays fixed, and where humans gate.

The ladder is extended by two finer axes:

• Maturity grades a–d on every level — how proven a level is, from defined policy to operational default.
• Sub-levels in the L1–L4 band — named variants of the autonomous unit, each with its own checkable assay evidence.

Use the ladder when scoping unattended runs, PDCA campaigns, wizard sessions, or Dark Factory targets—so teams do not claim more autonomy than their gates and resources support. Per-project observed maturity and scoring: Autonomy maturity framework.

Implementation readiness (summary)

Operator hub and per-level reference architecture (building blocks, evidence, vision): Forge Platform autonomy levels.

Full readiness matrix, Wizard ↔ execution mapping, and per-level architecture pages live on the Platform hub — this page remains the canonical policy table.

L0–L8 ladder

L0–L3 are defined and exercised today (L1.1b, L1.2b, L2.2b, L3.1b demonstrated in the worked examples); L4–L8 remain vision requiring ADRs, go/no-go, and strategic checkpoints. Higher levels add gates and never remove lower-level ones. The previous flat ladder diagram (methodology-autonomy-ladder-l0-l3.svg) is retained for reference.

Maturity grades (a–d)

A level number says what a run was allowed to change; a grade says how proven that level is in practice. Grades apply to every level L0–L8 and to each sub-level, and they compose with the ladder rather than replacing it.

Grades are scoped: a claim names where it holds (for example "L2.2c in forge-lenses" — repeatable cross-file defect fixes in that repo). A grade earned in a sandbox does not transfer to a production repo; re-earn b and above per target.

Sub-levels (L1–L4 band)

Sub-levels give named, testable variants of the autonomous unit where day-to-day progress actually happens. L0 and L5–L8 stay flat — sub-dividing suggestions-only or vision-stage levels would add taxonomy without adding checks. Each sub-level exists only because it has distinct assay evidence.

Sub-levels within a level are peer variants ordered by typical adoption, not strictly increasing risk. For example L4.2 has wider span than L4.1 but lower architectural risk — a mechanical cross-repo change-set with a submodule bump changes less about the system's shape than introducing a new component in one repo.

Notation

Claims combine level, sub-level, and grade as L<level>.<sub><grade> plus scope:

• L2.2c in forge-lenses — cross-file defect fixes, repeatable, in that repo.
• L3.1b — sandbox use-case slice, demonstrated once.
• L1b (no sub-level) — legacy or aggregate claim at the level grain; valid, but prefer the sub-level form when the evidence identifies one.

Do not confuse execution sub-levels with the Wizard planning enum (l0_analyst…l3_goal_autopilot), LCDL schema maturity (L0–L4), or standards precedence (L1–L6) — see the concept map collision register.

Promotion criteria (grade transitions)

• a → b — one green run at the declared (sub-)level with a passing Assay gate and machine + human trace.
• b → c — ≥5 green runs at the same (sub-)level in the same repo, with escalation rate < 40% across those runs (loop escalation to a human, not worker-ladder stepping — see Respecting resources).
• c → d — escalation rate trending down over a 30-day window and periodic human review sampling finds no mis-sized claims (an L2 pass that was really an L1 patch, etc.).
• Demotion is expected: a spike in escalations or a failed review sample drops the grade one step; grades are observations, not entitlements.

How a level is enforced

1. A run (or campaign item) declares its target level — and, in the L1–L4 band, its target sub-level.
2. The Assay gate for that level must pass before the change is considered done. Core evidence in forge/forge.config.yaml includes tests_pass, acceptance_criteria_met, and risks_reviewed.
3. Higher levels do not skip lower-level gates; they add gates (for example ADR + release at L4).
4. At L2, multi-file work should produce proof that two or more distinct files changed when acceptance criteria require a change-set—not a single-file patch dressed as L2. Sub-level assays go further: L2.2 additionally requires a pre-existing failing test recorded before the fix, and L3.x E2E evidence must come from a registered runner allowlist, not name matching.
5. When a sub-level is declared, its distinct assay evidence (table above) is enforced in addition to the level's core evidence; a run that fails the sub-level check may still be reported at the plain level grain if that level's evidence holds.

Resource honesty (local-first)

Fully cloud-free autonomy above L1 is not realistic on a ~4GB local model profile: planning, architecture, and ambiguity exceed small-model capability.

The realistic operating mode is local-first with ROI-gated escalation. Track escalation rate over time; it should fall as capability cards and deterministic scaffolds improve. See Respecting resources.

Wizard alignment (planning intent)

The Blueprints Wizard in Forge Lenses captures planning-time autonomy separately from runtime loops. The AutonomyLevel enum includes l0_analyst, l1_drafter, l2_stage_autopilot, and l3_goal_autopilot, with MutationPolicy describing how far downstream automation may edit artifacts.

Wizard policies inform prompts and downstream automation; they do not silently apply upstream edits. Persisted session policies should match the ladder level you intend for execution. Full Wizard ↔ execution mapping: Platform autonomy levels hub.

Forge Dark Factory (PoC reference implementation)

Forge Dark Factory is the current PoC reference implementation for bounded autonomous coding—not a production Platform submodule.

The governed loop for L1–L3. Verify failures trigger bounded repair; ambiguity or budget exhaustion escalates to a human, who still approves the branch or merge.

Do not treat Dark Factory as compliance-ready or as permission for unsupervised push/deploy. It demonstrates how the ladder and respecting resources rules compose in code.

What we do not claim

• No unsupervised push/deploy — Git workflow and release decisions remain human-gated unless your org explicitly automates them with separate policy.
• No compliance-ready autonomy — The ladder is engineering governance, not a certification.
• No “fully autonomous” delivery — Even L8 assumes mission definition by humans; intermediate levels add explicit gates.
• Escalation is expected — Especially for architecture, security, and ambiguous work; a low escalation rate is a goal, not a guarantee on day one.

How it fits the Forge ecosystem

This page belongs to its owning repo's canonical documentation and links outward to the related Forge surfaces (methodology in Blueprints, product docs in each product handbook, adoption narrative on forgesdlc.com). Follow the related links to stay on the governed path.

Related

• Autonomy maturity framework — per-project observed level, grade, 0–100 score, and recommendations
• Forge Platform autonomy levels — operator hub, readiness matrix, per-level reference architecture
• Bounded execution examples — real L1–L3 runs with loop, PDCA, and dual-wiki diagrams
• Respecting resources — token economics, decompose-before-escalate, bounded loops
• Cost-aware planning and model tiering — interactive Cursor planning
• Agentic SDLC — humans own intent; agents amplify execution
• Agentic coding standards — review capacity and smaller PRs
• Assay Gate ceremony

Executive capsule

Autonomy is not binary. Levels are theoretically unbounded; this ladder gives a meaningful, testable progression for governed agent execution. Each level is defined by its unit of autonomous delivery, what stays fixed, and where humans gate. Maturity: defined.

Who this is for

Engineering leaders at the adopt stage. Skim the executive capsule first; agents should respect the page frontmatter contract.

Trust boundary

Forge keeps humans in charge of promotion, approval, and release decisions; automation proposes and executes only within approved boundaries described here.

How to use this page

Read top-to-bottom at your depth: capsule for the decision, mechanism for design, links below for the next step in your journey.

Related pages

• Forge — artifact and decision model
• Autonomy maturity framework
• Bounded execution examples
• ForgeSDLC — concept map and term-collision…
• Cost-aware planning and model tiering