One of our agents may need to inspect a repository, search a library of company documents, read a job’s uploaded files, query current security state, and then produce a report. The machine doing that work does not need to live forever. In fact, we prefer it not to.
We run agent workloads on ephemeral Modal machines. A machine starts for a job, receives narrowly scoped credentials, does the work, seals the result, and can then disappear. That model gives us good isolation and lets compute scale with demand.
The difficult part was the workspace.
Agents and their tools expect a normal filesystem. They traverse directories, edit repositories, run command-line tools, create indexes, and sometimes use SQLite. Rebuilding all of that from object storage on every cold start is possible, but it makes the user wait and forces every tool through a storage adapter.
We introduced Archil as the persistent, low-latency POSIX workspace beneath those ephemeral machines. It is not a replacement for S3 and it is not a new source of truth. It is the hot place where active work happens.
This is a generalized description of how we use it. It includes no real tenant names, identifiers, documents, production measurements, or operational data.
A typical job before Archil
Imagine a risk-analysis job that needs a policy library, a project repository, some documents uploaded by the user, and the latest cloud-security evidence.
Before the agent can analyze anything, a fresh machine has to reconstruct its working set. Large immutable artifacts fit naturally in S3, but a repository or document tree is less pleasant when every read starts as an object request. The agent either downloads everything up front or builds a local cache that vanishes with the machine.
That is manageable for a one-off task. It becomes wasteful when the same organization runs several jobs against substantially the same working set.
With Archil, the approved projects and organization data survive machine recreation as an ordinary mounted filesystem. The next ephemeral machine can continue from the same hot working set after verifying its route and storage receipt. The compute is disposable; the useful workspace is not.
What we put in the hot workspace
We learned quickly that “persist the working directory” is too broad a rule. A working directory can contain credentials, browser state, temporary extraction files, package caches, incomplete runs, and private runtime databases. Making all of that durable would create more problems than it solves.
Instead, every category has an owner.
The ephemeral filesystem holds scratch space, extracted intermediates, dependencies, tool caches, and private runtime state. Those things can be rebuilt.
Archil holds the reviewed POSIX working set: project files, organization knowledge, explicit job inputs, and selected immutable payloads that benefit from fast repeated reads.
S3 holds the authoritative copy of accepted inputs and outputs, manifests, receipts, reports, indexes, lifecycle state, and current pointers.
Credentials, cookies, SSH material, OAuth state, and machine identity never go into Archil. Neither do mutable pointers such as “latest” or “current.” If a hot copy and S3 ever disagree about accepted state, S3 wins.
A user uploads a document
Uploads are a useful example of how the two durable layers work together.
Suppose a user adds a policy document for a future compliance or risk job. We want the document immediately available to tools through the filesystem, but we also need a canonical copy that can be audited and used for recovery.
The platform follows this sequence:
- Write the bytes to that tenant’s Archil workspace.
- Read the hot copy back and calculate its digest.
- Write the same bytes to the tenant’s canonical S3 namespace.
- Read the canonical copy back and verify the same digest.
- Acknowledge the upload only after both copies agree.
If the S3 seal fails, the unsealed Archil object is removed or replaced with the previous canonical content. The UI never reports a successful upload that exists only in the hot layer.
Later, an agent reads the Archil copy for speed. If it is missing, the runtime falls back to S3 and can repair the hot copy after verification. This makes Archil a performance layer without weakening the recovery model.
A job that uses Archil and Durable Objects together
The hot workspace becomes more useful when combined with our security-state architecture.
For example, a job may need to answer, “Do any recent cloud changes conflict with our documented controls?” The agent gets the latest structured inventory, posture, and change projection through the authenticated Cloudflare Worker API. That state is served by tenant-scoped Durable Objects.
The same agent reads the organization’s control documents and project context from Archil using ordinary filesystem tools. It correlates the two sources, produces a Markdown or structured report, and seals the result and its evidence receipt in S3.
Each component is doing the job it is best suited for:
- Durable Objects provide current structured state and analysis history;
- Archil provides fast POSIX access to working documents and repositories;
- Modal provides short-lived compute for the agent and its tools;
- S3 provides immutable evidence, accepted outputs, and reconstruction.
The agent does not need storage-specific logic for every file operation, and none of the fast layers gets to invent canonical history.
How we keep tenants isolated
Every routed organization has an exact mapping to one Archil disk and one disk-scoped credential. The runtime checks that the authenticated organization, tenant identity, disk identity, region, and secret all agree before mounting.
The account-level Archil credential is used only by a separate administrative path. It is never attached to a customer job. A job machine sees only the credential for its own disk and only the cloud or API credentials explicitly required for that job.
We also keep compute close to the disk’s region. The runtime validates the placement before mounting so a configuration mistake fails visibly rather than turning ordinary filesystem operations into unexpected cross-region traffic.
If a tenant has no approved Archil route, nothing changes for that tenant. This allowed us to introduce the storage layer gradually instead of making a global cutover.
Moving an existing workspace safely
The human temptation during a migration is to copy a directory and see whether the application starts. We wanted a process that could tell us exactly which files moved and prove that their contents did not change.
We begin by mounting the existing workspace read-only and generating a manifest. Every regular file receives a path classification and a SHA-256 digest. Project and organization-data files can enter the review lane. Secrets, runtime state, caches, symlinks, hardlinks, incomplete runs, and unknown paths do not move automatically.
For every approved file, the copier re-reads and re-hashes the source, writes a temporary destination, flushes it, atomically replaces the final path, and independently verifies the destination. At the end it writes an immutable receipt binding the tenant, source manifest, target disk, approved files, and digests.
An interrupted copy has no valid receipt and therefore cannot be activated by mistake. An exact retry can verify and reuse content that already arrived.
Most importantly, copying and activation are separate decisions. We can mount the new Archil workspace in shadow mode, verify it with production-shaped jobs, and leave the existing application paths untouched. Only after review do we activate the route for one tenant. The source remains available for rollback until a later, explicit retirement decision.
What happens when a machine disappears
Once the workspace boundaries are explicit, destroying and recreating an agent machine becomes much less dramatic.
At cold start:
- secrets and machine identity are injected again;
- dependencies and caches are rebuilt;
- private runtime databases are reconstructed;
- the tenant’s Archil disk restores the approved POSIX workspace;
- S3 restores canonical tasks, inputs, reports, receipts, and pointers;
- the route and migration receipt are verified before work begins.
The agent gets the continuity it needs without treating a compute machine as a pet. If Archil is unavailable or a hot object is missing, canonical S3 remains the recovery path.
Why we did not just use S3 for everything
We still use S3 extensively. It is exactly where immutable evidence and accepted artifacts belong.
The problem is that many agent tools assume POSIX behavior: directory walking, atomic rename, file locking, append, executable permissions, SQLite, and normal command-line paths. Re-implementing those expectations over object storage adds adapters and repeated local staging. It also makes existing tools harder to use unchanged.
Archil gives those tools a real filesystem with persistence across ephemeral machines. The cost of that convenience is the need for strong boundaries. A hot filesystem must not absorb secrets, cross tenant boundaries, or silently become authoritative. Our route checks, path policy, digests, receipts, and S3 sealing are what make the convenience safe.
What users actually notice
Users do not see a storage diagram. They notice that a newly started agent can open the organization’s working set without a long hydration step. An uploaded document is available to the next job. A repository remains where the previous job left its approved working copy. A report still has an immutable source and receipt even though the machine that produced it no longer exists.
This is the experience we wanted: persistent context without persistent compute.
What we learned
Archil was most valuable once we stopped thinking of it as “another place to store files” and started treating it as a controlled hot work plane.
S3 remains the audit and recovery authority. Durable Objects remain the fast, serialized home for current security state. Modal machines remain replaceable. Archil gives agents the filesystem continuity that sits between those layers.
Together, they let a job wake up on fresh compute, recover its context quickly, use ordinary tools, combine documents with live structured evidence, seal its result, and disappear again. That is the operating model we were after: the work persists, the evidence is trustworthy, and the machine itself is temporary.
