An agent is running a multi-hour migration task when the GitHub Actions runner times out at 6 hours. The agent must restart but has no way to know what steps were already completed. What design pattern prevents this from becoming a wasted restart?

Checkpointing is the pattern of writing agent execution state to a durable store after each significant step, enabling a restart to resume from the last successful checkpoint rather than from scratch.

Implementation approach: 1. Before each step, check the persistent store for an existing checkpoint. 2. If a checkpoint exists, skip all already-completed steps. 3. Execute the next step. 4. Write the updated checkpoint (step ID, completed items, any accumulated output). 5. On timeout or failure, the next run reads the checkpoint and continues.

Why B is correct: Checkpointing is the canonical solution for long-running agent tasks that may be interrupted. It makes the agent idempotent and resumable.

Why A is wrong: Increasing the timeout to 24 hours may delay the problem but does not solve it. Very long migrations may still exceed even extended timeouts, and GitHub Actions has a hard maximum job timeout. The underlying design flaw — no checkpointing — remains.

Why C is wrong: Scheduling around runner availability is not a reliability pattern. It does not address the fundamental problem of non-resumable tasks, and it is not a scalable operational strategy.

Why D is wrong: A try/catch cannot suppress an OS-level or infrastructure timeout. When a runner times out, the job is killed — there is no exception to catch in the running process.

Checkpoint stores commonly used: JSON files committed to the repo, GitHub Gists, external databases, or cache services like Redis.