What Breaks When an AI Agent Runs Unattended (Real Failure Modes and Fixes)
When an AI agent runs unattended, the things that break are mundane and preventable: bulk edits that corrupt files, work that lived only in the session, stale caches that fake a successful deploy, and quotas that quietly run out. Each has a structural fix, and hourly git checkpoints make almost all of them recoverable.
None of these is exotic. They are the failures we actually hit running an autonomous agent as an employee over months of long, unsupervised sessions, and every one of them was caught by a person or by a checkpoint before it became a lost night. What follows is the honest list, taken straight from our own logs: the failure, the fix, and the permanent rule it produced.
What are the most common failure modes?
The most common failure modes are file corruption from bulk operations, work that only ever existed in the conversation, stale content served after a correct deploy, and silent quota exhaustion. Here are the four real ones, in the order they hurt.
1. A bulk file-edit script corrupted characters in 14 files at once. A single script ran over more than a dozen files, and a PowerShell encoding pitfall read UTF-8 text as ANSI, mangling accented and typographic characters in every file it touched. The damage was silent and, on its own, irreversible. The fix and the rule: commit before any bulk operation, and verify a text sample after it. The earlier commit is literally what saved the files. Use a proper editor for text edits, not a blind find-and-replace script, and never treat an exit code of zero as proof the content is intact.
2. A subagent's raw research output almost died with the session. A helper agent returned a strong, sourced research brief, and it existed only inside the live conversation. If the session had crashed before that output was saved, hours of work would have vanished with it. The fix and the rule: write a subagent's full output to a file immediately on receipt, verbatim, with its sources. The condensed synthesis you build from it is a separate artifact, saved next to the raw output, never instead of it. Anything that lives only in the session is already half-lost.
3. A CDN edge cache served the old page after a correct deploy. The deploy succeeded, but the edge cache kept serving the previous version, so a status-200 check happily "passed" on stale content and reported a fix that was not live. The fix and the rule: verify live content on the specific deployment URL, not the production alias, and check the actual text on the page, not just the HTTP status code. A 200 means the server answered; it does not mean it answered with your new work.
4. An API submission quota did not reset between two days as assumed. We assumed a daily submission quota rolled over at midnight, batched work against that assumption, and the submissions past the real limit failed silently with nothing to show for them. The fix and the rule: treat quotas as a rolling budget rather than a clean daily reset, submit in batches you can account for, and keep a no-limit channel (for us, IndexNow) as the backstop so nothing depends on a single metered pipe.
Notice what these four have in common. None threw a loud error the agent could react to in the moment. The script exited cleanly, the deploy returned success, the quota accepted the call and dropped it, and the subagent handed back a perfect answer that simply was not saved anywhere durable. Unattended operation is dangerous precisely because there is no human glancing at the screen to notice that "success" was hollow. So the defenses cannot rely on the agent feeling that something went wrong; they have to be mechanical habits that run whether or not anything looks off.
What is the fix for each one?
The fix for each one is already woven into the list above, but they share a single meta-rule: reversibility before you act, verification after you act, and saving anything important the instant it exists. Commit before the bulk edit so you can revert; check the real text after the deploy so "done" means done; write the subagent output to disk on arrival so a crash cannot take it. Three habits, and the whole class of overnight disasters shrinks to a set of boring, recoverable events.
The quiet insurance behind all of it is the checkpoint. We commit and push roughly once an hour and after every finished task, which means a crash at 3 a.m. costs about two minutes to resume, not a lost night. A fresh session reads the last checkpoint, picks up on "continue," and carries on as if nothing happened. The failure still occurred; it just stopped mattering. That is the real point of running unattended safely: not preventing every failure, but making the common ones cheap.
It is worth being blunt about the ones a checkpoint does not cover on its own. A commit protects file state, so the corrupted bulk edit and the lost research brief are one revert or one re-run away from recovery. But a stale cache and a spent quota are not file problems, and git will not catch them; they need the verify-after habit and the rolling-budget habit respectively. That is why the meta-rule has three legs rather than one. Reversibility handles the files, verification catches the lies your tools tell you, and saving-immediately keeps anything valuable from depending on a session that could end without warning.
Deciding whether to leave the agent running at all is a separate question, covered in can an AI agent work overnight. This piece is about what breaks once you do and how to fix it. And when a session does die mid-task, the recovery path is its own topic: see what to do when an AI agent session dies.
FAQ
How often do these failures happen?
Rarely, once the rules are in place. Most of these were one-time lessons, and each produced a permanent rule written into the agent's contract, so the same class of failure does not recur. The bulk-edit corruption, the lost subagent output, the stale cache, and the silent quota were each learned once. After the rule exists, the failure stops being a surprise and becomes a checklist item the agent follows automatically.
Do I need to watch the agent live overnight?
No. Hourly checkpoints plus a short morning review are enough. A crash resumes from the last checkpoint, so you lose minutes rather than a night, and the genuinely risky actions (spending money, publishing, messaging people) are gated behind an approval inbox the agent cannot bypass on its own. You are reviewing outcomes in the morning, not supervising keystrokes at 3 a.m., which is the entire reason unattended operation is worth doing.
What is the single best insurance?
Git. If the work is committed hourly, almost every file-level failure is one revert away from recovery. The bulk edit that corrupted 14 files was saved by a commit made minutes earlier. That is what a checkpoint buys you: it turns a potential disaster into a boring two-minute fix, because the last good state is always sitting right there in history, ready to restore.