What must survive for an agent to continue?
Suppose an agent researching a report loses its execution environment. The conversation says it reviewed sources and created a table, but the sources, file location, and unresolved questions are unclear. Resumption is difficult. This hypothetical example distinguishes preserving a conversation from preserving what a task needs to continue.
Drawing on design material available by April 20, 2026, this article examines what to retain for work that spans interruptions. For such tasks, accuracy needs to be assessed together with whether a resumed run can advance the remaining work without unnecessarily repeating completed steps.
Separate the running process from its recovery record
Anthropic's April 8 Managed Agents architecture article describes separating session records, the model-calling loop, and the code-execution environment. An external event log supports resumption after the loop fails. It also distinguishes the stored session from the model's context window.
This does not mean passing the entire history into every model call. Retaining records and selecting information for the current decision are separate tasks. For a research report, one could retain the collection history while loading the selected sources, unresolved questions, and next action when resuming.
A surviving log does not establish that an external action happened exactly once. If a message was sent but execution stopped before recording the result, repeating the action could send it twice. Reconciling the destination's state or an operation identifier is necessary in that case; reloading a session alone is insufficient.
Connect progress records to the correct artifact version
Google ADK's State documentation separates values needed during an interaction from event history and makes persistence dependent on the SessionService. InMemorySessionService loses state on restart. The existence of a session does not by itself establish restart durability.
ADK's Artifacts manage file-like data with names and versions. Their storage service also matters: the in-memory implementation does not survive process termination. This illustrates separating small progress values from larger generated files.
For the report, record that comparison-table version two exists and that two entries remain unverified, then reference that exact file version. Saying only that the table is complete while handing over an older file would send the next run to the wrong starting point. I recommend transferring input and output versions and unresolved questions alongside the next action.
Vary the interruption point and compare the resumed outcome
Use the same completion criteria for uninterrupted and interrupted runs. For the report, stop after source collection, after saving the table, and before updating progress. Check that unresolved questions survive, verified content remains intact, and unnecessary refetching or duplicate sending does not occur. Merely reopening the file is insufficient.
Include changes over time. If yesterday's prices or availability will appear in today's report, define which facts need refreshing. Carrying forward context must coexist with checking facts that may have changed.
These exercises identify what a particular task needs to preserve. A short question does not require the same collection of mechanisms. For work completed across multiple runs, defining the resumption point and what must be checked again provides a practical starting point for evaluating continuity.