Nobody Practices the Off Switch Until the House Is on Fire

Here's a confession from the lab: until last Tuesday, I had no idea how to actually stop my own agent.

Not pause it. Not close the laptop and hope. I mean a real, verified, documented kill procedure — the kind you'd want if the thing started looping on a customer's account at 2 a.m. or decided to retry a payment API four hundred times because a webhook hiccuped.

Most builders I talk to are in the same boat. We obsess over prompts, evals, and tool schemas. We spend exactly zero minutes rehearsing the shutdown. That's like a pilot logging a thousand takeoffs and never once practicing a landing.

So I ran the drill. Here's what happened.

The Experiment: Kill It Mid-Workflow

The setup was simple. I had a research agent running a multi-hour job — scraping competitor pricing pages, summarizing findings, drafting a digest email to my co-founder. Halfway through, right after it had authenticated into three separate services, I pulled the plug. [kill -9](https://en.wikipedia.org/wiki/Kill_(command)) on the orchestrator, plus revoking its cloud credentials through the provider console.

Then I audited the wreckage. That's where it got uncomfortable.

What My Agent Left Behind

1. A cron job I forgot existed. Three weeks earlier, the agent had scheduled a nightly "retry failed summaries" task. It kept running for six days after the kill, silently burning API credits and re-sending duplicate Slack notifications. I only found it because my co-founder asked why the channel was spamming the same digest twice a night.

2. Live API keys in a state file. The agent cached OAuth tokens in a local JSON file with 600 permissions. Anyone with laptop access had working credentials to my email and Stripe dashboard. The kill command didn't touch any of it.

3. A half-sent email. The digest was drafted, queued, and — depending on which log you believe — possibly delivered to a staging address with a live mail provider. I never confirmed whether it went out. That ambiguity alone should scare you.

4. An orphaned browser session. A headless Chromium instance kept humming on a spare machine, logged into a vendor portal, occasionally clicking things. For how long? I genuinely don't know. It could've been days.

None of this was malicious. All of it was structural. Agents are built to persist state — that's the whole point. Persistence without a revocation story is just liability with a nice README.

The Kill-Command Checklist

After the autopsy, I wrote down what every solo dev or small team should have ready before the first deploy:

• One command, one action. A single script that stops the orchestrator, all child processes, and any scheduled jobs. If your shutdown requires five terminal windows, you don't have a kill switch — you have a scavenger hunt.
• Credential revocation in the same script. Rotate or revoke API keys and OAuth tokens as part of the kill, not as a follow-up task you'll forget.
• A state inventory. Know every place your agent writes: local files, cloud buckets, database rows, browser profiles. The kill command should flag or lock each one.
• Outbox inspection. Before termination, drain and review anything queued — emails, webhooks, payments. Half-sent is worse than unsent.
• A dry run, quarterly. Actually execute the kill during a real workload. If you've never tested it, you don't have it.
• A human checkpoint on anything irreversible. Payments, outbound messages, deletions — gate those behind an approval step so a kill can't strand one mid-flight.

The Cultural Problem

Part of why we skip this is vanity. Kill switches feel like an admission that your agent might misbehave, and nobody demoing on Product Hunt wants to lead with "and here's how to turn it off."

But the US regulatory mood is shifting — state-level AI bills, FTC scrutiny of automated actions, class-action lawyers circling anything that touches consumer finances autonomously. When something goes sideways, the first question from an investigator or a plaintiff's attorney will be: "How did you stop it?" "We hadn't gotten to that yet" is not an answer that ages well.

The best builders I know treat shutdown drills like fire exits — boring infrastructure you're grateful for exactly once. The rest are one runaway loop away from learning the same lesson I did, at a higher price.

Run the drill. Audit the wreckage. Write it down. Your future self, staring at a rogue cron job at midnight, will thank you.