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 and Infographic
A hiker doesn't keep their trail map in their head — they mark progress on a physical map and leave checkpoints. For long-running agent tasks, durable artifacts like GitHub issues and workflow artifacts are the checkpoints that survive an interruption and let the agent pick up where it left off.
Full explanation below image
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 C 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 A 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 B 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 D 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.