Long agent runs die of boring things

We run coding agents, browser agents and RPA orchestrations on long autonomous jobs: migrations, test sweeps, batch extraction over thousands of documents. Over the last year I have kept an informal tally of why those runs fail.

Almost none of it is the model.

The list, roughly in order of frequency:

1. The host went to sleep or locked the screen, and a browser-driving step died with it.
2. An OAuth token expired four hours in, and the agent cheerfully retried a 401 two hundred times.
3. The disk filled with per-step traces and screenshots.
4. A rate limit hit, the backoff had no jitter, and eight parallel workers synchronised into a thundering herd.
5. The SSH session dropped and took the foreground process with it.
6. The model did something genuinely wrong.

Six is the interesting one. One through five are the ones that actually cost me nights.

The sleep problem

That first item annoyed me enough that I fixed it in public. Windows will suspend or lock a machine on its own schedule, and a browser-driving agent on a workstation or an unattended VM dies with it. The folk remedy is a mouse jiggler or a script that presses F15 every minute, which is exactly the wrong answer when the thing you are protecting is automation that reads the screen. Synthetic input races your own agent.

So SAIGuard does it properly: a single-file tray app that calls the Windows SetThreadExecutionState API with ES_CONTINUOUS | ES_SYSTEM_REQUIRED | ES_DISPLAY_REQUIRED every 30 seconds. It tells the OS "stay awake," which is the supported way to ask, and it sends no input at all. No installer, no dependencies, MIT.

It is a hundred lines of consequence. That is the point.

The pattern underneath

Agent frameworks are all built around the reasoning loop, because that is the part that is fun to design. Long-horizon reliability lives entirely outside that loop, and it looks like ordinary operations work nobody wants to own:

• Credentials that outlive the run. Refresh proactively on a timer, not reactively on a 401. Treat auth failure as fatal, not retryable.
• A supervisor that is not the agent. Something outside the process that notices "no step completed in 20 minutes" and kills or restarts. Agents cannot detect their own hangs.
• Bounded artefacts. Cap trace and screenshot retention per run. An agent that logs everything will eventually stop for a reason that has nothing to do with intelligence.
• Idempotent steps and a checkpoint. The question is not whether a six-hour run dies. It is whether it resumes at step 400 or step 1.
• Jittered backoff on every external call. Non-negotiable once you run more than one worker.
• A host that stays awake. See above.

Why this matters commercially

When an enterprise pilot fails, the postmortem rarely says "the host slept." It says the agents were not reliable enough for production. The verdict lands on the model and the whole programme gets deferred a quarter.

That is why I care about the boring layer. The gap between an agent demo and an agent in production is mostly not intelligence. It is watchdogs, token refresh, disk quotas, and knowing which Windows API to call instead of faking a keystroke.