7.9
Hooks, Routines And Scheduled Agents
Why this exists
This is the thing you were excited about at the very start — something working while you're not. It's last in the level rather than first because it's the one with the sharpest edge, and everything before it was the safety training.
The idea
Something running unattended is the same power you've had all along, minus the person who checks.
Every safeguard you've built assumed you were present. Plan mode shows you a plan — if you're there. Permission prompts wait for approval — if you're there. A scheduled run at 6am has none of that. Whatever it decides to do, it does.
Which is exactly why 6.5 insisted a monitoring check be read-only, and the same logic scales up.
Three shapes, in ascending order of how much can go wrong:
| Shape | When it runs | Risk |
|---|---|---|
| Hook | Automatically, around an action you take | Low — you're there |
| Routine | On a schedule | Real — nobody's there |
| Triggered | When something external fires | Highest — timing isn't yours |
Hooks run around things you're already doing — format after a save, run checks before a commit. You're present, so the blast radius is small. Good first thing to build.
Routines are the 24/7 agents. A schedule, a task, a set of connectors. The morning check from 6.5 is one.
The rules that keep them safe:
Minimal access, hard. A routine gets exactly the connectors its job needs. Not everything you own. If it reads email, it gets email — not your drive, your calendar and your database. Same principle as 1.7 and 7.6, but it matters more because there's nobody watching.
Read-only until proven. Let it observe and report for a week before it changes anything. You'll learn what it actually does versus what you assumed, and the cost of being wrong during that week is a wrong message rather than a wrong action.
It must be able to tell you it failed. A routine that breaks silently is worse than no routine, because you're relying on something that isn't running. This is the same trap as an untested alert in 6.5 — make it fail on purpose and confirm you hear about it.
Write down what it does. Six weeks from now something odd happens at 6am and you need to know instantly what runs then and what it touches. Undocumented automation becomes nobody's automation surprisingly fast.
The honest test before you schedule anything: if this does the wrong thing at 3am, what happens, and how would I find out? Comfortable answer, ship it. Uncomfortable answer, keep it read-only.
Do
- Build a hook first. Something small around an action you already take — a check before commit, a format after save.
- Use it a few times. Note whether it helps or gets in the way.
- Now a routine. Use the check from 6.5 if you built one, or something you do every morning.
- During setup, look at the access list and cut it to the minimum. Write down what you granted and what you declined.
- Make it read-only — it reports, it doesn't change.
- Break it on purpose and confirm you get told. Fix it.
- Let it run for a few days. Compare what it actually did against what you expected.
- Write
automation.md: what runs · when · what it can reach · how it tells you it failed · what you'd check if it misbehaved. - For each, answer in writing: if this did the wrong thing at 3am, what happens and how would I find out?
Step 9 is the gate. If you can't answer it comfortably, the thing isn't ready to be scheduled — it's ready to keep reporting for another week.
Done when
That's Level 7. You can find, judge, build and improve skills, connect systems properly, build your own connector, get a second opinion worth having, and set things running without you.
Never do
Never schedule something with write access on its first version. It runs when nobody's there. That's the whole point and the whole risk.
Never grant a routine more connectors than its job needs. Unattended plus broad access is the combination that turns a small mistake into a large one.
Never trust automation you haven't seen fail. Until you've watched it break and tell you, you don't have a routine — you have a belief that one is running.