Archil and Amazon S3 Files close the gap between object storage and the file systems AI agents expect, but at different layers. Archil fits agent workspaces that need isolated compute, durable environments, and branching. S3 Files fits AWS-native teams that need to work with the S3 data they already have through files.
Why AI agents struggle when compute and storage live at different layers
AI agents work with file paths, directory traversal, and standard POSIX tools, the interfaces that feature heavily in their training. But large amounts of enterprise data live in object storage, where tools use API calls to reach the data. The usual bridge is a staging pipeline that copies data out of S3, processes it locally, and copies the results back. That bridge duplicates storage, adds latency, and leaves several copies competing to be the truth. A file should not need a travel itinerary before an agent can read it.
The same mismatch also affects session state. When an agent’s files live in a scratch copy, the next session starts by rebuilding them. With several agents writing shared state, stale copies and brittle sync scripts become a coordination problem. Durable access must therefore connect what an agent sees with what the next session or pipeline step can use. The two products address that same problem at different layers of the stack.
What Amazon S3 Files actually does and where it fits
Amazon S3 Files lets an existing S3 bucket work as an NFS file system without moving the data. AWS’s announcement (April 2026) describes a shared file system built using Amazon EFS that connects AWS compute directly to S3 data. Its supported compute includes EC2, EKS, ECS, Fargate, Batch, and Lambda. Applications get real NFS semantics rather than a FUSE adapter translating object API calls into an imitation of file behavior. This is a storage-layer change.
That change removes specific pieces of plumbing, including the S3-to-EFS staging pipeline, the Lambda /tmp download pattern, and scripts that synchronize two storage systems. The synchronization model is “stage and commit,” in which changes accumulate on the file system side and are exported to S3 after 60 seconds without writes, as whole objects. Both the file system API and the object API can still read and write the same data. But readers that use the S3 API have to wait to see file system writes.
Workspace access is handled through access points. AWS’s S3 Files documentation describes POSIX user identity and root directory enforcement, which confine clients to a directory and its subdirectories. Together with IAM and POSIX permissions, these controls divide the namespace into application-specific entry points. The service is scoped to AWS compute and S3 data, excluding GCS or R2 buckets. Its job is to make existing data usable through files while leaving execution to the surrounding AWS stack.
What Archil does and how the architecture differs
Archil’s foundation rests on the premise that the file system is the right interface between AI and data. Rather than stopping at that interface, it pairs a durable, forkable file system with Firecracker microVM sandboxes. Each sandbox has its own kernel and persistent disk, so it keeps files and installed packages through stops and restarts without having to rebuild the environment. Compute and storage therefore travel together as a workspace.
A disk can be Archil-managed or mount an existing S3, GCS, R2, Azure Blob, or S3-compatible bucket as a POSIX file system without migration or a separate staging pipeline. Every disk is also reachable through an S3-compatible API that is strongly consistent with its file system view. Because Archil disks work from any compute, this shared view is not tied to AWS infrastructure. The backing bucket is a separate timing boundary, however. Writes are durable once fsync returns, then copy to that bucket in the background, where visibility can lag by tens of seconds or more.
That lag matters for readers outside the workspace, and Archil has archil invalidate-cache for readers that need to see the latest files. Strong consistency through Archil’s own API must not be confused with immediate visibility through the backing bucket’s API. Product maturity also differs by execution mode. Serverless execution, which runs one command in a fresh microVM against a disk, has been available since April 2026. Persistent sandboxes are generally available and run on Firecracker infrastructure that has carried production load for over a year.
Isolation: what each product does for agent-generated code
A file system can keep an agent’s work without containing the code that produced it. S3 Files provides no compute isolation of its own, because it mounts into the AWS compute environment the caller already runs. It inherits that environment’s isolation properties and IAM identity. This leaves the execution boundary and credential handling with the surrounding compute configuration. A storage mount is not a sandbox, just as a filing cabinet is not a locked laboratory.
With Archil, the execution boundary is a Firecracker microVM with its own hardware-virtualized guest kernel. Containers share a host kernel, so a kernel exploit from agent-generated code can reach the host. A microVM instead places a hardware virtualization boundary between guest and host. That distinction explains why microVMs have become a common default for hosted agent sandboxes. It identifies where isolation is enforced without treating any boundary as a promise that code can do no harm.
Network access adds another boundary. On the Developer plan, Archil limits outbound traffic to an Archil-managed allowlist of package registries, git hosts, and model APIs. This is not a user-configured default-deny firewall, while Team plans can set their own firewall rules. On Team plans and above, Archil can also broker credentials at the network boundary so secrets do not enter the sandbox as ambient IAM roles or baked-in API keys. Archil pairs these controls with execution, whereas S3 Files leaves them to the caller’s AWS compute design.
Persistence and shared state across agent sessions
Both products let useful state outlive the session that created it. S3 Files keeps that state on the file system behind the mounted bucket, where agents can use shared directories, notes files, and project directories. Several agents can mount the same bucket at the same time, so those with access can use the shared state. This replaces the need to reconstruct a private download cache after a session ends. It does not, by itself, settle which agent should write which file.
Archil keeps state on a disk that survives sandbox stops and restarts, and the disk can be mounted on many machines in shared or conditional mode. Concurrent writers should coordinate through explicit ownership. Its flock and fcntl locks behave normally within one client but are not visible to other clients. Concurrent O_APPEND across clients can therefore lose writes.
Readers also need to account for freshness. A reader already running elsewhere may have to wait to see a new file unless it runs archil invalidate-cache, and pipelines that read the backing bucket directly must allow time for asynchronous propagation. This is separate from whether a write is durable.
Branching and parallel agent attempts
S3 Files lets agents work in parallel on a mounted bucket and keep their work in order through ordinary file system conventions such as subdirectories. It does not offer native branching or checkpointing of workspace state. Separate paths can keep attempts apart, but they are not the same operation as forking a disk from a known checkpoint. The distinction matters when the workflow is to try several approaches and keep the best result.
Archil disks can checkpoint and branch quickly regardless of disk size. The roughly 90 ms checkpoint-and-branch figure applies to Archil-managed disks, and the operation is limited to disk state. One checkpoint can fan out into competing branches, and the workflow keeps using whichever branch wins. That supports parallel hypothesis testing, rollback after failed runs, and audit trails of workspace state.
There is an important plan boundary here. Checkpoints and branching for bring-your-own-bucket disks are Enterprise-only. That is the configuration most directly comparable to an existing-bucket S3 Files deployment, so the managed-disk figure cannot stand in for a universally available feature. Branching is a strong reason to choose Archil when the chosen disk configuration and plan include it.
Multi-tenant agent products and per-workspace isolation at scale
S3 Files access points support large numbers of independent workspaces within a shared file system. They can enforce a POSIX user identity and confine each client to a root directory. The underlying file system remains shared, with workspace separation enforced through access points, IAM, and POSIX permissions. This is a policy-governed storage model whose isolation depends on correct configuration.
Archil places the tenant boundary at a different layer. Each sandbox is a Firecracker microVM with its own kernel, while per-tenant disks are independent. Tenant separation therefore includes a hypervisor boundary rather than relying only on policies inside a shared file system. Storage is elastic and billed on active data rather than a provisioned size, with colder data billed at a lower archive rate. This matters when workspace sizes vary unpredictably and capacity planning otherwise becomes a guessing game with an invoice.
S3 Files covers the multi-tenant storage case for AWS teams satisfied with IAM-governed, policy-level separation and no additional vendor. Archil fits products that require hypervisor-level isolation per tenant or access beyond AWS. Once the required boundary is clear, the choice becomes much less about product labels and much more about what the team would otherwise have to build.
Where S3 Files fits better and where Archil fits better
Archil is the stronger fit when the unit of work is an isolated agent environment. Choose it when agent-generated code needs its own guest kernel, files and installed packages must survive restarts, and checkpointing or parallel branches are core workflows. For bring-your-own-bucket branching, that recommendation means Enterprise. On Team plans and above, credentials can be brokered outside the guest, which keeps secrets out of the persistent environment. Archil also fits teams whose data spans GCS, R2, Azure Blob, and S3, or whose compute is not AWS-exclusive.
S3 Files fits better when compute already runs on AWS and the team needs an AWS-native, IAM-governed file interface to S3. It also fits workloads that require NFS cross-client locks, because its EFS-based model supports them while Archil’s advisory locks are per-client. If S3 versioning is already the desired history mechanism, S3 Files works with that choice and requires versioning to be enabled. This is the direct path when the team already has suitable execution isolation and does not want another vendor.
S3 Files is also worth weighing for write-heavy workloads with large sequential or random writes. Archil’s own benchmark reports EFS ahead on large sequential and random write workloads, providing indirect context for S3 Files. Choose S3 Files to give AWS compute a file view of S3, and choose Archil when isolated execution and durable, forkable storage need to form one agent workspace.