You are configuring an agent that uses an MCP tool to apply automated code fixes across 100 repositories. The agent crashed at repository 47. You want to restart it so it resumes at repository 48 and applies exactly the same fix strategy decided in earlier runs. Which implementation correctly achieves this?
Select an answer to reveal the explanation.
Short Explanation and Infographic
A skilled surgeon doesn't restart the operation from the first incision because of a power flicker — they pick up exactly where they left off using the operative notes. The agent equivalent is reading the checkpoint, loading the recorded decisions, and invoking the next tool call from the right position. That's clean resumption without drift or repeat.
Full explanation below image
Full Explanation
Safe resumption from a checkpoint requires two things: knowing where to resume (progress tracking) and what decisions to carry forward (decision log). Both must be explicitly encoded in the checkpoint artifact and explicitly loaded at resume time.
Why B is correct: Reading the checkpoint artifact on startup provides: 1. The list of completed repositories (1-46), so the agent skips them entirely. 2. The fix strategy decisions (e.g., 'use approach X for Python repos, approach Y for TypeScript repos') that were already established, ensuring the resumed run doesn't diverge from the prior run's decisions. 3. The exact starting point (repository 48), so the MCP tool is invoked from the correct position. This is the complete, correct resumption pattern.
Why A is wrong: Re-deriving the fix strategy from the original prompt is non-deterministic. Language models may produce a slightly different strategy when given the same prompt on a different run, especially if temperature > 0 or if the model version has changed. This introduces decision drift — the resumed run may apply different fixes than the original run intended, violating the 'resume without diverging from prior decisions' requirement.
Why C is wrong: While idempotency is a useful property for robustness, re-running all 100 repositories wastes time and compute on 46 already-completed repositories. For operations with side effects (e.g., PR creation, notification triggers, API calls), even idempotent operations may create noise (duplicate PRs later de-duped, etc.). The goal is clean resumption, not brute-force replay.
Why D is wrong: Relying on version control history to detect skippable work is fragile. It assumes all prior changes were committed and pushed, that the commit messages or diff content are parseable by the agent to determine 'already applied', and that no concurrent changes have been made. It also doesn't address the fix strategy — VCS history alone doesn't tell the agent which decisions were made for repositories not yet started.