A code generation agent runs a 45-minute workflow to refactor a large codebase. It operates entirely in-memory and produces no persistent artifacts until delivering the final output. The workflow fails at minute 43 due to a GitHub API rate limit. The team loses all progress and must restart from scratch. Which design change would enable the agent to safely resume from a checkpoint rather than restarting the full workflow?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Flying blind with no checkpoints is how you lose 43 minutes of work. Option D is correct: write durable milestone artifacts as you go — completed outputs, a manifest of what's done versus pending, and current state — so a failure at minute 43 only costs you the work since the last checkpoint, not the whole run. This is the classic checkpoint-resume pattern applied to agentic workflows.
Full explanation below image
Full Explanation
The correct answer is D. Long-running agentic workflows face the same reliability challenge as any distributed system: failures are inevitable, and the cost of failure scales with how much work must be redone. The solution is checkpoint-based execution: after each significant unit of work (a file refactored, a module processed), the agent writes a durable artifact capturing (1) the completed output for that unit, (2) an updated manifest distinguishing processed items from pending ones, and (3) any state required to continue from that exact point. On failure and restart, the agent reads the last checkpoint manifest and skips already-completed work.
This pattern is sometimes called 'idempotent progress recording' — the agent only processes each work unit once, and its progress is durable across process restarts, rate limit errors, or infrastructure failures.
Option A is wrong because requesting a higher rate limit is an operational workaround that does not address the fundamental architectural flaw: a long-running workflow with no durability. Rate limits can still be hit at higher tiers, and other failures (network interruptions, timeouts, cost limits) remain unaddressed.
Option B is wrong because extending the timeout does not prevent the rate limit from occurring — it only changes when the agent gives up after it occurs. A timeout is a failure boundary, not a resumption mechanism.
Option C is wrong because caching the active context window is not the same as writing structured, application-level checkpoints. Context window snapshots are large, unstructured, and not easily interpreted by the agent on restart. They also do not capture the semantic state of the workflow (which files are done, which are pending) in a way the agent can act on. Structured milestone artifacts are far more useful for checkpoint-based resumption.