Code Storage Performance Requirements for Cloud-Native AI Agents

Cloud-native AI agents do not do what human developers do, only faster. They produce a storage access pattern that traditional version control was never built to carry, a structural difference in kind. This piece lays out what that difference actually demands of code storage, and why teams that treat agents as fast humans will keep hitting walls that have nothing to do with how smart the agent is.

Why AI Agents Impose a Different Storage Load

A human developer treats a repository the way a person treats a filing cabinet: open it occasionally, pull what's needed, put things back in batches, close it again. The pattern is sparse, irregular, and paced by whatever the person is doing between commits, whether that's a meeting, a lunch break, or simply thinking. Clone once at the start of a project, read selectively while working, write in batches, push when ready. None of that maps onto how an agent touches the same repository. An agent reads constantly to pull context into its working memory, writes continuously to record intermediate progress, and triggers clone and sync operations every time a task gets broken into smaller pieces. A fleet of agents runs at once, multiplying that load until the access pattern stops resembling anything a version control system was tuned for.

The CNCF TAG Infrastructure white paper gives this pattern a name by treating agentic AI as its own storage profile, distinct from both model training and inference. Agents need short-term memory in the form of mutable state tracking and append-only event histories, a place to hold intermediate code or media as artifacts, and a long-term memory layer that consolidates what happened across past sessions. It's a closed loop, built to run continuously and feed back into itself, and nothing like it appears in batch training jobs or in the way people write software. Coding agents now sit inside projects across every maturity level and language, making this load the baseline condition engineering infrastructure has to handle now.

Three storage failure modes that only appear under agent-generated load

The gap between what agents do and what storage was built for produces three specific failure modes, each invisible at human speed and obvious the moment agents take over.

The first is the small-file trap. Agents working through a codebase generate huge numbers of individual read and write calls against single files, one at a time, over and over. The CNCF white paper calls out datasets made of millions of small files as a direct source of pressure on storage metadata servers, and agentic workflows reproduce that exact condition at the level of an ordinary code repository. A platform that never noticed metadata overhead under human commit volume will notice it fast once dozens of agents are opening and closing files in parallel.

The second is the overhead that comes from separating compute and storage. The same white paper points out that decoupled compute and storage scales well on paper but adds heavy API call overhead and leaves GPUs underused in practice. For a human, an extra round-trip to storage costs a fraction of a second nobody notices. For an agent calling storage programmatically at high frequency, that same round-trip gets paid repeatedly, and the overhead compounds with every call.

The third is a mismatch in workload profile. Traditional version control was built around a single profile: sparse, human-paced, forgiving of a little latency here and there. The CNCF paper separates two other profiles that matter here, high-throughput batch jobs that need sustained data movement, and latency-sensitive inference that needs a fast response under spiky demand. An agent pulls context, which needs speed, while writing artifacts, which needs throughput, in overlapping cycles, so agentic code storage has to serve both at the same time. A system tuned for one profile will fail the other, and most version control systems were never asked to run both at once.

What "low latency" means for a clone or sync operation when an agent triggers it

For a person, clone latency is a minor annoyance, a few seconds staring at a terminal before getting back to work. For an agent that clones a fresh repository at the start of every task, or spins up dozens of parallel instances across a fleet, that same latency becomes a recurring cost that compounds directly into how long the whole pipeline takes to run. A delay that was trivial at the scale of one developer's morning becomes a recurring tax paid on every single task, multiplied by however many agents are running.

The scale of the fix hyperscalers are building toward makes the size of the problem clear. Google Cloud's AI infrastructure announcements at Next '26 describe Managed Lustre delivering a major jump in bandwidth over the year before, up to 10 TB/s, and up to 20 times the throughput of managed Lustre offerings from other cloud providers, with capacity reaching up to 80 PB. That system is built specifically to keep storage from becoming the bottleneck in agentic work. At the object storage layer, the same announcements describe Rapid Buckets offering sub-millisecond latency and millions of operations per second, letting large checkpoints and recoveries happen almost instantly and keeping expensive accelerator hardware busy while it waits on data.

The lesson for anyone running code storage at smaller scale than Google Cloud is the same regardless of size. Clone and sync latency for agent workloads needs to be measured as a cost paid on every task, not a one-time setup expense, and that cost scales with however many agents are running concurrently. A number that didn't matter at human scale becomes the term that decides how fast the whole system runs once agents are the ones triggering it.

Concurrency is the requirement that most decisively separates agent workloads from human ones

People generate concurrency at the pace of people. A team of fifty engineers might have a handful of repository operations happening at the same moment, scattered across a workday. A fleet of agents working the same codebase generates concurrency at the pace of compute, and that's a different kind of problem entirely, not just a bigger version of the same one.

Concurrent access to shared state opens a category of failure that sequential human work never runs into. When agents operate on the same branch or the same artifact at the same time, the result is a race condition, corrupted state, or data quietly lost in a way nobody notices until something downstream breaks. The danger is that things become wrong, silently, with the wrongness surfacing somewhere else entirely by the time anyone finds it.

The CNCF white paper's insistence on append-only event histories as a core piece of agentic storage architecture makes sense in that light. Mutable shared state under heavy concurrency is unsafe, so the storage layer has to enforce write rules that human-centric version control systems never had to formalize because they never ran under that kind of pressure. The common objection is that Git's existing locking and branching already solve concurrency, and that objection misses the dimension that actually matters: frequency. Git's model was designed for people coordinating over minutes and hours. Agents coordinate over milliseconds and seconds, and at that rate they exhaust locking mechanisms that were never tested against that kind of load.

Persistence and stateful environments as a storage requirement, not an orchestration preference

A stateless sandbox works fine for an agent running one short task and disappearing afterward. It fails for an agent that carries memory, session history, or accumulated knowledge of a codebase across multiple runs, because that kind of agent needs storage that survives between sessions, and most traditional version control infrastructure was built around the assumption that it wouldn't need to.

Northflank's analysis of cloud environments for AI coding agents treats persistence as a baseline requirement. Long-running tasks need the workspace itself to survive pauses, restarts, and dropped connections, with files, branches, and installed packages still sitting where the agent left them. Some platforms impose hard limits on how long a session can run, and those limits break any workflow that stretches past them. The CNCF white paper treats long-term memory, the consolidation of what happened in past sessions, as a structural piece of agentic storage architecture built in from the start. The storage layer has to be designed from the start to carry sessions forward, not patched later to approximate it.

Northflank's evaluation criteria for agent cloud platforms, isolation model, whether environments are ephemeral or persistent, GPU availability, support for bring-your-own-cloud, and pricing, point at a single underlying idea: persistence and isolation have to be judged together, not separately. An environment that persists but isn't isolated lets state from one session bleed into another. An environment that's isolated but doesn't persist can't support any task that runs longer than a single session. GitOps, the practice of declaring the entire state of infrastructure and applications in code and storing that declaration in version control as the one source of truth, depends on that version control layer being able to serve as durable, consistent, programmatically accessible storage for agents to read and write against, not just a readable log of what people changed in the past.

The merge queue as a downstream symptom of inadequate code storage under agent load

Storage failures don't stay contained at the storage layer. When code storage can't keep up with the speed and concurrency agents need, the damage moves downstream: agents that can't clone fast, sync reliably, or write without stepping on each other produce pull requests with more defects, and those agents retry more aggressively, which piles more load onto an already strained merge queue.

The merge queue itself was built around how fast a person types. Teams that bring in AI coding agents see their PR arrival rate climb sharply while the merge pipeline's capacity to process them stays exactly the same as before. Queueing systems behave badly once arrivals start approaching capacity, and wait times don't grow in a straight line. They grow nonlinearly. A queue that looked fine at last month's volume can become unworkable at this month's without much warning.

Agent retry behavior makes the problem worse. An agent told to land a pull request will keep re-queuing the same change, burning a full CI run on every attempt rather than stopping to ask whether something upstream has changed. A retry loop that wasted a little time at human frequency turns into something closer to a denial-of-service attack on the pipeline once it's running at agent frequency. The link back to storage is direct: an agent that can't reliably sync state before opening a PR is more likely to produce a PR that conflicts or fails once it reaches the merge group, and a storage layer that adds latency to clone operations slows down how fast the agent can pull in upstream changes, which raises the conflict rate even further.

What purpose-built code storage for cloud-native agents must provide

Putting the preceding argument together yields a clear specification: high-frequency programmatic access, clone and sync latency measured in milliseconds even at scale, write semantics that stay safe under heavy concurrency, and storage environments that persist across sessions. These are requirements human-centric version control was never designed to meet, and no amount of patching gets it there without rethinking the architecture underneath.

Storage for agents has to be reachable entirely through code, because agents don't click through graphical interfaces or run the CLI commands a person would type by hand. That means exposing stable, low-overhead programmatic interfaces built to handle the volume of reads and writes agents actually generate, not interfaces designed around occasional human use and stretched to cover a much higher load. Concurrency-safe write behavior has to be part of the system from the start rather than added once something breaks: append-only event histories and write paths that keep different agents isolated from each other, the same patterns the CNCF white paper treats as core to agentic storage, need to be foundational, because a fleet of agents given shared mutable state without those protections will eventually corrupt it.

Performance headroom for concurrency spikes has to be planned for. Google Cloud's Next '26 announcements, Rapid Storage scaling to 15 TB/s and Managed Lustre reaching 10 TB/s with 80 petabytes of capacity, show what a hyperscaler's answer to this problem looks like at its scale. Teams running their own code storage need to plan for equivalent headroom relative to their own size, because the alternative is storage that works fine under light load and falls over the moment several agents hit it at once. Isolation has to exist at the storage layer in step with isolation at the compute layer: Northflank's evaluation framework treats isolation model as one of the primary things to check when choosing an agent cloud platform, and microVM-based isolation on the compute side means little if the storage operations those same agents perform aren't kept separate from one another too. Finally, syncing with upstream repositories has to run as a continuous, low-latency operation built into the system rather than a periodic task a person kicks off by hand, because the sync path sits on the critical path of every single task an agent runs.