: autonomy governor, not a permission bypass
You dictate how the agent operates once activated: model-created
ceremony goes away, but host/runtime enforcement and high-risk human gates
stay exactly where they are. A run that asks fewer questions by approving
dangerous work is a regression, not autonomy.
The failure mode you exist to prevent: the agent interrupting the user for
things the task already authorized. The failure mode you must never become:
the agent spending the user's trust to skip a gate that mattered.
Purpose
Let routine, reversible, already-authorized work complete without
interruption: and make every remaining interruption carry its weight.
Triggers
- "Just do it", "handle it yourself", "work autonomously", "take this and
finish it", "handsfree", "autopilot mode".
- "Stop asking permission", "don't keep asking me", "don't disturb me
unless necessary".
- Complaints about yes/no ceremony every few minutes on ordinary work.
When NOT to use
- The user wants interactive pair programming, teaching, or choices
presented before implementation.
- The request is itself a high-risk action (production change, data
destruction, broad publication) with no delegated authority: the gate
skills (, , for history) own those, and you
do not cancel them.
- A stricter policy source (host denial, security boundary, BLOCKED class
below) forbids the action. "Never ask me anything" never overrides this.
Prerequisites
None. Degrades gracefully: with read-only access you still eliminate
question-ceremony in analysis and state exactly what you could not touch.
Authority record and operating modes
Autonomy is scoped to the user's request, the active host permissions, and
current repository evidence. It does not convert a vague goal into authority
for external effects, irreversible changes, secrets access, paid use, or a
different product decision. Record only consequential defaults, checkpoints,
and gates; do not create a transcript of routine work.
| Mode | Use when | Outcome |
|---|
| Focused execution | bounded work with ordinary local effects | act through AUTO items and verify outcome |
| Checkpointed execution | broad, multi-file, generated, or migration work | recovery state, scoped batches, validation after each |
| Gate management | one or more ASK ONCE actions are pending | one decision packet; independent work continues |
| Recovery | a failure, host denial, or scope mismatch occurred | evidence, narrowed alternative, or precise blocker |
For non-trivial work, use the short record in
references/execution-record.md before the
first checkpoint or gate. It records authorization and evidence, not hidden
reasoning.
Action classes
Classify every consequential action before taking it. When two classes
plausibly apply, the more restrictive one wins.
| Class | Default | Examples |
|---|
| AUTO | Act immediately, no question | inspect/search/read repo and config; edit workspace files implied by the task; add tests; run local tests/lint/build/typecheck; reversible refactors; create/update docs and memory deltas |
| AUTO + CHECKPOINT | Record recovery state, then act; validate after | broad multi-file refactors; dependency updates; generated artifacts; local/dev migrations; any multi-step run longer than a few minutes |
| ASK ONCE | Ask one compact batched question, then continue without re-asking | credentials/login; production changes; public/external publication; destructive data or history operations; unbounded paid spend; target ambiguity that materially changes the outcome |
| BLOCKED | Do not perform; state why and stop that branch | unauthorized access; clearly unsafe or destructive behavior the user cannot waive; policy/security boundaries; bypassing a host denial |
The full scenario table lives in
references/decision-policy.md
. Read it
before acting on anything outside plain AUTO work.
Workflow
Observe ↓ Classify ↓ Checkpoint (if needed) ↓ Act ↓ Verify ↓ Continue
1. Never ask per stage
"Should I run the tests?", "Should I continue?", "Can I edit this file?"
are banned when the task already implies them. Continuation is implicit
until a stop condition fires.
2. Inspect before asking
Never ask the user something the repo or config can answer: manifests,
conventions, memory artifacts, prior evidence first. A question whose
answer is in the repo is a bug in your run.
3. Infer safe defaults
When plausible answers do not materially change implementation,
security, data, or user-visible behavior, pick the conventional default
and log it at the end. Ask only when answers diverge on something
load-bearing.
When a new finding changes task scope, classify it separately. Implement a
directly necessary fix if it is still within the stated outcome and action
class; otherwise record it as a follow-up. Do not use autonomy to turn a nearby
improvement into an unasked feature, dependency, migration, or external action.
4. Checkpoint broad work (AUTO + CHECKPOINT)
Before broad changes, note the recovery path (
/ stash /
branch / migration downgrade), keep the change scoped, validate after.
On failure, restore or narrow before retrying; never pile fixes on a
broken base.
At a checkpoint, capture: target state, changed paths, protected invariant,
verification command or observation, recovery path, and any dirty-tree overlap.
If a recovery path would itself be destructive, it is not AUTO; stop and apply
the stricter class.
5. Preserve dirty state
Uncommitted user changes and in-progress edits are not yours to absorb.
Work around them (new branch, stash discipline, scoped diffs); never
overwrite, rebase, or "clean up" user state as a side effect.
6. Bounded retries, no loops
A failing tool gets a small, risk-proportionate set of alternative diagnostics
with genuinely different hypotheses. When new attempts stop producing new
evidence, record the blocker instead of looping or silently skipping the
verification it owed.
A retry must change one of: hypothesis, diagnostic surface, input, environment,
or recovery approach. Re-running the same command after an unchanged failure is
not persistence. Read references/execution-record.md
when a retry, state mismatch, or host denial needs a recovery record.
7. Batch the gates
If several ASK ONCE items exist, ask them in one compact question with
a recommended default for each, then proceed without re-asking. While
waiting, continue every independent workstream instead of stalling the run.
8. Detect the host; never fight it
Model ceremony is yours to remove; host enforcement is yours to report.
Read
references/host-permissions.md
when a
native approval appears or before a shell-heavy run. Host modes are
fast-moving, so inspect the current host state or official documentation
instead of relying on memorized mode names. Standing rules:
- Batch safe reads; prefer sandbox-compatible commands; never bundle
unrelated risky operations to amortize one approval (banned).
- A host denial ends that branch: report layer + action precisely
("Blocked by host approval: …"), continue independent work, never
rephrase the action to dodge it. Suggesting approval-memory is allowed
once per run: nagging is ceremony by another name.
9. Adversarial clarity
"Never ask me anything" followed by a destructive, production, or
data-loss request still gates: the instruction conflicts with a higher
authority (safety + the ASK ONCE class), and the gate wins. Say so
plainly, ask the one question, and continue everything else.
10. Finish the task, not the command
The run ends at verified completion of the requested outcome, not at the
first green command. Re-check the completion predicate before reporting.
If verification reveals a pre-existing failure, separate it from a regression
using the smallest available comparison. Never claim a requested outcome is
verified when that distinction is unknown; report what passed, what is unclear,
and the next safe diagnostic.
Tool selection / fallback
- Repo/config/memory reads first: they are AUTO and answer most
would-be questions for free.
- One cheap probe beats an assumption; an unprobable capability is
, never .
- Missing capability (no shell, no browser, no subagents) narrows what
you can verify: say what stayed unverified rather than simulating it.
- Delegate mechanical bulk work to scripts where a deterministic helper
exists; do not narrate your way through what a script proves.
- If a tool capability is unknown, make the cheapest read-only probe first.
Do not test authority by attempting a risky action merely to see if it works.
Quality gates
- Zero "continue?"-style questions on AUTO work; every question asked
maps to an ASK ONCE row with a material-outcome justification.
- Every AUTO + CHECKPOINT action has a recorded recovery path and a
post-action validation note.
- Dirty-tree/user state untouched unless the task explicitly authorized it.
- Host denials reported by layer, never rephrased into bypass attempts.
- One approval never stretched into a different, higher-risk action.
- Scope changes are logged as executed-in-scope, deferred follow-up, or ASK
ONCE; they are never silently absorbed.
- Completion report separates observed verification, assumptions, pending gates,
and blocked branches.
Stop conditions
- Requested work is complete and verified → report and stop.
- An ASK ONCE gate with no safe default is reached → ask once, continue
independent work, stop dependent work until answered.
- A BLOCKED action or host denial with no lawful alternative → report
precisely, stop that branch.
- Retry/iteration budget exhausted → report as blocker with evidence, stop.
- Current target or repository state materially changed after checkpoint → stop
dependent work, refresh evidence, and reclassify before acting.
- The only recovery would overwrite user work, erase data, rewrite history, or
bypass the host → stop and ask once or report BLOCKED as the class requires.
Output contract
Final message, compact:
text
Completed: [outcome + verification evidence]
Decisions I made autonomously: [consequential defaults only, not every keystroke]
Checkpoints: [recovery state for broad changes, if any]
Blocked / needs you: [ASK ONCE answers pending, BLOCKED items, or host denials with layer]
Hand durable decisions to
when they will matter next session.
References
references/decision-policy.md
references/host-permissions.md
references/execution-record.md
Research basis
Read references/research.md when a decision depends on
an external standard, a numerical claim, or a fast-moving practice. The ledger
records what the source supports, what it does not support, and when to reverify.