To persist AI agent files across sessions, store the actual output files outside the disposable run, record which version was accepted, and tell the next session where to start. Test that handoff by opening the workspace from a fresh process.

Consider a small agency producing a weekly market report. The agent reads source PDFs, updates a metrics CSV, and writes a report. Next week’s job needs those accepted files and a short account of unfinished work. A saved chat alone cannot establish which report the operator approved.

Separate the files from the running process

Choose a durable location whose lifetime matches the project: an existing local directory for one machine, or a persistent volume or object store for remote runs. Check exactly what survives stopping, deleting, and recreating your runtime. Treat those as separate events.

For example, Daytona documents volumes whose contents persist independently of a sandbox and can be shared between sandboxes. That solves a storage-lifetime problem. Your application still needs to decide which returned report is ready for the next job.

Daytona volume persistence

Keep execution state and useful artifacts connected

An execution checkpoint answers where a workflow stopped. A report file is an artifact people can open. LangGraph distinguishes thread-scoped checkpoints from stores for application-defined data across threads. Choose the durable backend your workflow needs and record references to artifact versions alongside execution state.

If a checkpoint says “report complete” but its file lived only in a deleted temporary directory, the next run cannot recover the report from that status. Verify both the recorded state and the bytes it references.

LangGraph persistence concepts

Make the next starting point readable

Here is a small illustrative folder layout. The handoff file is ordinary project documentation, not a Folderbase protocol record. Keep credentials and unrelated client files outside the agent’s selected workspace.

Illustrative project layout
client-research/
  sources/market-brief.pdf
  data/metrics.csv
  reports/weekly-report.md
  handoff.md

run-018-output/
  weekly-report.md
  source-notes.md

Record acceptance and unfinished work

Use a short handoff that identifies the accepted result and its inputs. When the storage system provides version IDs, use them. In a simpler setup, name an immutable snapshot and record content hashes. A filename such as final-report.md is useful navigation; by itself it does not identify stable content.

Illustrative handoff.md
# Weekly research handoff

Accepted snapshot: research-017
Main result: reports/weekly-report.md
Inputs: sources/market-brief.pdf, data/metrics.csv
Accepted by: workspace owner
Next task: verify the unresolved source in section 3
New drafts: write to the run output directory
Source updates: return for review before acceptance

Return a proposal before changing the accepted result

Let the agent produce its next report in a working copy or separate output directory. Review the changed files, verify their source references, and accept the useful result. Record the new accepted snapshot only after the required files are present and checked.

If someone edited the accepted report while the agent worked, compare against the original base before accepting. Preserve the proposal so the operator can resolve the difference. Make retries reuse the same result identity instead of creating duplicate accepted versions.

How to review AI agent file changes

Test the second session

A successful upload is one checkpoint in the test. Finish the test with a new process that has no in-memory context from the first run.

  • Close the original agent session and open a fresh one.
  • Resolve the accepted snapshot and read the report from durable storage.
  • Check the referenced inputs and confirm they match the recorded version.
  • Ask the agent to continue the unfinished task using that report.
  • Recover the previous accepted result after an intentionally bad update.
  • Measure setup, review, and recovery effort against your existing workflow.

Where Folderbase fits today

Folderbase Core adds an open, local workspace layer to ordinary files. Its quickstart covers inspection, previewed initialization, validation, and file listing without an account. Start there to evaluate the format.

As checked on September 15, 2026, Core 0.7.2 has an open issue applying Change Sets that add files. Cloud continuity remains a pilot goal. Do not use this article as a claim that the complete Folderbase remote workflow is released.

Try the local Folderbase quickstart Core new-file apply issue #78