STATE AND CONTROL FLOW

CHECKPOINTS A checkpoint is a saved snapshot of the state at a particular moment, taken so the agent can return to it later. If you play video games, a checkpoint is the same idea as a save point. If your character falls off a cliff, you restart from the last save point, not from the very beginning of the game. For an agent, a checkpoint answers the question "if something goes wrong, how far back must we go?" Consider a long job that takes 30 steps. With no checkpoints, a crash at step 25 means starting over and paying for all 25 steps again. With a checkpoint saved after step 10 and again after step 20, the same crash means resuming from step 20, and only five steps are redone. When should a checkpoint be written? Good moments include: after each completed step, after every expensive or slow tool call, just before any risky action, and whenever a human approval is requested. The tradeoff is that saving takes time and storage, so you do not want to save in the middle of every tiny operation. A well-designed checkpoint must be consistent. Consistent means it describes a state that actually made sense, not a half-finished moment where the step count says 11 but the results of step 11 were never saved. Many harnesses write the checkpoint to a temporary file first and then rename it into place, so that a crash during saving cannot leave a corrupted file behind. Another careful design point is that a checkpoint saves the harness's state, but it cannot automatically undo things that happened in the outside world. If step 7 sent an email, restoring a checkpoint from step 6 does not unsend it. That is why the next two topics, pause and rollback, matter so much.