AI Agents Are Killing the Git Client, Not Git: What Anthropic's Scion and Cursor's Origin Show

Executive summary

Git will not become obsolete, but the Git client model is about to be demoted from the center of the developer stack to a compatibility layer, and the economic value in source control is moving to the server. The organizations that leave Git outright over the next three to five years are a small set: frontier AI labs, hyperscalers, and a handful of monorepo-scale enterprises where merge rates are measured in tens of thousands a day. Everyone else keeps Git-compatible protocols at the edge while the forge underneath them is rebuilt for agents.

The strongest evidence to date is Anthropic's Scion, announced October 13, 2026. Anthropic's daily merges grew from roughly 2,500 in May 2026 to more than 30,000 in September, and seven engineers replaced Git across the whole monorepo in five months. Its stated design principles (clients are always online, the server does the computing, the working copy is optional) are a direct inversion of Git's founding assumptions. Anthropic says explicitly that Scion is not a general-purpose Git replacement and that the right path for most companies is to pull Scion's server-side ideas into Git platforms.

The second signal is Cursor Origin, launched in early beta on August 18, 2026, the same day as a multi-hour GitHub outage. Origin keeps Git as the wire protocol but attacks GitHub's position from the agent side: the editor, cloud agents, automations, stacked PRs and merge queues are all under one roof, and hosting is the last piece. Origin does not abandon Git; it abandons GitHub.

The practical thresholds this report lands on:

• Under ~100 engineers: Git on a hosted forge remains correct for the foreseeable future. The change is in the forge's agent features, not the protocol.
• 100 to ~2,000 engineers: Git stays, but the server behind it needs to behave like Scion: server-side RPCs for diff, blame, merge-base and merges; virtual or sparse checkouts; CI that never clones. This is the segment GitHub and GitLab must win in the next 18 months or lose to agent-native forges.
• Over ~2,000 engineers, or any org whose agents merge more than ~5,000 changes a day: an in-house or heavily customized system becomes rational. Google, Meta and now Anthropic have all made this choice; the cost of doing so just fell by an order of magnitude because agents can write the system.

The strategic implication for a platform incumbent is that the moat is no longer "we host Git". It is three things: a server-side source-control API standard that clients and agents speak directly, the merge and review layer that decides what lands, and the identity, policy and compliance layer that enterprises will not rebuild themselves. Whoever ships the first widely adopted server-side protocol for Git forges sets the terms for the next decade.

Why this question is live now

The trigger is a change in who commits code. For twenty years source control scaled with headcount, and headcount grows slowly. Agents broke that link in 2026, and the two most visible incumbents and the two most visible challengers all moved within a single quarter.

Three structural shifts sit under these events:

1. The ratio of machine clients to human clients inverted. At Anthropic, Claude authors more than 80% of merged code and the company performs roughly 25 million checkouts a day for CI alone. Agents are online by definition, so Git's offline guarantees become pure cost.
2. Merge rate decoupled from headcount. Every bottleneck removed increases code volume. A merge queue with a global lock, two human approvals per change, and full-clone CI all assume a ceiling that no longer exists.
3. The cost of building a source control system collapsed. Seven engineers built Scion and Antique in five months, with Claude writing most of the implementation. Google's Piper and Meta's Sapling each took years and dozens of engineers. When building is cheap, the "nobody builds their own VCS" rule that protected GitHub for a decade stops being true at the top of the market.

Git's design assumptions and where they break

Git was built in 2005 for the Linux kernel: a few thousand human contributors, often disconnected, each needing full autonomy over a repository that fit on a laptop. Every one of those assumptions is now wrong for the top of the market, and each failure maps to a specific cost.

The reasons Git won still hold for the rest of the market. Offline work matters to field engineers, open-source maintainers, and anyone on a plane. Full autonomy over a clone is what makes forking, mirroring and migrating between hosts trivial, and that portability is the single biggest check on forge lock-in. A system that drops those properties is strictly worse for a 40-person startup, and Anthropic's own post says Scion's concepts "really only make sense for truly enormous monorepos."

The important nuance is that Git the protocol and Git the client can be separated from Git the server. Anthropic's closing argument is that a Git server does not have to work like a Git client, that forges could expose Scion-style server-side RPCs in a standardized way, and that Git's sparse and shallow features could be made to compose. That is the path by which Git survives: as a compatibility surface over a server that no longer looks like Git inside.

The online/offline divide is the fault line

The single assumption that decides whether an organization stays on Git is whether its clients are usually offline or always online. Everything else, from full clones to local merges to packfiles, is downstream of that one choice, and it is the choice Anthropic put first in its list of principles.

For human developers the honest answer in 2026 is "usually online, occasionally not." Git's offline capability is used far less than it is valued; it functions mostly as insurance and as a guarantee of portability. For agents the answer is "always online, by construction." A cloud agent, a CI runner or a research job that loses its network connection has lost its reason to exist. Nothing is gained by letting it carry a 25 GB copy of a repository it will touch for ninety seconds.

That asymmetry explains the shape of every system in this report:

• Git optimizes for the offline client and makes the server a dumb object store. Every clone is a peer.
• Scion optimizes for the online client and makes the server the only place that computes. The client is a cache plus a file-layout engine.
• Google Piper and Meta Sapling sit in between: a central authoritative server with virtual file systems (CitC, EdenFS) that fake a full checkout while fetching lazily.
• Cursor Origin, GitHub and GitLab keep Git's wire protocol so that offline clients keep working, and compete on what the server does with agents once a push arrives.

The practical consequence is that "always online" is not a property of a company; it is a property of a client type. A company of 300 engineers will have both kinds: humans who sometimes work on planes and agents that never do. The architecture that wins for that company is one where human clients keep speaking Git and agent clients speak a richer server API, with both landing on the same server-side truth. Anthropic's own recommendation to the ecosystem points at this hybrid: standardized server-side RPCs that the Git client can learn to talk to.

The tell to watch is the share of checkouts performed by non-human clients. Once that share passes roughly half, the economics of the full clone collapse: the organization is paying full-clone bandwidth, storage and maintenance for clients that get no benefit from it. At Anthropic the figure is overwhelming: 25 million CI checkouts a day against a few thousand humans. At a typical 500-engineer company running cloud agents and CI, it has probably already crossed 50% without anyone measuring it.

Case study: Anthropic's Scion

Scion is the clearest existence proof that a company can leave Git in months rather than years, and the clearest statement of what it costs. All figures below are from Anthropic's October 13, 2026 engineering post.

What drove it. Daily merges to the monorepo rose from about 2,500 in May 2026 to over 30,000 in September. The main-branch history approached 100 GB; a compressed working copy exceeded 25 GB; CI alone performed roughly 25 million checkouts a day. Anthropic ran several hundred internal Git mirrors plus blob-storage snapshots to cope, and the mirrors stopped scaling once the repo outgrew their disks and memory.

What they built. Scion is a client-server system with a write-ahead log of "changesets" as its unit of work. A changeset records the files changed relative to its first parent and content-addressed pointers to blob storage. Everything else (blame, path history, commit-graph skip lists) is "derived data" computed recursively from parents and stored in Spanner. Refs exist but are discouraged; moving one is a compare-and-swap on a single row.

How it serves data. A three-tier cache (per-node scion-daemon, regional scion-cache, authoritative scion-server) answers identical RPCs, so the client never knows the topology. The client asks for specific immutable trees and blobs by hash rather than negotiating what it has, which makes every request cacheable and resumable and makes sparse and virtualized checkouts free.

What it cost and returned.

What they gave up. Offline work, Git-compatible tooling, and any easy path back. Scion requires its own code review (Antique), code search and CI; Anthropic says these are bespoke and would be hard for others to adopt. They also abandoned the global merge-queue lock in favor of post-merge and pre-deploy testing, accepting that concurrent changes can conflict because Claude fixes conflicts faster than humans notice them.

What they are telling the market. Three things, and all three matter for an incumbent's strategy:

1. Scion is not a general Git replacement; it only makes sense for enormous monorepos with tens of thousands of engineers or swarms of agents.
2. They expect this class of problem to become commonplace in the next six to twelve months, and think it would be wasteful for every Git user to face it alone.
3. They are explicitly offering to partner with GitHub, GitLab and the open-source community on server-side RPCs, a revised negotiation protocol, and composable sparse and shallow features. That is an invitation, and the first forge to accept it in public gets to co-author the standard.

One more detail is strategic rather than technical: Anthropic reports that Claude wrote most of Scion's implementation, that an early Mythos snapshot rewrote the Git-to-Scion ingestion pipeline unprompted to use 20x less memory and run 4x faster, and that engineers' main job was design, invariants and telling the model "no." The barrier to building infrastructure of this class is now a handful of senior engineers and a token budget, which changes the make-versus-buy math for every company above a certain size.

Case study: Cursor Origin

Origin is the opposite bet from Scion. It keeps Git entirely and attacks the forge, on the theory that the company that owns the editor and the agents can own hosting as a by-product. It matters less for what it is today than for what its parent has assembled around it.

What it is. Per Cursor's documentation, Origin is "Cursor's git forge for storing and sharing code": create repos, push and pull with standard Git over HTTPS at origin.cursor.com/{owner}/{repo}.git, mirror from GitHub, browse and search code at cursor.com/codebase, open and merge pull requests, and share with a Cursor team. It is in early beta on Start, Pro, Pro+, Ultra, Teams and Enterprise plans. Repos are private only; sharing outside a Cursor organization still requires syncing to GitHub, and mirrored repos keep GitHub as the source of truth.

What makes it agent-native. Cloud agents can clone, branch, commit, push and open PRs on Origin repos; automations trigger agents on schedules or source-control events; a cloud agent can now start a project with no repo at all and save it to a freshly created Origin repo (changelog). Cursor's new Rollouts feature connects to Origin or GitHub for source control, to CD for deploy events, and to Datadog for signals. The forge is being built as the substrate for an agent control loop, not as a place humans browse files.

Why the Graphite acquisition is the real story. Cursor announced the Graphite deal in December 2025, reportedly well above Graphite's $290M valuation (TechCrunch). Graphite's assets are stacked pull requests, the gt CLI, a stack-aware merge queue with speculative execution and dependency-aware bisection, and the Diamond AI reviewer, used by Shopify, Snowflake, Robinhood, Figma and Ramp (Graphite). The Graphite founders are now building Origin from inside Cursor, and HackerNoon's coverage at the time framed the deal as closing the loop from writing code to merging it, with GitHub already playing catch-up on stacked diffs (HackerNoon). The merge and review layer, which is where Anthropic says source control actually breaks at agent scale, is the part Origin inherited fully formed.

The timing. Origin's beta rolled out on August 18, 2026, the day after a GitHub outage that lasted roughly seven and a half hours, and coverage framed it as a hedge against GitHub reliability (InfoQ). SpaceX completed its acquisition of Cursor in August 2026, so Origin is now inside the SpaceX/xAI ownership structure.

Where it is weak.

• No public repositories and no built-in CI, so it cannot be the home of an open-source project and cannot replace Actions.
• Tightly bound to Cursor accounts, which makes it an extension of the Cursor environment rather than a neutral forge.
• Shipped without clear data-retention or training-use terms, and some developers have said in public they would rather tolerate GitHub downtime than host code on infrastructure controlled by Elon Musk. Code custody and neutrality are the objections enterprises will raise first.
• Origin's internals have not been published. Cursor staff have described work on scalability and on moving PRs toward a mergeable state automatically, but there is no Scion-style disclosure of how the server stores or serves data.

What it tells us. Origin shows the second route out of GitHub: not replacing Git, but making the forge a feature of whoever owns the agent. If a developer's agents, review, merge queue and rollouts all live in one vendor, the hosting decision stops being a decision. That is a distribution threat to GitHub, not a protocol threat to Git, and it is the one an incumbent can lose fastest because it requires no migration at all.

The in-house precedents and what they teach

Scion is the third well-documented case of a large engineering organization leaving Git (or never adopting it) at monorepo scale. The pattern across all three is the same: a central server, a thin or virtual client, and a bespoke review and CI layer. None of the three has been successfully productized for outsiders, and that failure is the most important lesson for anyone deciding whether to build.

Four lessons follow.

1. The client is replaceable; the review and merge layer is where the company's workflow actually lives. Google has Critique and TAP, Meta has Phabricator-derived tools, Anthropic built Antique. Every in-house VCS is really an in-house SDLC. Anthropic says outright that Scion "requires its own code review, code search, and CI," and that is the real migration cost.
2. The Microsoft path is the only one that generalized. GVFS, Scalar, sparse-checkout and partial clone went upstream into Git and are now used by every large Git shop. Microsoft solved the Windows-repo problem by making Git better rather than leaving it, and the industry inherited the result. This is the strongest argument that a forge incumbent should put Scion's ideas into Git and the forge rather than compete with a new protocol.
3. Virtual file systems were the bridge; server-side APIs are the destination. CitC, EdenFS and GVFS all tried to preserve the illusion of a full checkout for a human at a workstation. Scion drops the illusion because its clients are mostly not human. As agents become the majority client, the virtual file system becomes a special case of "the working copy is optional."
4. The build cost has collapsed, which changes who can afford precedent-setting systems. Piper and Sapling were multi-year efforts by teams of dozens. Scion was seven people in five months with Claude writing most of the code. The next Scion-class system will be built by a 400-person company that decides the forge is in its way.

The competitive landscape

The market is splitting into four layers, and the interesting competition is no longer "which forge" but "which layer owns the agent." Most entrants attack exactly one layer and keep Git underneath.

A few entrants deserve specific notes.

Entire (Thomas Dohmke). Raised a $60M seed at a $300M valuation in February 2026, the largest dev-tools seed on record per its lead investor (TechCrunch). Its thesis is that the bottleneck has moved from authoring to review, and its architecture is a Git-compatible database that stores prompts, decisions and execution traces alongside each commit, plus a "universal semantic reasoning layer" and an agent-native UI. The first product, Checkpoints, is an open-source CLI supporting Claude Code and Gemini CLI. Entire says it is not necessarily competing with GitHub; it is competing for the metadata layer GitHub does not have. The former CEO of GitHub leaving to build this is itself a data point about where GitHub's leadership thought the gap was.

East River Source Control. Founded 2025, came out of stealth in September 2026. Martin von Zweigbergk, who built Fig (Google's Piper client) and then Jujutsu over 15 years at Google, is CTO. ERSC's bet is the mirror image of Scion's: keep Git as the storage substrate everyone already has, and replace the client and history model so that an agent opening forty changes before lunch is a supported user rather than an abuse case.

Jujutsu. The most important open-source project in this space because it has no adoption cost: it uses Git's on-disk format and coexists with Git tooling in the same repo. Its model (working copy is a commit, conflicts are data not errors, every operation is undoable, no staging area, bookmarks instead of mandatory branches) is close to what an agent wants from a client. Google was on track to adopt it as the Piper client. If a forge wanted to ship a better-than-Git client without breaking compatibility, jj is the obvious base.

Perforce and Unity Version Control. The incumbents for games and large-binary workflows have been centralized and always-online for decades: Perforce's own comparison tables list both Helix Core and Unity Version Control (formerly Plastic SCM, acquired by Unity in 2020) as centralized check-in/check-out systems (Perforce). They are proof that the Scion model is not new; it is a return to the architecture Git displaced, now justified by a different client population. Neither has an agent story worth noting, both carry high self-hosting and licensing cost by competitors' accounts (Diversion), and both are exposed if a modern centralized server with Git compatibility ships.

Federated and self-hosted forges. Forgejo, Codeberg, Gitea and the ATProto-based Tangled gained mindshare in 2026 as GitHub's reliability fell and Origin raised custody questions; Hacker News commenters on the Origin launch named all three as the federation-minded alternative (InfoQ). The terminal emulator Ghostty left GitHub in April 2026 and the Zig language in November 2025 (youngju.dev), and the Dutch government launched a self-hosted Forgejo instance at code.overheid.nl in April 2026 (jorijn.com). They matter as the open-source community's exit option rather than as enterprise competitors, but open-source projects leaving GitHub is a slow leak of the network effect that made GitHub the default.

GitHub and GitLab: where they are and what they do next

Both incumbents are responding at the product layer (agents, stacked PRs, policy) while their infrastructure layer is where the pressure actually lands. GitHub's exposure is reliability and capacity; GitLab's is that its agent platform is a feature of a DevSecOps suite rather than the center of a developer's day.

GitHub. The platform claims 225 million users and 90% of the Fortune 500, and COO Kyle Daigle said in June 2026 that GitHub had recorded 1 billion commits in the year to October 2025, was tracking toward 14 billion this year, and saw 17 million agent-created pull requests in March 2026 alone (Every). Its leadership has been candid that agent load broke its planning assumptions: CTO Vladimir Fedorov wrote in April 2026 that GitHub set out to expand capacity 10x and concluded by February it needed 30x (GeekWire). Independent tracking counted 257 outages and 48 major incidents totaling roughly 112 hours of downtime between May 2025 and April 2026, with Copilot alone logging 44 (IncidentHub). GitHub's own March 2026 availability report described an incident where github.com request failures peaked near 40% (GitHub Blog). Microsoft confirmed in June 2026 that it is renting AWS capacity for GitHub while continuing the migration onto Azure, and the August 17 outage post-mortem cited a traffic peak that overran a data-center component and an autoscaling setting that did not engage. Organizationally, GitHub was folded into Microsoft's CoreAI division when Thomas Dohmke left in August 2025, which puts the forge under the same leadership as the model and Copilot strategy.

On the product side GitHub has moved fast: Agent HQ (Universe 2025) positioned GitHub as the control plane for any agent on Git, PRs and issues, with branch controls for agent-created code and agent identity and access; Agentic Workflows (technical preview, February 2026) run agents inside Actions with sandboxing and a Safe Outputs subsystem; Stacked PRs reached public preview on July 30, 2026 with a first-party gh stack CLI and an agent skill, and GitHub said explicitly the feature responds to the PR volume AI tools create; stacked Copilot sessions let an agent branch off another agent's in-flight PR.

What GitHub does next, in likely order:

1. Finish the capacity story: the Azure migration, the AWS overflow, and structural fixes SVP Jakub Oleksy described as removing failure modes permanently. Nothing else matters if archive downloads hit 50% error rates on the day a competitor launches.
2. Take Stacked PRs and merge queue to GA and make them the default landing path for agent output, with Copilot review as first-line gate.
3. Ship server-side source control APIs. This is the Scion lesson and the one GitHub is best placed to act on: a GraphQL or MCP surface for diff, blame, merge-base, server-side merge and rebase, so that Copilot cloud agents, Actions and third-party agents stop cloning. GitHub already owns the two largest consumers of that API (Actions and Copilot), so it can prove the economics internally first, as Anthropic did.
4. Push partial clone, sparse checkout, and a revised negotiation protocol upstream into Git, repeating the Microsoft GVFS-to-Scalar play. This keeps Git the protocol while the server stops behaving like a Git client.
5. Decide what to do about Entire and ERSC: the metadata layer (prompts, traces, checkpoints alongside commits) is adjacent to GitHub's PR model and could be absorbed, partnered or acquired.

GitLab. GitLab passed $1B ARR in fiscal 2026 and reported $286.3M revenue for the quarter ending July 2026, up 21% year over year. Duo Agent Platform went GA on January 15, 2026 as an orchestration layer for agents across the lifecycle with shared context, permissions and audit; 19.4 (September 17, 2026) added a /goal command in Duo CLI where one model implements and a separate model verifies against the stated goal, MCP server tools so external agents can run pipelines, review and merge MRs and triage vulnerabilities under existing group and project rules, GitLab-hosted open-weight models at up to 4x more calls per credit, and per-user credit caps (GitLab). Alphabet holds roughly 22% of GitLab's voting power and the platform is integrated with Vertex AI's model library.

GitLab's advantages are self-hosting and Dedicated for regulated customers, governance that treats agents as principals under the same permissions and audit trail as humans, and a merge-train primitive that already looks like an agent-era merge queue. Its disadvantage is distribution: the agent that writes the code increasingly lives in Claude Code, Cursor or Codex, not in GitLab's UI, so GitLab wins by being the governed landing zone those agents push to via MCP rather than by owning the agent.

What GitLab does next: extend MCP server tools until any external agent can complete a full task inside GitLab's permission model; position Dedicated and self-managed as the custody answer to Origin's neutrality problem; and, if it is ambitious, offer a Scion-style server API for self-managed monorepos, where it has customers large enough to need one and no hyperscaler parent to conflict with.

Will Git become obsolete, and at what organization size

The answer depends on which "Git" is meant. Git the on-disk format and wire protocol will be in use in 2036. Git the mental model (local commits, branches as the unit of work, full clones, the human at a terminal as the client) is already obsolete at the top of the market and will be replaced from the top down. The variable that predicts when an organization crosses over is not headcount but daily merges plus daily checkouts by non-human clients, and headcount is only a proxy for it.

The thresholds are deliberately wide because the tweet's framing ("no 100+ person company will use Git") is wrong about the size and right about the direction. A 100-person company in 2029 will still type git push. What changes is that the push lands on a server that computes the merge, that its CI never clones, and that most of the objects its agents touch are fetched by hash from a cache. That is Git by name and Scion by architecture.

Three reasons the 100-person line does not hold:

• Migration cost is paid in workflow, not in code. Anthropic's own account is that the hard part is review, search, CI and every tool that assumes Git. A 100-person company's entire engineering budget is smaller than the cost of rebuilding those.
• Offline and portability still matter below the top tier. Forking, mirroring and leaving a vendor all depend on every clone being complete. Smaller companies are the ones who most need that insurance against forge lock-in.
• The incumbents will absorb the server-side ideas. Anthropic published the design and offered to help GitHub and GitLab adopt it. GVFS-to-Scalar shows the ecosystem can take an in-house scaling solution upstream in two to three years. By the time a 300-person company would hit the wall, the hosted forge will have moved it.

The honest timeline: a 12-to-24-month window in which Scion-class problems appear at companies well below Anthropic's scale (Anthropic's own estimate is six to twelve months for "this class of problem" to become commonplace), a two-to-three-year window in which forges ship server-side APIs and composable sparse features in response, and a five-year horizon at which the Git client is a compatibility shim for humans while agents speak a server protocol directly. Obsolescence of the model, not the format, and from the top of the market down.

Should you build your own source control system

For almost everyone, no. For a specific and growing set of organizations, yes, and the cost of yes just fell by an order of magnitude. The decision turns on four questions, in order.

1. Are your clients mostly online? Count checkouts by client type. If humans are under 10% of checkouts and agents and CI are the rest, Git's full-clone design is pure overhead and a server-centric system pays for itself in infrastructure alone. Anthropic reported a 200x smaller footprint and a 25% CI capacity win.
2. Is the repository bigger than a client can hold comfortably? Tens of GB of history or working copy, where shallow and sparse workarounds are themselves a maintenance burden, is the signal. Below that, Git with partial clone and sparse-checkout is fine.
3. Is the merge rate above what a global merge-queue lock can serve? Once hundreds of changes merge while a test run is in flight, the queue is the bottleneck and the design has to move to post-merge and pre-deploy verification. That change forces a redesign of CI and review regardless of VCS.
4. Can you replace review, search, CI and every Git-assuming tool at once? This is the real cost. Anthropic built Antique, code search, IAM and related systems in the same five months. If the answer is no, build the server-side APIs behind a Git front door instead and keep the tooling.

A rough cost model. Scion is the only public data point for the agent era: seven engineers, five months, with the model writing most of the code and the engineers supplying architecture, invariants and judgment. For a company without Anthropic's token budget or internal model access, a defensible planning figure is 10 to 15 senior engineers for 9 to 12 months, plus the parallel rebuild of review and CI, plus a migration window in which both systems run. Against that, the infrastructure savings at Anthropic's scale (several hundred mirrors eliminated, CI checkouts from minutes to seconds) are large enough that the project paid back inside the migration period. At a tenth of Anthropic's scale the savings are a tenth and the build cost is not, so the break-even is somewhere around the 2,000-engineer or 5,000-merges-a-day line.

The middle path most organizations should take. Keep Git as the wire protocol and client, and change what the server does:

• Expose source control queries (diff, blame, history, merge-base) as an API so CI and agents never clone.
• Perform merges and rebases server-side; make CI consume diffs from the API rather than from a checkout.
• Use partial clone, sparse-checkout and a virtual file system for the human clients that still need a working copy.
• Replace the global merge-queue lock with post-merge verification and automated revert for low-risk changes, with human review concentrated on changes the review tool classifies as consequential.
• Store agent context (prompts, traces, checkpoints) alongside commits so review can happen at the level of intent.

This gives roughly the operational benefits of Scion without abandoning the ecosystem, and it is the path Anthropic itself recommends for everyone who is not Anthropic. Whether it is delivered by GitHub, GitLab, a vendor like ERSC, or an internal platform team is a procurement question, not an architecture question.

Strategic recommendations for a platform incumbent

The incumbent's position is strong on distribution and identity and weak on infrastructure and the merge layer. The recommendations below assume the goal is to remain the default landing zone for code over the next five years, in a market where the author is increasingly an agent that someone else owns.

1. Treat reliability as the product for the next four quarters. Every competitor's launch narrative in 2026 was written against a GitHub outage. Capacity planned at 30x, the Azure migration, the AWS overflow, and the structural changes already promised are table stakes; publish the post-mortems and the capacity curve. An agent-native forge that is down during a traffic peak is not agent-native.
2. Ship a server-side source control API and propose it as a standard. Anthropic has offered, in public, to partner with GitHub, GitLab and the OSS community on server-side RPCs, a revised negotiation protocol and composable sparse and shallow features. Accept the offer and co-author the spec. The first forge to expose diff, blame, merge-base, server-side merge and rebase as a documented, rate-limited API that any agent can call becomes the default back end for every agent vendor, including the ones that compete with Copilot. Prove the economics internally first on Actions and Copilot cloud agents, which are the largest clone consumers on the platform.
3. Put the scaling work upstream into Git. Repeat the GVFS-to-Scalar play: partial clone, sparse-checkout, a lazier negotiation protocol, and object fetch by hash should land in Git itself so the client the whole world already has learns to talk to the new server. This keeps Git the protocol and makes every alternative forge's compatibility claim a claim of compatibility with your design.
4. Win the merge layer or lose the margin. Stacked PRs and the merge queue need to reach GA and become the default landing path for agent output, with post-merge verification and automated revert for low-risk changes and human review concentrated by a classifier on consequential ones. Graphite is now inside Cursor; Aviator and Mergify are independent and acquirable; Antique is private. The forge that does not own the merge decision will be charging for storage while someone else charges for judgment.
5. Own the metadata that review now needs. Entire's Checkpoints and ERSC's history model are both built on the observation that an agent's prompt, plan and trace are part of the change. Make that first-class in the PR data model and in the API so that review at the level of intent, which Anthropic describes as how its engineers now work, is native rather than bolted on by a startup. The broader case that AI-native engineering needs a provenance and proof layer on top of version control, including for regulatory reasons under the EU AI Act, has been made on HackerNoon (Git Was for Code. AI-Native Systems Need a Proof Layer).
6. Separate the forge from the agent commercially. Cursor's Origin shows the vertical play; GitLab's MCP tools show the horizontal one. The incumbent should be the governed landing zone for any agent, with agent identity, branch controls and policy that treat agents as principals, rather than betting the forge on one agent winning. Agent HQ is the right posture; the API in item 2 is what makes it credible to third parties.
7. Build a Scion-class reference deployment for the top 50 customers. The organizations that will leave Git are a known, countable set. Offer them a virtualized, server-computed, sparse-by-default configuration of the forge, co-developed, before they build their own. Losing one of them to an in-house system is a reference loss; keeping them is proof the forge scales to the agent exponential.
8. Decide the custody story explicitly. Origin shipped without data-retention terms and lost enterprise trust for it. A clear statement that hosted code is not training data, with the self-hosted and Dedicated options that GitLab already sells, is a differentiator against agent-vendor forges and a prerequisite for regulated customers moving agent workloads onto the platform.

Risks, open questions, and signals to watch

Risks to the thesis.

• Scion is one data point from the most agent-heavy company in the world. Anthropic itself says most organizations will not have these problems in the very near term. If merge rates at typical enterprises grow 3x rather than 12x, the window stretches and the incumbents have time.
• Agent-generated code volume may be partially a measurement artifact: more, smaller changes rather than more useful change. If review and verification become the hard limit, the merge layer matters more than the storage layer and the "obsolete Git" argument weakens.
• Server-centric systems reintroduce the single point of failure Git was built to remove. GitHub's 2026 outage record shows what that looks like when the server is also the only place that can compute. Scion's regional cache tiers mitigate this, but a company that moves everything server-side is betting on its own operational excellence.
• Protocol standardization efforts often stall. If GitHub, GitLab and Anthropic cannot agree on a server-side API, the market fragments into vendor-specific RPCs and the migration cost stays high.

Open questions.

• Will Anthropic release any of Scion's components, or only the design? The post says the former is impractical; a client library or protocol spec would change the competitive picture.
• What does Origin's server look like internally? Cursor has disclosed only the Git-compatible surface.
• Will Google adopt Jujutsu as the Piper client at scale now that its creator has left, and will ERSC's storage layer ship as a product or stay a design?
• How do regulators and auditors treat post-merge verification in place of pre-merge approval? Anthropic noted two human approvals per change was a compliance control it has moved away from; most regulated industries have not.

Signals to watch over the next 12 months.

• A second company below hyperscaler size publishing a Scion-style migration.
• GitHub or GitLab announcing a server-side source control API or a joint protocol effort with Anthropic.
• Patches to upstream Git for lazier negotiation or object-by-hash fetch from the forges.
• Stacked PRs and merge queue reaching GA at GitHub; Origin adding CI and public repos.
• ERSC and Entire shipping their platforms and naming customers above 1,000 engineers.
• The share of GitHub commits authored by agents (Claude Code was estimated at roughly 4% of GitHub commits as of March 2026) crossing a quarter, which is roughly where full-clone economics stop making sense for the median large repository.
• GitHub's monthly availability reports: a sustained run of months under three incidents would indicate the capacity story is fixed; another nine-incident month would not.

Sources

• Anthropic, Redesigning source control at Anthropic, October 13, 2026
• InfoQ, Cursor Releases Origin as an Agent-Native Alternative to GitHub, August 25, 2026
• Cursor, Origin documentation and changelog
• Graphite, Graphite joins Cursor, December 2025
• TechCrunch via Yahoo Finance, Cursor continues acquisition spree with Graphite deal, December 2025
• HackerNoon (SIA), Cursor's Graphite Deal Aims to Close the Loop From Writing Code to Merging It
• HackerNoon, Git Was for Code. AI-Native Systems Need a Proof Layer, April 30, 2026
• GeekWire, GitHub outage disrupts developers worldwide, August 17, 2026
• GitHub, Availability report: March 2026
• IncidentHub, GitHub Outages 2025-2026: Reliability Analysis
• DevX, GitHub Outages in 2026: Why AI Coding Agents Are Straining Its Infrastructure
• Every, Transcript: Can GitHub Be for Everyone? (AI & I with GitHub COO Kyle Daigle), June 2026
• TechCrunch, Former GitHub CEO raises record $60M dev tool seed round, February 10, 2026
• GeekWire, Former GitHub CEO's startup Entire unveils its answer to the crush of AI coding agents, 2026
• East River Source Control, Martin von Zweigbergk named CTO, 2026
• Jujutsu, jj-vcs/jj on GitHub
• Meta, facebook/sapling and sapling-scm.com
• Wikipedia, Piper (source control system)
• 01net, GitLab 19.4 Brings New Agentic Automation at a Lower Cost, September 2026
• MarketBeat, GitLab Q4 earnings call highlights, March 2026
• agentpedia.codes, GitHub Stacked Pull Requests: gh-stack Agent Guide, July 2026
• Perforce, Unity Version Control (Plastic SCM) vs. Perforce Helix Core
• Diversion, Perforce vs Plastic SCM vs Diversion
• youngju.dev, Why Developers Are Leaving GitHub for Codeberg, July 2026
• Jorijn, Why I'm leaving GitHub for Forgejo, 2026