2026 Comparative Analysis: Persistent Workspace and Artifact Infrastructure for AI Agents — Applied Technology Index

Executive Summary

A persistent agent workspace is a file-oriented state boundary that survives beyond one model call or compute session. It can hold repositories, documents, generated reports, installed packages, plans, images, and intermediate outputs. An artifact service stores named outputs separately from the live execution filesystem, usually with explicit scope, metadata, or versions. These are related but not interchangeable mechanisms.

This analysis compares five publicly documented approaches:

OpenAI Sandbox Agents define a portable workspace manifest, a live sandbox session, serialized session state, snapshots, mounts, and memory as separate concepts. A run can reuse a live session, resume provider state, or seed a fresh sandbox from a snapshot.
Claude Agent SDK ties each active agent to a subprocess, working directory, local transcript, and local files. Its SessionStore can mirror transcripts across hosts, but memory files and working-directory artifacts require a separate volume or object-store strategy.
Google Agent Development Kit (ADK) treats artifacts as named, versioned binary objects managed by an ArtifactService, separate from conversational session state. Artifacts can be session-scoped or user-scoped and backed by memory, Google Cloud Storage, or a custom implementation.
LangChain Deep Agents expose one virtual filesystem API over pluggable backends. Files can live in thread-scoped LangGraph state, a cross-thread store, local disk, a sandbox, or path-routed combinations of those systems.
Vercel Sandbox persists the execution filesystem by automatically snapshotting a sandbox when a session stops and restoring the latest snapshot on the next session. Manual snapshots can also create checkpoints or forks.

The principal finding is that production agents need more than “persistent files.” They need explicit answers to six questions: what is authoritative, what scope owns an object, when a write becomes durable, how a worker resumes, which state is copied or excluded, and how retention and deletion work.

The most robust design separates at least four state planes:

conversation state: messages, tool calls, approvals, and model-visible history;
workspace state: mutable directories, checked-out code, package installations, and scratch files;
artifact state: named outputs intended for retrieval, review, exchange, or publication;
business state: committed workflow steps, operation IDs, external side effects, and reconciliation status.

A filesystem snapshot can recover files but does not prove that an external API call committed. A transcript store can resume a conversation but does not preserve a generated report. An artifact object can preserve a report but not the shell environment that produced it. A durable workflow can record a step while still requiring separate storage for its files. Treating these planes as one state blob creates ambiguous recovery and deletion behavior.

Key Findings

Workspace persistence and artifact persistence solve different problems. Workspace systems preserve a mutable environment; artifact systems preserve selected named outputs. Snapshots are convenient for resume, while object-style artifacts are generally easier to version, share, retain, and govern independently.
Transcript resume does not imply workspace resume. Anthropic explicitly documents that SessionStore mirrors transcripts only. OpenAI separately models conversational sessions, sandbox sessions, snapshots, and memory. The identifier for one plane should not be assumed to address another.
Scope is a security primitive. Google ADK distinguishes session-scoped and user-scoped artifact names. Deep Agents can namespace stores by user, tenant, assistant, thread, or combinations. Claude recommends per-tenant working and configuration directories. A path without an authenticated scope is not tenant isolation.
Snapshots copy more than final deliverables. A whole-filesystem snapshot may contain source documents, package caches, command history, temporary files, generated credentials, or poisoned configuration. Snapshot creation therefore needs exclusion, scanning, encryption, provenance, and retention controls.
Mounted data may not be part of a snapshot. OpenAI documents mounts as ephemeral workspace entries that snapshot and persistence flows skip instead of copying into saved workspace contents. Restoring the workspace may therefore require remounting the same external data with current authorization.
Automatic persistence changes the default risk. Vercel Sandbox makes persistence the default and snapshots on session stop. This improves continuity but means one-off workloads can accrue storage and retain material unless the application opts out or configures expiration and snapshot-count limits.
Virtual filesystems improve portability but do not create isolation. Deep Agents can route paths across state, stores, local filesystems, and sandboxes. Its documentation warns that local filesystem and shell modes are not security boundaries. Backend selection and execution isolation remain separate decisions.
Version numbers are not provenance. Google ADK automatically versions an artifact saved under the same filename. That supports historical retrieval, but a trustworthy artifact also needs producer identity, source references, model and tool versions, policy decisions, content hash, and lineage.
Storage durability and workflow durability are independent. Persisting a file after every tool step does not make remote side effects exactly once. Systems still need idempotency keys, write-ahead operation records, result reconciliation, and explicit recovery policy.
Deletion must span every plane. Removing a session record may leave snapshots, artifacts, mounted-object versions, traces, backups, and derived publications. Retention and erasure should be designed as a graph of copies, not as one database row.

Methodology

The live ATI research index and local public research collection were checked before topic selection. Existing ATI work covered agent memory, sandbox isolation, durable execution, context compaction, caching, credential brokering, human approval, harnesses, and other adjacent infrastructure. It did not provide a dedicated comparison of mutable workspaces, selected artifacts, filesystem backends, and snapshot-based persistence.

Current public discussion was used only to identify the research question: operators were increasingly separating disposable agent compute from durable workspaces and debating snapshot, remote-filesystem, and object-store patterns. Claims in this article are grounded in primary technical documentation available on 21 August 2026.

The source set comprises OpenAI’s Sandbox Agents guide and official example repository; Anthropic’s Agent SDK hosting and session-storage documentation; Google ADK’s artifact and session documentation; LangChain’s Deep Agents backend and sandbox documentation; and Vercel’s Sandbox concepts, persistent-sandbox, and snapshot documentation.

Each approach was assessed on nine criteria:

State unit: live filesystem, snapshot, named artifact, virtual file, transcript, or provider session state.
Scope: run, conversation, thread, sandbox, session, user, tenant, assistant, or application.
Durability boundary: in-process memory, checkpoint, object write, mirrored transcript batch, automatic stop snapshot, or external mount.
Resume semantics: reconnect to live compute, hydrate provider state, restore a snapshot, reload a thread, or retrieve selected objects.
Versioning and forking: overwrite, append, automatic versions, manual checkpoints, or child environments.
Portability: whether state is coupled to one process, machine, cloud storage system, sandbox provider, or backend protocol.
Isolation: namespace controls, per-tenant directories, sandbox boundaries, mount permissions, and local-host exposure.
Lifecycle: expiration, retention count, explicit deletion, cleanup ownership, and cost implications.
Operational completeness: observability, failure behavior, concurrency, lineage, scanning, reconciliation, and recovery gaps.

This is a documented-capability and architecture comparison. No common workload, crash-injection suite, concurrent-write test, storage benchmark, malware scan, snapshot inspection, cost simulation, or deletion audit was run across all five approaches. The compared systems also occupy different layers: SDK workspace orchestration, agent hosting, artifact APIs, filesystem abstraction, and sandbox compute.

Comparative Analysis Table

Approach	Persistence model	Scope and versioning	Resume and sharing model	Best fit	Main limitation
OpenAI Sandbox Agents	Portable manifest creates a workspace; live sandbox session owns changes; serialized provider state reconnects a stopped session; snapshot seeds a fresh session; external storage can be mounted	Workspace paths are manifest-relative; live session, run state, snapshot, SDK conversational session, and memory are separate; snapshot semantics depend on the sandbox client	Resolution order favors an injected live session, then resumed `RunState`, then snapshot, then fresh creation; mounted remote storage is remounted rather than copied into snapshots	Agents that need files, shell, packages, previews, controlled mounts, provider choice, and resumable workspaces under one SDK contract	Beta APIs; durability and isolation vary by sandbox client; whole-workspace snapshots can retain sensitive or stale state; mounts are outside the saved workspace
Claude Agent SDK hosting	Subprocess writes JSONL transcripts, memory files, settings, and work artifacts to local disk; `SessionStore` mirrors transcript batches; volumes or object sync must preserve other files	Session ID addresses transcript resume; working directory and config paths require separate per-tenant scoping; no unified artifact-version model is documented	Resume can hydrate a transcript on a new worker, but working-directory files and `CLAUDE.md` memory must be restored independently; mirror errors are best-effort and non-fatal	Claude-based coding, research, and computer-like agents where a complete local tool environment is valuable	One active session maps to a subprocess and local state; transcript persistence is not workspace persistence; dual-write failure and tenant-directory isolation remain operator concerns
Google ADK ArtifactService	Named binary `Part` objects live outside session state in an artifact service; in-memory, GCS, and custom backends are available	Plain filenames default to app/user/session scope; `user:` names can span that user’s sessions; saving the same name creates a new integer version	Agents or tools save, load, list, and request versions through context APIs; object storage lets application instances share artifacts without restoring a complete runtime	Reports, images, audio, documents, and other selected outputs needing explicit retrieval and versions	Not a general POSIX workspace; cleanup is application-owned; very large objects may need direct storage links; versioning alone does not supply lineage or workflow recovery
LangChain Deep Agents backends	One file-tool surface can map to thread state, cross-thread LangGraph store, local filesystem, sandbox backends, or path-routed composites	`StateBackend` is thread-scoped; `StoreBackend` uses configurable namespaces for cross-thread durability; `CompositeBackend` routes by path prefix	Checkpointers retain state files inside a thread; stores share selected paths across threads; filesystem and sandbox backends expose real execution environments	Applications needing a portable agent-facing filesystem with explicit routing between scratch, memory, project, and sandbox storage	Backend abstraction does not guarantee host isolation, transactionality, or safe namespace construction; local shell and filesystem modes can expose the host
Vercel Sandbox persistence	Persistent sandboxes automatically snapshot filesystem and configuration when a compute session stops, then restore the latest snapshot for a new session; manual snapshots support checkpoints and forks	Sandbox spans multiple compute sessions; snapshot expiration and retained-count controls bound history; snapshots preserve filesystem and installed packages	A later SDK operation can automatically start a new session from the latest snapshot; a snapshot can seed another sandbox	Coding, testing, and long-horizon agents that benefit from microVM isolation and environment-level resume without managing each file as an object	Snapshot storage is separately billed; the filesystem is not a database or shared-data substitute; automatic persistence can retain unwanted material unless explicitly governed

Observed Profiles

OpenAI Sandbox Agents: explicit separation of workspace inputs, live state, and saved state

OpenAI’s architecture makes a useful distinction between the manifest, sandbox session, run configuration, and saved state. The manifest describes what a fresh workspace should contain: files, repositories, mounts, environment values, users, groups, and setup. It is not the complete source of truth after the agent begins changing files.

A live sandbox session owns the active filesystem, commands, ports, and provider state. The runner can receive that session directly, reconnect from serialized provider state, or create a new session from a snapshot. A snapshot does not reconnect the same live compute instance; it supplies saved workspace contents to a fresh session. That distinction affects process continuity, open sockets, temporary credentials, and whether an external service believes the old worker is still active.

The guide also separates sandbox state from SDK-managed conversational sessions and from sandbox memory artifacts. Resume and snapshots preserve workspace state; conversational sessions preserve message history; memory preserves reusable guidance generated from earlier work. Applications that need continuity should therefore store and correlate several identifiers rather than treating one “session ID” as universal.

Mount behavior is particularly important. OpenAI documents mounted remote storage as an ephemeral workspace entry: snapshot and persistence flows skip it rather than copying the remote data into the saved workspace. This avoids silently duplicating a mounted data room into a snapshot, but recovery depends on successfully recreating the mount with current credentials and permissions.

The architecture is portable because the sandbox client can target local Unix, Docker, or hosted providers. Portability does not make their guarantees equal. Operators must test whether each provider serializes state, snapshots all intended files, excludes mounts and secrets correctly, encrypts saved content, and restores permissions and metadata as expected.

Claude Agent SDK: transcripts, memory, and work files have separate durability paths

Claude Agent SDK’s hosting documentation is unusually direct about local-state coupling. Each query() spawns or uses a claude subprocess that owns a shell, a working directory, and JSONL transcript files. Three relevant classes of state—transcripts, memory/settings files, and working-directory artifacts—live on the container filesystem by default and do not survive a restart, scale-down, or move to another node without additional storage.

SessionStore addresses one part of this problem. It mirrors transcript batches to an adapter such as S3, Redis, Postgres, or a custom implementation, allowing another worker to hydrate and resume the transcript. Anthropic explicitly states that it does not mirror CLAUDE.md memory files or other working-directory artifacts; those need a mounted volume or object-store synchronization.

The transcript path is also a dual-write design rather than a transactional replacement for local storage. The subprocess writes locally first and the SDK forwards batches to the store. Documentation describes mirror writes as best effort: if a batch cannot be delivered, the SDK emits a mirror_error, drops that batch, and continues the query. Teams that require complete transcript durability must alert on these events and define whether the run should continue, pause, or become non-resumable.

Multi-tenant hosting adds another scope boundary. Anthropic recommends per-tenant working directories, per-tenant configuration directories, explicit cwd, and tenant-aware network policy. Otherwise global settings or memory files can leak one tenant’s context into another session. Persisting a shared directory without authenticated path construction would preserve the leak instead of fixing it.

This model is workable when the operator accepts that transcript storage and workspace storage are separate systems. It becomes fragile when application code restores one plane but assumes the other followed automatically.

Google ADK ArtifactService: selected, versioned objects outside conversational state

Google ADK provides the clearest artifact-specific abstraction in this comparison. An artifact is named binary data with a MIME type, stored outside the conversational session state and managed through a BaseArtifactService. Saving under the same filename creates a new integer version rather than overwriting the previous version.

The default scope is the tuple of application, user, session, and filename. A user: filename can make an artifact available to that user across sessions within the application. This makes scope visible at the API layer and supports use cases such as a session-specific report or a user-level settings file. Production systems should still derive user identity from authenticated runtime context rather than from model-selected strings.

ADK supplies in-memory and Google Cloud Storage implementations and permits custom services. The GCS implementation stores versions as distinct objects, persists across deployments, and can be shared by application instances that have the necessary IAM access. In-memory storage is appropriate for tests but is neither durable nor suitable for large collections.

The artifact service is intentionally not a complete filesystem. It works well for reports, PDFs, images, audio, and selected intermediate results. It does not preserve installed packages, process state, directory permissions, repository metadata, or an interactive shell environment. An agent that must continue editing a project needs a workspace in addition to its artifact service.

Operational responsibility remains with the application. Persistent artifacts remain until deletion or bucket lifecycle policy removes them. Very large payloads can create memory and transfer overhead. Historical versions need retention rules, and a version number should be accompanied by content hashes and lineage if the artifact is used for audit or publication.

LangChain Deep Agents: path routing across state, stores, disk, and sandboxes

Deep Agents presents a stable file-tool interface—listing, reading, writing, editing, deleting, globbing, and searching—over multiple backends. The default StateBackend stores virtual files in LangGraph state for the current thread. With a checkpointer, those files persist across turns in that thread but are not shared across threads.

StoreBackend moves files into a LangGraph store and uses a namespace factory to control cross-thread scope. The namespace can include user, tenant, assistant, thread, or other authenticated runtime identity. This supports durable shared memory or policy files, but a constant or model-controlled namespace can accidentally create a global cross-tenant filesystem.

FilesystemBackend reads and writes real files under a root directory, while sandbox backends can add isolated execution. CompositeBackend routes virtual paths to different backends. A practical arrangement can keep /workspace/ thread-scoped, route /memories/ to a cross-thread store, and map /project/ to a real or sandbox filesystem.

This routing is powerful because it turns data classification into path architecture. It also creates policy obligations: each route needs a scope, durability level, quota, retention rule, and tool-access rule. Deep Agents automatically writes internal data such as offloaded tool results and conversation history to the default backend; its documentation recommends composites when project files should not be mixed with internal agent data on real disk.

The most important caveat is security. A virtual root is not a kernel boundary. Deep Agents warns that local filesystem and local shell configurations can expose the host, and that virtual mode does not provide security when shell commands can access arbitrary paths. Use a sandbox backend for untrusted execution rather than assuming path normalization is isolation.

Vercel Sandbox: environment-level continuity through automatic snapshots

Vercel Sandbox uses a two-level lifecycle. A sandbox is the persistent identity and configuration; a session is one running Firecracker microVM instance inside that sandbox. When a persistent sandbox session stops or times out, the SDK automatically snapshots its filesystem. A later operation starts a fresh session from the latest snapshot and reapplies the saved configuration.

Persistence is the default. This minimizes application code for agents that install dependencies, modify repositories, and resume after idle periods. It also means operators must deliberately select non-persistent sandboxes for one-off or sensitive jobs that should discard their files.

Manual snapshots can checkpoint a running workspace or seed a child sandbox from known state. This supports setup reuse, branching experiments, and review-before-continue workflows. The snapshot captures filesystem state and installed packages, not a database transaction spanning external tools. Forking the filesystem therefore must not duplicate externally committed identities, leases, credentials, or idempotency tokens without review.

Vercel exposes snapshot expiration and a keepLastSnapshots policy. Current documentation states a 30-day default expiration measured from last use for automatic snapshots, with the timer reset when used, and permits retaining a bounded number of recent snapshots. Storage is billed separately from compute. These controls should be configured by workload class rather than left as accidental defaults.

Vercel also warns that its persistent filesystem is not a substitute for a database or object store for large or shared datasets. Use snapshots for environment continuity; use external durable services for authoritative shared data, searchable artifact catalogs, and records requiring independent transactions or retention policy.

State-Plane Design Analysis

Conversation state versus workspace state

Conversation state answers, “What did the agent and tools say?” Workspace state answers, “What files and environment does the agent have now?” The two can diverge after any partial failure.

If the transcript records that a report was generated but the workspace write was not snapshotted, resume will describe a file that does not exist. If the workspace contains a report but the last transcript batch was lost, the agent may regenerate or overwrite it. Recovery logic should verify both planes and record a stable artifact identifier when a deliverable becomes authoritative.

Workspace state versus artifact state

A workspace is mutable and optimized for continued work. An artifact is selected and optimized for retrieval or exchange. Publishing directly from arbitrary workspace paths makes it difficult to distinguish temporary files from approved deliverables.

A safer promotion flow is:

write and test inside the workspace;
validate the intended output;
compute a content hash and collect provenance;
copy it into an artifact store under an authenticated scope;
record the artifact version in durable workflow state;
publish or distribute only that immutable version.

This makes snapshots useful for resuming production work without making every hidden workspace file a public or permanent record.

Snapshot state versus external side effects

A snapshot captures local state at a point in time. It cannot atomically include an email provider, payment processor, source-control host, or cloud API. An agent may complete a remote side effect and crash before the local snapshot records the result, or snapshot an “about to execute” flag and then repeat the action after resume.

Consequential tools need a stable operation ID written before execution, idempotency support where available, and a reconciliation call after uncertain failures. Snapshot restore should resume a recovery protocol, not blindly repeat the last local command.

Tenant scope versus path scope

Path prefixes and session IDs are labels, not authenticated authorization. The host must derive tenant and user scope from trusted identity, bind it to storage namespaces and encryption keys, and prevent agent-controlled paths from escaping that scope.

Apply the same boundary to snapshots, artifact versions, mounted storage, indexes, traces, and deletion jobs. Cross-session user artifacts are useful only when the system can prove which user is requesting them.

Persistence versus minimization

Persisting everything maximizes resume convenience and incident evidence but increases exposure, storage cost, and deletion complexity. Persisting too little makes long-running work unreliable.

Use data classes rather than one retention default:

discard scratch files at run completion;
retain resumable workspace snapshots for a bounded idle window;
retain approved artifacts according to product or contractual policy;
retain audit metadata longer than sensitive content where possible;
keep credentials and mounted secrets out of snapshots entirely;
record derived-copy locations so erasure can propagate.

Selection Framework

Choose an SDK-managed workspace and snapshot model when applications need a portable harness contract over multiple sandbox providers and want the runner to coordinate manifest creation, live sessions, resume, and snapshots. Verify provider-specific save, restore, exclusion, encryption, and failure semantics before relying on portability.

Choose a subprocess-local workspace with separate transcript and volume storage when a preassembled coding or research environment is the priority and the team can operate sticky or hydrated containers. Treat transcript mirroring, memory-file persistence, and artifact synchronization as three explicit deployment components.

Choose an artifact service when the primary need is to preserve selected reports, media, or binary outputs with explicit names and versions. Pair it with a workspace for interactive file operations and with workflow state for approvals and external transactions.

Choose a virtual filesystem backend layer when agents should use one file interface while applications route scratch, thread, user, project, and policy paths to different stores. Require trusted namespace factories and use real sandbox isolation for shell execution.

Choose automatic environment snapshots when installing tools and reconstructing workspaces dominates startup time and users expect an environment to resume after compute stops. Opt out for disposable work, bound snapshot history, and move authoritative shared data into databases or object storage.

Before production selection, test every candidate against the same acceptance suite:

crash during a file write and inspect the recovered file;
crash after artifact creation but before transcript persistence;
resume on a different worker with no original local disk;
restore with an external mount unavailable or authorization revoked;
fork a snapshot and verify tenant, credential, and external-operation isolation;
perform concurrent writes to the same filename or workspace;
scan a snapshot for secrets, temporary inputs, and poisoned configuration;
delete a user and trace removal across sessions, artifacts, snapshots, mounts, indexes, traces, and backups;
expire old workspace state while retaining approved deliverables;
reconstruct one published artifact from its recorded producer, inputs, content hash, policy decision, and storage version.

The correct architecture is usually hybrid: ephemeral compute, a bounded resumable workspace, selected immutable artifacts, and a durable business-state ledger. The interfaces between those systems matter more than whether one vendor labels all of them “memory” or “session state.”

Limitations

This analysis reflects public documentation available on 21 August 2026. OpenAI marks Sandbox Agents beta, and APIs, provider integrations, snapshot behavior, defaults, and examples may change. LangChain Deep Agents, Google ADK, Claude Agent SDK, and Vercel Sandbox were also evolving rapidly.

No equivalent workload was executed across the five approaches. The article does not measure snapshot latency, restore time, storage throughput, maximum file count, concurrent-write correctness, incremental-copy efficiency, object consistency, cross-region replication, encryption performance, cost, or developer productivity.

The approaches are not strict substitutes. OpenAI supplies agent-to-sandbox orchestration; Anthropic documents a subprocess hosting model; Google ADK supplies an artifact API; Deep Agents supplies a filesystem abstraction; Vercel supplies isolated compute with environment persistence. The comparison is intended to clarify architecture boundaries rather than rank unlike products on one score.

Public documentation does not prove sandbox escape resistance, tenant isolation, deletion completeness, backup recovery, regulatory compliance, artifact authenticity, or protection from malicious files. Those properties depend on application code, identity systems, cloud configuration, storage policies, tool implementations, and operational testing.

Snapshot and artifact pricing was not normalized. Vercel documents separately billed snapshot storage, while costs for object storage, egress, requests, databases, hosted sandbox sessions, and custom backends vary by provider, region, retention, and workload.

Google ADK behavior can differ by SDK language and artifact-service implementation. OpenAI snapshot and resume support can differ by sandbox client. Claude SessionStore adapter reliability depends on the implementation and its surrounding infrastructure. Deep Agents durability depends on the configured checkpointer or store. These abstractions should not be treated as stronger than their selected backends.

This article does not provide a legal determination about data residency, privacy rights, retention, discovery obligations, open-source licenses, or service terms. Organizations handling regulated or customer-controlled data should review those obligations separately.