Carry an agent’s work into tomorrow: memory, artifacts, and recovery

Can yesterday's research become today's work?

Suppose an agent stops after saving a product-comparison table. The next day, asked to continue, it collects the sources again and starts another table. Yesterday's decisions have not necessarily disappeared. A conversation saying that a table was created is insufficient when the selected sources, saved file, and two unresolved entries are disconnected.

This is a hypothetical example for examining the mechanism. Accepting yesterday's table as complete would create another problem: prices or supported regions may have changed overnight. The resumed task needs to update those facts. We want less unnecessary repetition without freezing yesterday's judgments.

Material available by April 20, 2026 shows continuity work extending from conversation reuse to execution recovery. I would compare more than memory capacity. Can the next agent or person receive usable results and the reasons behind decisions, then advance the remaining work under the right conditions?

Returning to the same thread is a useful beginning

OpenAI's April 16 Codex update includes automations that reuse existing threads, scheduled future wake-ups, and a memory preview for past corrections and preferences. These are user-visible forms of continuity that can reduce repeated explanation. Availability and release stages differed by feature and environment at the cutoff; the same capabilities were not available everywhere.

For a weekly comparison report, we may want to reuse the format and selection criteria while researching this week's prices. For yesterday's unfinished report, we need to distinguish verified entries from unresolved ones. Starting a new recurring task and recovering one incomplete task require different information.

A scheduled invocation does not guarantee a finished report. If a source becomes inaccessible after resumption, the product must also return the remaining work to its owner. Starting with conversation reuse and following the handoff through artifacts and unresolved items makes the convenience easier to assess.

Keep the recovery record outside the process that can fail

Anthropic's April 8 Managed Agents architecture article describes separating the session event log, the loop that runs models and tools, and the code-execution sandbox. The loop can reload an external log after failure. A replacement sandbox can be provisioned, but that alone does not establish restoration of every previously generated file.

The separation helps because progress need not exist only inside the failed process. After the report task stops, the next owner can inspect collected sources and returned operation results. Whether the saved table opens, and whether its contents agree with the recorded operations, still requires separate checks.

The article also distinguishes a stored session from the context supplied to the model at a particular moment. Retaining history does not mean loading every event into every call. Select enough information for the next decision and keep a path back to the underlying records. This makes a concise handoff compatible with preserving its evidence.

Reconnect to the environment, or rebuild from saved contents?

OpenAI's April 15 Agents SDK update describes a workspace with files and commands, externally retained state, and resumption from snapshots. The announcement began with Python; TypeScript and further extensions were planned. Availability should be distinguished from a claim that every API and persistence behavior is stable.

Indeed, the sandbox guide pinned before the cutoff carries a beta warning. It distinguishes reusing a live environment, reconnecting through serialized session state, and creating a fresh environment seeded from a snapshot. Reopening the same table can look similar in each case, while the recoverable state differs.

The guide excludes mounted and ephemeral paths from durable snapshot contents. It also allows a no-op snapshot fallback when a default local snapshot location cannot be established. Writing a report into some folder therefore does not establish persistence. Verify that the selected table is within the saved contents and can be read after restoration.

I would translate these distinctions into failure conditions when choosing an SDK. Reconnection may suffice after a temporary network interruption. If the original environment disappears, the question becomes whether saved tables and required inputs can reconstruct the work. This is a proposed test based on the guide, not a recovery measurement conducted here.

Link progress to the artifact version actually selected

Google ADK's State documentation separates progress values from event history and makes durability dependent on the SessionService. InMemorySessionService loses state on restart. Even with a persistent database service, updates need to follow the managed event flow. Directly modifying a retrieved Session can bypass history and persistence.

Artifacts, meanwhile, manage file-like data with names and versions. Saving the same name creates a new version; the returned version can be specified when loading it. Storage choice still matters: the in-memory implementation does not retain files across process termination.

For our table, record the selected filename and returned version, together with the two unresolved entries. Opening the newest file and opening the version used for a decision are different operations. A table extended by another run should not silently become the evidence for yesterday's judgment.

Versioned storage and progress updates do not alone establish that both commit together. Test a stop immediately after saving the table and before updating progress, then reconcile surviving files and records. The useful outcome is a procedure for choosing valid state from a discrepancy, rather than more names for stored data.

Five pieces of information for the next owner's decision

These are checks proposed by this article, not a shared vendor standard. They do not require five separate services. Connect them so the next model or human can determine what is usable and what remains unverified.

Separate remembered reasoning from facts to refresh today

The SDK memory documentation pinned before the cutoff describes preserving lessons from previous work in files, separately from conversation history. Reuse requires preserving the entire configured memory directory; a fresh empty sandbox starts with empty memory. It also explicitly recognizes that memories can become stale.

For the report, a reason such as prioritizing existing integrations because contracts are difficult to change may remain useful next week. A statement that a product is unavailable in a particular region may no longer hold. Keeping the reason, verification time, and review conditions together lets the next owner investigate change without repeating the whole explanation.

Rechecking everything reduces the benefit of memory; rechecking nothing preserves obsolete assumptions. I recommend distinguishing volatile prices, availability, and permissions from the comparison's purpose and selection rationale. Editing for brevity should preserve this distinction: the next owner needs to understand why a judgment can still be carried forward.

An uncertain send needs more than conversation history

Imagine execution stopping immediately after sending the report but before recording success. Missing success in the retained history does not establish failure. A resumed run that sends the report again could deliver two copies to the recipient.

Check destination records or an operation identifier before choosing the next action. If a mechanism can recognize retries as duplicates, verify its conditions. If neither that mechanism nor reconciliation is available, return the uncertainty to a person. Session persistence helps retain decision evidence; it does not guarantee exactly-once external actions or undo them.

The user's request or sharing scope may also change overnight. Prior permission to send one version does not automatically settle whether a changed report may be sent under changed conditions. Carrying forward the rationale is different from ignoring developments since that rationale was established.

Evaluate whether the remaining work can be completed

AWS's March 31 general-availability announcement for AgentCore Evaluations describes sampled online trace evaluation and development or CI evaluations. Session goals and tool behavior can be assessed alongside responses. These are evaluation capabilities, not task persistence or pre-action approval of every operation in production.

For report continuity, use the same completion criteria for interrupted and uninterrupted runs. Stop after source collection, after saving the table, before updating progress, and before recording the send result. Also update one source overnight. Check whether the agent preserves verified information while detecting that change.

Measure more than reconnection time. Does the resumed run avoid claiming completion with two unresolved entries, unnecessary research, obsolete tables, and duplicate sending? Include the human time required to rediscover state and repair incorrect reports when comparing the handoff burden.

This is a proposed trial, not a measured product ranking. Match models, inputs, budgets, and persistence conditions where possible, distinguishing model capability from recovery mechanisms. A detailed log cannot advance the work if the next model cannot understand the remaining questions. Capable reasoning and an actionable handoff both matter.

Design the handoff for the person who will read it

A short question does not need this entire persistence setup. A weekly report needs its format and selection reasons; development across days needs changes and verification; customer work needs commitments and actual updates. Start with one task, identify the results that should survive a stop, and decide what must be checked again the next day.

The user or business owner defines completion. Implementers check the persistence boundary for records and files. Operators decide where discrepancies and uncertain outcomes should go. One person can hold all these roles for a small task, provided the explanation does not disappear at a handoff.

Being able to describe yesterday's activity is insufficient. Today's owner should be able to adopt yesterday's usable results, refresh the necessary facts, and finish the remaining work. Preserving reasons and review conditions makes continuing work easier for a person to delegate.