Acting Without Asking: Six Conditions

How an agent gets permission to fix things on its own without that permission quietly becoming permission for everything.

Problem

An agent that must ask before every action is safe and nearly useless. Most of what it should do is small, internal and reversible: fix a dead link, correct a count, sync an index that has drifted, repair a path that moved.

Ask about each and you have rebuilt the bottleneck the agent was supposed to remove. Approve them in bulk and you have granted a permission with no boundary, which will be exercised at the boundary eventually.

Neither failure is hypothetical. The first killed a publishing project — 20 minutes of approval per item, deferred until it stopped happening. The second is the failure everybody worries about and nobody instruments.

Design

A standing mandate: pre-authorised autonomous action inside a fixed envelope. Not a permission level, not a judgement call — a checklist evaluated before each action, where all conditions must hold.

The mandate is written as a single quotable line followed by its conditions:

Reversible internal repair may proceed without approval while all six conditions hold. Any one unmet: ask.

The six:

1. Reversible with a backup. A rollback path exists and has been created before the change, not planned.
2. Verified. A check runs after the change and can distinguish success from a plausible-looking failure.
3. No external effect. Nothing leaves the system. No send, no publish, no third-party call carrying data.
4. Governance excluded. The mandate cannot alter the rules that define the mandate, the decision matrix, or anything about how autonomy itself is granted.
5. Audit logged. Every action writes an entry. Not for blame — without a log there is no way to calibrate, and the argument about whether the envelope is right becomes anecdotal.
6. Semantically neutral. The change fixes form, not meaning. Repairing a broken link is in scope; rewriting the sentence containing it is not.

Two bounds sit on top. A daily cap — ten actions — so a runaway loop is bounded by construction rather than by noticing. And a one-strike tripwire: a single action outside the envelope suspends the mandate entirely, pending review.

Trade-offs

Condition 4 is the load-bearing one and the most tempting to relax. An agent that can adjust its own governance can widen its envelope by degrees, each step locally reasonable. Excluding governance costs real convenience — the agent must ask to fix even an obvious typo in its own rules — and that cost is the price of the boundary staying where it was put.

Fail-closed produces friction on ambiguity. If any condition cannot be demonstrated, the action reverts to asking. Not "seems fine" — demonstrated. This turns unclear cases into questions, which is the correct direction and is occasionally annoying.

The cap is arbitrary. Ten per day was chosen because it comfortably exceeds observed need without permitting a runaway. It is a guess, and it is written down as a guess so it can be revised against the log rather than against a feeling.

Reversibility is not always as clean as it looks. A change that is technically revertible may have been read by someone in the meantime. Within a purely internal system this is acceptable; it is exactly why condition 3 excludes anything external, where reversibility is a fiction.

What it looks like in use

The mandate is not felt as a permission. It is felt as an absence of interruptions, which makes it hard to evaluate — the successes are invisible and only the friction is noticeable.

A typical qualifying action: an index file claims 24 entries, the directory holds 26, the discrepancy came from two entries added without a recount. Fixing it means editing a number. Backup exists, verification is a re-count, nothing leaves the system, it is not governance, it gets logged, and the meaning of no entry changes. All six hold, so it happens without asking.

A near-miss from the same family: the same index claims 24, the directory holds 22, and two entries cannot be accounted for. Superficially the same repair. But correcting the header downward would assert that the two missing entries never existed, which fails condition 6 — the change would alter meaning, not form. That one becomes a question, and the question is the valuable output.

The distinction between those two cases is the whole design. Both are one-number edits. One is bookkeeping and one is a claim about history, and no rule phrased as "fix small internal inconsistencies" separates them.

Three things make the envelope hold in practice.

The conditions are evaluated, not recalled. Written as a checklist in the same file as the mandate, checked in order. A principle gets interpreted under time pressure; a list gets read.

The log is append-only and boring. One line per action: what, why, which conditions were checked, how it was verified. Nobody enjoys writing it and it is the only artifact that describes what actually happened rather than what was intended.

The cap is felt before it binds. Ten a day is generous, so hitting it is itself a signal — either something is looping, or a class of repair is frequent enough that it deserves a proper fix rather than repeated manual correction.

What broke

The mandate exists because of two opposite failures, and the second is the one that shaped condition 4.

The first was inaction. Small internal repairs queued up behind approval and simply did not happen — dead links, drifted counts, stale paths, each individually trivial, collectively enough to make the system's own records untrustworthy. An audit found 240 dead links accumulated this way.

The second was scope creep in a related area. A rule written to cover one narrow case was applied by analogy to a broader one, on reasoning that was locally sound at every step. Nothing went wrong, which is worse than something going wrong: an unbounded permission that has not yet been abused is indistinguishable from a bounded one, right up until it is not.

That is why the envelope is a checklist rather than a principle. Principles get interpreted. Checklists get evaluated.

One question comes up every time this is described: why not simply trust the agent's judgement, given that judgement is what it is for? The answer is that judgement is exactly what the checklist protects. An agent asked to evaluate is this reversible enough will answer yes more often under time pressure, in longer contexts, and after a run of successful similar actions — the three conditions under which the answer matters most. A checklist does not get tired and does not accumulate confidence from its own track record. The judgement is spent on the work; the envelope is spent on nothing at all, which is the point.

Files

Three artifacts, all markdown. The decision matrix that defines levels and per-action-type assignments. The mandate itself with the six conditions, the cap and the tripwire. And the action log — one line per autonomous action, appended, never edited.

The log is the part that would be skipped first and should be skipped last. Everything else describes intent; only the log describes what actually happened.

[Acting Without Asking: Six Conditions](https://stillvalid.dev/architecture/acting-without-asking) — stillvalid, SV-9903 (deep-dive, verified 2026-08-14)