Giving AI agents file access to large S3, GCS and R2 datasets should not require copying those datasets first. A better way is to mount the bucket as a POSIX file system inside the agent’s environment. File tools then work on live data, while persistent, isolated workspaces keep a lost session or a bad command from turning into a rebuild or a shared disaster.
Why AI agents default to file tools even when data lives in object storage
AI agents find their way through data much like Unix processes. They reach for paths, directories, and tools such as grep, find, and cat. Object storage instead speaks GET, PUT, and DELETE against named objects, without real directories, atomic rename, or in-place edits. The tools and the data speak different languages.
AWS engineering teams using Kiro and Claude Code encountered the practical cost of that mismatch. Their agents defaulted to local file tools while the data lived in S3, so downloading files became the workaround. That worked until the context window compacted and the agent lost its record of what it had downloaded. Starting over was an architectural failure.
Why the previous generation of fixes — FUSE drivers and SDK wrappers — did not solve it
AWS’s Mountpoint, Google’s gcsfuse adapter, and Microsoft’s blobfuse2 exposed object storage through file interfaces, but the available approaches either added metadata that disrupted the object API view or refused unsupported file operations. Andy Warfield of AWS put the underlying constraint plainly. “S3 is not a file system, and it doesn't have file semantics on a whole bunch of fronts.”
SDK wrappers such as s3fs, boto3, and fsspec moved the translation into application code. They simulated file access through object API calls, with slower operations, no true locking or atomic appends, and changes required in applications touching the data. Copying data into a separate file system avoided some compatibility problems but introduced two copies, two security perimeters, and a growing sync gap. The agent’s tools still needed to account for these workarounds.
What native bucket mounting actually means and how S3 Files works
Amazon S3 Files, launched April 7, 2026, adds a native file system layer to the way the data is stored. Built on Amazon EFS infrastructure as a caching layer in front of S3, it keeps the bucket as the system of record. Existing buckets need no migration. Data remains accessible through both file paths and S3 APIs, so file-based applications do not displace existing object-based consumers.
The service uses a “stage and commit” model in which changes accumulate on the file system side and return to S3 as whole objects. That preserves the guarantees existing S3 applications depend on while supporting file operations on the other side. Both interfaces remain live against the same data, though that does not make every write instantly visible everywhere. For the agent, the translation disappears from tool calling. Thousands of compute resources can connect to the same file system, so multi-agent pipelines can use one dataset without making their own working copies.
How OpenAI Agents SDK v2 made workspace mounting a first-class SDK concern
OpenAI Agents SDK v2, released April 15, 2026, brought this way of mounting data into the framework layer. Its harness manages workspace mounting from local files, S3, GCS, Azure Blob, and Cloudflare R2 without copying cloud datasets to the orchestration host. Mounting is now an explicit SDK concern.
Before v2, teams building coding workflows on v1 had to handle rolling context windows, safe shell execution, file editing without corruption, and restoring the right file system state before each turn. Teams solved these problems in different ways, which made their agents hard to move between environments. Standardizing workspace mounting removes one source of that variation across clouds. It gives the framework a common way to describe the workspace an agent needs.
What agents gain when the bucket is mounted — shared state, persistent memory, and no session resets
When context compacts, a mounted, persistent workspace avoids the download-ledger failure. The agent returns to the same files and working state instead of rebuilding its view of the dataset from a vanished record of transfers. Memory can live in files as well as in the conversation. Context loss need not become workspace loss.
Notes files, subdirectories, and shared project directories let one agent read another’s output without presigned URLs, polling loops, or custom transfer glue. The same file interface lets applications use grep, find, awk, and diff against live data without code changes, while ML data preparation avoids a separate staging exercise. These are ordinary file workflows applied to cloud datasets.
The concurrency and consistency limits that mounting does not solve
A shared mount is not a coordination protocol. Two agents that write to the same file can still clash, even when both have a path they can use. S3 does not provide the close-to-open consistency model for concurrent writers that a traditional file system does.
Read-heavy workloads and pipelines whose agents write to distinct files or subdirectories fit mounting cleanly, while concurrent updates to the same file require an explicit coordination layer. That layer sets who can read and write and when, since a shared directory alone cannot make agents agree.
Why each agent needs its own isolated environment with the bucket mounted inside it
Write conflicts are only one risk of shared access. An agent that has broad write permission on a production bucket can damage data that other agents and services use. A mount alone does not contain that blast radius. The stronger architecture places the mount inside an isolated execution environment and scopes the agent’s writes, so access to real data does not imply permission to damage everything around it.
A disposable sandbox creates a different failure. If each session rebuilds it, the installed packages, partial results, and working state are lost even though the source dataset is still safe in its bucket. Persistence must therefore accompany isolation. Firecracker microVMs provide dedicated kernels per workload, gVisor provides a user-space kernel, and hardened containers offer another boundary, though containers are suitable only for trusted code. For agent-generated code, microVMs provide the strongest isolation of these approaches.
Archil combines a Firecracker microVM with a persistent disk so packages and files survive stops and restarts. That disk can mount an existing S3, GCS, R2, Azure Blob, or S3-compatible bucket as a POSIX file system without migration or a separate dataset copy. Like S3 Files, this architecture keeps the bucket as the system of record while exposing file semantics, including atomic rename, mmap, and fsync. Writes are durable when fsync returns and reach the backing bucket in the background. Revoking access leaves the data in the customer’s account.
The disk also remains accessible from sandboxes, serverless execution, and the S3 API, allowing other parts of the stack to use the same data. Isolation need not strand the workspace. Outbound traffic on the Free plan follows a managed allowlist of package registries, git hosts, and model APIs, while Developer plans and above can set their own firewall rules and broker credentials to keep secrets out of the sandbox.
Forking the agent’s environment so parallel attempts and rollbacks are routine
Teams can try different strategies against separate branches, select the useful result, and discard a failed attempt without touching the base data. A checkpoint taken before a destructive operation gives teams a point they can go back to. Experimentation no longer requires making a full duplicate first.
For Archil disks, a checkpoint takes about 15 ms and a branch about 35 ms regardless of disk size, using copy-on-write branches billed on active data. This is a disk operation, with the sandbox’s CPU and memory state excluded from the snapshot. The distinction limits what a restore promises. The 2026 arXiv paper When Can Agents Safely Checkpoint, Fork, Restore, and Merge? derives formal conditions under which these execution edits are exactly and decidably safe. Teams should therefore treat checkpoint discipline as an unsettled design problem whose safety conditions apply even to fast forks.
Applying the same architecture to per-tenant storage in multi-tenant agent products
Tenant data also appears in memory, caches, tool credentials, and agent working state, so database isolation alone cannot protect the whole workflow. Every layer needs a tenant boundary. If a shared bucket keeps tenants apart only through application path logic, one bug can cross that boundary, while a workspace-per-tenant model ties every file operation to a specific workspace identifier.
In a disk-per-tenant design, supported by Archil, each tenant’s existing bucket mounts inside a Firecracker sandbox scoped to that tenant. Separation then exists at both the storage layer and in application code. Branching can give a tenant an isolated working copy of its data without changing production (for disks synced to the tenant’s own bucket, on Enterprise). Billing on active data also avoids pre-provisioning storage capacity for each of thousands of tenants with different dataset sizes. S3, R2, GCS, and Azure Blob do not themselves let agents provision scoped storage or provide a production fork primitive, so these capabilities require an additional architectural layer.
Choosing the right mounting approach for where your data already lives
The practical decision starts with the existing cloud stack and the required execution boundary. For data in S3 with AWS-native compute, S3 Files is the most direct path, offering full POSIX semantics, existing IAM controls, and no migration. It was generally available in 34 regions as of April 7, 2026. Its gaps are distinct from file access. Agents cannot get scoped credentials on their own, and the storage layer has no branch primitive.
For GCS, the XML API provides partial S3 compatibility, so most teams treat adoption as a migration. Its built-in way to access files is gcsfuse, which has the adapter limits described earlier. R2 presents a different trade-off. Its strong S3 compatibility and zero-egress cost make it easy to mount through S3-compatible tools, but it has no branch primitive and agents cannot set up scoped storage on their own.
When the requirement includes agent-generated code, multi-agent pipelines, or tenant isolation, the mounting layer belongs inside a real sandbox. Archil is an option for that combination, mounting S3, GCS, R2, and Azure Blob through the same POSIX interface inside Firecracker microVMs while retaining the customer’s bucket as the source of truth. Its serverless execution and sandboxes share a Firecracker runtime that has run production workloads since 2025, and persistent sandboxes have been generally available since September 2026. That fit still has limits. Teams needing S3 versioning or Object Lock at the API layer, or branching and checkpointing on bring-your-own-bucket disks below the Enterprise tier, must evaluate those gaps explicitly.
The final test is what the agent sees. Models are trained heavily on bash and file tools, so the setup should give them a real POSIX file system. The storage can stay in its bucket. The agent should be able to get on with the files.