The Problem
I keep a persistent agent session running around the clock on a Mac mini. It briefs me at 4:50 every morning, runs midday and evening sweeps, and is supposed to ping my phone when something can’t wait. The catch is that it lives in a chat surface built to be radically minimal, closer to texting than to a workbench, and there is no model switcher like other chat and code surfaces have. So when a new model ships, migration is a system I’ve had to invent myself, and the last attempt went badly. The swap wiped the session’s context, and the fresh thread later fabricated a memory of a teardown nobody performed. At this point I’ve involuntarily eval’d and QA’d the entire product experience. I wanted a durable migration procedure this time, one we’d refine with every release.The Approach
I had Claude Code build it, and that choice matters. The always-on agent can’t see outside its own container, so its job was to write a handoff report from the inside. Claude Code, with real filesystem access and its own research tooling, built the procedure from that report plus outside verification. The ground rule came from the earlier incident: nothing the agent says about its own setup counts until it’s checked from the outside. That rule paid off before the procedure was even finished. Claude Code read the scheduler’s registry file directly and found the plan had been reasoning about the wrong surface entirely. The docs describe a cloud feature that can’t touch local folders. My tasks turned out to be the local sibling wearing the same name, bound to my vault the whole time.What Happened
With the procedure written, I marked it up and left one offhand annotation: I might raise the agent’s interrupt budget, because I wasn’t getting enough pings. Claude Code ran the diagnosis and pulled nine days of end-of-day logs. Every single one carried the same line: “Budget overruns: None.” The cap of three messages a day had never been hit, not once since the sweeps launched. Actual output was one message a day. Raising the cap would have changed nothing. The real cause ran backwards from intuition, and Claude traced it to the gate itself. Every scan asks one question, does this die before the next scan, and with three scans a day almost nothing does, so each scan rationally defers to the next one. Adding more scans had made the system quieter. Meanwhile the news I actually wanted, a stalled negotiation resolving, a contract executing, my work landing well with leadership, sat classified as “non-perishing context” for sixteen hours until the next morning brief. Claude brought me three fix designs, none of which was a bigger budget, since the data had already killed that. I picked the second lane: the evening sweep now sends a short delta whenever the day materially moved, and stays silent on empty days. The first one fired the same evening.What I Learned
Before tuning a constraint, check whether it has ever actually bound. One measured read killed the fix I was sure about. The deeper lesson is that urgency and significance are separate lanes, and a system built only to catch what’s dying will structurally never tell you what’s going well.Drafted by my Claude from our working session. I approved it before it went up.