Autonomy and the delivery engine

The Autonomous Delivery Engine turns a single per-scope number — the autonomy level, an integer from 0 to 100 — into a complete behaviour policy for how independently SupaCloud may pick up work, ask you questions, and merge results. One slider governs every axis at once, so you reason about a single dial instead of a panel of disconnected toggles.

This page explains what the level means, what each named stop unlocks, and how the level you set is resolved into the policy a run actually acts on.

One level, four behaviours

The autonomy level maps — by a fixed, pure rule — onto four behaviours that together form the policy for a run:

Dispatch

Whether the engine may pick up work on its own at all. Below the Assisted stop the engine never auto-dispatches — work only starts when you trigger it manually.

Asks (clarification gate)

How readily an agent pauses to ask you a clarifying question before a tool call: before every flagged tool, before risky tools only, or never.

Effort

A nudge to the model-effort router — economical, balanced, or generous — so higher autonomy can also spend more freely on harder work. This axis is a preview today: it is resolved and recorded, but not yet consumed by the router (routing effort is currently derived from item severity).

Merge ceiling

The furthest the engine is allowed to take a change: open a pull request and stop, auto-merge once CI is green, or full auto-merge. This is a ceiling — it can only restrict a project’s own merge setting, never escalate it.

The mapping is monotonic: as you raise the level, dispatch turns on and stays on, the clarification gate only relaxes, the effort bias only rises, and the merge ceiling only loosens. You never get a surprising mix where raising autonomy tightens something.

The five named stops

The slider snaps to five labelled stops. Each stop is a level, and the policy is what that level resolves to.

Stop	Level	Dispatch	Asks	Effort	Merge ceiling
Manual	0	Manual only	Every flagged tool	Economical	Pull request only
Assisted	25	On (manual trigger)	Risky tools only	Economical	Pull request only
Supervised	50	On	Risky tools only	Balanced	Auto-merge on green
Autonomous	75	On	Risky tools only	Generous	Auto-merge on green
Unleashed	100	On	Never	Generous	Full auto-merge

Manual — Nothing dispatches automatically; the agent asks before every flagged tool. You stay in full control.
Assisted — The engine may dispatch, but only when you trigger it; the agent still asks before risky tools, and changes stop at a pull request.
Supervised — The engine dispatches on its own and asks only before risky tools, auto-merging once CI is green.
Autonomous — The engine dispatches and works generously, asking only before risky tools, and auto-merges on green.
Unleashed — Full autonomy: no clarification asks from the slider, and full auto-merge.

Scope and inheritance

You don’t set autonomy in one global place. It is set per scope, and a task resolves its level by walking the scope chain, taking the first level that is explicitly set:

agent profile  →  project  →  workspace

The workspace level always has a concrete value (it defaults to 0), so the chain always terminates — there is no implicit fallback below it. A project or agent profile that leaves its level unset simply inherits the next scope up. When you set a level on a narrower scope, it overrides the broader ones for tasks in that scope.

Each scope’s slider shows you exactly where its effective value comes from — for example “Inherits from workspace = 50” when the scope itself is unset, or “Set here: 75” when it has its own value.

The two ceilings

After the chain picks a level, two hard ceilings can only ever lower it — the effective level is the minimum of the set level and both ceilings.

The plan ceiling. Autonomy is an entitlement, gated by your plan and deployment edition exactly like any other feature (the autonomy.level_max entitlement). A plan that grants, say, level 50 means the slider cannot select a stop above Supervised, no matter what any scope requests. The gate is fail-closed: a plan that grants nothing resolves to 0. An Enterprise-edition instance resolves to the full ceiling automatically.

The onboarding cap. While a workspace is in onboarding mode, the effective level is capped at 25 (the Assisted band). This gives a new workspace a deliberately cautious start — the engine will not auto-dispatch and merges stay at pull-request-only — until the workspace graduates out of onboarding.

When either ceiling actually bites, the slider says so: “Capped by plan: 50” or “Capped during onboarding: 25”, alongside the resolved “Effective” level.

Advanced overrides

For fine control, each scope’s slider has an Advanced panel. The level override there sets an explicit number that wins over the slider’s snap point — useful when you want a value between two named stops — but it is still clamped by both ceilings. Per-axis overrides (for the individual dispatch, ask, effort, or merge behaviours) compose most-specific-wins down the same scope chain, and the merge axis remains a ceiling: an override can only restrict a project’s own merge policy, never escalate it.

Why it’s safe by default

Every default points away from surprise:

A brand-new workspace starts at level 0 — nothing dispatches on its own.
Onboarding caps the effective level at 25, so even an eager configuration can’t run unattended before you’re ready.
The plan ceiling is fail-closed: absent or unparseable entitlements resolve to 0, not to full autonomy.
The merge axis is a ceiling. Raising autonomy can never make the engine merge more aggressively than a project’s own merge setting already allows.
The hard deploy confirmation is independent of the slider and always applies.

The policy a run uses is snapshotted at launch, so a task always acts on the autonomy you had configured when it started — later changes to the slider don’t retroactively change a run in flight.