Help a Coding Agent Resume Without Guessing

Quick answer: Save a compact task record containing the current objective, exact source state, completed work, evidence, unresolved questions, and next action. When an agent resumes, have it compare that record with the repository and any external job before continuing. A handoff should help reconstruct reality; it should never turn an old progress claim into fresh evidence.

A coding session ends halfway through a change. The next session sees modified files, a passing test log, and a note saying “almost done.” It still cannot tell whether the log covers those files, whether another worker is editing them, or whether “done” means implemented, reviewed, or deployed.

Saving more conversation may preserve all three ambiguities. A useful handoff records the facts needed to make the next decision.

Anthropic's November 2025 engineering article on long-running agents describes using progress artifacts and Git history to help subsequent coding sessions recover their bearings. It presents one harness design for web development, not a universal recovery guarantee or a required directory layout. Anthropic's long-running agent guidance.

The layout and worksheet below are original illustrative proposals. They have not been exercised as a recovery implementation.

Save the task's position, not its entire history

A transcript answers “what was said?” A task record should answer “where does the work stand now?” Keep a short current summary and link to detailed evidence when needed.

The minimum useful record has six parts:

Part	What the next session needs
Objective	The user-visible result and acceptance criteria
Scope	Owned paths, permitted actions, and important exclusions
Source	Repository identity, revision, and uncommitted work
Progress	Completed, partial, and untouched work
Evidence	Check commands, input revisions, outcomes, and log locations
Continuation	The next action, its preconditions, and unresolved decisions

Write observations separately from interpretations. “The parser returns an empty result for this fixture” is an observation if a retained result supports it. “The parser probably drops the final delimiter” is a hypothesis. The next session needs to know which one it can rely on.

Avoid repeating every earlier plan. Preserve an abandoned approach only when its failure constrains the next attempt: an unsupported API, an unavailable credential, or an architectural choice the user rejected.

Use one small continuation record

A repository might keep a task note under .agent/tasks/, in an existing issue, or in its normal work log. The location matters less than discoverability and ownership. Do not create a competing task system if the project already has one.

Here is a fictional handoff for a CSV import change. The placeholders represent values the real task owner must supply.

task: import-empty-final-column
objective: Preserve an empty final field in supported CSV imports.
acceptance:
  - A trailing delimiter produces an empty final field.
  - Existing quoted-field behavior is preserved.
scope:
  paths: [src/import/, tests/import/]
  external_actions: none
source:
  repository: OWNER/REPOSITORY
  base_commit: REPLACE_WITH_FULL_COMMIT
  current_commit: REPLACE_WITH_FULL_COMMIT
  dirty_paths: [src/import/parser.ts]
progress:
  completed: [Located the delimiter handling branch.]
  partial: [Candidate parser edit exists in the working tree.]
  remaining: [Review quoted-field cases, verify the final candidate.]
evidence:
  - check: Existing import suite
    input_commit: REPLACE_WITH_CHECKED_COMMIT
    result: not_recorded
    log: null
ownership:
  active_writer: none_confirmed
next_action: Inspect the candidate diff against the acceptance criteria.
resume_preconditions:
  - Confirm the checkout and dirty paths still match this record.
  - Confirm no earlier worker or command is still changing these files.

A missing result remains missing. Do not fill the evidence section with an optimistic summary because a check was planned or started. If the result is unknown, the resumed session should recover it or obtain new evidence before claiming completion.

Reconcile the note with the checkout

On resume, read the task note and local project instructions, then inspect the current repository. Establish its path, branch, revision, and dirty files before editing.

Git status distinguishes index changes, working-tree changes, and untracked files; ignored files need separate consideration. Git log provides commit history. Together they help compare the note with the checkout, but neither establishes the state of a remote deployment or an external job. Git status and Git log.

Three disagreements deserve different responses:

• The revision advanced. Inspect the intervening changes and decide whether the saved plan and checks still apply.
• The dirty files differ. Preserve the actual work and establish who changed it before overwriting anything.
• The recorded evidence is missing. Keep the claim unresolved until its result can be recovered or replaced.

A handoff is a starting index. It can be stale, incomplete, or wrong. Reading it is the beginning of recovery.

For results that will support a release, retain the connection between checks and their inputs described in verifying the exact code your agent will ship.

Reconcile external work before retrying

An interrupted conversation does not necessarily stop a build, upload, database operation, or deployment. Record external job identifiers and the system that can answer whether each operation completed.

Suppose a job was submitted but its acknowledgement never reached the agent. “No acknowledgement recorded” leaves two possibilities: the submission failed, or it succeeded and the response was lost. Repeating the operation may create a duplicate.

AWS's guidance on idempotent APIs explains how caller-provided request identifiers let a service recognise retries of the same request. That protection depends on the service's contract; adding a local identifier does not make an arbitrary operation idempotent. AWS guidance on safe retries.

Save the provider's operation ID or supported idempotency key, then query the provider before deciding to retry. Where the outcome cannot be established, mark it unknown and stop dependent actions. Keep credentials out of the handoff; reference the approved access mechanism instead.

The companion guide on what to check after stopping a coding agent covers the immediate recovery boundary in more detail.

Make updating the record part of finishing a step

Update the task record after a meaningful state change: a decision, a completed edit, a check result, a submitted job, or a new blocker. A note written only at the end of a perfect session will be absent when recovery matters most.

Give one owner responsibility for the current summary. Multiple workers can contribute separate results, but simultaneous edits to the same “current state” paragraph make it difficult to know which result won.

Keep the record small enough that the next session can read it before acting. Move bulky logs and historical detail behind stable links. When the task completes, record the final outcome and archive its continuation state so a later agent cannot mistake it for active work.

Before handing off, ask whether a new session could identify the task, preserve existing work, locate the evidence, and choose one justified next action. If those answers require remembering an earlier conversation, the handoff still has a gap.