An agent processes large code analysis tasks that typically take 45–60 minutes. The hosting environment enforces a 30-minute session timeout. When a session times out mid-task, all in-progress work is lost and the task must be restarted from scratch by a human. The agent stores all intermediate results only in the current session's working memory. What architectural change would prevent work loss on session timeout?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Trusting a session to last the whole race is like relying on one leg to hold a 60-minute marathon — halfway through, the leg buckles and all progress is gone. Durable checkpointing is the solution: periodically write where you are to a persistent store so when the session ends, the next one picks up the baton, not the starting pistol.
Full explanation below image
Full Explanation
Session timeouts are a reality in cloud hosting environments, and any long-running agentic task that exceeds the timeout without persisting state will lose all in-progress work. Durable checkpointing is the architectural pattern that makes tasks resilient to session boundaries.
A checkpoint is a snapshot of the task's current state written to a persistent store (database, object storage, filesystem) at regular intervals or at defined milestones (e.g., after completing each module of the code analysis). The checkpoint captures enough state to reconstruct the working context: which files have been analyzed, partial findings, current position in the task plan, any intermediate data computed so far.
When a session times out, a new session starts, detects the existing checkpoint, loads it, and resumes execution from the last checkpoint position. Work before the checkpoint is preserved; only work since the last checkpoint needs to be redone.
Option A (extend timeout) is an operational workaround that does not change the architecture. If a 90-minute timeout is available today, a future 100-minute task will still fail. This is a fragile dependency on environment configuration.
Option C (break into 10-minute subtasks) may be appropriate for some workflows but is not always feasible. Code analysis tasks may have sequential dependencies where intermediate state must flow from one subtask to the next, requiring the same architectural persistence that checkpointing provides.
Option D (run locally) removes the timeout constraint but introduces availability, maintenance, and security concerns that a cloud environment addresses. It is not a scalable architectural solution.