An agent is running a 50-file migration task. After processing 30 files successfully, the agent is interrupted due to a network timeout. When the developer restarts the agent, it begins the migration again from file 1, repeating all 30 already-completed migrations and causing data corruption. What should have been configured before starting the task to prevent this?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Think of it like downloading a huge file — you want resume capability, not a restart from zero every time. A progress checkpoint artifact (like a completed-files log written after each successful migration) gives the agent a breadcrumb trail so it can skip already-done work and pick up exactly where it left off after any interruption.
Full explanation below image
Full Explanation
Resumable task execution requires persisting progress state externally so that an interrupted agent can reconstruct where it stopped. A progress tracking artifact — typically a file, database record, or tracking issue — records the completion state of each step as it finishes. When the agent restarts, it reads this artifact first and skips all already-completed steps.
For this 50-file migration task, the correct implementation would write a record (e.g., a JSON file or GitHub Issue comment) after each file is successfully migrated, marking that file as complete. On restart, the agent reads this record, determines that files 1–30 are done, and begins processing from file 31.
Progress artifacts should be: - Written immediately after each unit of work succeeds (not in batches) - Stored externally (not in the context window, which is lost on restart) - Idempotent-aware (the agent should verify the recorded completion is accurate before skipping)
Why the other options fail: - Option A (longer timeout) reduces the probability of interruption but doesn't make the task resumable. Infrastructure failures, deployments, or other interruptions can still occur regardless of timeout length. - Option C (lock file to prevent restart) prevents double execution but also prevents recovery. The task would be stuck in a failed state with no path forward without manual intervention. - Option D (atomic all-or-nothing transaction) is actually a good pattern for some tasks, but requires rollback support across 50 files — this is often impractical for file migrations and doesn't help when the task legitimately needs to be split across multiple runs. The question specifically calls for resumability, not rollback.
Progress tracking artifacts are a fundamental requirement for any long-running, multi-step agent task that may be interrupted.