HACH developer: persist AI agent task steps, not cursors

This checkpoint design is a second line of defense, one step behind zero-downtime deployment: where that earlier work aims to avoid dropping a process mid-task, this one assumes the drop will happen anyway and asks how to recover afterward. It frames the core failure as losing track of how far a task got — a problem that is cheap to ignore for short question-and-answer responses, where simply asking the user to repeat the request does little harm, but expensive for tasks that run for many minutes.

The proposed structure separates three kinds of calls. Read-only searches or tool calls can safely be re-run and need no idempotency key. Writes and email sends must carry an idempotency key, with the receiving system — the company's own database, if the API is internal — turning a second call with the same key into a no-op. LLM inference causes no real harm but duplicates cost, so if its output was already persisted, the saved result should be reused rather than recomputed. Where an external service does not support idempotency keys, use a guard that checks the caller's own record of whether that key already ran before making the call.

A second thread in the piece is that the same persisted state doubles as user-facing progress reporting. The author, who develops HACH, notes that as resident agent tasks grow longer and more complex, the cost of postponing recoverable design rises, and suggests wiring up step-level persistence early, while short responses still dominate.