Where Agent Code Lives Is a Containment Decision

GitHub crossed one billion commits in a single year. Kyle Daigle put the 2025 number on record, and the rate has not slowed: Matt Rickard estimates roughly 275 million commits a week now, a pace that projects to about 14 billion a year. CI volume tells the same story. GitHub Actions ran 500 million minutes a week in 2023 and doubled to a billion minutes a week by 2025.

Those curves did not bend because humans started typing faster. They bent because agents started committing.

That single fact reframes a question most teams have not asked out loud yet: where should agent-generated code actually live? The reflexive answer is “in the repo, same as everyone’s.” It is also the wrong answer, and the volume data is what makes it wrong.

The Substrate Was Built for People

A platform like GitHub is a social system first and a storage system second. Stars, issues, pull-request threads, code review, a follower graph, a profile that doubles as a resume. Those features exist because software was, until very recently, a human collaboration act. The repository is where trust accumulates: you read who touched a file, when, and why, and you extend or withhold confidence accordingly.

Rickard’s blunt observation is that agents need almost none of that. An agent does not need a UI, an issue tracker, a social feed, or stars. It needs a durable, programmatic Git layer it can write to at machine speed and read back from with precision. The features that make a human platform valuable are dead weight to an agent, and worse, they are an attack surface and an attribution hazard when machine output flows through them.

Pour 275 million commits a week into a substrate designed for human-paced collaboration and the trust signals stop meaning anything. A commit history was a ledger of human intent. Fill it with agent output and the ledger no longer tells you who decided what. The signal that made the repository valuable gets diluted by the very volume the repository now carries.

Mixing Is the Governance Mistake

The real problem is not volume in the abstract. It is co-mingling. When agent commits land in the same branch, the same history, and the same review queue as human commits, three things break at once.

Provenance blurs. You can no longer answer “did a person decide this, or did a model?” by looking at the history, because the history treats both as the same kind of event. Attribution by commit author is trivially spoofable and routinely wrong once agents commit under service accounts or, worse, under a developer’s identity.

Blast radius expands. A human repository carries production credentials, deploy hooks, protected branches, and the implicit trust of everything wired to it. An agent that writes into that repository inherits all of it by default. The sandbox you built at the compute layer means little if the agent’s output lands one merge away from production.

Review collapses under load. Human review was calibrated for human commit rates. It cannot absorb a machine firehose. So teams do the rational thing under pressure: they wave agent commits through. The control that was supposed to catch bad output becomes a rubber stamp precisely when the output volume makes catching things hardest.

None of these is a tooling bug. They are the predictable result of running machine output through infrastructure designed for human trust.

A Separate Substrate, by Design

The fix is to treat “where agent code lives” as a containment decision, decided up front, not discovered after an incident. Three properties define the substrate agents actually need.

It is durable and programmatic. Agents need real Git, not a scratch directory that evaporates. They need to commit, branch, diff, and read history through an API at machine speed, without a human-facing interface in the path. Commits become checkpoints in an agent’s work, a fine-grained record of what changed at each reasoning step, which is exactly the audit trail you want when something goes wrong.

It is ephemeral and on-demand. The unit is not a long-lived shared repository. It is an isolated repo spun up for a task and torn down when the task closes. Isolation per task means a runaway agent corrupts its own workspace and nothing else. There is no shared history to poison, no protected branch to threaten, no neighbor’s work to overwrite.

It is scoped by short-lived credentials. The agent’s substrate gets its own identity and its own narrowly scoped, expiring tokens. It cannot reach the human repo’s deploy keys or production secrets because it was never handed them. Provenance is then structural: code that came from an agent lives in agent-scoped infrastructure, and promotion into a human repository becomes an explicit, reviewable event rather than a silent merge.

This is the same logic the containment stack applies at the compute and data layers, extended to the layer most teams forgot: the place the code itself accumulates. We laid out the broader build in the agent infrastructure that shipped in one week and the four-floor model in the agent containment stack. Where agent code lives is the floor under all of them.

The Promotion Boundary

Separation is not a wall; it is a gate. Agent code does not stay quarantined forever. It earns its way into the human repository through a defined boundary: a point where output is reviewed, attributed, and signed before it joins the trust-laden history.

That boundary is where governance actually lives. On one side, machine output at machine volume, ephemeral and disposable. On the other, human-owned history where every commit still carries intent. The membrane between them is the control surface. When promotion is explicit, you can audit it, rate-limit it, and require a human signature on anything headed for production. When promotion is implicit, you cannot, because there is no boundary to instrument.

A note on the source. Rickard is building a product in exactly this space, so read the product framing with that interest in mind. The commit-volume data is third-party and holds independently of any product: the scale is real, and the scale is the argument.

Do This Now

Pick one repository where agents already commit. Answer two questions. First, can you tell, from history alone, which commits a model authored and which a person authored? If the answer is “by author field,” it is not reliable, and you have a provenance deficit. Second, what is one merge away from production in that repo, and does the agent’s identity have a path to it? If it does, your blast radius includes everything the agent can reach.

If either answer worries you, the next move is not better review discipline. It is a separate substrate: ephemeral, programmatic, credential-scoped Git for agent work, with an explicit promotion boundary into the repositories where humans still own the history. Decide where agent code lives before the volume decides for you.

---

This analysis synthesizes Where should agent-generated code live? (Matt Rickard, May 2026).

Victorino Group helps teams decide where agent code lives so provenance and blast radius are designed, not discovered. Let’s talk.