Running agents
The other side — loops, guards, and the things I decided not to automate.
Run an agent unattended and the accidents are rarely loud. They don’t arrive as exceptions; they arrive as empty successes.
So what this category cares about isn’t making them smarter, it’s making failure look like failure. And the opposite edge of that — stop and ask every time you want to be safe, and you spend a person’s whole day and buy nothing.
Written
| Post | The problem |
|---|---|
| Agents are quiet when they fail | What catches a failure that exited with code 0 |
| Unattended regression is built by recovery, not speed | How a loop survives when nobody is watching |
Not written yet
- How often the approval gates actually fire — I’m not counting
- How to separate a precise tap from a rough fallback tap in the report
- Where to set the retry ceiling, and what to leave behind when it’s reached
- Why I keep forgetting to carry a guard learned in one repository into the one next to it
The rule for this category
The boundary of automation is drawn on whether it can be undone, not on what’s possible. Draw it on capability and it keeps sliding, and the ground it slid over goes unwatched until something breaks.
And when it’s ambiguous or something fails, the default is not to act. That one line decides where to go in a situation the list doesn’t cover.