Cache-Billed Cloud Filesystems vs Provisioned Capacity for Unpredictable AI Agent Workloads

Isolated per-tenant storage for multi-tenant AI agent applications needs identity-scoped workspaces, sandbox isolation, and persistent file access that cannot cross tenant boundaries. Cache-billed cloud filesystems suit sessions whose needs are hard to predict because the charges are based on active data. Provisioned storage earns its place when measured demand is steady enough to keep that reservation busy.

Why AI agent workloads break the assumptions behind provisioned storage

Provisioned capacity relies on demand being steady enough to predict, but measured agent workloads have long tails in both how long they run and their context size. Yuan et al. (2026) characterize agents that alternate reasoning and action as stateful, multi-turn executions that repeatedly invoke models, call tools, and accumulate context. Some tasks need many turns. Others build large contexts in fewer turns, so session length or context size alone cannot reliably show how much capacity a task needs.

A file read, shell command, web retrieval, and delegated subagent task have very different resource needs and waiting times. Yuan et al. show that GAIA workloads spend substantial time on WebFetch/WebSearch, while a software-engineering benchmark relies heavily on Bash, Read, Edit, Agent, and TaskOutput. Liu et al. (2026) find that a small fraction of tool calls account for most waiting time, dominated by installs, builds, test suites, and generated scripts.

Kondrashov et al. (2026) find that tool sandboxes sit idle for long periods, then use resources in short bursts. Those gaps belong to the execution loop. They are not scheduling accidents that disappear with a tidier queue. Provisioning for the peak leaves capacity unused between bursts, while provisioning for the average risks running out when the expensive calls arrive.

How provisioned-capacity billing turns idle gaps into a recurring tax

Provisioned-capacity billing charges for reserved throughput whether or not work is running. The charge for the reservation keeps running while an agent waits for a model response or another tool to finish. As agents wake and suspend over and over, that fixed charge becomes harder to justify for the amount of work they get done.

Suspension offers an escape, but not a free one. Kondrashov et al. find that snapshot-based state management is one reason it costs so much to suspend sandboxes often with the infrastructure in use today. Keeping the sandbox running burns capacity during idle periods, while suspending it introduces snapshot overhead when work resumes.

Context retention repeats the same pattern at the serving layer. Keeping more KV-cache state improves accuracy up to a point, after which it reduces serving capacity without proportional task benefit. Fixed-size storage volumes add another version of that waste when an agent’s needs swing from a small working set to a large dataset. Under provisioned pricing, idle time is not free, just easy to overlook until its charges are added together.

Why agents access data through file semantics, not object APIs — and why that shapes your storage choice

The billing model only helps if agents can use the storage. Agents overwhelmingly reach for POSIX file tools, including open(), shell commands, and path-based reads. That preference comes from how their tools work. Yuan et al. also find that agents spend most early turns on read-and-explore operations and do more execution and writing later, so the way they access data changes within a single session.

Object storage does not expose those operations in the same way. Listing a prefix is not listing a directory, atomic rename behaves differently, and reading part of a file requires different mechanisms. A bucket is not a directory wearing a cloud hat.

A filesystem interface over durable, elastic storage addresses that gap without tying the data to a disposable local disk. Google Cloud Storage FUSE and its GKE CSI driver let applications mount Cloud Storage through familiar Kubernetes APIs, avoiding a full dataset download before work starts. Incremental discovery then becomes a normal file-access pattern. That scope extends beyond input data, as Archil illustrates with durable, shared POSIX disks for working directories, installed packages, cached outputs, and shared state across parallel runs. Its disks can mount on many machines simultaneously and connect to existing buckets without migration.

What cache-billed storage actually charges you for, and when that matches agent workload shape

Cache-billed storage bases its charges on the hot working set that agents access. Cold data does not need the same high-performance allocation as active data.

AWS S3 Files makes the distinction concrete. Files smaller than the 128 KB threshold are loaded onto high-performance storage when accessed, while reads of 1 MiB or larger stream directly from S3 with no S3 Files charge. The file-size threshold and read-size rule each apply to a different operation.

Durable backing storage and retained snapshots are separate from active execution, just as a sandbox can charge for snapshot storage during standby while charging nothing for idle compute. The useful distinction is what remains billable during the gap. An agent that needs a small working set today and a large dataset tomorrow can change its active footprint without first selecting a larger fixed volume.

The KV-cache layer offers a related example of separating capacity from the serving cluster. Zhu et al. (2026) propose ObjectCache, which stores reusable KV cache in S3-compatible object storage and adds only 5.6% latency over local DRAM for long contexts. That result measures latency for KV retrieval. It nevertheless shows that retained state need not grow in lockstep with serving capacity. Where idle time is both substantial and unpredictable, active-data billing is structurally better aligned.

When provisioned capacity still makes sense for agent storage

Provisioned storage has a strong case when utilization stays high, the working set is stable, and latency requirements leave little room for cold cache fills. A pipeline that stays busy can access enough data to make its fixed cost a better deal than paying repeated cache-fill charges. Predictability earns its keep here. Provisioned local storage also keeps latency consistently low, which can make the reservation worth paying for when per-tool-call budgets are tight.

The same team can reasonably use both models. A scheduled, high-throughput batch agent pipeline has a different cost equation from interactive agents that arrive unpredictably and inspect different datasets each time. Batching work or running agents back-to-back can remove the gaps that otherwise make provisioning wasteful. Provisioned capacity wins when demand can fill the floor, while cache-billed storage wins when the team cannot predict whether it will.

Isolation and persistence as constraints on storage architecture choices for agents

The choice of how to pay for storage still needs a secure execution boundary. Firecracker microVMs give each workload its own kernel with hardware-enforced isolation, while gVisor interposes a user-space kernel to reduce the syscall attack surface. Google uses gVisor to keep tenants isolated from each other in Cloud Run and App Engine. The gVisor documentation notes significant overhead for I/O-heavy workloads, with the extent varying by workload. Standard containers share the host kernel and are not appropriate for untrusted agent-generated code.

Persistence is a separate requirement from isolation. A sandbox that discards its filesystem forces packages to be reinstalled and data to be downloaded again, turning each burst into another setup job. Archil’s persistent disks remain live across sandbox restarts, keeping the working set and installed packages available when execution resumes.

Cheap checkpoints and branches change the suspension equation further. Storage that branches in milliseconds regardless of size avoids making every parallel attempt or rollback a full-copy operation. With Archil’s disks forking in ~90 ms, suspension and parallel attempts become practical operational patterns. The distinction is between preserving a starting state and rebuilding it. That difference affects both resume latency and how much data must be fetched again.

Network policy completes the isolation boundary. The lesson for a multi-tenant platform is to disable egress by default, apply explicit allowlists per tenant, and keep credentials out of agent code. Agent processes should also be blocked from the instance metadata service, with no east-west networking by default and credentials brokered at the network boundary. A filesystem boundary alone cannot stop unrestricted outbound exfiltration.

How do you give each customer isolated storage in a multi-tenant AI agent platform

Each customer needs a persistent workspace with an identity scope that stops another tenant’s agent from reading or writing its state. That scope must hold through file access and the application’s user interface. A shared mount is not an isolation policy. Sandbox boundaries and network restrictions then constrain what agent-generated code can reach beyond its assigned workspace.

Microsoft Azure AI Foundry introduced user-scoped persistent memory in its April 2026 update, binding each user’s memory store to the Microsoft Entra token’s tenant ID and object ID. Amazon Bedrock AgentCore Runtime, launched in 2026, addresses execution isolation with lightweight per-session microVMs and isolated filesystems. Those filesystems are ephemeral by default, with optional persistence through managed session storage. Identity scoping, execution isolation, and durable storage are distinct responsibilities.

Uncertainty about storage charges multiplies across tenants because neither their schedules nor their data needs are reliably known. Provisioning each workspace for its possible peak reserves capacity for customers who may not be active at all. Staggered sessions change the arithmetic. Active-data billing follows how much tenants use together rather than the sum of their separate peaks, so each idle tenant needs no active-capacity reservation, though durable storage itself still has a cost.

Data ownership adds another architectural choice. A platform-controlled managed volume makes access revocation or migration depend on coordination with the platform, whereas a tenant-owned bucket keeps the source data in the tenant’s account. Archil provides a bucket-mount option across S3, GCS, R2, and Azure Blob, presenting existing data through POSIX semantics without migration. That avoids a separate platform-owned dataset requiring synchronization. Paired with access controls, tenant-scoped workspaces, and active-data billing, bucket ownership addresses control and provisioning as distinct responsibilities.

Reading workload shape to make the provisioning decision

Start the provisioning decision by measuring how much clock time goes to file reads and writes versus waiting for models and tools, using the burst-and-gap pattern identified by Kondrashov et al. as the hypothesis to test. Then measure data volume per session.

Next, test cold-cache latency against the actual per-tool-call budget. The ObjectCache result provides evidence that object-backed reuse can have modest overhead. Measure overlap across tenant sessions as well. Staggered activity supports active-data billing, while sustained aggregate demand may justify a reservation even when individual agents are bursty.

Serving-layer decisions can also use better signals. Liu et al. show that explicit tool-progress reports help systems make more accurate cache decisions than static predictors do when choosing whether to hold or evict KV state. For the storage choice itself, default to cache-billed capacity when idle gaps, variable data volumes, or a large and varied tenant population dominate. Move to provisioned capacity only when measured sustained use can consistently fill the provisioned floor.