Code Storage Architecture Differences Between Human and Agent Workflows

Code storage was built for one developer, one branch, and one pull request at a time. Agent workflows break that model because they run in parallel, and the rest of this piece traces what has to change in response.

The design assumptions baked into Git do not hold for agents

Run two agents against the same repository and within minutes branch collisions and stash conflicts appear, leaving a working tree that no longer reflects what either agent believes it's looking at. Git was built around a clone-and-branch model that assumes a single developer checking out a repo, working a feature branch, and opening a pull request when the work is done. That model holds up fine under sequential, human-paced attention. It was never designed to manage two or more actors writing to the same working directory at the same time, and it shows the strain immediately rather than gradually. Every downstream problem this piece covers, from merge correctness to context budget, traces back to that single unmet assumption: one actor, one working directory, one thread of attention.

Parallelism as the forcing function that breaks human-centric storage

Parallelism is the specific mechanism that turns a workable tool into an inadequate one. A single agent operating inside an IDE, making changes the way a human assistant would, doesn't stress Git's assumptions much. The trouble starts the moment a second agent, or a dozen, start operating on the same repository concurrently, each with its own context window and no visibility into what the others are doing mid-task. Agents clobber each other's files, fight over shared resources like a dev server port, and leave behind a state that nobody can reconstruct without digging through the reflog. It helps to think of the problem the way systems architects think about compute: a context window behaves like main memory, and the agent framework around it behaves like an operating system scheduling access to that memory. Classical systems solved concurrent-write problems like this decades ago, with locking, queuing, and isolation, and the solution was never "ask the writers to be careful." Code storage faces the same category of problem now, and the fix has to be architectural, not procedural. Beyond the file collisions themselves, parallel agents without a shared context layer, meaning versioned architecture decision records, project memory files, and rules files that persist across sessions, start to drift apart conceptually: they contradict each other's design choices and re-litigate decisions the team already settled. Better workflow discipline will not fix that. A database handles concurrent writes because it was built to, not because its users are told to coordinate by hand, and code storage for agents needs the same kind of built-in handling.

Git worktrees as the immediate structural response to agent parallelism

The first real fix for the collision problem is a Git feature that already existed: worktrees. A worktree gives each agent its own isolated working directory, its own branch, and its own working state, while all of them still share one underlying Git history. No agent has to stash its changes to make room for another. No two agents land on the same files at the same time. No context gets lost in the handoff between sessions. The practical payoff is throughput: agents stop waiting on each other, so adding more agents increases the amount of work getting done instead of just adding more contention for the same working directory. Claude Code has supported worktrees as a first-class feature, and its later release extended that support to subagents, background agents, and desktop parallel sessions, with each subagent invocation automatically getting its own temporary worktree. A September 2026 guide to agentic workflows treats worktrees not as a nice-to-have but as a foundational primitive on the same level as CLAUDE.md files and architecture decision records, something the rest of the agentic loop assumes is already in place. It's fair to ask why a Git feature that has existed for years is suddenly load-bearing. The pattern isn't new, but the context is: agent parallelism turned worktrees from an edge-case tool into the default operating mode, and tooling like Worktrunk alongside Claude Code's native support has made running worktrees at that scale something teams can actually rely on in production.

Worktrees are necessary but not sufficient: the case for agent-native storage primitives

Worktrees fix the collision problem, but two costs remain untouched underneath them. The first is clone latency: every new agent session still has to wait on a full clone of the repository before it can read a single file, and at agent throughput, where sessions are cheap, short, and numerous, that wait gets paid over and over. The second is the absence of any native place for agents to record their own metadata, things like the prompt that generated a change or which agent produced it, without mutating the code objects those changes live in. Cloudflare Artifacts, launched in private beta in April 2026 with a public beta targeted for early May 2026, is the first infrastructure primitive built specifically to close that gap. It's Git-compatible versioned storage designed to support creating tens of millions of repositories, forking from any remote, and handing a URL off to any standard Git client, described by Cloudflare as "a distributed, versioned filesystem built for agents first." Artifacts introduces native git-notes support, which lets agents attach metadata, prompts, agent attribution, and similar detail directly to Git objects without altering the objects themselves, creating an audit trail that lives inside the repo rather than cluttering the commit history. Artifacts is a storage primitive built around the agent session as its basic unit of work, in the same way object storage was built around the API call rather than around a mounted filesystem meant for a human to browse, rather than a Git host that bolted on some agent-friendly features.

How agents navigate code differently from humans

Human developers find their way around a codebase by accumulation: they remember where things live, they recognize naming conventions, and they lean on IDE tooling tuned to how people read and scan. Agents build none of that up. They move through a repository by issuing tool calls: directory listings, glob searches, individual file reads, each one costing tokens and time, and each one spent on exploration rather than on the actual task. That exploration isn't free in a second sense, either. The context window fills up as the agent reads, and the quality of its reasoning degrades as that window fills, so every unnecessary file read is a latency cost and a hit against the budget the agent has left to reason well. A September 2026 guide to agentic workflows treats that context budget as the central constraint the whole practice has to manage, stating that "almost every practice below exists to manage that constraint, which is why the context layer later in this guide is load-bearing rather than optional." The field's answer has been to give agents something to read before they start exploring: files like CLAUDE.md and AGENTS.md, along with architecture decision records, serve as persistent, versioned ground truth that an agent can consult first, cutting down on the blind traversal that would otherwise eat into its context budget. Research tracking agent-authored plan files in open-source repositories backs this up: task-oriented Markdown documents that spell out implementation steps, the files involved, and how to validate the result are showing up as a distinct, recognizable kind of artifact, and they measurably reduce the undirected search agents would otherwise do at runtime. The architectural conclusion follows directly: code storage for agents needs module boundaries, symbol signatures, and architectural constraints to be retrievable without a full traversal of the codebase every time, and a plain file tree was never built to answer that kind of query.

What the merge boundary requires at pipeline throughput

Parallel agents generating changes continuously push the real correctness test to the merge boundary. A merge queue checks each pull request against the latest state of the target branch plus every other change already queued ahead of it, so two changes that each pass their own tests in isolation can't combine into a main branch that's broken. At human pace, running CI only on individual branches was defensible because tests were often too slow to sit in the merge path itself. Agent throughput removes that excuse: tests need to run fast enough to keep agents productive, and once they do, a merge queue outperforms branch-based CI by a wide margin. One team's policy, as of September 2026, makes main writable only by the queue, has agents hand in diffs and nothing more, runs every agent in a throwaway sandbox rather than a developer's machine, grants no agent cluster credentials, and routes the only path to main through CI inside the merge queue. Factory's software factory model, described at its June 2026 launch, formalizes this as a continuous loop rather than a one-time handoff: external signals feed a triage layer, AI agents build and test the resulting changes, and version control sits at the intake boundary of that loop rather than serving as the final resting place for finished human work. Enterprise customers including NVIDIA, Adobe, EY, Palo Alto Networks, Adyen, Blackstone, Wipro, and Comarch are running that model in production. The storage implication follows from the role code storage now plays: it's no longer a place where developers park finished work, but the control plane that automated signals, agent-generated diffs, and CI verification all pass through continuously, which calls for high-concurrency write throughput, atomic queue operations, and metadata that tracks which agent did what, properties human-centric storage was never built to deliver.

Where human judgment still belongs in the loop

The strongest challenge to everything described so far is that it optimizes for throughput at the expense of correctness. Agents can miss bugs, miss edge cases, and miss architectural problems that a careful human reviewer would catch, and a merge queue only solves the problem of landing parallel changes cleanly once the work already looks sound on its own. That objection has real force, and the answer is not to wave it away but to locate precisely where human judgment still has to carry weight. The plan boundary and the merge boundary are where senior engineering attention pays off the most, and the same September 2026 workflow guide is explicit that the human role moves earlier in the process rather than later, because correcting course during planning costs little while correcting course after a large diff has already landed costs a great deal. In practice, most teams start by having a human approve every merge and shift individual workflows toward auto-merge only as confidence in a given agent or task type builds, automating the approvals that were effectively rubber stamps anyway and reserving real review for the cases where judgment actually matters. Factory's fully autonomous loop sits at the edge of what's been proven out, and the open question there is measurement: which platform can demonstrate that its agents are not just faster, but reliably correct, secure, and auditable at scale, backed by evidence about outcomes rather than by counting tokens consumed or pull requests opened. Air-gapped configurations, now offered by Factory and several other enterprise platforms, reflect a shift in what buyers expect: agents operating on production code need to be controllable at the infrastructure level, not through policy alone, and that's a requirement human-centric storage and CI tooling was never built to satisfy.

Changes to make first when building or transitioning to agent pipelines

No team needs to close all the gaps described across this piece simultaneously. The point of this architecture is that its pieces are composable: a team adds the layer its current bottleneck actually demands, and adds the next one once throughput grows enough to need it. Start by instrumenting agent sessions with transcript-level visibility, so it's possible to see where context budget is being spent and which exploration patterns are generating overhead, because no team can tune a system it can't observe. Adopting Git worktrees as the default working mode for any repository more than one agent touches removes the collision and stash problems that otherwise block parallel work. As session volume grows, the clone-latency and metadata gaps that worktrees leave untouched become the next bottleneck. That is where a storage layer built for agents, such as Cloudflare Artifacts, becomes worth evaluating rather than optional. And as soon as agents are generating changes fast enough that branch-based CI can't keep up, the merge queue stops being a nice-to-have and becomes the only correctness gate that scales with them. None of these layers substitutes for the others. Each solves a different constraint at a different point in the pipeline, and the teams that get this right will be the ones that add each layer exactly when the bottleneck in front of them demands it, not before.