How do you manage agent state in long-running autonomou...

Three separate problems show up once a run stretches from minutes to hours or days, and each needs its own fix:

• Crash recovery — persist the full state (current step, completed actions, findings so far) to a database after every step, not just at the end. If the process dies at step 247 of 500, restart by loading the last saved state and resuming from there instead of the beginning.
• Context growth — a run long enough to matter will eventually generate more tokens than fit in context. The fix is tiered detail: keep full detail for recent steps and periodically compress older ones into a summary, so the agent retains the gist of early work without paying full token cost for it forever.
• Idempotency — this is the one that’s easy to skip and expensive to skip. If a step fails partway and the recovery logic reruns it, every tool action in that step needs to be safe to repeat. “Send confirmation email” retried after a crash should not send a second email; the tool needs to check whether it already ran (an idempotency key, or checking observable state first) before acting again.

Pausing at defined checkpoints for human approval before a particularly consequential step is worth adding on top of all three, but it doesn’t substitute for them — a system that can’t safely resume after a crash is broken whether or not a human is in the loop.