Running unattended AI agents reliably

I run Claude Code agents unattended on my own Mac. An unattended agent can hit a usage limit, hang, or stop halfway, and nobody is watching when it does. The rule I set for the whole system is at most 20 minutes a week of human upkeep during term, so anything that needs babysitting does not belong in it.

Treat every agent run as a managed job, and treat "done" as a claim to check rather than a fact.

Every unattended run goes through one agent manager. It gives each run its own directory holding every event the session emitted, a readable log and the agent's own checkpoint. A watchdog winds the agent down at 90% of the usage window and queues a resume that brings back the full conversation. A time cap stops runs that overrun, and any abnormal end writes a crash report with the exact command to resume.

On top sits a build pipeline: one request in, a staged, gated, supervised series of managed runs out. Only the supervisor writes the gate files. It passes a stage only when the run ended done, its output exists and was written after the launch, the output ends with a completion marker and the last message does not read as waiting. A stage that fails is re-queued with a note. The scheduler calls the supervisor every minute.

The agent manager is 1,842 lines of Python and the build pipeline 1,518. I set the design and the checks each part had to pass, and Claude Code agents wrote the code to that specification.

LT Capture

An iPhone app that records a voice note and drops it into the life tracker's inbox in iCloud Drive, where the Mac files it. Each note on screen shows what the Mac did with it, read back from a receipt file, so I see "filed" rather than guess. Eight checks can only be proved on a real phone, such as locking it for three minutes mid-note, and no build stage claims them.

Over 15 to 29 Sep 2026 the record holds 249 runs recorded done, 3 killed, 2 timed out, 2 refused and 1 no-op. The median run took 32 minutes. The more useful finding is that a "done" from the manager only means the process exited cleanly and the checkpoint changed. Several runs that stopped halfway were still recorded as done.

Seven runs were recorded done while still waiting on background work, so the next stage started on a missing input. A written rule in the brief did not stop it. The fix moved the check out of the prompt and into the supervisor: a done is provisional until the output exists, ends with its marker and the last result does not read as waiting.