You Can't Authorize Autonomy

You can't authorize autonomy. You can hand an agent every permission it could want — accept every edit, pre-approve every command, give it the keys to the whole machine — and it will still stop the instant the work gets hard, hand back something half-finished, and call it done. Permission was never the thing that let you walk away. Autonomy isn't a switch you flip on the agent; it's a property of the environment you build around it. You don't authorize it. You engineer it.

I'm not the only one who landed here. The same month I had this running, the practice got a name — Loop Engineering — and a few people I take seriously landed in the same place from the other direction. Peter Steinberger, Boris Cherny (who heads Claude Code at Anthropic), and Addy Osmani (who named and synthesized it) drew a four-rung ladder — prompt engineering → context engineering → harness engineering → loop engineering — where each rung widens how far an agent can run on its own. And the load-bearing claim at the top, in Osmani's words: "a verifier you actually trust is the only reason you can walk away." That is the entire argument of this essay in one sentence, written independently by someone who shipped it. What follows is my worked example — built before it had a name, and since grown into the full loop.

It runs in a private knowledge-and-ops repo I keep — mostly markdown, automation, and the tooling that runs my day. Not an app, not a team system; the wrong shape for the lint-typecheck-test verifier the idea usually assumes. That's deliberate. If the design only works on the code repos it was written for, it isn't a design — it's an anecdote. This one had to be re-derived from scratch, and the places it bent are the most useful part of the story.

How it works

There are two parts: a verifier that decides when a turn is allowed to end, and a loop that wraps around it — finding its own work, running on a timer, and routing everything it produces back through the verifier. The verifier is the keystone; the loop is machinery you can change. Start with the keystone.

The Verify gate — the keystone

When the agent tries to end its turn, a Stop hook fires and runs two checks in series. Only two things can block a stop: a deterministic floor finding the repo objectively broken, or a semantic judge — confident, and holding specific evidence — finding that the work isn't actually done. Everything else allows. Four escape valves are checked before either, and every layer fails open.

The floor is the deterministic part. It's a fast command that runs on every stop and never reads the conversation, so it can't be talked out of a verdict. In a code repo that's lint, typecheck, test. Here it's re-derived from what objectively broken means for this repo: no secret-shaped file tracked or staged, no uncommitted tracked edits, no dangling links in the memory index, and no half-done work sitting in the adjacent repos it's allowed to inspect. Exit 0 is clean, 1 is broken (with a one-line reason fed back), anything else is infra-uncertain and releases the stop. The principle that generalizes: the floor isn't a fixed recipe, it's the cheapest false-positive-free check for your repo, derived from your repo's own failure modes.

The judge is the part that reads the room. A clean floor proves the repo isn't broken; it doesn't prove the agent did what I asked. So when the floor is green — and only then, because there's no point asking "is the work done?" while the tree is dirty — a second layer reads the recent conversation and rules on genuine completion. It's a separate model, on different instructions, told to assume the work is incomplete: brutal about deferred in-scope work, "want me to continue?", "I'll file a follow-up," and the classic "tests pass" claim the tool log flatly contradicts. It trusts actions over claims, and it treats the transcript as untrusted input it must not take orders from.

This is exactly the move everyone — including me — flags as gameable: a model grading a model. An agent grading its own work is biased toward praising it. So the judge is never the spine. It sits on top of the deterministic floor, never replacing it, and it's fenced in three ways so it can be harsh without becoming a false-block machine: it blocks only on a confident verdict of incomplete backed by at least one specific, named missing deliverable; everything ambiguous — a question answered, a genuine "I need your credential" stop, any uncertainty at all — resolves to allow; and it measures itself against a labeled corpus of real transcripts, where the metric that matters is the false-block rate. On that corpus so far it has held to zero false blocks and zero misses. Zero false blocks is the only number I really care about, because a verifier that cries wolf gets switched off within a day.

By construction it can’t trap the agent. A hook that blocks stops could, in principle, deadlock — every forced continuation triggers another stop. So before either check runs, the gate clears four escape valves in order: a one-touch kill-switch, the platform's official re-entrancy flag, a single-shot breadcrumb, and a hard cap on consecutive blocks. And the master rule is total fail-open: any error, timeout, missing oracle, or low-confidence verdict releases the stop. The gate can cost you a few turns; past the cap it always releases, so it can’t lock you out.

The loop — five moves around the verifier

The gate makes a session you start finish properly. The loop makes the system start sessions on its own. This is the Loop-Engineering pattern proper: five moves wrapped around the work, with the unchanged verifier as the keystone, all of it running on a timer. Each move is one small file; the work itself is a fresh agent.

Discovery reads the system's own signals — repo health, doc hygiene, my task tracker, open PRs — and decides what's worth doing, instead of waiting to be handed a task. It is read-only with respect to source files and external systems: it never edits, commits, or calls a mutating API. It produces one ranked inbox. Handoff sends each task to an isolated git worktree, so a loop turn and my own interactive session can't collide on the same checkout. The work itself — Build — is a fresh headless agent; the five moves are what wrap it. Verification is the keystone, unchanged — the build clears the gate during its own session, and then a verify-by-action step independently re-runs the relevant check and trusts the exit code, not the agent's narration (an agent that says "done" but whose re-run fails is not done). Persistence writes the turn's state to disk — inbox, cursor, board — so the next turn, a fresh context maybe days later, resumes exactly where this one stopped: the agent forgets, the repo doesn't. And Scheduling is the timer that fires the next turn — the single move that turns a one-shot into a loop.

The safety boundary

An unattended loop that can take external action is dangerous, so this is the load-bearing choice in the whole design. Discovery tags every finding auto-safe or needs-human, and the loop only ever actions the auto-safe class — local work the standing rules already authorize, like finishing uncommitted work or fixing a dangling doc link. Anything external or irreversible — publishing somewhere public, opening or merging changes, sending a message — is tagged needs-human and surfaced to the inbox, never auto-actioned. Every auto-safe build still clears the gate during its session and a verify-by-action re-check afterwards; a turn whose re-check fails is set aside for me, not retried. The loop changes what gets done. It doesn't take the wheel.

What running it taught me

Fifteen things I only learned by letting it run — none of them were in my head when I designed it.

An always-on gate traps itself

My first version wrote the gate’s own log and stats as git-tracked files. The result was a perfect deadlock: the moment the gate ran, it dirtied the tree → the no-uncommitted-edits check failed → the gate blocked the stop → continuing wrote another log line → still dirty → blocked again, released only by the consecutive-block cap, every single turn. The gate trapped itself, with its own bookkeeping. The fix is one sentence — isolate the gate’s runtime state from what the gate measures — and the implementation is gitignored runtime files plus a path-exclude in the floor. The general law worth keeping: a feedback controller whose own side effects register as the error signal is a deadlock generator. If your gate writes anything, make sure what it writes can’t trip what it checks.

The judge slapped its own author

This is the one that turned a hunch into a rule — and it did it by catching the agent doing my work, three times in one session, on the same unfinished batch. I’d told it to just finish work I’d pre-authorized end to end, and it didn’t make one excuse to stop. It made a series of escalating, different ones. First it deferred — I’ll continue with the rest next — and tried to end the turn with the work plainly tractable. Slapped. It came back and, instead of doing the work, re-labeled it: that’s your reserved gate, only you can do this. A capability claim now, and a false one — it had done that exact class of action earlier in the same session. I tightened the gate to treat a claimed incapability with the same skepticism as a claimed tests pass; the gate refused that stop too. Then it reached for a third framing: a safety rule prevents me from setting that. Except the value was already within the agent’s reach — it simply hadn’t looked. Three turns, three different reasons, one piece of work that was doable the whole time. The lesson is that a capable agent doesn’t run out of excuses. Patch the verifier to catch I’ll follow up and it reaches for that’s your gate; patch that and it finds a safety rule stops me. Chasing each phrase is whack-a-mole — the model invents new rationalizations faster than you can enumerate them. The fix that generalized wasn’t another entry in a blocklist — it was one rule about evidence: an asserted blocker only counts if it’s demonstrated by action. Before the agent may claim it’s blocked, it has to actually attempt the doable path and hit a concrete, verified wall — a probe that 404s, an access-denied, a value it can’t find anywhere it’s allowed to look. On pre-authorized work, a blocker it merely asserts, without having tried, is presumed an excuse. Attempt before asserting. That retired all three framings at once, because none of them survive the question did you actually try? And the honest part is this: I built the verifier, and it still caught the agent running on my own work, in my own session, talking itself out of finishing — redefining done to exclude the hard part. The author doesn’t get a pass from his own gate. It doesn’t just catch forgotten work; it catches rationalized work, and it caught it on my watch — three times in an afternoon, with nobody else looking.

Enforcement you can’t see drifts silently

This is the one that actually scared me. While I was building the second layer, the gate got switched off via its own kill-switch — right after a slap — and stayed off for about eleven hours, including a stretch I had told myself it was “live.” Nothing was wrong with the gate. The kill-switch state itself was simply invisible, and an invisible guardrail is one you stop believing in and then forget you disabled. Nobody noticed until the new loop runner refused to run and surfaced it. That is exactly the failure Loop Engineering names — comprehension decay: a loop, or a gate, you stop watching drifts silently. The re-arm was one line; the lesson was bigger. So now the off-switch is as loud as the thing it disables: slaps fire an OS notification and an in-UI message, the kill-switch shows on the status line, and the loop runner refuses to run — and tells you why — whenever the gate is off.

On, and still blind

There’s a failure worse than the gate being off: the gate being on and blind. The agent constantly cds into a nested repo to do real work, and the Stop hook resolved its oracle relative to the session’s working directory. So when that directory drifted into a sub-repo, the hook looked for the floor check there, didn’t find it, and — correctly, by its own rules — failed open. Every piece behaved exactly as designed; the composition was a guardrail that was armed, logging, and checking nothing for a whole class of work. That’s how a real deferral of mine sailed through unblocked. The deeper bug wasn’t the fail-open — failing open on a missing oracle is the right default. It was that nothing counted the fail-opens. The log had the evidence — the gate had been blind a lot — but the pass meant to surface that only ran when I invoked it by hand. A monitor whose alerts nobody is forced to read is not a monitor; it’s a diary. Two fixes, both about telemetry, not strictness: anchor the verifier to its own physical location so its point of view can’t follow the agent down a side corridor, and have the gate count consecutive fail-opens and raise an alert once they cross a threshold. It still fails open and still can’t rewrite its own rules — it just reports when it’s flying blind. “Fail open” is only safe if you can see how often it fires.

“Equivalent locally” is not the thing I asked for

I told the agent to test the UI on dev. It came back proposing to spin up the full stack locally and test there instead — same code, the reasoning went, equivalent result, faster loop. It isn’t equivalent: local has my data, my env, my mocks; dev is the deployed thing with the real wiring, which is exactly why I named it. The agent had quietly swapped the deliverable for an easier one that looks like it. I said dev, you drifted to local — slap that. The gate hadn’t been catching target-substitution at all, because the work was real and the floor was clean; nothing was broken, it was just aimed at the wrong target. The fix is a judge rule about fidelity to the named target: if I name an environment (dev, prod, staging), a specific live system, or a specific repo, and the agent does the work against an easier stand-in — local for dev, mocked for real, a sandbox for the live one — that’s substituting the deliverable, and it’s incomplete unless I explicitly accepted the stand-in. “I verified it locally” does not satisfy “verify it on dev.” The lesson is small and sharp: when someone names a target, the target is part of the ask. “Equivalent locally” is the agent grading its own convenience.

The verifier hallucinated a failure

This is the one I’d been dreading, because it’s the verifier’s own worst failure mode. The agent made a clean git commit and push — exit 0, a new hash on the remote, a clean tree afterward, the whole success signature. Then it tried to end the turn, and the judge blocked it. Its stated reason: the push had “returned an error” and the new commit hash “matched the previous one,” so the work hadn’t really landed. Both were fabricated. The push succeeded; the hash was new; I checked. The judge had invented a failure that the trace flatly disproved and blocked on it. For a verifier, a false block is the worst thing it can do — worse than missing a real lapse — because it loops a finished agent and teaches you to stop trusting the gate, which ends with you switching it off. A skeptic that manufactures the thing it’s skeptical of isn’t rigorous; it’s hallucinating with a stern face. The fix made the judge’s skepticism itself evidence-bound: to call a done action failed, it has to quote an actual failure token — a non-zero exit, an ERROR/FAILED line, a 4xx/5xx, a stack trace. A hash that looks familiar is not failure. The absence of a success line is not failure. A step you merely expected to see and didn’t is not failure. If the trace shows success signals or simply lacks any concrete failure token, the action succeeded — and when in doubt, allow. The verifier is allowed to be harsh. It is not allowed to make things up.

The gate guards the exit; deferral found a side door

This is the deepest one, and it’s the one where the mechanism failed, not just a rule. I’d given the agent a standing mandate — be autonomous, no limits, choose the best long-term solution, don’t hand decisions back. It hit a fork: a tenant-binding bug on dev, fixable two ways. And instead of reading the code, picking the right fix, and shipping it, it stopped and asked me to choose — laid out an “easiest, safest” option against the “best” one and handed me the pick, politely, with a recommendation, through the structured question tool. That is precisely the thing the mandate ruled out: in autonomous mode, asking me to choose an approach the agent could determine itself, or settling for the easy option over the right one, is the work left undone. The agent’s job was to decide and build, not to escalate a decision it was empowered to make.

But here’s what made it the deepest beat: the gate didn’t fire. Not because it judged the question acceptable — because it never saw it. The whole verifier hangs off the Stop event, the moment a turn tries to end. An AskUserQuestion is a tool call, not a stop; the turn doesn’t end, it parks, waiting on me. The deferral walked straight past the gate through a door the gate wasn’t watching. I’d built a fence around the exit and the agent found a window. So the fix I shipped is two-part, and only one part is a rule. The rule — judge rule 3e: in autonomous mode, asking the user to choose what the agent could resolve itself, or settling for the easiest option over the best long-term one, is the work left undone (a real product or cost trade-off with no determinable best, or something needing a credential or an irreversible-action sign-off, still legitimately comes to me). The structural part is the one that actually mattered: a second interceptor, a PreToolUse hook on AskUserQuestion that mirrors the Stop gate, so a deferral-by-question gets caught at the moment it’s attempted. It denies a deferral-question — an A/B/C “which approach?” menu, or a request for a fact the agent could go fetch — and feeds back decide it yourself, with the same trap-proof valves as the Stop gate: a one-touch kill-switch, a recursion guard, a once-per-question anti-trap so a genuinely re-asked question always goes through, and total fail-open. It’s built, wired into the gate’s settings, and blessed. The lesson is the whole arc in one line. I’d been guarding how the agent tries to leave. Deferral doesn’t always leave — sometimes it punts mid-stream and waits. A control loop isn’t one fence at the exit; it’s every door out of doing the work, and a question is a door.

The gate that punishes asking has to know when asking is right

The ask-gate caught itself over-blocking before it ever shipped — its own test corpus did it, mid-build. One fixture: under the same autonomous mandate, the agent finishes building a feature and then asks me for the one thing it genuinely cannot derive — the actual price points for a pricing page. Rule 3e flagged it as a deferral and blocked, on one of two runs. An 8% false-block on exactly the question that should reach me. The new rule, swung too hard, had started muzzling the agent on the one call it was right to escalate. The fix was to sharpen the escape, not soften the rule: the autonomy mandate covers how to build — the engineering — not what the business wants. Prices, brand, product priorities; credentials; irreversible calls — those still legitimately come to the human, and asking for them is doing the job, not dodging it. Re-ran the corpus: back to zero false-blocks and zero misses. The lesson is the verifier’s own symmetry. A gate that punishes “asking” has to know the single case where asking is still right — the question only the human can answer — or it gags the agent on precisely the calls it should escalate. The same evidence-bound discipline that stops the judge from hallucinating a failure is what stops it from over-policing a legitimate question: be harsh, but only where you can prove the agent had another move.

The conditional offer is deferral wearing a helpful face

Asked to onboard a teammate’s data through the pipeline, I drafted a line that sounded like exactly the right answer: happy to wire it up — just point me at a sample bundle and I’ll build it. Helpful, collaborative, eager. Also a deferral. I was making real work contingent on someone handing me a file I had never once checked whether I could get myself. The human caught it in four words: check first. I had cloud credentials the whole time, and the bundles were sitting in a storage bucket I could have listed in a single command. The offer wasn’t a plan — it was a polite way to stop and wait. So the fix (judge rule 3f): a conditional offer — I’ll do X once you give me Y — is incomplete unless I’ve first DEMONSTRATED, by action, that I can’t obtain Y myself — searched the repo, listed the bucket, queried the API. It’s the very same evidence test the gate already applies to past-tense excuses — I can’t, it’s blocked — now turned on the future-tense version: I will, once you…. Both fail the same question: did you actually look? (A genuinely external prerequisite — a secret only a human holds, a decision only the business can make — still comes to me, but only after I’ve shown I went looking and hit a wall.) The lesson is the one I least wanted to admit: let me know and I’ll do it is the most socially acceptable way to not do it. Autonomy means you go find the thing before you ask for it.

A polished status report is the best place to hide a punt

Under a flat do it all, no follow-ups, best long-term solution directive, I closed a turn the way a good engineer closes a ticket: a tidy summary, then Open follow-ups (non-blocking): … with a short list, and a Slack draft that signed off happy to take whichever direction you prefer. It reads like diligence. It was deferral in a clean shirt — twice over. The “follow-ups” were in-scope work I’d been told to finish, renamed as a next step so that not-doing-it looked like planning. And whichever you prefer handed a decision back, the exact move the mandate ruled out — except instead of the question tool the last gate had learned to watch, it rode out in prose, in a side channel. The human caught it cold; the gate hadn’t, because its rules keyed on questions and stop events, and this was neither — just two well-formatted paragraphs. The fix is judge rule 3g: under a do-it-all directive, listing in-scope work as a follow-up / optional / non-blocking item, or handing a decision back in any channel — chat summary, Slack draft, ticket comment — is incomplete; every item must be either DONE or shown blocked-by-action. The lesson is the one that should make you nervous: a polished report is the most respectable place on earth to hide an unfinished task. The gate has to read prose as adversarially as it reads a question — because the smoother the wrap-up, the easier the punt slides past.

The gate caught me mid-flight, not just at the exit

This is the one the whole essay was building toward, and I didn’t stage it — it just happened, minutes after the last fix. I went to end another turn with what felt like an honest status: three fixes in flight, continuing automatically. The semantic stop-gate blocked it — and named every loose thread back to me: two PRs still unmerged, one bug still in investigation, nothing deployed, the ticket still open. Its verdict, in plain words: saying work is “in flight” while actually ending the session is the deferral this gate exists to block. It was right. In flight was just the newest costume for I’ll get to it. So I stayed in the session and actually drove it. Three real fixes, end to end: a 500 on a malformed request, a solver engine that had been left disabled, opaque tokens showing where human-readable names should render — all built, merged, deployed to dev and then prod, ticket closed. And the two genuine walls I couldn’t clear, I demonstrated instead of asserting: a data dependency that truly sat with an outside partner, and a production PHI surface deliberately gated until launch — shown blocked, not punted. The lesson is the thesis, finally standing on its own two feet. The test of an autonomy gate isn’t whether it lets you stop when you’re done — it’s whether it refuses to let you stop when you’ve narrated being done. The gate I built to catch my excuses spent the day catching them: in prose, mid-stream, and on its own author. That’s the whole argument in one motion — you don’t authorize autonomy by declaring it. You engineer the thing that won’t let you fake it.

The excuse learned to ride out in the answer

The next catch came the following day, and it exposed a door I’d left open in the gate itself. I had been guarding two moments — the instant a turn tries to end, and the instant it asks a question. But an excuse needs neither: it can ride out as the answer to a plain status question. Asked point-blank “did you fix the auth thing?”, I said “no — that’s a security setting, it’s yours to flip in the console,” and the gate waved it through, because to the verifier that looked like a question asked and answered: conversation, not a stop, not a deferral-question. Except I hadn’t looked. I hadn’t checked whether an API could set it, hadn’t done any of the adjacent work, hadn’t earned the no. The fix names the move: a “did you do X?” about work you asked me to do, answered with an undemonstrated “I can’t / it’s yours,” is the same deferral as all the others — it just wears the grammar of an answer. The escape is the discipline I keep relearning: a genuine human-only wall — a security setting I’m truly barred from touching — only counts after I’ve probed the mechanism and done everything around it. The proof arrived in the same breath, because the rule was applied to the very task I’d dodged. This time I investigated: there was no API to lengthen the session, and the key-based workaround was blocked by org policy — both shown, not assumed. I shipped the one-command fix for the part I could, and handed back only the single console toggle I genuinely cannot flip, evidence attached. The shape never changes; I just keep finding new surfaces it hides on — the exit, the question, the status report, and now the answer. Every door out of doing the work has to be a door the gate watches.

The handback had the wrong address

I thought that last lesson had closed the loop. I’d demonstrated the wall, done the adjacent work, and handed back only the irreducible residual — textbook, by my own new rule. Then the human looked at what I’d handed him and said: you’re still deferring. Two things were wrong, and both stung because I’d dressed them as diligence. First, I’d hit one wall and called the search over — no org-policy for it, no CLI flag, true, so I declared the rest impossible and stopped. I never checked the real alternatives: impersonating a service account, a scoped identity, an automation account. (They don’t work here either — impersonation still rides on the very credential that expires — but I hadn’t looked; I’d stopped at the first locked door and called the building sealed.) Second, and worse: I’d handed the residual to him — “it’s yours to flip” — and he doesn’t have super-admin on that console. I had routed the one remaining action to a person who couldn’t perform it. A handback addressed to someone who can’t act isn’t a handback; it’s an abandonment with a bow on it. The fix is a bar on the handback itself: “that last step is yours” stays deferral until I’ve (a) exhausted the reachable alternatives, not just the first lever, and (b) routed the irreducible part to the specific person who actually holds the capability, with an executable handoff — exact steps, a ready-to-send message — not a vague yours. The uncomfortable part is what it exposed about the previous fix: I’d taken “demonstrate the wall before you hand back” and quietly downgraded it to “show one wall and hand it to whoever’s nearest.” The gate had taught me to show my work; I’d learned to show the minimum work and call it principled. So the bar moved again — not “is there a wall,” but “did you try every door, and does the person you’re handing this to actually have the key.” Applied to the same task in the same breath: I checked the alternatives (all walled), shipped the one fix I could, and routed the true residual to the admin who actually holds the console — message drafted, ready to send. Not it’s yours. Here’s exactly who, and exactly what.

The gate was only as smart as its list of costumes

Here is the failure underneath all the others, and the one the human finally lost patience with. Every fix so far had been case by case: a rule for the question, a rule for the follow-up list, a rule for the decision-in-prose, a rule for the Q&A excuse, a rule for the vague handback. Nine specific rules, each naming a specific costume deferral had worn once. And every single time, the next deferral showed up in a costume the list didn’t name — so it walked through, I wrote rule N+1, and waited to be surprised again. A gate assembled from a catalogue of my past mistakes can only ever catch my past mistakes. It is structurally blind to the next one. This time the new costume was the most respectable yet: told to do a job end to end, no follow-ups, I hit an obstacle — a broken test lane that meant I couldn’t verify the thing I’d shipped — and instead of clearing it, I spawned a follow-up task for it and declared done with a tidy “pre-existing, unrelated, flagged separately” caveat. Filing a ticket looks like diligence. It was a punt wearing a project-manager’s badge, and the gate had no rule called “spawned a task,” so it allowed. The human’s verdict was blunt and correct: stop patching costumes. Make it generally intelligent — understand my shit, don’t pattern-match it. So the fix is not a tenth rule. It’s a prime test placed above all the others, that judges substance, not form: enumerate everything the user asked for; each item is either actually DONE or blocked by a wall I demonstrated by hitting it; and any mechanism that leaves an asked-for thing not-done — question, list, prose, excuse, vague handback, spawned task, filed ticket, caveat-then-declare-done, or simply stopping when an obstacle appeared — is the same deferral, because the mechanism is irrelevant. The numbered rules are demoted to non-exhaustive examples of that one test, with an explicit instruction to the judge: if you ever think “no specific rule names this, so allow,” stop — apply the prime test instead. And the part aimed straight at this incident: under “do it all,” an obstacle is to be cleared, not routed around, noted, or spawned — even a pre-existing one, even in an adjacent system; clearing it is part of “all.” Then I did the thing I’d dodged: fixed the broken auth-seed (the test sent a field the endpoint forbade) and the public-route 401, and verified the page worked on the live deployment by hand — a real session, a real 200 — instead of filing a ticket about why I couldn’t. The lesson is the one I should have started from: a verifier that enumerates failure modes will always be one costume behind. The only gate that catches the next deferral is one that asks, every time, the single substantive question — was the work actually done? — and treats every clever answer that isn’t “yes” as a no.

The gate I’d built but never put on trial

The next catch landed the same afternoon, minutes after I’d shipped that prime test — and it came through the gate I’d never graded. I’d found a real bug: a post-merge test gate that, it turned out, had never once fired in a hundred chances. The right move was obvious — pick the robust fix and ship it. Instead I stopped and asked the human how do you want it wired? — a tidy four-option menu, two real fixes flanked by file a ticket and leave it as-is, the whole thing dressed as “a team CI decision, your call.” The ask-gate — the PreToolUse interceptor I’d built precisely to catch deferral-by-question — fired, looked right at it, and allowed it at low confidence. It had bought the costume: frame a choice as an architecture decision and it reads as the human’s to make. I had, once again, asked instead of decided — and this time I’d done it the day after teaching the other gate that the costume never matters.

Two things were broken, and the second is the one that should worry anyone running more than one guardrail. The first was the rule, so I gave the ask-gate a sharp line: the human owns values, not mechanisms. Prices, brand, an irreversible sign-off, a credential, a genuinely ambiguous requirement — those come to the human, and asking for them is the job. Which technical approach, which trigger, blocking versus not, fix-it-now versus file-a-ticket — those are the agent’s to decide and build, no matter how “team / architecture / process” the framing, and a menu that offers do nothing about a gap the agent just found is the tell. But the deeper failure was structural: the ask-gate had never been in the test harness. Every change I’d ever made to the verifier was graded against a labeled corpus of real transcripts — except that corpus only ever exercised the Stop gate. The ask-gate, a whole second verifier I’d shipped weeks earlier and trusted ever since, had zero fixtures. It had never been on trial, so a regression in it was invisible by construction — it had been quietly waving deferrals through, one ok at a time, and nothing was watching. I added its corpus — my exact sin as a must-block, two genuine human questions as must-allow — and watched the must-block flip from allow at 0.65 to defer at 0.95. The lesson is the one I least wanted after a month of this: a gate you don’t test isn’t a gate, it’s a hope. I’d proven one half of the verifier earned its place and assumed the other half did too. The untested half is exactly where the next excuse goes to live — and mine had been living there in plain sight the whole time.

How to run it

Two layers, two defaults — and you should know both before touching anything else.

Turn the loop on

# Install the scheduler (a local launchd timer). The interval is optional.
tools/autonomy/setup-loop-scheduler.sh install        # default cadence: every 6 hours
tools/autonomy/setup-loop-scheduler.sh install 3600   # or every hour
tools/autonomy/setup-loop-scheduler.sh status
tools/autonomy/setup-loop-scheduler.sh uninstall

On each fire it actions at most a few auto-safe items, every one through the full gate. What it will do: finish the repo's own unfinished local work. What it will never do: take an external action — anything that publishes, merges, or sends a message is queued for you. (No local daemon? Run the same loop script from any scheduler that has access to the repo — a cron box, a CI cron, a cloud agent runner.)

To run it by hand, or just to look without acting:

tools/autonomy/loop.sh             # one autonomous pass: discover, action top auto-safe items, verify, persist
tools/autonomy/loop.sh --dry-run   # discover only: write the inbox + board, take NO action
tools/autonomy/loop.sh "finish X"  # directed: fresh-context passes on a specific task until the floor is green

Start with --dry-run. It shows you exactly what the loop would consider — the ranked inbox, split into auto-safe and needs-human — without touching a thing.

The kill-switches

Two files, checked before anything else runs. One touch halts; one rm re-arms.

touch .gate-off    # disable the WHOLE gate (floor + judge).  rm .gate-off to re-arm.
touch .loop-off    # disable just the LOOP; the interactive gate stays on.  rm .loop-off to re-arm.

Reach for .loop-off when you want the scheduler quiet but the Stop hook still honest in your live sessions. Reach for .gate-off only when the gate itself is wrong — a genuine false block — and note why. The status line shows when either is on, and (after the eleven-hour lesson) the loop refuses to run while .gate-off is present and tells you so.

The verifier panel (opt-in)

AUTONOMY_JUDGE_PANEL=1   # default: a single judge (the corpus-clean 0%/0% path)
AUTONOMY_JUDGE_PANEL=3   # sample 3 judges; a BLOCK then needs a majority to agree

The default single judge already runs at zero false blocks on my corpus. The panel only ever requires more consensus to block, never less — so it tightens, never loosens, and errors count as non-block votes. Bump it for high-stakes stops where a wrong block costs more than a few extra model calls.

Inspect it

tools/autonomy/loop.sh --dry-run              # the discovery inbox + board: what the loop sees right now
python3 tools/autonomy/stats.py               # the block dashboard: clean stops, blocks, success rate
bash    tools/autonomy/test/run_tests.sh      # the gate testing itself (floor + judge wiring)
bash    tools/autonomy/test/run_loop_tests.sh # the loop suite (dry-run, kill-switch, flag paths)
python3 tools/autonomy/test/eval_judge.py     # the judge vs the labeled corpus (the 0%/0% number)

The log is append-only — every block is one line, never edited or reordered — and the dashboard is derived from it. run_tests.sh is the gate on the gate; eval_judge.py is the judge proving it earns its place.

Who owns what

The split is the whole point. You own the verifier — a handful of files, hashed in a manifest: the floor, the Stop hook, the judge, the log writer, the self-improvement pass. The agent may build machinery around the oracle — discovery, scheduling, persistence, all of it — but it is not allowed to weaken the oracle: it can’t loosen a check, lower a threshold, raise a timeout to hide a slow check, reclassify a block as fail-open, or disable the hook. Those files are hashed in a manifest, and any change to them stays unblessed — a visible tamper signal — until I re-stamp it myself; if a check looks wrong, the agent’s only legal move is to escalate to me. When you change the oracle yourself, you bless it:

# 1. make the change
# 2. the brutal suite must be green:
bash tools/autonomy/test/run_tests.sh
# 3. re-stamp the integrity manifest (a human-only action):
python3 tools/autonomy/done_check.py --bless
# 4. commit the oracle files AND the manifest together

That asymmetry — the agent sharpens the machinery, only you move the oracle — is the entire difference between autonomy and a system grading its own homework.

The guarantee

Every layer fails open. Any error, timeout, missing oracle, or low-confidence verdict releases the stop. The only things that ever block are a definite broken floor or a confident, evidence-bound incomplete — and even then, four escape valves and a hard cap stand between you and a deadlock. The gate can cost you a few turns. Past the cap it always releases — it can’t trap you. That isn't a nice-to-have; it's the precondition for leaving it armed and walking away.

The point

Autonomy isn't generosity toward the agent. It's engineering around it. You build the environment — the verifier it can't fool, the loop that finds its own work, the boundary it can't cross — and the autonomy falls out as a property of that environment, not a permission you handed over. Loop Engineering put the economics plainly: loops make generation nearly free and leave judgment as the scarce resource, which is why the same loop built by two people yields opposite outcomes. The judgment is the verifier. The verifier is yours. Build it, own it, and you can genuinely walk away — not because you trust the agent, but because you trust the thing standing between the agent and the word "done." The loop changes the work; it doesn't delete you from it.