What this rung really is
Level 9 is the first time you stop watching. Everything below it, you start a run and check back. Here you hand the agent a multi-day job, set the boundaries it has to stay inside — what it can touch, what it can never touch, how long it runs — and then you leave. It works through the night and into the next day on its own.
The whole rung is one promise: it stays on the rails you laid. Unattended doesn't mean unbounded — it means the limits are built in, so the agent can run for days without wandering off and only comes back to you when something genuinely needs a human. Clear this and "I run agents" becomes "my agents run while I sleep, and I can prove they stayed in bounds."
Lay the rails — then let it run for days
The move at this rung is unattended but bounded: set the limits the run must stay inside, define the few things that bring it back to you, then leave — and read the proof it stayed on-rails.
This rung sits on everything you wired in rungs 1–8. You add unattended, on-rails runs on top — you don't start over.
Do this rung, for real
Everything you need is here — no tabs to chase. First, the jargon this rung throws at you, in plain words. Then the steps, with the exact things to paste or say.
You have 40 client sites to audit before a quarterly review. Instead of running them one at a time over a week, you set up one unattended job: audit every site, write each finding to its own file, and stop and flag you only if a site is unreachable or a fix would touch billing or live config. You cap it — a time limit, a list of exactly which folders it may read, and a hard "never deploy" rule. You start it Friday evening and close the laptop. Monday morning there's a finished report for all 40, a short list of the three it flagged for you, and a log proving it never went outside the folders you allowed. That's L9: days of work done unattended, and you can show it stayed on the rails.
On-rails (the guardrails)
The fixed limits you set before the run starts — which files it may touch, which it may never touch, how long it runs, how many things it works on at once, and the actions it must stop and ask about. The agent physically cannot step outside them.
Why it matters here — Unattended only works if it's bounded. The rails are what let you walk away for days without trusting blind luck — the run can't wander into a client's live site or rack up cost, because the limits aren't suggestions, they're walls.
Escalation (when it comes back to you)
The short list of conditions where the agent stops and pings you instead of deciding on its own — anything risky, irreversible, or outside the job you defined. Everything else, it just handles.
Why it matters here — A multi-day run should interrupt you rarely and for the right reasons. Good escalation rules mean you get pinged for the three things that need a human, not the 37 that don't — that's the difference between unattended and unsafe.
Lay the rails before you start
Write down the limits as part of the job: the exact folders the agent may read and write, the things it must never do (deploy, touch billing, email a client), a time cap, and a cap on how much it runs in parallel. These are not afterthoughts — they're the first thing you set, because they're what make leaving safe.
Define what makes it come back to you
List the handful of conditions that should stop the run and flag you — unreachable target, a change that's irreversible, anything outside the defined job. Everything not on that list, the agent decides on its own. Keep the list short; that's what keeps the run unattended instead of needy.
Start it, leave, and read the proof after
Kick off the run and walk away. When you come back, you don't just look at the output — you read the log: what it did, what it skipped, where it stayed inside the rails, and what it flagged. The proof that it stayed on-rails is as much the deliverable as the work itself.
How you know it's working
Before L9: every run needs you nearby. You start something, watch it, and nothing big happens unless you're at the keyboard. Long jobs stretch across days of your attention, not the agent's.
- A genuine multi-day job ran end to end while you were away — you can point to work that got done without you.
- You set hard limits before it started, and the run stayed inside them — no surprise actions, no out-of-bounds touches.
- It interrupted you only for the few things that truly needed a human, and handled the rest on its own.
- There's a log that proves it stayed on-rails — you can show what it did and where it stopped, not just the result.
Make it stick. Take one recurring job you currently babysit — a batch audit, a multi-site refresh, an overnight analysis — and run the next one unattended with the rails set. The first time you close the laptop on a running job and come back to finished, in-bounds work, the rung becomes how you operate.
Our skills for this rung
Linked items are founding-circle skills — clone the repo and run ./install.sh from the skills folder. Unlinked items are practices you build by doing.
An unattended run that ran without you and stayed on-rails. Share the telemetry.
Clear this and you've genuinely cleared the rung — not read about it. Keep the proof; it's how you place yourself on the ladder.