Why Long-Running Agents Lose Their Place—and How to Resume Them

Table of Contents

1. Why an agent loses its place
2. Conversation history is not progress state
3. Design a progress artifact
4. Checkpointing and context compaction
5. A worked example: preparing a vendor renewal
6. Resume through decisions, not summaries
7. Failure modes and recovery choices
8. Choosing what to persist
9. A practical implementation sequence
10. A worksheet for your first resumable run
11. Where to go deeper

Why an agent loses its place

A long-running agent rarely loses its place because it has forgotten every sentence. It loses its place because the conversation no longer gives a reliable answer to the operational question: what is true now, what has already happened, and what is safe to do next? A model may have a transcript, a summary, or both, yet still be unable to distinguish an intended action from a completed one.

That distinction matters whenever a task spans sessions, context windows, people, or external systems. A research agent may have gathered evidence but not reconciled conflicting records. A workflow agent may have sent a request but not received confirmation. A planning agent may have outlined the next step without committing to it. In each case, a fluent summary can sound complete while concealing a missing transition.

A long-running agent is an agent whose work cannot safely be treated as one uninterrupted exchange. Its task may pause because a context window fills, a process restarts, an external service is unavailable, or a person needs to review something. Resumption is the act of continuing from a known state after such a pause, rather than asking the model to reconstruct progress from an undifferentiated history.

A useful mental model is a field notebook alongside a conversation. The conversation contains exploration: questions, attempts, tool output, and reasoning. The notebook records the facts another operator needs to continue: the goal, current phase, verified findings, unresolved questions, completed effects, and next permitted action. When the conversation must be shortened or replaced, the notebook remains the working reference.

This article focuses on that progress record: what it should contain, when to update it, and how to use it to resume without repeating work or silently skipping work. It is not a general treatment of context selection, agent manifests, or durable workflow orchestration. For those distinct implementation questions, see Context Engineering for Agents: A Keep, Summarise or Retrieve Experiment, Build an AI Harness Run Manifest: State, Tools and Stop Conditions, and Durable Execution for Agents That Run for Hours.

Conversation history is not progress state

Conversation history is a record of messages and observations. Progress state is a compact account of the task’s current, validated position. They overlap, but they are not interchangeable. A transcript can preserve what was said without identifying which facts were checked, which action actually took effect, or whether a proposed next step is still valid.

A summary is also not automatically a checkpoint. A summary describes selected content, often in natural language. A checkpoint records a recoverable boundary: what state was committed, which evidence supports it, and what should happen after restart. A short, well-structured checkpoint can be more useful than a long summary if it answers those questions directly.

The distinction becomes clearer when a task has a sequence of phases. Suppose the phases are “collect records,” “compare values,” and “prepare a recommendation.” If the agent has collected the records and started comparing them, a vague note such as “records reviewed; recommendation in progress” does not reveal whether every record was compared. Nor does it identify the input set used or the comparison rule. A new session might repeat the review, skip the unfinished comparison, or make a recommendation from incomplete evidence.

A resumable design therefore gives each phase an explicit state. “Not started,” “in progress,” “complete,” and “blocked” are often more informative than a single percentage. Completion should mean that the phase’s defined acceptance condition has been met, not merely that the model wrote a sentence saying it was done.

External effects need a separate distinction. A draft message being ready is not the same as a message being sent. A requested update is not the same as an update confirmed by the destination system. Persist the operation’s status and any available receipt separately from the model’s account of what it intended to do. When a side effect cannot be verified, the state should say “outcome unknown,” not silently convert uncertainty into success.

This is where a durable record and replay boundaries matter. Persistence helps retain state across interruptions; non-deterministic actions need careful boundaries so replay does not casually repeat an external effect. LangGraph’s persistence guidance discusses those concerns. The design implication is straightforward: resume from a recorded state transition, and reconcile uncertain effects before attempting them again. That is not a promise of exactly-once execution; it is a way to make uncertainty visible and recovery deliberate.

Design a progress artifact

A progress artifact is the small, versioned record that tells the next run what work is complete and what remains. It might be stored as a database row, a JSON document, or an application record linked to a task. The storage format matters less than stable identity, clear update rules, and the ability to distinguish trusted facts from tentative conclusions.

A practical artifact begins with identity and scope. Give the run a stable run_id, name the task, record the current revision of its input, and identify the relevant subject. If the task concerns a particular renewal request, for example, the record should make it possible to tell which request and which source documents it represents. Without identity, an otherwise accurate checkpoint can be attached to the wrong task.

Next, record the workflow position in terms that have operational meaning. A phase field might be collect, compare, draft, or awaiting_review. A status might be active, blocked, ready_for_review, or complete. These values should describe the process, not its tone. “Almost done” is hard to route; “draft prepared, reviewer decision pending” is actionable.

Then preserve findings with provenance. Each finding should carry a value, a source reference, a time or revision indicator where relevant, and a confidence or verification status appropriate to the application. “Renewal date is 30 June” is weaker than “renewal date is 30 June, extracted from document X, page 2, checked against request revision 4.” The latter can be tested when inputs change.

The artifact should also record decisions and assumptions separately. A decision is a choice made under an identified rule or by an authorized person. An assumption is an unresolved condition temporarily used to proceed. If those are mixed together, a later agent may present an assumption as settled fact. For example, “use the latest approved rate” needs a reference to the approval record; “assuming the latest spreadsheet is authoritative” should remain visibly provisional.

Finally, record the next action and its guard conditions. “Send the notice” is not enough. A useful instruction says what content or record the action concerns, what must be verified first, and whether the action is permitted now. Where approval is required, bind approval to the exact payload to be acted on and set a clear expiry or revalidation condition. If the payload changes, the earlier approval should not be treated as covering the new version.

A compact conceptual schema might look like this:

This is a starting point, not a universal schema. A regulated workflow, a research assistant, and an internal operations bot may require different fields. The governing test is whether a new run can use the artifact to identify the next safe step, detect stale information, and explain why the task is not yet complete.

Checkpointing and context compaction

A checkpoint is a saved, internally consistent state from which work can continue. Checkpointing at every token or every model response is often unnecessary. Waiting until the end of a long task is risky. A more useful rule is to checkpoint at meaningful boundaries: after a phase satisfies its acceptance condition, after an important decision, before an external effect, and after that effect is reconciled.

Context compaction is the act of reducing the conversation available to the next model call, usually by dropping, summarising, or retrieving selected material. It is a context-management decision, not a progress update. Before compacting, first write or update the progress artifact; then check that it captures the state the next run needs. Compressing first can discard an unresolved detail before anyone has decided whether it belongs in the durable record.

A good checkpoint is conservative about claims. It should state what is known, how it is known, and what remains unverified. It should not convert a tool’s error message into a finding about the business world. If a search returned no results, record that the search found none under its query and scope; do not conclude that no relevant records exist unless the search was complete for that purpose.

A brief handoff can accompany the structured record. It should point to the important evidence and explain the key snag, not repeat every conversation turn. Structured handoffs and progress artifacts can help work continue across context windows, but they do not guarantee that a task will finish or that a later model will interpret every detail correctly. Anthropic’s guidance on harnesses for long-running agents makes that practical point. The artifact remains a mechanism for reducing ambiguity, not a substitute for validation.

The following flow shows a safe high-level resumption path. It assumes that the run has a saved artifact and that the system can inspect relevant external outcomes when needed.

flowchart TD
  accDescr: Workflow stages and decisions: Load saved checkpoint, Validate identity and inputs, Checkpoint valid?, Stop and repair state, Effect outcome unknown?, Reconcile external outcome, Resume permitted next action. The adjacent text explains the conditions and exceptions.
  accTitle: Why Long-Running Agents Lose Their Place—and How to Resume Them workflow
    A["Load saved checkpoint"] --> B["Validate identity and inputs"]
    B --> C{"Checkpoint valid?"}
    C -->|"No"| D["Stop and repair state"]
    C -->|"Yes"| E{"Effect outcome unknown?"}
    E -->|"Yes"| F["Reconcile external outcome"]
    F --> E
    E -->|"No"| G["Resume permitted next action"]

The first decision prevents a checkpoint for one task revision from being reused blindly against another. The second prevents an ambiguous external operation from being repeated just because the agent restarted. “Reconcile” means inspect the relevant system or ask for human confirmation if the system cannot establish the outcome. Only when identity and input scope are sound, and any uncertain effect has been addressed, should the agent proceed from its recorded next action.

A worked example: preparing a vendor renewal

Consider a hypothetical operations agent asked to compare a vendor’s renewal proposal with an internal contract and prepare a recommendation for a manager. The task is not to autonomously sign or send anything. Its work involves reading three documents, checking dates and terms, drafting a comparison, and handing the result to a reviewer. This scenario illustrates the state design; it is not a report of a deployed system.

At the start, the run record names the vendor request, the three input files and their revisions, the task boundary, and the expected output. The first phase is “collect and validate sources.” Its completion condition is not “the agent has opened three files.” It is “the expected three inputs were found, their revisions were recorded, and each document was readable enough for the required fields to be checked.” If one document is missing, the run becomes blocked with that specific reason.

The agent then extracts a small set of fields: renewal period, notice deadline, listed price, and any relevant change clause. Each value is linked to the document and location from which it came. If the proposal says 12 months while the contract says 24 months, the artifact records both values and their origins. It does not resolve the conflict by choosing whichever value appeared last in the conversation.

The comparison phase can now be marked complete if its rule has been applied to every required field. The artifact records the comparison method and the resulting discrepancy. If a clause is ambiguous, it records the ambiguity and the section that needs review. The next action might be “prepare recommendation draft using verified fields; flag disputed clause,” not “recommend renewal.” This makes the boundary between extraction and judgment visible.

Before a context reset, the run saves the artifact and a short handoff: the source revisions, the verified findings, the unresolved clause, and the draft requirement. After restart, the agent checks that the request revision and documents still match. If the proposal has changed, it invalidates affected findings and returns to the relevant collection or comparison phase. It should not quietly combine old extracted values with new input.

Suppose the first run also saved a draft to a shared workspace, but its response was lost before the agent recorded success. The checkpoint must represent that effect as uncertain. On resumption, the agent checks the workspace for the draft using its run identity or another reliable marker. If the draft exists and matches the intended revision, it records the observed result and continues. If the outcome cannot be established, it stops for reconciliation instead of creating a second draft and assuming duplicates are harmless.

The manager’s review is another explicit state boundary. “Ready for review” means the draft and its evidence are assembled; it does not mean the recommendation has been approved. A reviewer’s decision should be recorded with the draft version it covers. If the draft changes materially afterward, the workflow should return to review rather than treating the old decision as blanket permission for a new version.

This example shows why a progress artifact needs more than a summary field. It must connect the task identity, input revision, completed phase, evidence, unresolved issue, external effect, and next action. The record remains small because it stores pointers and decisions, not a duplicate of every document and every model message.

Resume through decisions, not summaries

A useful resume prompt should be generated from validated state rather than assembled by copying the last several messages. It tells the model what task it is resuming, which inputs are current, which phases are complete, what remains unresolved, and what action is permitted next. It also instructs the model to stop if a required assumption is no longer true or evidence cannot be located.

The order matters. First load the record by stable run identity. Then validate its version and input references. Next retrieve the evidence needed for the next phase, not every historical interaction by default. Finally, ask the agent to confirm its interpretation of the state before it performs any consequential action. A short “I will continue by checking X against revision Y; Z remains unresolved” gives the system an opportunity to catch a mismatch early.

Do not use a model-generated statement of completion as the only proof that a phase is complete. Tie completion to observable conditions: all required fields have a source; a comparison covers the full input set; a draft is stored at a known revision; or a reviewer decision is recorded for that revision. The exact conditions depend on the task, but they should be inspectable outside the model’s narrative.

Likewise, a model’s confidence is not a substitute for freshness. If the source has changed, a once-correct answer may now be wrong. Store a revision, timestamp, or content fingerprint suitable to the data source, then define which changes invalidate which findings. A changed title might not matter to a calculation; a changed term or amount probably does. Avoid invalidating everything automatically if a narrower dependency map can identify affected work, but prefer rechecking over relying on an untraceable assumption.

If your team is choosing an orchestration approach as well as a resumption pattern, the Claude Agent SDK: When It Beats Your Own Orchestration article is a related implementation discussion. A workflow that reaches a human decision point also benefits from a clear review boundary; see AI Agents in Production: Human-in-the-Loop Patterns. These are adjacent design considerations, not substitutes for keeping an accurate progress record.

Failure modes and recovery choices

A checkpoint is written before the work it claims to represent. This can happen when a system updates the artifact to “complete” before confirming the underlying output. The remedy is to define the commit order: persist the result, verify that it can be read back or otherwise observed, then record the phase as complete. If the process stops between those steps, the record should remain pending or uncertain rather than assert success.

A checkpoint is written after a side effect but the result is not recorded. A restart may see “send notice” as the next action and send it again. Record the action’s intent before attempting it, then record the observed outcome after reconciliation. If the system supports a stable operation identifier, preserve it. If it does not, design an explicit lookup or human recovery step. Do not promise exactly-once behavior where the underlying operation cannot provide it.

The artifact and the inputs drift apart. A user replaces a file or changes the request, while the stored findings still point to an earlier version. The failure may be subtle because the old extraction is internally coherent. On resume, validate input identity and define invalidation rules. If a material input has changed, mark dependent findings stale and return to the earliest affected phase.

A summary removes the exception that mattered. A compressed note might retain the headline result and omit a caveat, such as an unreadable page or a missing date. Keep exceptions, blockers, and unresolved assumptions as explicit structured fields. Summaries should be generated from those fields and checked against them, not used as the only surviving representation of task state.

A stale lock or “in progress” status strands a run. If a process dies while the record says work is active, a new worker may be unable to tell whether the previous one is alive. Store enough execution metadata to identify the owner or lease and its freshness, then define when a run can be reclaimed. Reclaiming the record should not imply that any uncertain external action is safe to repeat.

The schema changes while old runs remain active. A new version may rename a field or change the meaning of a status. Treat the schema version as part of the artifact, validate it on read, and migrate deliberately. If a reliable migration is unavailable, stop and route the record for repair instead of interpreting unknown values optimistically.

A retrieval step returns a plausible but wrong run. Similar task names or repeated work for the same account can cause an agent to pick the wrong record. Retrieve by stable identity and confirm the subject and input revision before using its contents. A search result that “looks right” is not enough when it can lead to an external action or a consequential recommendation.

In each case, recovery begins by making uncertainty explicit. The system should know whether to retry, reconcile, re-collect, request review, or stop. “Try again” is not a universal recovery policy: it may duplicate an effect, overwrite newer work, or conceal a mismatch that should have blocked the run.

Choosing what to persist

The goal is not to save every token forever. Persist information because it supports a future decision, proves a task boundary, or helps detect that a previous conclusion has become stale. For a particular field, ask: will a later run need the value, its source, its status, or the reasoning behind a decision? Keep the smallest representation that answers that need reliably.

Raw records and progress state serve different purposes. Raw records can support audit, re-extraction, or dispute resolution, subject to the application’s retention and access policies. The progress artifact should point to relevant records rather than copying all of them into a growing summary. A compact pointer such as a document identifier, revision, and page or section is often more useful than another large block of repeated prose.

Keep durable decisions separate from transient observations. “The source file returned an access error at 10:04” may explain why the run is blocked, but it should not become a permanent fact about the underlying document. “The reviewer selected option B for draft revision 3” is a decision that may matter later. Explicit types make it easier to expire operational noise without losing meaningful state.

Set a freshness rule for every important category. A customer preference may need confirmation after a period of inactivity; a source document may be valid only at a particular revision; a calculated result may be reusable until its dependencies change. If no freshness rule exists, old state tends to acquire undeserved authority simply because it is easy to retrieve.

Avoid storing free-form reasoning as the sole basis for resumption. A short rationale can help an operator understand a decision, but it should be connected to the evidence, rule, or reviewer input that supports it. The next agent should be able to verify the underlying basis rather than having to trust an earlier model’s polished account.

A practical implementation sequence

Start with one workflow that naturally pauses and has observable completion conditions. Map its phases on paper before changing prompts or adding a memory store. For each phase, define its inputs, its output, the condition for completion, and what makes the result stale. This reveals whether the real problem is lost context, an ambiguous business process, or missing external-system evidence.

Give each run a stable identity and choose one authoritative record for progress state. If multiple components can edit the state, define how conflicts are detected rather than letting the last write silently win. Keep the artifact’s schema small at first; add a field only when a real resumption decision requires it.

Implement a checkpoint at the end of each meaningful phase and immediately before an external effect. After the effect, reconcile its outcome and update the record. A phase should not be marked complete merely because the model emitted the expected text. Where an outcome is not observable, make the uncertainty a first-class status and define the human or system action that resolves it.

Build a resume path that reads the artifact, validates identity and freshness, retrieves the evidence needed for the next step, and refuses to continue when the record is inconsistent. The refusal path is part of the design. It should explain which field or condition failed and what repair is needed, instead of returning a generic error or inventing a plausible continuation.

Test recovery with deliberately interrupted runs. Stop between writing a draft and recording its result; change an input revision; remove a referenced source; and create a record with a newer schema version. Check that the system routes each condition as intended. These are proposed acceptance tests, not a claim that any particular implementation has been executed or validated.

Useful acceptance criteria are concrete and observable. A resumed run selects the same task identity and current input revision; it does not repeat a confirmed external effect; it does not treat an unknown outcome as success; it identifies stale findings; and it stops on an invalid checkpoint with a repairable explanation. Teams can add task-specific criteria, such as complete field coverage or reviewer binding to a draft revision.

Once the path is reliable for one workflow, consider whether progress records need indexing, retention tiers, or a broader orchestration layer. Keep those decisions tied to actual operational needs. More storage and more sophisticated retrieval do not fix a status field that confuses “prepared” with “sent.” If implementation support is useful, AI agent engineering is one relevant next step.

A worksheet for your first resumable run

Use this worksheet to define the minimum state needed for one workflow. It is intended to be filled in by the people who operate the process and the engineers implementing it. The answers should describe a real task boundary, not a generic agent persona.

Run identity and scope

• Stable run identity: What identifier uniquely selects this task, even if multiple sessions or workers touch it?
• Subject and boundary: Which customer, case, document set, or operational unit does it concern? What is explicitly outside the agent’s task?
• Input versions: Which source revisions, dates, or identifiers must match before old findings can be reused?
• Completion definition: What observable condition means the task is complete, and who or what can verify it?

State and evidence

• Phases: What are the smallest useful stages, and what must be true before each is marked complete?
• Findings: Which extracted or computed values must survive a pause? For each, what source and verification status are required?
• Decisions: Which choices need their basis recorded? Are assumptions visibly separate from decisions?
• Exceptions: What missing evidence, ambiguity, or failed lookup should block progress rather than disappear into a summary?
• Freshness: What changes invalidate each finding, and how will the next run detect those changes?

Effects and resumption

• External actions: Which actions change another system or create a communication? What state is recorded before and after each action?
• Unknown outcomes: How does the workflow reconcile an action whose result was not recorded before interruption?
• Approval boundary: If a person must approve an action, is that approval tied to the exact version of the payload and rechecked if it changes?
• Next action: Does the artifact name one permitted next step and its preconditions, rather than a vague instruction to continue?
• Stop path: What should happen when identity, inputs, schema, evidence, or effect status cannot be validated?

Recovery review

• Interruption test: Can the team interrupt the workflow at each checkpoint and explain how it resumes?
• Duplicate-effect test: Can it distinguish an unattempted effect, a confirmed effect, and an unknown outcome?
• Staleness test: Does a changed input invalidate the right findings without silently preserving obsolete ones?
• Operator handoff: Can someone unfamiliar with the original conversation identify what is complete, what is blocked, and why?

Printable summary: For each run, record its identity and input revision; current phase and status; verified findings with sources; decisions and assumptions separately; unresolved blockers; external effects with observed outcomes; the next permitted action and its conditions; and the checkpoint’s schema version and update time. If any item cannot be established, record what is unknown and who or what must resolve it before the run proceeds.

Where to go deeper

The central design choice is to treat resumption as a state-validation problem, not a memory-recall trick. Conversation can help an agent reason, but a compact progress artifact should establish which work is complete, what evidence supports it, whether the inputs remain current, and what action is allowed next. Checkpointing at phase boundaries, recording external outcomes distinctly, and making uncertainty explicit turn an interrupted run into a recoverable one.

Start with the workflow that most often restarts or hands work between people. Define its completion conditions, build the smallest useful artifact, and rehearse its failure paths before expanding the design. A system that reliably stops when its state is unclear is more resumable than one that produces a confident but unsupported continuation.

WANT TO TALK THROUGH YOUR SITUATION?

Talk it through with us. Thirty minutes, no slides.