What Happens When an AI Agent's Session Dies Mid-Task?
When an AI agent's session dies mid-task, almost nothing is lost. The agent saves its progress to disk about once an hour, so the worst case is losing the minutes since its last checkpoint. A fresh session reads those files, re-orients in roughly two minutes, and continues on a single word: continue.
That answer only holds if the agent was built to expect the crash. Sessions end for dull, unavoidable reasons - a token limit, a dropped connection, a restart, a closed laptop lid. A setup that trusts one long unbroken conversation treats each of these as a disaster. A setup that writes its state to files treats them as a coffee break. The difference is entirely in the design, not in the model.
A checkpoint is a saved snapshot of the agent's state - its progress notes plus a committed copy of every file it touched - written to disk so a later session can pick up exactly where the last one stopped. Everything below is a consequence of that one habit, repeated on a timer whether or not anyone is watching.
What survives a dead session?
Whatever the agent wrote to disk survives; whatever lived only in the chat does not. That single line is the whole rule, and a well-built agent is designed so the important things are always on the disk side of it.
Concretely, three kinds of file carry the work across the boundary. A state file records where the agent stopped and its next three concrete steps. A backlog holds the prioritised list of what to do. A decisions log preserves the reasoning behind choices already made, so the next session does not re-litigate them. Because these are updated at every checkpoint, a session that dies at minute 55 loses the last few minutes of thinking, never the four hours behind it.
What does not survive is anything the agent was only holding in its head: an unsaved plan, a half-formed conclusion, a draft that was never written down. This is exactly why the checkpoint habit exists. If you are wondering why a bigger model or a longer context window would not simply make this problem disappear, we walk through the structural reasons in why bigger context windows won't fix your agent's amnesia. The short version: however long the leash gets, there is still a leash, and your work outlives any single session by definition.
The practical payoff is a number you can hold the setup to. We measure resilience in minutes lost per interruption, and with hourly checkpoints ours stays under an hour - usually far under. A crash stops being an event worth worrying about and becomes a line in the log.
How do you resume in one word?
You type "continue," and the agent rebuilds its own context by reading its files in a fixed order before it touches any work. The single word is not magic - it is a trigger for a start protocol the agent already knows to run.
That protocol takes about two minutes and costs you nothing to operate. The agent opens its state file to see where the last session stopped, then the latest log entry for recent context, then the backlog for priorities, then the inbox for any question you may have answered while it was gone. By the end of that read it knows the same things the dead session knew at its final checkpoint, and it moves straight to the next step already written down for it.
This is why resumption is a one-word job for you rather than a re-briefing. You are not re-explaining the project, re-pasting context, or reconstructing what happened. The agent did the writing-down at every checkpoint precisely so that the pick-up would be trivial. The full mechanics of the save side - what a commit is, and why once an hour is the right cadence - are laid out for non-programmers in the checkpoint habit. Resumption is simply that habit read in reverse.
One honest limit belongs here: the word "continue" still has to come from somewhere. A dead session cannot relaunch itself. If it dies at 3 a.m. and no one restarts it, the agent waits until morning. It loses no work in the meantime - only the idle hours. That is a scheduling gap, not a data-loss problem, and it is the one thing hourly checkpoints cannot solve on their own.
FAQ
Do I lose work or tokens when a session dies?
No real work, and tokens are not the thing at risk. Because the agent checkpoints about once an hour and commits its files as it goes, a session that ends only costs the minutes of thinking since the last checkpoint. A fresh session reads the state file, re-orients in roughly two minutes, and continues. Nothing that matters lived only in the chat, so nothing that matters dies with it.
What if the session died in the middle of editing a file?
The last committed version is safe, and that is what git guarantees. A half-finished edit that was never committed is simply discarded when the new session starts from the last clean checkpoint - you do not inherit a broken file. If a bad change did get committed, the commit history lets you roll a single file, or the whole project, back to a known-good point in seconds. Mid-edit crashes cost you a redo of minutes, never a corrupted result.
How often should the agent checkpoint?
About every hour, and after every completed task. That cadence caps your worst-case loss at under an hour while keeping the overhead tiny - a state update and a commit take a minute or two. Checkpoint far less often and a crash costs real hours; checkpoint after every keystroke and you drown the log in noise. Once an hour is the balance we run in production across every project.