How can a long-running AI agent task resume without repeating work?

A research or production job may continue after a browser closes, a worker restarts, or a reviewer returns the next morning. Asking an agent to “pick up where you left off” is not an execution protocol. The application needs a durable account of completed units, the next permitted unit, unresolved tool calls, and the authority under which a future worker may continue.

This page designs planned continuation of the same business task. The loop guard decides whether a live run may take another step. Conversation compaction protects facts inside a smaller model context. The recovery runbook governs impact, compensation, and takeover after an incident. Here the product must make an ordinary pause and later re-entry safe even when no incident has occurred. A single-run trace review can inspect a failed continuation afterward.

Separate the five kinds of state

State	What it answers	Where its authority belongs
Conversation or session history	What messages and tool outputs might the model see next?	A session store or provider conversation. It is context, not proof that a business step completed.
Execution checkpoint	Which graph or workflow step, typed variables, and pending branches can the runtime restore?	A durable checkpointer or execution history with a stable task cursor.
Business progress	Which input objects passed review, what output versions exist, and which objects remain?	An application-owned ledger tied to source and output IDs.
External effect	Was a publication, reservation, or other write accepted by its target system?	The target system’s authoritative record, joined to an operation ID.
Approval	Who approved which exact action and version, under what policy and time limit?	An authenticated, server-owned decision record; it is not a sentence in a chat summary.

OpenAI Agents SDK sessions manage conversation history across runs, while a paused approval run has a separate serializable RunState. LangGraph distinguishes a thread’s checkpointer from its cross-thread store. These are examples of why keeping a session ID alone does not prove that a paused job can survive a process restart. Choose a persistent backing store, define retention and access, and keep secrets or raw restricted source material out of this site’s browser-saved worksheet.

Commit progress at a supported boundary

Give the business task a stable task_id, and distinguish each execution attempt with a separate attempt_id. Save a checkpoint ID or event-history cursor, workflow and state-schema versions, accepted output references, per-object completion states, the next permitted step, cumulative budgets, deadline, cancellation state, and the source versions used. Store large inputs by protected reference and hash rather than repeatedly embedding them in a conversation snapshot. A checkpoint should say what is confirmed, what is in progress, and what is unknown; an in-progress item must not be silently promoted to done after restart.

The exact safe boundary depends on the runtime. LangGraph checkpoints full graph state at super-step boundaries, and its durability modes trade write timing for overhead: exit does not preserve mid-run progress through a process crash, async has a small write-loss window, and sync writes before the next step. Its in-memory saver loses checkpoints on restart. LangGraph can retain successful node writes from a partially failed parallel step, but those writes are not the same as an arbitrary line-by-line resume point. Select the mode against the loss the task can tolerate, then test a real process kill on each side of the chosen boundary.

Do not assume a replayed model call will return the same text. LangGraph’s replay from an older checkpoint reruns later nodes, including LLM calls and API requests; resuming a node interrupted for human input starts that node from its beginning, so code before the interrupt runs again. Persist decisions and accepted outputs that must remain stable, and put side effects behind a repeat-safe operation protocol. Temporal uses an event history to replay workflow progress, yet an activity task can still be retried after a worker crashes following a function call. A durable orchestration record and an external side effect are different facts.

Put a ledger around each external write

Before a tool submits a non-repeatable operation, durably record its business object, approved argument fingerprint, operation or idempotency key, target system, and expected result. Move the row to dispatching durably before sending, then record the response and a target-system lookup reference. Distinguish pending, dispatching, confirmed, rejected, and unknown. If the worker dies after the target accepted a write but before local success is recorded, the row may still say dispatching; if the dispatch transition itself was lost, it may even say pending. Treat any action that could have been sent as unknown until a target lookup by operation ID or business key settles it. Submit another write only when non-execution is established or the target’s actual deduplication contract makes that exact replay safe.

This is not a claim that the checkpoint and external service commit atomically. A generic “exactly once” label on a framework cannot settle a lost acknowledgment from an unrelated API. Keep the rule for each tool in its tool-calling contract: key lifetime, changed-argument behavior, concurrency, authoritative lookup, and who handles an inconclusive result. If no safe lookup or replay exists, pause for a person rather than guessing from the agent’s previous message.

Recheck approval and allow one resume owner

For this contract, bind an overnight approval to one tool call and its exact arguments, not to a vague instruction such as “continue the project.” Store the reviewer identity, decision, exact output or argument version, policy version, scope, expiry, and decision time. When the draft, target object, policy, requester authority, or deadline changes, put the action back through the relevant gate. The OpenAI Agents SDK also supports always_approve=True, which can keep approval for later calls to the same tool. Disable that broader mode here or add an application gate that checks each call’s arguments and version. The SDK can serialize pending calls and approval decisions in RunState; its documentation warns that deserializing that state does not authenticate the snapshot or the person submitting it. A server must load its own trusted state, authenticate and authorize the reviewer, and atomically consume a pending decision before resuming. Do not let a browser submit a replacement serialized run.

For the job itself, use one owner-checked transition from paused to resuming, with an attempt ID or lease so two workers cannot both act on one checkpoint. A duplicate “resume” click should find the existing attempt or return a pending status, not start another execution. A lease can expire while the old worker is still alive, so a check just before the write has a race. Enforce a fenced owner epoch or version at the commit boundary; if the external target cannot honor fencing, route writes through a single owner-checked proxy or rely on the target’s verified deduplication for the exact operation. Make cancellation and task expiry terminal gates for new work. Serialized state can outlive the agent or tool definition that created it, so retain a version marker and route incompatible snapshots to migration or human review.

Gate the next step from current evidence

On resume, load the server-owned state by stable task ID and verify its integrity, schema, source and output versions, and the caller’s current access. Reconcile every unknown external action against the target system before selecting another write. Recheck approvals for the exact current arguments; carry forward elapsed time, model turns, tool attempts, tokens, and money instead of resetting limits because a new process started. Confirm that the task was not canceled, expired, or already completed. Only then give the next worker the permitted step and its source pointers.

Test at least four fault windows with synthetic data: a crash just before a checkpoint commit; a crash just after its acknowledgment; a target write accepted while the local acknowledgment is lost; and two concurrent resume requests. Also expire an old worker’s lease while it is still alive, let a new worker take over, and verify that the old worker’s commit is rejected by fencing or safely deduplicated at the target write boundary. Add a source-revision or approval-change case. For each, record the authoritative final object count, what the resumed agent did, and whether any confirmed unit was repeated. The workbench below leaves result cells empty until these drills run. A successful prompt continuation alone is not enough evidence.

Example: an archive photo batch crosses a restart

A fictional archive asks an agent to draft searchable captions for a set of historical photographs. Each image has an approved source ID and file hash. The agent writes a draft caption, then a curator accepts or edits it before that image is marked complete. A worker stops while one caption is being generated, after several earlier images were accepted.

The resume contract records accepted image IDs and output revisions separately from the in-progress image. After restart, it checks the latest source hashes and loads accepted captions by reference. It does not spend another model call on already accepted images or treat a partly generated caption as approved. If an image was replaced overnight, that item is held for fresh review while unaffected completed items remain complete. The actual object counts and restart result belong in the trial, not in this illustrative story.

Example: a museum label waits for publication approval

A fictional museum agent drafts a set of exhibit labels and pauses before publishing them to a content management system. A curator approves one named draft revision and target page. The next morning, a colleague has corrected a date in the draft. The old approval does not authorize publishing the changed revision. The resumed worker must compare the approved fingerprint with the current content and request a new decision.

In a separate test window, the CMS accepts a publish request but the worker loses the response. The saved operation key remains unknown until the CMS record is queried; reopening the agent or repeating the approval must not create a second page. If the target cannot confirm what happened, the task stays paused with a named human owner. Neither outcome is asserted as a measured run here.

Fill the resume-state contract

The workbench records task and attempt IDs, durable checkpoint location, source and output versions, per-object progress, approval binding, external operation status, cumulative limits, single-owner resume gate, and fault-window probes. It saves a draft in this browser and supports copy and TXT export. Use synthetic IDs and controlled evidence pointers in this public worksheet; keep actual serialized run state, credentials, restricted files, and approval records in authorized server storage.

Boundary

A short read-only task that finishes in one request may need no durable workflow. This contract also does not replace an incident runbook when damage requires compensation, a context-compaction test when model facts are lost, or a trace review when an earlier step is disputed. Framework guarantees differ by version and execution mode. Resume only from boundaries and state transitions that the selected runtime and target systems have actually verified.