Journal · The AI Architect · 2026-08-02
Before you let anything run on its own, know your off switch — and test it once, so you know the plug pulls.
Before you let anything run on its own, know your off switch — and test it once, so you know the plug pulls.
The tension isn’t whether you trust the system you built. It’s that trust and verification are two different muscles, and most people only exercise the first one. You believe your automation will do what you designed it to do, so you skip the part where you confirm you can actually stop it. That gap — between believing and confirming — is where the real risk lives, not in the automation itself.
Know the difference between “off” and “paused”
A lot of systems don’t have a true off switch. They have a pause button, a rate limit, a “disable” toggle that stops new tasks from starting but doesn’t touch the ones already running. If you’ve never looked closely, you probably don’t know which one you have.
This matters because the moment you need to stop something, you’re usually not in a calm, exploratory mood. Something’s gone sideways — the automation is sending duplicate emails, spinning up cloud resources faster than expected, posting content you didn’t approve. You need the thing to stop now, not after the current batch finishes, not after some graceful shutdown sequence that was designed for convenience rather than speed.
Try this: pick one automated system you rely on and write down, in plain words, what happens in the first ten seconds after you hit stop. Does it halt immediately? Does it finish the current task first? Does it require a second confirmation? If you don’t know the answer, that’s the finding — not a failure, just information you didn’t have five minutes ago.
Test the switch before you need it
There’s a reason pilots run through emergency checklists in simulators instead of reading them for the first time mid-flight. Knowledge under calm conditions and knowledge under pressure are not the same knowledge. The off switch you’ve read about is not the same as the off switch you’ve used.
Testing it once, deliberately, while nothing is on fire, does two things. First, it confirms the mechanism actually works — that the button is wired to something, that the plug really does pull. Systems drift. Permissions change. Someone updates a script and doesn’t realize they broke the emergency stop. You won’t know unless you check. Second, it builds the muscle memory so that when you do need to act fast, you’re not fumbling through documentation or guessing which of three dashboards has the real control.
Try this: schedule fifteen minutes this week to actually trigger the stop condition on one system — ideally in a low-stakes moment, maybe during a maintenance window or right after you’ve backed something up. Watch what happens. Does it stop the way you expected? Time how long it takes. Write down anything that surprised you. That written surprise is worth more than any assumption you were operating on before.
Match the switch to the actual risk
Not every automation needs the same level of scrutiny. A script that reformats a spreadsheet once a week doesn’t need the same off-switch rigor as something that touches customer data, spends money, or acts on your behalf in public. Part of knowing your off switch is being honest about which systems actually deserve this kind of attention.
A useful question: if this ran uncontrolled for an hour, what’s the worst plausible outcome? For some systems, the answer is “a minor annoyance.” For others, it’s “real damage that’s hard to undo.” The second category is where you slow down and actually verify the mechanism, not just assume it exists because a menu item says “stop.”
This also means you should know who else has access to the switch, and whether it depends on anything fragile — a specific person being reachable, a specific login working, a specific service being online. If your kill switch depends on a single person’s phone being charged, that’s not really a kill switch. That’s a hope.
I go into this more in the book, including how to think about staged shutdowns for systems that are too complex to stop all at once, and what to do when the automation is genuinely so distributed that no single switch exists. But the starting point is always the same: don’t assume, verify. It’s a small habit — fifteen minutes, once — that changes what kind of surprises you’re capable of having later.
Go deeper. The full method is in The AI Architect. New here? Start with the free companion pack, or explore the series.