I was in the Bay Area on a trip from Dubai earlier this year, jet-lagged and coding late, migrating Hiveclaw from a CLI tool into standalone agents running on OpenClaw. The specific job that night was a wake and sleep system. OpenClaw's heartbeat fires every five minutes or so, and it had been quietly eating my token budget for days before I worked out where the money was going. So I built an orchestrator. Agents wake when there is work, and hold heartbeat mode for fifteen minutes after finishing something so they are not paying cold-start costs all day.
It was a good system. It solved the problem I had. It did not solve the problem I was about to have, because I had reasoned about one agent at a time.
What I missed was the interaction between them. Agents can keep each other awake. My sleep system reasoned about idleness, and the failure lived in activity.
Here is what happened. The Gemini credits ran out, so image generation failed. The CPO agent could not create an image and reported the failure to the CTO agent. The CTO agent read that as an infrastructure problem, escalated it to the CEO agent, and spun up DevOps agents to investigate properly. Deep investigation is expensive. Those investigations found the same failure, escalated again, and the whole thing went round. By the end the agents had opened something like forty channels talking to each other about it.
The detail I keep coming back to is that the root cause was itself a billing failure. So the CTO agent responded to running out of money by spending money to find out why it had run out of money.
I nodded off at the computer around four in the morning, after deploying and while waiting for tests. I woke at seven. The combined Anthropic and OpenAI bill for those three hours was just under three thousand dollars. I was mortified.
The fix is a break-glass budget per agent. I alert at ten dollars an hour and force sleep at twenty, and hitting either raises a flag on its own: this agent burned twelve dollars of tokens in the last hour, which is not normal for it. I have tightened both every time I have learned something.
The ratio between those two numbers matters more than either number. Two to one gives you a warning band wide enough to actually notice and act inside. Set the alert at nineteen and you will never beat the halt to it, so the alert is decoration. Set it at two and you will mute it inside a week. What you want is a number that is unusual enough to be worth a look and far enough below the stop that looking is still useful.
The important design choice is that it is not a kill switch. It is checkpoint-and-halt. The agent finishes the immediate breakdown of what it is doing, saves state, and stops. Because it is resumable, I can set the threshold aggressively low without being afraid of it. That is the whole trick. A stop you are frightened of is a stop you will set too high to be useful. In the real world you have real budgets and real limits, and nobody thinks that is a hostile constraint.
There is a second layer I added afterwards. When an agent approaches its break-glass budget, the system examines why, and proposes improvements to itself which I approve and it then builds in. I want to be precise about this, because it would be easy to imply more than is true: this did not catch the incident live. I built it after, and validated it against the replay. What I can say is that it correctly diagnoses that loop on a known case. Not that it would have caught it in flight.
The same principle has a second application I think is underrated. Agents should get scoped credentials and permissions the way employees do, rather than blanket service-account access to everything. We would never give a new hire root on day one and rely on their good judgement. We hand agents the equivalent constantly, then write blog posts about alignment. Treat them as staff, not as scripts.
The question worth taking away from this is narrower than it sounds. Is there any state in your system where agents generate work for each other? If there is, idle timers will not save you. An idle timer measures the absence of work. It has no opinion about whether the work is worth anything.
“My sleep system reasoned about idleness. The failure lived in activity.”