A long-running agent task is processing 200 code files over multiple hours. If the agent's execution is interrupted, the team needs to be able to resume without re-processing completed files. How should task progress be captured?
Select an answer to reveal the explanation.
Short Explanation
You don't keep your trail map in your head—you mark checkpoints. For long-running agent tasks, durable artifacts like GitHub issues, PR comments, or workflow artifacts are those checkpoints, so you can resume without re-processing completed files.
Full Explanation
Long-running agent tasks require durable state tracking that survives interruptions, timeouts, and context resets. The key principle is that progress state must be stored outside the agent's ephemeral execution context.
Why the durable artifacts approach is correct: GitHub issues, PR comments, and workflow artifacts are all durable artifacts that persist beyond the agent's execution. Progress can be written as structured checklists in a GitHub issue (✅ processed, ⬜ pending), as workflow artifact JSON files listing completed items, or as PR comments with progress summaries. When the agent resumes, it reads these artifacts to determine where it left off.
Why the approach that stores progress only in the agent's active context window and restarts from scratch if interrupted is wrong: The active context window is cleared when execution is interrupted. Storing progress only there means all progress is lost on interruption, requiring a full restart.
Why the approach that logs progress verbally to a team chat channel and relies on chat history as a recovery reference is wrong: Chat history is an informal, unstructured recovery reference that is difficult for the agent to parse programmatically. It is also subject to the chat retention policy, which may not match the task's duration.
Why the approach that processes all 200 files in a single atomic operation so interruption results in either full completion or no change is wrong: Processing 200 files in a single atomic operation is not feasible for file-system-level operations over hours of execution. Most execution environments will timeout, and forcing atomicity at this scale creates a brittle all-or-nothing system.