We let agents run tickets to PR unattended. The thing that made it work wasn't a better prompt, it was deleting a tool.

Context so you can weight this: small team, real production codebase, running for about four months, 63 tickets from intake to merged PR. I'm posting the design rather than the repo because I want the holes found, not stars. The problem I actually had The agent was competent. It just wouldn't stop stopping. Every ambiguity became a question, so a "40 minute unattended run" was really six interruptions spread across an afternoon, and each one cost me more in context-switching than the thing it was asking about. Autonomy wasn't limited by capability. It was limited by the interaction pattern. So the goal collapsed into one sentence: a run executes to completion and halts only at the human stops declared for its flow. Feature gets one stop. Hotfix gets two, once before spending money and once before an irreversible ship. Nothing else may block. 1. "Blocked" is a state, not a stop The ask-the-user tool is removed from every flow agent's tool list. Not instructed against. Removed. When an agent hits ambiguity it records the question, the default it applied, and an impact rating, then keeps going: adw question <runId> --q "rate-limit window unspecified in REQ-API-011" \ --default "60s sliding, matching PAT-API-002" \ --impact low Every accumulated question surfaces together at the human gate. Six interruptions become one review. Highest-value change in the whole system and it's about four lines of config. 2. An assumption budget, because #1 is dangerous alone Unlimited autonomy plus silently-applied defaults lets a run drift a long way before anyone looks. So exceeding N high-impact assumptions trips an early human gate by itself. The system escalates when it notices it's guessing too much, instead of presenting a pile of guesses at the end. 3. Transport and judgment are separate layers The orchestration scripts know about fan-out, bounded retries, gate order, worktrees, resume. They know nothing about whether a spec is good. That lives in the gate agents. Different change rates: transport is mechanical and stable, judgment changes constantly. When they were conflated, changing a review rule meant editing an orchestrator, which is how you end up afraid to change review rules. 4. A failing gate is a bounded repair loop, not a halt. Blockers feed back into authoring and re-review, three attempts. The gate keeps full authority to reject. It just doesn't need a human to carry the verdict back to the author. 5. Done is machine-checked. A run is done only when every gate passed, a PR exists, commits are recorded, the knowledge base was written back, assumptions were reviewed, and worktrees are clean. Anything else is blocked or failed. No quiet partial successes, which used to be my most common failure: something reports success and two weeks later you find the traceability never happened. The opinionated parts Two test roles, not one. One agent answers "is it green?". A separate one answers "is green meaningful?" — does every acceptance scenario map to a test that actually asserts it, and did any test get weakened to reach green. That second question is completely invisible to a green CI run. The review panel is conditional on measured blast radius, from a read-only recon pass, not on how the ticket describes itself. Security review only fires when the diff reaches auth, secrets, sensitive data, or outbound calls. A one-line chore shouldn't pay for a six-agent panel. Hotfixes race three sandboxes under three different strategies (minimal-patch, root-cause, defensive-guard). I tried identical agents racing first and it's useless: three near-identical diffs, and the selector has nothing to choose between. Diversity is the entire product of the race. Selection is an arbiter reading the actual diffs, never first-green-wins. Arrival-time selection rewards whoever reached green cheapest, and the cheapest route to green is weakening the failing test. Anything that loosened or skipped an assertion is disqualified outright, and "none of these should ship" is a valid verdict. A hotfix takes on debt, not an exemption. It skips the spec gates, so the run refuses to close until the retro-spec is back-filled. The moment service is restored is when everyone stops caring, and it's the only moment the reasoning is still in someone's head. Traceability by ID, not by file path Boring, and it mattered more than any prompt change. Our traceability originally cited file paths. I audited it against ~3,200 lines of knowledge base covering 20 released epics, carefully maintained by humans: 184 citations - 0 resolved to exactly one requirement 16 resolved to nothing at all 39 resolved to 11 candidates each 10 resolved to 19 candidates each A path names a document, and a document holds many assertions, so "see auth-spec.md" tells an agent almost nothing. I also found 69 blocks of reasoning buried in the YAML comments of a machine-read registry, purely because there was nowhere else to put a decision, and a stack of in-place "superseded" blocks where each correction had been appended to the thing it corrected. Current truth was sitting behind three layers of retraction. Fixed by moving to atomic nodes with stable IDs, first line is the whole assertion, supersession writes a new node linking back so retractions stay off the answer path, CI fails on a dangling citation. How I check the pipeline itself, which is the part I'd most like torn apart At some point I realised I had a system that reviews code, and nothing that reviews the system. So there's a check battery ("the gauntlet") with three rules: Everything runs, every time. Never "just the failing one." A loop that re-checks only what it touched converges on a state where each check passed at some point and none passed simultaneously. Looks finished. Isn't. Regressions are labelled. "Was green, now red" is different information from "still red" and demands a different response. The previous run's results are kept on disk purely to make that distinction. Green means green. No allowance for known failures. A check that shouldn't block isn't a check. In loop mode it stops when a round produces no net improvement, rather than burning budget pretending it's converging. Some of the checks are structural in a way I've found unusually high-yield: no agent declares the ask-the-user tool — the autonomy contract is a grep in CI, not a paragraph in a doc every declared workflow phase is actually reachable — caught two phases (release, and the hotfix debt back-fill) declared in metadata and never executed. Both silently did nothing. Runs looked successful. no helper is defined but never called — caught a doc-curation function that was wired into nothing every agent a flow invokes actually exists run state validates against its schema, exercised against a throwaway fixture Right now it's 14 green out of 17, and I wrote the three red ones before the fixes, because a check written after the fix only ever encodes what I already did: Flows embed full payloads into prompts instead of pointers (4 sites). The central claim of the design is that orchestrator context stays O(1) in what the agents find. Currently false. 51 shell commands are run by spawning an agent to run them. I have a helper that spawns a cheap model whose entire job is to run one command and echo stdout. It works, it's absurd, and it's most of my per-run overhead. Gate 3 escalates on the first failure while gate 1 and build/test both auto-repair 3 times. That's an inconsistency I talked myself into calling a design choice. The scoreboard Learning is only real if numbers move, so there's a metrics command that splits runs at a baseline date and shows before/after, specifically so a ratified change can be judged instead of assumed. Headline metric is the human override rate. Also tracked: gate-1 rejection rate (high means specs are being authored badly), assumption override rate (high means my defaults are wrong), average build attempts and how often the retry budget maxed out, median hours to ship, and tokens per run broken down by phase so the heaviest phase is visible. Only instrumented runs count toward token averages, because averaging in zeros from un-instrumented runs would hide the trend. What I don't trust The gauntlet only checks structure. It can prove a phase is reachable and that no agent can halt a run. It cannot check whether a reviewer's verdict was right. So the parts most likely to be wrong are exactly the parts nothing verifies, and I don't have a good answer for that. Correlated reviewers. Six agent reviewers may not be six independent checks. Shared blind spot means the panel is theater with a cost. Goodhart on the repair loop. When a gate rejects a spec and the spec is auto-revised and re-reviewed, am I improving the spec or training it to satisfy the reviewer? Three attempts is a guess at where that flips. The arbiter is the same kind of thing it's judging. Its only hard rule is "disqualify anything that weakened a test," and that's still pattern matching over a diff. I traded interruption count for review size. One stop at the end means a human reviews a much bigger diff with less context on how it got there. Above some size that's clearly worse than three small interruptions and I don't know where the line is. Cost. Three racing sandboxes is roughly 3x. Justifiable during an incident and nowhere else. If you've built something in this space: where did yours break? Most interested in anyone who removed the interactive question path and regretted it, anyone who found a way to verify judgment quality rather than structure, and anyone who has a better answer than "more reviewers" to the correlated-reviewer problem.