L0-L8 Autonomy Ladder With Gates

Core Thesis

Forge's L0-L8 autonomy ladder is a major standout because it makes autonomy testable. Each level is defined by a unit of autonomous delivery, fixed boundaries, human gates, building blocks, and evidence expectations.

The key idea is: autonomy is not a switch; it is a governed ladder.

Condensed Thought

A vague promise of "autonomous software engineering" is difficult to trust. Forge replaces the vague promise with levels. A function-level change is not the same as a change-set, a use-case slice, a feature, a subsystem, a product increment, a multi-platform solution, or an autonomous problem-solving mission.

The ladder allows teams to say exactly how much autonomy a run has and where a human still decides. Higher levels add gates; they do not remove lower-level ones.

Why It Stands Out

This idea gives Forge a more credible vocabulary than broad claims about autonomous agents. It also creates a practical adoption path. Teams can start with assisted work and bounded function-level runs, then gradually move toward change-sets and use-case slices before considering feature or subsystem autonomy.

The ladder is useful for engineering, governance, procurement, and product strategy. It lets organizations compare claims and measure progress. A vendor or internal team can say, "We support L2 change-set autonomy with these gates and this evidence," instead of saying, "Our agent is autonomous."

Forge Ecosystem Hooks

• Blueprints hold the canonical policy for levels.
• Platform autonomy pages show adoption and reference architecture surfaces.
• Lenses records the run and review gates.
• LCDL helps verify reasoning and patch units.
• Fleet can execute approved jobs inside bounded runs.
• Workcells carry out scoped work within the declared level.
• EvidencePacket proves the run met the level's gates.

Architecture Implications

An autonomy ladder needs enforcement, not just documentation:

1. Each run should declare an intended autonomy level.
2. Each level should map to allowed actions, fixed boundaries, human gates, and evidence requirements.
3. Lenses should display the declared level and whether its gates passed.
4. Workcells should advertise which levels they can safely support.
5. Fleet templates should be level-aware where execution risk changes.
6. Higher-level runs should inherit lower-level gates.
7. Ambiguity, budget exhaustion, or verification failure should trigger bounded repair or human escalation.

The ladder can become the policy bridge between human governance and machine execution.

Blog Post Seed Paragraph

When people talk about autonomous software engineering, they often collapse many different capabilities into one word: autonomy. Forge separates them. A tool that can edit one function is not equivalent to a system that can deliver a feature or coordinate a multi-repo product increment. The L0-L8 ladder gives teams a vocabulary for bounded autonomy. Each level declares what the system may change, what must stay fixed, where humans decide, and what evidence proves the work is done.

Risks And Counterarguments

The ladder may be misunderstood as a linear maturity guarantee. Forge should emphasize that higher is not always better. Many tasks should remain at lower levels because lower autonomy can be faster, cheaper, safer, and easier to verify. The best level is the smallest level that can responsibly deliver the outcome.

Who this is for

Architects and platform engineers evaluating Forge (evaluate stage). Executives can stop after the core thesis; agents should honor the agent contract in the page frontmatter.

Evidence and maturity

Maturity: defined — this page records design intent captured from the Agentic SDLC standout analysis and reviewed for the platform handbook. Where behavior is shipped and observable it is called out explicitly; everything else should be read as direction, not commitment. Evidence trail: the hydration pack seed, the content registry entry for this content_id, and the claim registry entries linked via claim_ids.

How to use this page

• Evaluating Forge? Read the core thesis and ecosystem hooks, then continue with the standout index.
• Designing against the platform? Verify boundaries in the platform reference architecture before implementation.
• Automating? Use the frontmatter agent_contract and cite content_id in generated output.

Related

• Platform reference architecture
• Agents and workcells
• Autonomy levels

Agent contract

Allowed actions

• summarize this page for evaluation questions
• cross-reference claims via claim_ids and source_refs

Safe to infer

• the architectural boundary described here is the intended design

Do not infer

• production readiness beyond the stated maturity level
• specific vendor, customer, or benchmark commitments

Key artifacts

• forge-platform/docs-governance/content_registry.yaml

Machine-readable guidance from this page's frontmatter: what automated consumers may do, infer, and must not infer.