Featured image: AI-generated conceptual illustration. Sources checked 26 October 2026.
A long-running task can outlive one conversation, one process and one set of credentials. When the agent resumes, it needs to know what actually happened, what remains authorized and which facts may have changed. A long transcript is not always the best handover document.
Durable work records preserve the evidence needed to continue safely. They should be concise enough to inspect and precise enough to distinguish completed work from intentions. The record is part of the application’s state, not merely a pleasant summary the assistant writes at the end.
Imagine an interrupted supplier review
In a hypothetical procurement workflow, an agent is assembling a supplier review over several sessions. It has verified two documents, saved a draft comparison and requested access to a third source. The process restarts before the access decision arrives.
A weak handover says, “Most research is done; finish the report.” A useful handover identifies the documents reviewed, the draft’s location and version, the unavailable source, the pending access request and the checks still required before the report can be called complete.
Anthropic’s long-running harness case study describes using progress artifacts to bridge coding sessions. Applying that idea to procurement is an editorial inference: the domain changes, but the need to preserve verified progress remains a practical design concern.
Record facts, proposals and blockers separately
A completed step should include its evidence. “Registration document verified” needs a source reference, version or date and the scope of the check. “Draft prepared” needs an artifact location. Avoid a boolean complete flag that nobody can audit.
A proposal should remain a proposal. If the agent drafted a supplier message, record that it exists and has not been sent. If a reviewer has not approved it, preserve the pending state. A later session should not infer approval from the fact that the draft looks finished.
A blocker should identify the missing dependency and the authorized path to resolve it. “Need more information” is less useful than “current insurance certificate unavailable in the approved repository; awaiting document owner.” The second statement lets a person or resumed agent continue without repeating the entire investigation.
Keep the task identity stable
Use a durable task identifier that connects sessions, artifacts, approvals and tool operations. A new runtime session should not become a new business task unless the user intends that. Otherwise retries can appear as separate work and pending approvals can lose their connection to the original proposal.
The OpenAI Agents SDK sessions documentation describes preserving conversation history across turns and operational persistence considerations. Conversation continuity is useful, but task records need additional business meaning: what was requested, what was authorized and what the environment confirmed.
Store the record in a system appropriate to its sensitivity and reliability requirements. A casual text file may be sufficient for a local prototype. A shared production workflow may need access controls, versioning and transactional updates. Choose based on the consequences of lost or conflicting state.
Recheck the world on resume
A saved record describes the past. Before continuing, verify the current state of relevant external systems. A document may have changed, a draft may have been edited by a human or the user may have canceled the request. Do not treat a checkpoint as permission to overwrite newer work.
Revalidate time-sensitive facts and authority. If a role or credential changed during the interruption, the next action must respect the current access decision. If an approval was tied to a prior version of a proposal, confirm that the version still matches before execution.
The SDK human-in-the-loop guide documents durable paused-run state and resumption patterns. The surrounding application still needs to decide when an approval is stale and how to bind it to the actual business action.
Make resumption idempotent where possible
A resumed agent should not blindly repeat the last operation because the record ended abruptly. The operation may have succeeded before the checkpoint was written. Use an operation identifier, destination lookup or other supported verification mechanism to establish the outcome before retrying a consequential write.
For read-only research, repeated work may be wasteful but relatively manageable. For messages, purchases or record changes, duplicate execution can create real harm. Design checkpointing and tool execution together rather than treating progress notes as a separate convenience feature.
A useful checkpoint template
- Objective: the requested outcome and explicit exclusions.
- Authority: allowed tools, data scope and required approvals.
- Verified progress: completed steps with evidence references.
- Artifacts: locations, versions and ownership of drafts or outputs.
- Pending decisions: exact proposals awaiting review.
- Blockers: missing dependencies and their resolution paths.
- Next safe step: the action that can proceed after current-state checks.
- Completion criteria: what must be true before the task is closed.
Keep this record updated at meaningful boundaries. Writing it only at the very end does not help if the process stops unexpectedly. At the same time, avoid filling it with every intermediate thought. Preserve operational facts that another session or person can verify.
Test recovery as a normal feature
Interrupt the workflow after a read, after a saved draft, while awaiting approval and after a potentially committed write. Resume from each point and inspect whether the system repeats work, loses uncertainty or acts on stale authority. Use a controlled environment and synthetic data for consequential operations.
Include a human edit between interruption and resumption. The agent should detect or accommodate the change rather than overwrite it from an old plan. Recovery tests should verify both the final artifact and the history of actions taken to reach it.
Long-running agents need continuity, but continuity should be grounded in durable evidence. A clear work record lets the system resume honestly: knowing what is done, what remains uncertain and what it is still allowed to do. That is more valuable than merely remembering the conversation.
Sources and further reading
Anthropic: Effective harnesses for long-running agents. Coding progress-artifact case study; published November 2025. Other-domain application is editorial inference.
OpenAI Agents SDK: Sessions. History and persistence mechanisms; checked October 2026.
OpenAI Agents SDK: Human-in-the-loop. Durable approval state and resumption patterns; checked October 2026.
Leave a Reply