When an AI agent pauses halfway through a business task, give the next session a short, verifiable record of the unfinished job. Keep that record separate from the reusable skill that explains how to do the work. The next session needs both the method and the current facts: which inputs were used, what was actually produced, which checks remain and whether any external action already happened.
This is our recommended workflow for work that spans sessions, owners or machines. It is not a claim that every assistant can resume from files automatically. A handoff only helps if the receiving runtime can access the record and the artifacts it identifies.
The business decision is straightforward: before putting a recurring task on an agent, decide how another session will establish its current state. “Continue where you left off” should lead to evidence, not a reconstruction from confident prose.
The skill describes the method; the run records progress
The Agent Skills specification defines a package built around a SKILL.md file, with optional scripts, references and assets. It describes how instructions and supporting resources are organized and loaded. The format itself does not establish a universal contract for saving and restoring an unfinished execution across products.
For a monthly management report, the skill might explain how to validate inputs, calculate comparisons, draft commentary and check the final document. Those instructions should remain useful next month.
The current run has different information: the reporting period, the source revisions, a partially written report and an unresolved discrepancy. Putting that information into the reusable package would mix one job’s progress with the procedure for future jobs.
Our introduction to SKILL.md work instructions covers the reusable procedure. Here the additional design question is where the unfinished job lives. A small team could use a restricted project folder. A larger organization might use a workflow service with saved execution state. Neither choice removes the need to identify the authoritative artifacts.
Research supports explicit state, with important limits
Badhe, Tiwari and Chung’s 2026 SKILL.state paper investigates a runtime that supplies the model with a fixed procedure, structured execution state and the latest observation instead of an accumulating transcript. Its experiments include controlled procedural simulations and public interactive benchmarks. The authors report lower token consumption with competitive or improved task performance under their evaluated conditions.
That is research on an implemented architecture, not evidence that writing a handoff document delivers the same results. The authors include Google and Purdue affiliations; this article has not independently replicated their experiments. Their limitations matter: a predefined state representation can omit information whose relevance becomes clear later, and some tasks require the historical record itself. Their single-agent setting also does not resolve concurrent writers.
The practical implication we draw is narrower than adopting their entire architecture: make current state explicit, while retaining source artifacts and the history required for audit. A concise continuation record and a durable evidence archive serve different purposes. Deleting history merely to shorten the next prompt could undermine the work’s review requirements.
Engineering experience does not imply one universal reset policy
Anthropic’s March 2026 engineering account of long-running application development describes using structured artifacts to transfer context between sessions. It also reports that its later Opus 4.5 harness could omit the context resets used with Sonnet 4.5, relying on automatic compaction instead. This is vendor practitioner experience in particular coding setups, not an independent comparison of every current assistant.
For business teams, the useful lesson is to separate continuity requirements from a specific model’s context-management technique. A workflow may continue in one session, recover after a crash or move to another operator. In each case, someone needs to establish what exists and what remains authorized.
Do not require a new session simply because a guide mentions handoffs. Use the product’s supported continuation mechanism when it meets the need. Add a separate record when work must survive a boundary that mechanism does not cover, or when another owner needs inspectable status.
A small handoff contract for a real job
The following is our proposed record, not a standardized Agent Skills extension. Keep it in the job’s approved workspace and reference it from the workflow. Do not copy confidential run data into a public skill package.
| Record | What the next session should establish |
|---|---|
| Job identity and objective | Which reporting period or request this work belongs to |
| Scope and authorization | What was requested, what actions are permitted and any unresolved boundary |
| Procedure version | Which skill revision and relevant configuration guided the work |
| Input references | Exact files, revisions or snapshots used, including access dates where useful |
| Output references and status | Where each artifact is saved and whether it is partial, checked or complete |
| Evidence and open issues | Results of checks, known discrepancies and decisions still needed |
| External action status | Operation identifiers, confirmed results and actions with uncertain outcomes |
| Next step and owner | The first action to take after verifying the saved state |
Use precise status words. “Draft saved; totals unchecked” is more useful than “report almost done.” A check should identify the artifact revision it examined. If the report changes afterward, an earlier successful check does not automatically cover the new file.
Retain valid authorization already given for the task. The handoff should carry its scope, not trigger repetitive approval requests or silently expand permissions. If the next step falls outside that scope, resolve that specific gap through the organization’s existing process.
A hypothetical monthly-report interruption
Imagine an operations team preparing its monthly service report. This example is fictional. Its agent has permission to create and update the report in an approved workspace; distribution happens through a separate process.
The agent imports the approved monthly export, produces a calculation sheet and starts a narrative. Before the session ends, one department’s total does not reconcile. The report exists, but it is not ready for distribution.
A useful handoff would identify the export revision, calculation sheet and narrative revision. It would say that the import completed, the department discrepancy remains unresolved and the narrative’s affected comparison has not been checked. The next step would be to inspect the discrepancy using those artifacts, rather than regenerate the entire report.
When the next session starts, it should first confirm access to the named files and compare their revisions with the record. If someone replaced the export overnight, the saved calculation is no longer a sufficient basis for continuing unchanged. Establish which input should apply and rerun the affected calculation and checks.
This distinction prevents two different mistakes: discarding useful work because the conversation ended, and treating a saved summary as proof that all its assumptions still hold.
An interrupted action needs reconciliation before repetition
The difficult boundary is often an external write. Suppose an agent submits an update to a business system and loses the connection before receiving confirmation. The handoff should preserve the uncertainty, along with any request or operation identifier available.
Our recommendation is to inspect the system’s current state or supported operation history before deciding whether to retry. If the update succeeded, continue from the observed result. If it failed, use the supported retry path. If the outcome cannot be established, leave that uncertainty visible and route it to the responsible owner.
Writing “retry update” in Markdown cannot ensure that an action happens exactly once. That depends on the application, its external services and their supported controls. A plain handoff is a navigation aid for recovery, not a transaction system.
For implementations using a framework, inspect its persistence behavior directly. LangGraph’s documentation distinguishes thread checkpoints from data stored across threads. It also warns that in-memory checkpoints disappear on process restart. These are framework-specific capabilities and storage choices; a readable skill file does not confer them on another assistant.
Test the boundary you intend to cross
Start with fictional inputs and a task whose correct output is inspectable. Our proposed interruption exercise checks the receiving session’s behavior, rather than whether the outgoing session can write a polished summary.
| Interruption or change | What to inspect on continuation |
|---|---|
| Pause after a partial artifact is saved | The next session finds it and preserves usable work |
| Change an input after the handoff | The next session detects the mismatch and identifies affected work |
| Lose confirmation after an external write | The next session checks the outcome before repeating the action |
| Leave an unresolved discrepancy | The next session keeps it open instead of declaring completion |
| Start two continuations | The workflow establishes one owner or detects conflicting updates |
These are proposed acceptance checks, not tests performed for this article. Record the actual product, runtime, storage arrangement and result when your team runs them. If a framework already manages checkpoints and ownership, integrate with that mechanism instead of maintaining an uncoordinated second status record.
Scale the arrangement to the consequence of losing or duplicating work. A short drafting task may need only its saved document and a next-step note. A workflow that writes to shared systems may need durable checkpoints, action records and concurrency controls implemented outside the skill.
Choose one recurring job and interrupt it deliberately in a controlled environment. Continue only after verifying the inputs, artifacts and unresolved actions. The handoff has earned its place when it lets the next owner establish the truth of the job and take the next authorized step.