Autonomy, checkpoints, and stability

Move up the dial for a specific kind of work once it has repeatedly gone well, not across the board because the agent has generally been good. Most people end up running different levels at once — unattended for a nightly report, propose-only for anything touching production.

Every checkpoint spends attention, and attention is finite — so put them where the downside is real rather than everywhere.

• Irreversible. Deleting data, terminating resources, force-pushing, anything with no undo.
• Outward-facing. Anything a customer, a regulator, or the public will see. Sending is publishing.
• Expensive. Resources that bill by the hour, or that are easy to create and easy to forget.
• Security-relevant. Permissions, credentials, network exposure, anything touching IAM.
• Novel. The first few times in a new area, regardless of category.

Everything else is a candidate for act-and-report. If you are approving a change you would never have rejected, that checkpoint is costing you attention you need elsewhere.

A checkpoint is only real if it can produce a “no.” Three ways they quietly stop doing that:

• Rubber-stamping. You approve without reading, because it has been right thirty times. The gate still exists on paper and stops nothing.
• Approval fatigue. So many prompts that you batch-approve to clear the queue. Too many checkpoints reliably produces less scrutiny than a few.
• Unactionable detail. A four-hundred-line diff with no summary of what changed or why. If you cannot evaluate it in the time you have, you are not reviewing it, you are acknowledging it.

The habits that keep a delegated system stable are the ordinary ones, and they matter more here because changes arrive faster than intuition adapts.

• One substantive change at a time in anything that matters. When two land together and something breaks, you have doubled your search space.
• Let it settle. Give a change long enough in staging to show its second-order effects before promoting it.
• Prefer idempotent work. Operations that are safe to run twice turn a retry into a non-event instead of a duplicate.
• Keep the blast radius small. Separate environments, separate credentials, separate accounts where it is worth it.
• Verify from the running system. A merged change and a green build are not evidence that production changed.

A schedule is the highest-autonomy thing you can create: it acts with no one watching, repeatedly. Two failure modes deserve naming because both are quiet.

Silent no-ops. A scheduled job that stops doing anything usually fails silently — nothing errors, nothing is produced, and you notice weeks later. Ask for a positive signal on success, not only on failure, so absence is detectable.

Runaway repetition. A schedule that starts work faster than the work finishes, or that retries a failing action forever, compounds while you sleep. Cap concurrency, cap retries, and make sure stopping it once actually stops it — cancelling a task is not the same as cancelling the schedule that spawns it.

Monitoring is how autonomy stays safe, which means alert quality is an oversight concern rather than a cosmetic one. An alert that fires every five minutes for a condition you cannot act on does not inform you — it trains you to ignore that channel, including the day it matters.

Alert on transitions, not on states. Something that is still broken is not news; something that just broke, or just recovered, is. If a notification does not change what you would do, it should be a dashboard entry, not a message.

When you increase autonomy, do it as an explicit decision with a stated reason and a way back: “deploys to staging without asking, from now on, because the last dozen were correct — production still needs approval.”

Autonomy that expands by drift, one exception at a time, is how people end up unable to answer what their agent is currently allowed to do. Narrowing again after a bad outcome is a normal adjustment, not a failure of the tool.