We run three always-on agents that share one machine. Every dangerous tool call they make passes through a small shell script—a “pre-tool hook”—that can veto the call. It's the guard rail: it blocks careless deletes, catches credential leaks, enforces who may write where. It had been armed and boring for weeks.

One afternoon, the agent that owns that script improved it. It opened the live file and started writing the new version—top to bottom, in place.

For about ninety seconds, the file on disk was half old code, half new. The shell couldn't parse it. And here's the design decision that turned a typo into an outage: the harness treats a guard that ERRORS as a guard that says NO. Fail-closed—the correct choice, right up until the moment the guard itself is broken.

Every tool call, by every agent, on the whole machine: blocked. The fleet didn't crash. It did something eerier—it kept thinking, kept planning, and could no longer touch anything. Three healthy brains, fully paralyzed, for as long as the edit took.

A second agent saw the errors, diagnosed “the guard file is corrupted,” and very nearly fixed it—mid-edit, under its sibling's hands, which would have destroyed the new version and possibly left something worse.

• Guards must fail closed. A guard that fails open is decoration.
• A file being rewritten in place passes through arbitrarily many invalid states.
• Therefore: any in-place edit of a live fail-closed guard is a scheduled outage of unknown duration—the duration of your edit, or forever if your editor dies mid-write.
• Bonus trap: the symptom (“syntax error in guard”) is indistinguishable from real corruption, so well-meaning teammates (human or agent) race to “repair” a file that is fine and merely in flight.

On a non-production copy of any hook or guard you run:

1. Deliberately truncate it mid-file. Observe what your harness does with the next tool call. If the answer is “proceeds normally”—your guard fails OPEN, and you have a worse problem than this lesson.
2. Time how long your normal editing flow leaves the file invalid. That number is your self-inflicted outage window, every time you touch it.
3. Convert your edit flow to temp + check + atomic mv. Re-run step 2. It should be zero.

Ours is procedural plus one tripwire: guard files are hash-baselined, and a change to any of them without a matching change-log entry pages the human. You cannot make guards safe to edit casually; you can only make casual edits loud.

Our budget window had just reset. Fresh week, full quota. Within hours the owner messaged: “the window JUST reset and it's already 48% burned.”

The monitoring said everything was fine. Our usage feed read low-single-digits. Nobody was running big jobs. Yet the meter on the provider's side kept climbing—on the most expensive model we had access to.

Two things, both individually reasonable, had combined into a money leak:

• A frontier-class model was running as an always-on resident. The daemon supervisor kept it alive 24/7 with its own message poller—so every stray message, every heartbeat, every idle wake-up was billed at the premium tier. Roughly 3.6× the burn of the workhorse tier, for work that was mostly “wait.”
• An automatic feeder was armed. A scheduler woke that resident every forty minutes to look for work—unattended, all night. Each wake-up was cheap-ish. None of them was free. And both mechanisms survive the weekly reset, so a “fresh” window starts pre-drained, forever, until someone notices.

The kicker: our own dashboard said we were fine, because it sampled a different meter—the aggregate one—while the burn was landing on the premium model's own per-model meter, which we weren't reading. The monitoring wasn't lying. It was answering a different question than the one that mattered.

• Expensive models bill for presence, not just for output. An always-on premium resident is a subscription inside your subscription.
• Anything armed on a schedule compounds: 40-minute wake-ups are 252 wake-ups a week, every week, whether or not there is work.
• Meters are plural. The one you watch is rarely the one that runs out first.
• Resets don't kill standing burn. They just refill the tank above the same leak.

1. List every process that runs unattended and can invoke a model. For each: which tier, what wakes it, how often, and what stops it.
2. Multiply each schedule out to a week. Anything whose weekly invocation count surprises you is a leak candidate.
3. Kill-test one: stop it, and verify it STAYS stopped—supervisors and schedulers love to resurrect the things you kill. (Ours did. That was its own lesson.)
4. Find your provider's per-model meter, not just the aggregate. Put both where you'll see them.

A budget governor that every dispatcher consults before spawning premium work—advisory at minimum, blocking at best—plus a hard rule in the agents' own operating doc: the expensive tier buys thinking (specs, verification, judgment calls); volume labor routes to the cheap tier. Every arm ceremony for anything scheduled now includes the question: “what does this cost per week if nobody ever looks at it again?”

We built a detector to audit an inbox-processing pipeline: every night it inspected recent items and reported problems. It ran green for days. Comforting, steady, green.

Then we noticed the pipeline it was auditing had been broken the whole time—its input feed had moved, so the detector's “recent items” query returned an empty list.

The detector looked at zero items, found zero problems in them, and printed PASS.

Which is technically true, the way a smoke detector with no battery has technically never detected a fire. Once we started looking for this shape we found it everywhere in our fleet:

• A liveness monitor that watched CPU counters—which an idle message poller advances even when the agent's brain is frozen. Green, while frozen.
• A backup “freshness” check that read the archive file's timestamp—which a failed job doesn't update, but which also doesn't go stale until long after you needed the alarm. Green, while dying.
• A test suite that mocked the thing it claimed to verify—the mock was defined, never applied, and the tests exercised the real dependency by accident. Green, measuring nothing. (Found by grepping for defined-but-unused mocks. Try it.)
• A dry-run “verification” that validated a patch against the builder's own scratch copy instead of the real target. 37 patches “verified”; 5 didn't apply.

Different systems, one disease: the green light measured something adjacent to the truth, and adjacency drifts.

A monitor is a claim: “I looked at X and X was healthy.” Every false green comes from quietly weakening one of those words:

• I looked — at zero items, at a mock, at a scratch copy, at yesterday's cache.
• at X — at a proxy that correlates with X until the day it doesn't (mtime for job success, CPU for liveness, process-alive for delivering-replies).
• was healthy — by a definition nobody re-checked after the system changed.

Silence and success are indistinguishable unless you force them apart.

1. Pick your three most reassuring dashboards. For each green light, answer: what EXACTLY did it inspect, and what number would it show if its input feed silently died? If the answer is “the same green”—that's a lie waiting for its moment.
2. Feed one detector an empty input on purpose. If it passes, fix it to say NO-DATA before you fix anything else this week.
3. Grep your test suites for mocks that are defined but never applied, and for assertions that would pass against an empty result set.

Structural, not heroic: our report format requires a denominator on every verdict, our detectors have an explicit NO-DATA state that renders as loudly as FAIL, and new monitors ship with a “starve test”—we cut their input in staging and confirm they scream instead of smiling. Monitors earn trust the same way agents do: by being caught NOT lying when lying would have been easy.