Early July I went to bed and left an agent working. When I got up there was a working web app: built, tested, cross-reviewed by a second model, and deployed to production. The run took eleven hours, consumed 251,900 tokens in a single macro-turn, and needed exactly one human touch along the way, an approval at the deploy gate. What it built was the first slice of my own productivity tool: capture a task from my phone straight into my ticketing system, and a read-only page answering “what’s on today and this week” from tickets and calendar together.
The reaction I usually get to this story is about the model. The model matters, but it’s the least interesting part. Autonomy isn’t a model capability. It’s an envelope you engineer around the run before it starts.
Here’s the failure the envelope exists to kill: a capable agent stalls at 2am on a question I could have answered at 9pm. Every failed overnight run I’ve had traces back to that shape. The fix was never a longer prompt. The fix was moving every foreseeable decision in front of the run, and giving it one rule for everything unforeseen.
The envelope, part by part
Feasibility triage. Not everything runs unattended. Work that’s fully specified, writes locally, and ends in pull requests is green. Anything irreversible, production deploys, external shares, is a gate, and gates get handled before launch, never during.
The decision ledger. Before a run launches, I interview it in reverse: what will you need to decide that isn’t in the ticket? A recent control-plane build surfaced three such questions: which entity a record should attach to, where a particular action belongs in the flow, and whether a database migration gets applied or merely filed in the pull request. Ten minutes at my desk answering those. Each one would otherwise have been a 2am stall, or worse, a guess.
Scoped pre-authorisation. Some gates can’t be pre-answered, only pre-authorised. A production deploy gets a written authorisation with explicit scope, or the run gets a graceful fallback: stop at the last safe point with pull requests open and evidence attached. Both, ideally. “Use your judgement” is not a deployment policy.
A provable finish line. The run carries a goal condition that can be verified from the transcript. Not “make good progress” but a statement that is checkably true or false when I sit back down. Vibes don’t survive an eleven-hour absence.
The resumption ritual. The run ends by writing a dossier on the ticket: files changed, pull requests opened, diffs for anything outside version control, what it skipped and why. I review evidence before anything merges. The one human touch in that July run was exactly this shape: the agent reached the deploy gate, presented its case, and waited.
The version numbers are scar tissue
The envelope lives in a runbook, and the runbook has a changelog. The July run validated version 0.2. Three days later, a different run involving a gated database migration taught five more lessons, which became 0.3. Two further revisions landed within three days of that one. Every run that surprises me ends the same way: the surprise gets written into the runbook so no future run can repeat it.
That’s the part I’d defend as the asset. The run is just proof. The envelope is the thing that compounds.
If you’re buying “agents” from a vendor
Ask to see their envelope. Decision ledgers, authorisation scopes, provable finish conditions, an evidence ritual. These have boring names because they’re operational discipline, and operational discipline is what autonomy actually is. If a vendor’s answer to “what happens when it hits a decision at 2am” is a better prompt, they’re not selling autonomy. They’re selling optimism.