The industry is now racing to rebuild source code management for agents. We showed our answer at GitLab Transcend, but let’s reiterate why rebuilding the Git backend is only half the problem.Three things break when agents become the primary users of a Git server. Every developer running hundreds of agents hits the same wall, regardless of tools:The clone tax. An agent clones an entire repository to read a single file, then does it again for the next agent, and the next retry, transferring far more data than the task requires and burning context on a local grep or blame it shouldn't have needed to run. One agent invocation today can mean 5GB to 10GB transferred and 30+ seconds of setup, just to answer a single question.Concurrency collapse. Thousands of sessions hit a backend that was originally designed for human scale, producing bottlenecks and unpredictable availability.No isolation. Agents share accounts and one branch space, so they overwhelm the repository, leave no clean way to discard abandoned work, and keep no record of which agent did what.Our platform data shows how fast the pressure is building. Over the past year, our customers created 40% more CI/CD pipelines, and code pushes to GitLab.com were up 50%. While the secure repositories grew by 60%, codebase sizes have also grown by up to 500%.When we announced next-generation source code management (next-gen SCM) at GitLab Transcend in June, we walked through how Git, as an operational model, was not designed for the load agents placed on it. A few weeks later, new entrants, including Git hosts built specifically for agent-scale concurrency, are validating that claim independently. That convergence sharpens why rebuilding the Git backend is necessary, but on its own, it’s still not enough.What we’re building for agent scaleNext-gen SCM runs on the Git protocol for backward compatibility, with a redesigned backend and interfaces built for agents. Instead of cloning a full working tree, agents query the repository server-side for exactly what a task requires, with each agent limited to the minimum visibility its task needs. It’s the same Git compatibility and auditability with a different motor underneath.The architecture separates an intelligence layer (routing, caching, background work) from elastic compute that scales on demand and elastic object storage. Purpose-built read and write APIs let agents retrieve file, blame, and history data and commit changes without pulling the whole repository. Developers can run agents on any repo, fan them out by the thousands, and let them experiment safely. In practice, that means an agent gets a single batch-read instead of a full clone, a diff-stat request instead of clone-then-diff, and a last-commit-for-path lookup instead of clone-then-blame.This isn't designed for cloud-only. The compute and storage tiers talk to each other over the standard S3 API, so the same architecture that runs on GitLab.com runs on a customer's own infrastructure, whether that's a major cloud provider's object storage or a self-hosted, S3-compatible system running in a customer's own data center. For air-gapped, regulated, and sovereignty-constrained environments, that means the same horizontal scaling and consistency guarantees, without repository data ever leaving infrastructure the customer controls.In early internal testing, agents running against next-gen SCM showed:Up to 50x faster wall-clock timeUp to 2x fewer tokensUp to 1,000x less network trafficThese are ceilings, not guarantees, measured under our own testing conditions. The workload that actually stresses a Git backend at agent scale is concurrent reads and writes from many independent agents against the same repositories, sustained under load — so a number only means something if the test runs close to that target, the load generator isn't the bottleneck, and the full latency distribution is reported rather than a single best case.We hold our own results to that bar, and we'd encourage anyone evaluating this category to ask the same three questions of every number they're shown, including ours. That bar is built into the architecture itself, not only our test conditions. Storage maintenance compacts small artifacts into larger, frozen ones on a geometric schedule, which puts a hard ceiling on how much data any node has to fetch to catch up to the latest snapshot. With a 1GB freeze threshold and a 2x compaction ratio, that ceiling is 2GB, regardless of how large the repository has grown.Next-generation source code management is now in private beta, and here it is in action: