Autonomy Dial

Framing

The problem

Binary autonomy settings are too blunt for mixed-risk workflows where some tools should run free and others should never auto-execute.

The pattern

Let users grant per-tool / per-action autonomy — auto-run, ask-before-act, or denylist — instead of one binary toggle. The 2026 reality is gates more than continuous sliders.

Why chat breaks here

Conversation alone cannot express durable, per-tool permission boundaries that survive across sessions.

Risks

Too many knobs can offload system design complexity onto the user; too few collapse back to the binary toggle this pattern is meant to replace.

Avoid when

The workflow is simple enough that one global mode is sufficient and the gate UX adds friction without insight.

Use when

Delegation needs to vary by task type — research can be auto, sending mail must be approved.

DOPE evaluation

Directability

Toggle, allowlist, or denylist any tool at any time — the agent adapts on the next call

Observability

Active permission scope visible per tool, agent, and action

Predictability

Each gated action is gated the same way every run — no surprise auto-execution

Explainability

Each permission carries a label naming the tool, the scope, and what triggers a gate

In the wild

• Salesforce Agentforce (Salesforce) — Topics + Actions + escalation thresholds + per-agent permissions provide per-domain autonomy configuration. Service Agent escalates only on confidence threshold. The clearest enterprise example.
• Cursor Agent Settings (Cursor) — Settings → Features → Agent: ask-before-act vs auto-run, allow file deletion, command denylist, max-steps before re-prompt. Per-tool autonomy as explicit knobs.
• Claude Code Permission Modes (Anthropic) — Each subagent gets its own tool allowlist + permission mode — effectively per-task-category autonomy stored in .claude/agents/<name>.md, version-controlled.
• n8n HITL per-tool gating (n8n) — Per-tool human-approval toggle gives a per-action autonomy dial — the dominant 2026 paradigm of HITL-by-tool rather than continuous sliders.
• Tesla Autopilot (Tesla) — Off-domain analog — Autopilot vs FSD (Supervised) tiers (SAE Level 2). The mode-selection UI is not per-task software autonomy, but the metaphor of calibrated trust per category travels.
• Levels of Autonomy for AI Agents (Academic source · Feng, McDonald, Zhang (University of Washington, Jun 2025)) — Defines five discrete autonomy modes (Operator / Collaborator / Consultant / Approver / Observer) with corresponding human-side control modes. A named-modes framing that complements the continuous per-tool dial — useful as a vocabulary for what each setting actually means.

FAQ

What is an Autonomy Dial?

An Autonomy Dial is a per-task setting that lets users choose how much an AI may do on its own — from copilot (suggests only) to delegate (asks before acting) to autonomous (acts and reports back). It replaces a single global toggle with task-specific defaults users actually trust.

When should I avoid an Autonomy Dial?

Avoid the pattern when one global mode genuinely suffices for the workflow. Adding per-task knobs without a real reason offloads system design complexity onto the user and erodes trust.

How does this support directability?

Autonomy is no longer binary — users can keep manual control where stakes are high and delegate where they are not, all from a single visible surface that survives across sessions.

Related patterns

• Often paired with: Constraint Rules Engine — Soft level setting + hard rules the agent cannot cross.
• Often paired with: Approval Gates — Per-category autonomy + manual checkpoints for the highest-risk steps.
• Often paired with: Agentic Dashboard — Configure delegation, then supervise it live in the control room.