Persistent agent workspaces need a recovery policy

Keeping an agent's working directory between sessions can save the next session from rebuilding its environment. It can also preserve the incorrect dependency, temporary credential or half-finished migration left by the previous session. Persistence changes what a team must manage. A retained workspace should have an explicit recovery policy before it becomes the default place for autonomous work.

The historical starting point is Fly.io's 9 January 2026 Sprites announcement, which argued for computers that keep state across agent sessions. In his same-day account, Simon Willison described persistent filesystems and disk checkpoints. He also disclosed Fly sponsorship. These were descriptions of a particular product at launch. They establish neither a universal sandbox guarantee nor the current behaviour of every service sold under that label.

Retention creates an operational choice

A clean environment makes an incomplete setup procedure visible. If a task works only because a package was installed manually yesterday, recreating the environment exposes the dependency. A persistent environment can conceal that omission because yesterday's installation still exists. The immediate convenience is real, but the team should distinguish saved work from undocumented prerequisites.

The useful boundary is between state that belongs to the task and state that merely happened during it. Source changes, prepared test data and expensive intermediate output might deserve retention. Accidental configuration changes deserve investigation. A retained directory does not classify those files for you. Someone needs to decide what can be reused and what should be rebuilt.

That decision also affects handover. Another developer should be able to understand why the workspace is in its present condition. A record of accepted changes and an environment definition can serve that purpose better than a long conversation transcript. The transcript may explain intent, but it does not necessarily describe every package or file that a command changed.

Choose a checkpoint by what it represents

A checkpoint is useful when its meaning is clear. A state saved before a risky local edit gives the team a known point to compare against. A checkpoint taken after an unexamined failure may faithfully preserve the failure. Automatic creation can increase the number of recovery points without making any particular point trustworthy.

For this reason, a recovery policy should name the acceptance conditions for a checkpoint. The conditions could include a known source revision and the result of the relevant checks. They should also say which work would be lost on restoration. This is a proposed operating discipline, rather than a claim that the January product enforced it.

Filesystem persistence must be distinguished from process continuity. A saved file does not establish that a server, open connection or background task resumes in the same state. Before depending on recovery, the team should identify what the chosen checkpoint actually captures. Application-level consistency may require a separate plan even when disk state can be restored.

Willison's launch account describes checkpoint and restore capabilities, but the architectural question extends beyond that feature. Restoring a local workspace cannot reverse an email already sent or a change accepted by an external API. The remote service has its own state and permissions. Recovery therefore needs a record of external effects, with a separate decision about compensation or human intervention.

Consider the planning consequence without assuming a particular incident occurred. If an agent can edit local files and submit a remote update, those operations cross two recovery boundaries. A disk checkpoint might address the first. The second needs an application-specific response. Calling both operations part of one task does not make their rollback atomic.

Old secrets can return with old state

A credential written to disk may be retained with the workspace. Restoring an older state may bring back a credential file that someone later removed. Whether that credential still works depends on the issuing service. Deleting a local copy and revoking remote authority solve different problems.

A sensible policy should therefore specify how credentials reach the environment, which permissions they receive and how access ends. It should address retained copies as well as the current working tree. This is especially important when a workspace changes owners or tasks. A new session should not inherit authority merely because the filesystem survived.

The same caution applies to logs and test data. Their presence can help explain a failure, but keeping them indefinitely may exceed the purpose for which they were collected. Teams should decide retention separately from convenience. A checkpoint is a storage mechanism; it cannot determine which information the organisation is entitled to keep.

Disposable environments remain a strong alternative

The strongest argument against persistence is reproducibility. For short, isolated jobs with a well-defined input, rebuilding an environment can be simpler than examining accumulated changes. It makes dependencies explicit and reduces the amount of old state carried into the next run. Discarding the environment also provides a clear local ending to the task.

That alternative has costs when setup is substantial or work genuinely spans sessions. Rebuilding may repeat downloads or preparation that a retained workspace could avoid. The right comparison is the total work required to reach a trustworthy starting point. Neither persistence nor disposal wins that comparison for every workload.

A mixed policy can be reasonable: retain work that is expensive to recreate while keeping a reproducible baseline for checking the result. The baseline should remain usable without undocumented help from the persistent workspace. Otherwise the supposed independent check inherits the same hidden assumptions.

For a custom software system that includes agents, decide these boundaries alongside the agent's permissions. Name the state worth preserving, the checkpoint that counts as acceptable and the external effects that restoration cannot undo. The January launch made persistence easier to discuss as a product feature. Its value in a particular system still depends on whether the next session starts from useful work or from a saved mistake.