Agent storage has to support two different jobs: giving agents a place to work and preserving a record of what they produce. Archil and Cloudflare Artifacts approach those jobs from opposite directions.
Archil provides a persistent, shared POSIX filesystem for agents working directly against data over time. Cloudflare Artifacts uses Git-compatible repositories to preserve versioned snapshots of agent outputs. Artifacts can be useful as a record, but Archil is designed to be the workspace where the work actually happens.
Where Cloudflare Artifacts Fits
Cloudflare Artifacts is most useful as a versioned ledger for code, configuration, and structured text. Each task can work from an isolated repository, commit its output, and retain diffs, attribution, and rollback history.
ArtifactFS gives those repositories a filesystem interface through ArtifactFS, a FUSE driver Cloudflare publishes on GitHub. It uses a blobless clone and retrieves file contents on demand, reducing the startup cost of cloning a large repository in full. That makes Git-backed snapshots more practical inside short-lived agent sandboxes.
But the filesystem interface does not turn Artifacts into a persistent shared workspace. Uncommitted working state disappears with the sandbox, uncached reads can block while files hydrate, and Git remains the coordination layer. Artifacts is also in open beta, with hard limits that shape what it can hold: 1 GB of storage per repository (for repos created since September 29, 2026), 64 MiB per push, and no support for Git protocol v2 pushes. It is well suited to preserving outputs, but less suited to agents that continuously work against shared or data-intensive state.
What is Archil Built for?
The problem Archil is solving is distinct from Artifacts but starts from the same place: existing infrastructure wasn't designed for what agents actually need.
Here's the concrete pain. AI and analytics teams store data in object storage (S3, GCS, R2, Azure Blob) because it's cheap and it scales. That part works. The problem is that agents can't actually work inside object storage without POSIX semantics. There's no directory concept, no POSIX semantics, no locking. So before an agent can touch that data, something has to move it somewhere the agent can operate. That movement step is slow, expensive, and immediately stale the moment the source data changes. Think of it as being forced to photocopy every book in a library before you're allowed to read any of them.
Archil removes that step. Point it at an existing bucket and it mounts as a real POSIX directory. No migration. No ETL. No code changes. Data in Archil's durable, multi-Availability-Zone cache is served in under a millisecond; on a miss, Archil fetches it from the bucket (for Amazon S3, typically 10 to 30 ms) and caches it. A write is durable once fsync returns, committed to Archil's replicated storage layer, and then synchronizes asynchronously back to the bucket, where it lands as an ordinary object you can read with any S3 tool.
Archil supports the POSIX features tools rely on: random writes and appends, atomic renames (including directories), flock and fcntl locks, fsync, hard links, symbolic links, file modes and ownership, and extended attributes. Software written for a local disk generally runs against it unchanged.
Where this gets specifically useful for agents:
- Multiple agents can mount the same disk at the same time. Writers are coordinated with Archil's checkout and checkin ownership model, or in conditional mode, where several clients can write and your application coordinates them.
- Persistent context across sessions. An agent closes, comes back later, and the filesystem is right where it left it.
- Agents can run a command directly against a disk with serverless execution (disk.exec), without keeping a sandbox running.
Archil undergoes ongoing SOC 2 Type II audits and signs Business Associate Agreements for HIPAA workloads on its Enterprise plan. For teams that cannot let data leave their own cloud, BYOC deployments run Archil inside their own AWS, Google Cloud or Azure account. Archil's performance figures come from its own benchmarks, so test them against your workload.
Archil is a persistent cloud workbench. The agent's local disk, except it lives in the cloud, scales to petabytes, and multiple agents can share it simultaneously.
Why frontier models reach for the filesystem first
This point gets glossed over more than it should. Frontier models are not equally reliable across every interface. They are trained heavily on bash: directory navigation, cat, grep, pipes, writing results to disk. File manipulation produces the highest model reliability, not because someone designed it that way, but because most of the training signal lives there.
A filesystem interface puts agents in their native training environment. This isn't a UX preference. It's a capability question. When a model works through a protocol it was not trained on, errors become less predictable and harder to catch.
There's also a context window angle that matters at scale. An agent that can ls a directory and read selectively doesn't need everything front-loaded into the prompt. It discovers what it needs as it works. Every bespoke MCP tool you add instead burns context window space and accelerates context rot. A bash-native interface collapses the data-access surface into something the model already knows deeply.
Git lands in the same category. It's deeply embedded in training data, part of why Cloudflare chose it for Artifacts. Both products are making the same underlying bet: build on interfaces that already live in model training, not protocols the agent has to learn from scratch.
The distinction that matters practically: bash and POSIX are the interface for working against data. Git is the interface for recording what was done to data. Different jobs. Different strengths. Using either one for the other job is where the friction starts.
How the two products handle startup latency differently
Every task boundary is a potential delay. When an agent has to wait on data before it can start working, that latency compounds quickly at scale.
Artifacts handles this through ArtifactFS. The working tree mounts via FUSE with a blobless clone, a Git feature that skips transferring file content until it is actually needed, so file contents fetch on demand as tools read them rather than all at once upfront. Files that unblock developer tools come first (package manifests, dependency files, common source files) while large binaries are deprioritized. For a large repository that can save most of the clone time. The catch: if an agent reads a file that hasn't hydrated yet, that read blocks. Workflows that repeatedly touch large binary files will see the benefit shrink.
Archil's approach is structurally different. There is no clone step and no hydration queue. Data already in Archil's cache is served in under a millisecond. A first read of data that isn't cached yet goes to the bucket and is slower, but there's no upfront blocking phase at all. The cache warms as the agent works, and subsequent reads get faster.
The distinction is about the workflow each product assumes. Artifacts targets agents that start fresh from a repository snapshot for each task. Archil supports agents that return to persistent state, share live data, and continue working across task and session boundaries. For production systems that need more than isolated code generation, that persistent model is the more flexible foundation.
A Simple Decision Framework
Cloudflare Artifacts fits the narrower case where:
- Your agent primarily produces code, configuration, or structured text that needs diffs and rollback
- Each run should begin from an isolated, versioned repository
- The workflow already runs on Cloudflare Workers and Sandboxes
- Preserving committed outputs matters more than retaining live working state
Archil is the stronger default when:
- Your agent needs to work against data that already lives in object storage (training sets, model weights, large datasets) without a download or migration step
- You need persistent shared context across multiple agents reading and writing the same filesystem simultaneously
- Your code or frameworks expect real POSIX semantics and rewriting them isn't on the table
- You're cloud-agnostic or multi-cloud and need storage that behaves consistently regardless of provider
- You need SOC 2 Type II coverage, a HIPAA BAA, or a BYOC deployment that keeps disk data inside your own cloud account
If all you need is a versioned record of small, committed outputs, Artifacts may be enough. But when agents need a durable place to work, access existing object-store data, share state, or use standard filesystem tools, Archil is the more capable foundation. Artifacts can still complement Archil as an output ledger; it does not replace the working filesystem.
Final Thoughts
Cloudflare Artifacts offers a useful answer to one part of the agent-storage problem: preserving committed outputs with Git-style history. For teams already building on Cloudflare, it can provide a convenient record of what each task produced.
Archil addresses the broader requirement. It gives agents a persistent workspace where they can work directly against existing data, use familiar POSIX tools, share live state, and resume across sessions without rebuilding their environment. Those capabilities make it a better primary storage layer for production agents, particularly when workloads extend beyond isolated code or text generation.
The products can coexist: agents can perform data-intensive work in Archil and commit selected outputs to Artifacts or another version-control system. But if the architectural decision is which system should hold the agent's working state, Archil is the stronger choice. A ledger can preserve the result; the filesystem is what enables the work.