As of July 8, 2026, Entire, the startup founded by former Microsoft GitHub CEO Thomas Dohmke, has opened waitlist preview access to a distributed Git network that mirrors GitHub repositories onto regional infrastructure so AI coding agents can clone and pull without hammering one centralized host. The company is not merely pitching faster Git; it is arguing that centralized repository hosting has become a bottleneck for software development in the agent era. That is a provocative claim from a founder whose previous job sat at the center of the modern Git universe. It is also exactly the kind of claim that will be tested not by launch rhetoric, but by whether developers trust a new layer in the most sensitive part of their toolchain.
Entire’s announcement, reported by SD Times, lands with unusually large expectations attached: the company attracted $60 million in seed money five months ago at a $300 million valuation, a round that backer Felicis described as the largest seed round in developer tools history. That financial context matters because this is not a small utility company trying to shave seconds off CI jobs. Entire is trying to create a new infrastructure category around Git traffic, coding agents, repository-local memory, and eventually a fully decentralized network.
The basic product pitch is simple enough. A developer can mirror an existing GitHub repository onto Entire’s network while the canonical code remains where it is. From there, agents clone and pull from a regional Entire mirror rather than all hammering the same centralized platform.
That approach is meant to solve a very specific pain point in modern AI-assisted development: agents do not behave like humans. A developer may clone a repository occasionally and push a coherent branch after a burst of work. Agents can repeatedly clone, inspect, branch, push, discard, retry, and repeat at a scale that makes old assumptions about repository traffic look quaint.
Entire’s argument is that this shift turns centralized Git hosting from a convenience into a constraint. Rate limits, high latency, and outages are no longer rare annoyances at the edge of normal development; in agent-heavy workflows, they become part of the architecture. If ten developers become ten developers plus hundreds of automated workers, the repository host is no longer just a source of truth. It is a high-throughput coordination service for machines.
That is why Entire’s first public posture is not “GitHub alternative” in the old sense. It is closer to a regional distribution layer for Git, with a larger ambition to become a decentralized repository network. The company says developers will eventually be able to host repositories natively, worldwide, without a single central provider.
The distinction is important. Mirrors are easier to adopt because they do not require an immediate migration away from GitHub. Native hosting on a decentralized network is a much bigger bet. Entire is starting where the pain is easiest to understand — read-heavy agent traffic — while gesturing toward a future in which the repository itself is no longer anchored to a single platform.
That quote is doing a lot of work. Git’s original architecture was famously distributed; the modern developer experience, however, became organized around centralized collaboration hubs. GitHub, GitLab, Bitbucket, and enterprise-hosted equivalents made distributed version control usable for teams by centralizing identity, pull requests, review, permissions, issue tracking, automation, and policy.
Entire is arguing that the pendulum has swung too far. Not because centralized platforms failed, but because they succeeded so completely that nearly every modern development workflow depends on them. Once AI agents enter the loop at volume, the central repository host becomes the place where compute ambition collides with infrastructure limits.
Dohmke’s thesis is that the agent era exposes a mismatch between Git’s distributed design and the centralized services wrapped around it. “Today, we begin to return Git to its original promise,” he said in the announcement, describing a distributed and soon fully decentralized, open-sourced network of interconnected nodes. The target is not nostalgia. It is locality: agents and developers should push, pull, and clone close to where they operate.
That is a plausible technical thesis, but it also creates a trust problem. Developers tolerate centralized platforms partly because those platforms are known quantities. They have established security models, audit practices, ecosystem integrations, and failure modes. A new distributed Git network must prove not only that it is faster, but that it is safer, governable, observable, and boring enough to place in the path of production software.
That is the real bar for Entire. Developer tools do not win solely by being architecturally elegant. They win when teams can adopt them without rewriting their compliance model, retraining every engineer, or explaining to auditors why repository data, session logs, and agent history now live in a new distributed substrate.
The push benchmark is even more aggressive. Entire says it sustained 586 pushes per second, or about 2.1 million per hour, to a single repository or branch. That test involved 128 simulated agents pushing one to 10 files per push, each file 2 KB, over two minutes. Entire notes that this was tested on Entire native repositories.
The mixed workload is the most interesting because it better resembles an agent loop. Entire says 128 simulated agents repeatedly ran shallow clone, five pushes, and repeat, sustaining roughly 470 clone and push operations per second on a single repository at around 50 to 60 milliseconds p50 latency.
These are launch benchmarks, so they should be read as evidence of design intent rather than proof of real-world dominance. The tests are short, controlled, and described at a high level. They do not answer every question an infrastructure engineer would ask about repository size, history depth, authentication overhead, packfile behavior, write contention, branch explosion, geographic failure modes, or adversarial traffic.
But they do reveal what Entire thinks the bottleneck is. The company is not optimizing for the lone developer who complains that a clone took too long from a coffee shop. It is optimizing for many automated workers repeatedly touching the same repository, where the limiting factor is not human patience but aggregate machine throughput.
That makes the benchmark framing significant. Entire is betting that the next wave of repository stress will come from AI agents doing routine, repetitive, parallelizable work: inspecting code, applying changes, validating alternatives, generating branches, and seeking review. In that world, the repository host becomes a shared hot path for automation.
The numbers also point to an architectural boundary. Clone-heavy workloads can be served from regional mirrors, which is cleaner because reads are easier to scale and cache than writes. Push-heavy workloads are more complex because they imply coordination, ordering, permissions, conflict handling, and durability. Entire’s push benchmark on native repositories therefore matters, but it also raises the harder question of how the system behaves once it is not just absorbing test pushes from simulated agents but mediating real branches, reviews, policies, and human decisions.
For teams experimenting with coding agents, that may be enough. If agents are failing because of rate limits or because remote clone and pull operations add too much latency, a regional mirror could make the workflow feel less brittle. It also lets engineering leaders test the model without asking every developer to change where pull requests live.
But mirroring creates its own conceptual split. Where does truth live? Where does policy live? Where do credentials terminate? If an agent clones from a regional Entire mirror, pushes somewhere else, and the human review process remains on GitHub, the enterprise has to understand the path code and metadata take through each system.
This is why Entire’s long-term language matters. The company says data residency, sovereignty, and scale will be enabled when it decentralizes its network, allowing developers to host repositories natively. That is a bigger claim than faster Git operations. Data residency and sovereignty are procurement words, not just engineering words. They imply enterprises that need control over where code lives, where metadata is processed, and which jurisdictions can touch their development artifacts.
For WindowsForum’s IT audience, the parallel to cloud architecture is familiar. Centralization usually wins until scale, latency, compliance, or resilience pushes workloads outward. Then the hard part becomes managing the distributed system you just created. Entire is proposing the same arc for Git: keep the collaboration benefits of a global network, but move storage and traffic closer to developers and agents.
The catch is that Git repositories are not ordinary caches. They are sensitive, high-value, policy-laden assets. Source code contains credentials by accident, security fixes before disclosure, product strategy, infrastructure templates, and the history of how a company thinks. A distributed Git network has to be treated less like a CDN for text files and more like critical software supply-chain infrastructure.
Dohmke’s line is blunt: “Session logs are now the second most important artifact in software development, and they belong in the repository alongside the code.” That is a worldview, not a feature description. It says that in AI-assisted development, prompts, tool calls, checkpoints, and agent decisions are no longer disposable exhaust. They are part of the engineering record.
This is where Entire moves beyond performance and into software process. Traditional version control answers who changed what and when. Commit messages attempt, unevenly, to answer why. Code review adds discussion, but often outside the repository’s durable structure. AI agents complicate this because a change may be produced through many prompts, retries, hidden intermediate states, and tool invocations.
Entire’s answer is to bind that context to the repository. Entire Blame is designed to show why someone touched the code, including the agent session, prompt, and decision behind it. Entire Review sends a branch to multiple agents in parallel for an intent-aware review. Code and semantic search let developers and agents search both code history and the reasons changes were written.
That model has obvious benefits. If an agent repeats a mistake, repository-local memory can help future agents avoid it. Dohmke says that with semantic memory tied to the repo, agents stop repeating mistakes, improving accuracy, productivity, and token spend. For teams paying for large volumes of model usage, “lower token spend” is not a throwaway phrase; it is the economic argument for memory.
It also has audit value. If developers can understand and verify what was built and why, review can become faster, as Dohmke argues. In regulated or security-conscious environments, having the prompt and tool chain attached to the code could make agent-generated changes more reviewable than a mysterious human commit with a vague message.
But this is also where Entire enters dangerous territory. Session logs can contain secrets, customer data, vulnerability details, internal architecture, unreleased features, and legally sensitive instructions. Storing prompts, tool calls, and checkpoints “directly in the repository alongside the code” may be the right architectural move for traceability, but it is also a governance challenge.
Enterprises will need retention rules, redaction, access controls, encryption boundaries, and discovery policies for these artifacts. If session logs become the second most important artifact in software development, they also become the second most important artifact to secure.
Dohmke’s final claim in the announcement is the broadest: Entire’s approach opens the possibility of a new developer lifecycle that can understand and reason over the massive volumes of code AI agents now generate. That is the heart of the matter. If agents generate more code than humans can comfortably read, then the development lifecycle needs new tools for intent, provenance, summarization, comparison, and trust.
Entire Review is one answer: send a branch to multiple agents in parallel and get an intent-aware review. The concept fits the moment. If one agent writes the code, another can review it, a third can search for architectural drift, and a fourth can test assumptions against prior session history. But this creates a recursive trust problem: when agents review agents, humans need a way to understand both the output and the reasoning.
That makes repository-attached semantic history valuable. A human reviewer does not just need to know that a function changed. The reviewer needs to know what the agent believed it was doing, what prompt initiated the change, what tools it called, what alternatives it may have tried, and whether it ignored relevant prior decisions.
In a mature version of this workflow, “blame” stops being a socially loaded command for identifying who broke something and becomes a forensic tool for understanding intent. That is what Entire is reaching for with Entire Blame. The feature name is familiar, but the object of blame changes: not just a person and a commit hash, but a session, a prompt, and a decision trail.
The practical consequence is that version control may become less about storing code and more about storing the complete operational memory of software construction. That is a much larger scope for a repository. It also means repository performance, access control, indexing, and search become more important than they were in the human-only era.
Enterprises already struggle to govern code moving through GitHub organizations, Azure DevOps projects, self-hosted GitLab instances, CI runners, package registries, and cloud build systems. Adding AI agents multiplies the number of actors that can touch code. Adding a distributed Git network changes where repository data and metadata may flow.
That does not make Entire risky by default. It makes it infrastructure. Infrastructure needs controls.
The most immediate enterprise use case is likely safe experimentation: mirror a non-sensitive GitHub repository, point coding agents at regional mirrors for read-heavy work, and measure whether rate limits and latency improve. If the value is real, teams can expand gradually. If the governance story is incomplete, they can stop before the system touches critical repositories.
The deeper question is identity. Agents need credentials. Repositories need permissions. Session logs need access rules. If Entire becomes the place where agents clone, pull, push, remember, and review, then it becomes part of the trust boundary around the codebase. Enterprises will want to know how identity maps from existing providers, how branch protections are preserved, how audit logs are exported, and how incident response works when something goes wrong.
Admins should also think about data classification. A repository mirror may be acceptable for public or low-risk code. A repository containing proprietary platform code, customer-specific logic, infrastructure-as-code templates, or security fixes demands a different review. The same is true for session logs: a prompt can be more sensitive than the resulting code if it includes business rationale, credentials pasted by mistake, or internal vulnerability context.
This is where Entire’s future promises around data residency and sovereignty could become decisive. Many organizations will not be comfortable with agent memory and repository mirrors unless they can control region, storage, encryption, and operational access. The company’s plan to decentralize and open source the network may help, but those claims will need to materialize into deployable, inspectable, supportable options.
Open source can help in several ways. It allows security review. It lets enterprises understand behavior under failure. It gives developers confidence that a core workflow will not vanish behind a pricing change or platform pivot. It can also encourage ecosystem integrations, which are essential if Entire wants to coexist with GitHub rather than merely compete with it.
But open source does not automatically solve operational trust. The most important questions may live outside the code: who runs the nodes, how updates are shipped, how abuse is handled, how metadata is protected, how customers choose regions, and how commercial control interacts with decentralized architecture. A network can be open-sourced and still operationally centralized in practice.
This is why Entire’s launch should be read as the beginning of a technical argument, not the end of one. The company has offered performance numbers, a philosophical case, and an adoption wedge. Now it has to prove that the system works under messy enterprise conditions: huge repositories, monorepos, partial clones, long histories, binary assets, flaky networks, strict compliance, and developers who do not want to think about any of this before coffee.
The most promising part of Entire’s strategy is that it does not require the whole industry to abandon its current tools on day one. Mirroring lets the company attach to existing GitHub-centered workflows. The most difficult part is that the company’s ultimate ambition — a fully decentralized network for code and agent memory — asks the industry to rethink where software truth resides.
That tension is not a flaw. It is the product.
Entire’s stronger argument is narrower and more credible: centralized Git hosting may become too expensive, too rate-limited, or too latency-sensitive for the most aggressive agent workloads. That does not kill the central platform. It changes its role. The central host may remain the place where humans collaborate and policy is enforced, while distributed mirrors and native agent-aware back ends absorb machine traffic.
This resembles the way web architecture evolved. Origin servers did not disappear when CDNs became essential. They became protected, abstracted, and surrounded by layers optimized for traffic patterns the origin was not meant to handle alone. Entire is effectively asking whether Git needs a similar distribution layer for the agent era.
The analogy is imperfect because Git is already distributed, and because source code is far more sensitive than ordinary web assets. Still, the traffic-pattern argument is persuasive. If agents dramatically increase repository operations, the industry will need some combination of smarter caching, regional distribution, protocol optimization, host-side scaling, and policy-aware automation.
Entire is one possible answer. GitHub and other incumbents may offer their own. Enterprises may build internal mirrors. Cloud development environments may hide some of the problem by keeping working copies warm and close to compute. The outcome is unlikely to be one winner replacing all existing Git hosts. It is more likely to be a new layer in the stack, with different organizations choosing how much of it they trust.
What Entire has done is name the pressure point. The agent era turns Git from a developer-facing tool into machine-facing infrastructure. Once that happens, old assumptions about acceptable latency, clone frequency, review volume, and repository metadata start to break.
February — Entire launched under founder Thomas Dohmke, the former Microsoft GitHub CEO.
Five months before the preview announcement — Entire attracted $60 million in seed money at a $300 million valuation, described by Felicis as the largest seed round in developer tools history.
July 8, 2026 — Entire’s preview is open under waitlist, allowing developers to mirror existing GitHub repositories onto Entire’s distributed Git network.
That is a reasonable bet because agent output without provenance is hard to trust. A branch generated by an AI assistant may compile, pass tests, and still embody a wrong assumption. If the repository can show the prompt, the session, the tool calls, the checkpoints, and the decision path, reviewers have a better chance of catching the gap between what the agent did and what the organization actually intended.
The challenge is that every gain in context creates a new burden in governance. More memory means more searchable truth, but also more sensitive material to protect. More distributed infrastructure means lower latency and fewer bottlenecks, but also more places where policy must be enforced. More agent participation means more productivity, but also more review debt unless the lifecycle changes with it.
Entire is entering the market at the moment when that tradeoff is becoming unavoidable. If AI coding agents remain occasional assistants, centralized Git hosts can probably absorb the change with incremental improvements. If agents become persistent, parallel participants in the development process, the repository layer will need to become faster, more local, more semantic, and more accountable.
That is the bet Entire is making with unusual clarity: Git’s distributed past may be the blueprint for its agent-saturated future, but only if the industry can add the missing pieces — trust, memory, governance, and scale — without turning the software supply chain into another opaque platform dependency.
Entire Wants to Move Git’s Center of Gravity
Entire’s announcement, reported by SD Times, lands with unusually large expectations attached: the company attracted $60 million in seed money five months ago at a $300 million valuation, a round that backer Felicis described as the largest seed round in developer tools history. That financial context matters because this is not a small utility company trying to shave seconds off CI jobs. Entire is trying to create a new infrastructure category around Git traffic, coding agents, repository-local memory, and eventually a fully decentralized network.The basic product pitch is simple enough. A developer can mirror an existing GitHub repository onto Entire’s network while the canonical code remains where it is. From there, agents clone and pull from a regional Entire mirror rather than all hammering the same centralized platform.
That approach is meant to solve a very specific pain point in modern AI-assisted development: agents do not behave like humans. A developer may clone a repository occasionally and push a coherent branch after a burst of work. Agents can repeatedly clone, inspect, branch, push, discard, retry, and repeat at a scale that makes old assumptions about repository traffic look quaint.
Entire’s argument is that this shift turns centralized Git hosting from a convenience into a constraint. Rate limits, high latency, and outages are no longer rare annoyances at the edge of normal development; in agent-heavy workflows, they become part of the architecture. If ten developers become ten developers plus hundreds of automated workers, the repository host is no longer just a source of truth. It is a high-throughput coordination service for machines.
That is why Entire’s first public posture is not “GitHub alternative” in the old sense. It is closer to a regional distribution layer for Git, with a larger ambition to become a decentralized repository network. The company says developers will eventually be able to host repositories natively, worldwide, without a single central provider.
The distinction is important. Mirrors are easier to adopt because they do not require an immediate migration away from GitHub. Native hosting on a decentralized network is a much bigger bet. Entire is starting where the pain is easiest to understand — read-heavy agent traffic — while gesturing toward a future in which the repository itself is no longer anchored to a single platform.
Dohmke’s GitHub Past Makes the Pitch Sharper, Not Softer
There is an obvious irony in a former Microsoft GitHub CEO launching a company built around the limits of centralized Git platforms. Dohmke’s framing leans into that tension rather than avoiding it. In Entire’s announcement, he invokes Linus Torvalds’ 2007 Google Tech Talk line: “If you’re not distributed, you’re not worth using.”That quote is doing a lot of work. Git’s original architecture was famously distributed; the modern developer experience, however, became organized around centralized collaboration hubs. GitHub, GitLab, Bitbucket, and enterprise-hosted equivalents made distributed version control usable for teams by centralizing identity, pull requests, review, permissions, issue tracking, automation, and policy.
Entire is arguing that the pendulum has swung too far. Not because centralized platforms failed, but because they succeeded so completely that nearly every modern development workflow depends on them. Once AI agents enter the loop at volume, the central repository host becomes the place where compute ambition collides with infrastructure limits.
Dohmke’s thesis is that the agent era exposes a mismatch between Git’s distributed design and the centralized services wrapped around it. “Today, we begin to return Git to its original promise,” he said in the announcement, describing a distributed and soon fully decentralized, open-sourced network of interconnected nodes. The target is not nostalgia. It is locality: agents and developers should push, pull, and clone close to where they operate.
That is a plausible technical thesis, but it also creates a trust problem. Developers tolerate centralized platforms partly because those platforms are known quantities. They have established security models, audit practices, ecosystem integrations, and failure modes. A new distributed Git network must prove not only that it is faster, but that it is safer, governable, observable, and boring enough to place in the path of production software.
That is the real bar for Entire. Developer tools do not win solely by being architecturally elegant. They win when teams can adopt them without rewriting their compliance model, retraining every engineer, or explaining to auditors why repository data, session logs, and agent history now live in a new distributed substrate.
The Benchmark Numbers Are Built for Agent Anxiety
Entire’s launch data is striking because it focuses on the operations that agent-heavy development stresses most: clone, push, and mixed clone-push loops. According to Entire’s announcement, its rebuilt Git back end sustained roughly 570,000 clones per hour from a single repository. That test used 200 simulated clients shallow-cloning from Frankfurt, Paris, London, and Dublin over about three minutes, with Frankfurt accounting for 40 percent of the simulated clients.The push benchmark is even more aggressive. Entire says it sustained 586 pushes per second, or about 2.1 million per hour, to a single repository or branch. That test involved 128 simulated agents pushing one to 10 files per push, each file 2 KB, over two minutes. Entire notes that this was tested on Entire native repositories.
The mixed workload is the most interesting because it better resembles an agent loop. Entire says 128 simulated agents repeatedly ran shallow clone, five pushes, and repeat, sustaining roughly 470 clone and push operations per second on a single repository at around 50 to 60 milliseconds p50 latency.
| Benchmark | Sustained result | Simulated workload | Duration | Repository mode |
|---|---|---|---|---|
| Git Clone | ~570,000 clones/hour | 200 simulated clients shallow-cloning from Frankfurt, Paris, London, and Dublin | ~3 minutes | Single repository |
| Git Push | 586 pushes/second, or ~2.1 million/hour | 128 simulated agents pushing 1–10 files, 2 KB each, per push | 2 minutes | Entire native repositories |
| Clone + Push | ~470 clone + push operations/second | 128 simulated agents running shallow clone → 5 pushes → repeat | Not separately stated | Single repository, ~50–60 ms p50 latency |
But they do reveal what Entire thinks the bottleneck is. The company is not optimizing for the lone developer who complains that a clone took too long from a coffee shop. It is optimizing for many automated workers repeatedly touching the same repository, where the limiting factor is not human patience but aggregate machine throughput.
That makes the benchmark framing significant. Entire is betting that the next wave of repository stress will come from AI agents doing routine, repetitive, parallelizable work: inspecting code, applying changes, validating alternatives, generating branches, and seeking review. In that world, the repository host becomes a shared hot path for automation.
The numbers also point to an architectural boundary. Clone-heavy workloads can be served from regional mirrors, which is cleaner because reads are easier to scale and cache than writes. Push-heavy workloads are more complex because they imply coordination, ordering, permissions, conflict handling, and durability. Entire’s push benchmark on native repositories therefore matters, but it also raises the harder question of how the system behaves once it is not just absorbing test pushes from simulated agents but mediating real branches, reviews, policies, and human decisions.
Mirroring GitHub Is the Wedge, Not the Destination
The preview product is deliberately conservative in one sense: it mirrors existing GitHub repositories rather than demanding that teams move their source of truth immediately. That lowers the adoption barrier. A team can keep GitHub as the center of collaboration while using Entire to offload heavy, concurrent read traffic from agents.For teams experimenting with coding agents, that may be enough. If agents are failing because of rate limits or because remote clone and pull operations add too much latency, a regional mirror could make the workflow feel less brittle. It also lets engineering leaders test the model without asking every developer to change where pull requests live.
But mirroring creates its own conceptual split. Where does truth live? Where does policy live? Where do credentials terminate? If an agent clones from a regional Entire mirror, pushes somewhere else, and the human review process remains on GitHub, the enterprise has to understand the path code and metadata take through each system.
This is why Entire’s long-term language matters. The company says data residency, sovereignty, and scale will be enabled when it decentralizes its network, allowing developers to host repositories natively. That is a bigger claim than faster Git operations. Data residency and sovereignty are procurement words, not just engineering words. They imply enterprises that need control over where code lives, where metadata is processed, and which jurisdictions can touch their development artifacts.
For WindowsForum’s IT audience, the parallel to cloud architecture is familiar. Centralization usually wins until scale, latency, compliance, or resilience pushes workloads outward. Then the hard part becomes managing the distributed system you just created. Entire is proposing the same arc for Git: keep the collaboration benefits of a global network, but move storage and traffic closer to developers and agents.
The catch is that Git repositories are not ordinary caches. They are sensitive, high-value, policy-laden assets. Source code contains credentials by accident, security fixes before disclosure, product strategy, infrastructure templates, and the history of how a company thinks. A distributed Git network has to be treated less like a CDN for text files and more like critical software supply-chain infrastructure.
The Semantic Memory Layer Is the More Radical Product
The network is the headline, but Entire’s semantic memory layer may be the more consequential idea. The company says it already offers a memory layer that integrates with all major coding agents and automatically stores each session, prompt, tool call, and checkpoint directly in the repository alongside the code. In other words, Entire wants the repository to contain not just what changed, but the machine-readable story of how the change came to exist.Dohmke’s line is blunt: “Session logs are now the second most important artifact in software development, and they belong in the repository alongside the code.” That is a worldview, not a feature description. It says that in AI-assisted development, prompts, tool calls, checkpoints, and agent decisions are no longer disposable exhaust. They are part of the engineering record.
This is where Entire moves beyond performance and into software process. Traditional version control answers who changed what and when. Commit messages attempt, unevenly, to answer why. Code review adds discussion, but often outside the repository’s durable structure. AI agents complicate this because a change may be produced through many prompts, retries, hidden intermediate states, and tool invocations.
Entire’s answer is to bind that context to the repository. Entire Blame is designed to show why someone touched the code, including the agent session, prompt, and decision behind it. Entire Review sends a branch to multiple agents in parallel for an intent-aware review. Code and semantic search let developers and agents search both code history and the reasons changes were written.
That model has obvious benefits. If an agent repeats a mistake, repository-local memory can help future agents avoid it. Dohmke says that with semantic memory tied to the repo, agents stop repeating mistakes, improving accuracy, productivity, and token spend. For teams paying for large volumes of model usage, “lower token spend” is not a throwaway phrase; it is the economic argument for memory.
It also has audit value. If developers can understand and verify what was built and why, review can become faster, as Dohmke argues. In regulated or security-conscious environments, having the prompt and tool chain attached to the code could make agent-generated changes more reviewable than a mysterious human commit with a vague message.
But this is also where Entire enters dangerous territory. Session logs can contain secrets, customer data, vulnerability details, internal architecture, unreleased features, and legally sensitive instructions. Storing prompts, tool calls, and checkpoints “directly in the repository alongside the code” may be the right architectural move for traceability, but it is also a governance challenge.
Enterprises will need retention rules, redaction, access controls, encryption boundaries, and discovery policies for these artifacts. If session logs become the second most important artifact in software development, they also become the second most important artifact to secure.
Agent-Scale Development Breaks Old Review Assumptions
The conventional code review model assumes scarcity. A human author prepares a change, reviewers inspect it, CI validates it, and a merge gate decides whether it lands. AI agents alter that rhythm by making code generation cheaper, faster, and more parallel. The bottleneck moves from authoring to understanding.Dohmke’s final claim in the announcement is the broadest: Entire’s approach opens the possibility of a new developer lifecycle that can understand and reason over the massive volumes of code AI agents now generate. That is the heart of the matter. If agents generate more code than humans can comfortably read, then the development lifecycle needs new tools for intent, provenance, summarization, comparison, and trust.
Entire Review is one answer: send a branch to multiple agents in parallel and get an intent-aware review. The concept fits the moment. If one agent writes the code, another can review it, a third can search for architectural drift, and a fourth can test assumptions against prior session history. But this creates a recursive trust problem: when agents review agents, humans need a way to understand both the output and the reasoning.
That makes repository-attached semantic history valuable. A human reviewer does not just need to know that a function changed. The reviewer needs to know what the agent believed it was doing, what prompt initiated the change, what tools it called, what alternatives it may have tried, and whether it ignored relevant prior decisions.
In a mature version of this workflow, “blame” stops being a socially loaded command for identifying who broke something and becomes a forensic tool for understanding intent. That is what Entire is reaching for with Entire Blame. The feature name is familiar, but the object of blame changes: not just a person and a commit hash, but a session, a prompt, and a decision trail.
The practical consequence is that version control may become less about storing code and more about storing the complete operational memory of software construction. That is a much larger scope for a repository. It also means repository performance, access control, indexing, and search become more important than they were in the human-only era.
The Windows and Enterprise Angle Is Supply Chain, Not Syntax
This story is not Windows-specific in the narrow sense. Git is cross-platform, and coding agents do not care much whether a developer is on Windows, macOS, Linux, or in a cloud dev container. But for WindowsForum’s audience — admins, enterprise developers, consultants, and IT pros — Entire’s launch belongs squarely in the software supply-chain conversation.Enterprises already struggle to govern code moving through GitHub organizations, Azure DevOps projects, self-hosted GitLab instances, CI runners, package registries, and cloud build systems. Adding AI agents multiplies the number of actors that can touch code. Adding a distributed Git network changes where repository data and metadata may flow.
That does not make Entire risky by default. It makes it infrastructure. Infrastructure needs controls.
The most immediate enterprise use case is likely safe experimentation: mirror a non-sensitive GitHub repository, point coding agents at regional mirrors for read-heavy work, and measure whether rate limits and latency improve. If the value is real, teams can expand gradually. If the governance story is incomplete, they can stop before the system touches critical repositories.
The deeper question is identity. Agents need credentials. Repositories need permissions. Session logs need access rules. If Entire becomes the place where agents clone, pull, push, remember, and review, then it becomes part of the trust boundary around the codebase. Enterprises will want to know how identity maps from existing providers, how branch protections are preserved, how audit logs are exported, and how incident response works when something goes wrong.
Admins should also think about data classification. A repository mirror may be acceptable for public or low-risk code. A repository containing proprietary platform code, customer-specific logic, infrastructure-as-code templates, or security fixes demands a different review. The same is true for session logs: a prompt can be more sensitive than the resulting code if it includes business rationale, credentials pasted by mistake, or internal vulnerability context.
This is where Entire’s future promises around data residency and sovereignty could become decisive. Many organizations will not be comfortable with agent memory and repository mirrors unless they can control region, storage, encryption, and operational access. The company’s plan to decentralize and open source the network may help, but those claims will need to materialize into deployable, inspectable, supportable options.
Action checklist for admins
- Start with a non-critical repository and treat Entire as a mirror layer, not a new source of truth.
- Measure clone, pull, push, and CI-agent behavior before and after mirroring to confirm the bottleneck is real.
- Classify session logs as sensitive development artifacts, not disposable telemetry.
- Review how prompts, tool calls, checkpoints, and agent decisions are stored, retained, searched, and deleted.
- Confirm how existing branch protections, identity rules, secrets scanning, and audit workflows apply.
- Require a rollback plan that returns agents to the existing Git host if the mirror layer fails or creates policy conflicts.
The Open-Source Promise Is Necessary but Not Sufficient
Entire says the rebuilt Git back end will be open sourced, and Dohmke describes the network as soon fully decentralized and open-sourced. For developer infrastructure, that promise is almost mandatory. A closed black box sitting between agents and repositories would be a hard sell to the very audience most likely to understand the risks.Open source can help in several ways. It allows security review. It lets enterprises understand behavior under failure. It gives developers confidence that a core workflow will not vanish behind a pricing change or platform pivot. It can also encourage ecosystem integrations, which are essential if Entire wants to coexist with GitHub rather than merely compete with it.
But open source does not automatically solve operational trust. The most important questions may live outside the code: who runs the nodes, how updates are shipped, how abuse is handled, how metadata is protected, how customers choose regions, and how commercial control interacts with decentralized architecture. A network can be open-sourced and still operationally centralized in practice.
This is why Entire’s launch should be read as the beginning of a technical argument, not the end of one. The company has offered performance numbers, a philosophical case, and an adoption wedge. Now it has to prove that the system works under messy enterprise conditions: huge repositories, monorepos, partial clones, long histories, binary assets, flaky networks, strict compliance, and developers who do not want to think about any of this before coffee.
The most promising part of Entire’s strategy is that it does not require the whole industry to abandon its current tools on day one. Mirroring lets the company attach to existing GitHub-centered workflows. The most difficult part is that the company’s ultimate ambition — a fully decentralized network for code and agent memory — asks the industry to rethink where software truth resides.
That tension is not a flaw. It is the product.
Centralized Git Is Not Dead, but It Is Being Repriced
It would be easy to overstate this launch as the beginning of the end for centralized Git hosting. That is not what the evidence supports. GitHub and its peers remain deeply embedded because they are not merely Git remotes. They are collaboration systems, automation hubs, security surfaces, social networks, policy engines, and enterprise procurement line items.Entire’s stronger argument is narrower and more credible: centralized Git hosting may become too expensive, too rate-limited, or too latency-sensitive for the most aggressive agent workloads. That does not kill the central platform. It changes its role. The central host may remain the place where humans collaborate and policy is enforced, while distributed mirrors and native agent-aware back ends absorb machine traffic.
This resembles the way web architecture evolved. Origin servers did not disappear when CDNs became essential. They became protected, abstracted, and surrounded by layers optimized for traffic patterns the origin was not meant to handle alone. Entire is effectively asking whether Git needs a similar distribution layer for the agent era.
The analogy is imperfect because Git is already distributed, and because source code is far more sensitive than ordinary web assets. Still, the traffic-pattern argument is persuasive. If agents dramatically increase repository operations, the industry will need some combination of smarter caching, regional distribution, protocol optimization, host-side scaling, and policy-aware automation.
Entire is one possible answer. GitHub and other incumbents may offer their own. Enterprises may build internal mirrors. Cloud development environments may hide some of the problem by keeping working copies warm and close to compute. The outcome is unlikely to be one winner replacing all existing Git hosts. It is more likely to be a new layer in the stack, with different organizations choosing how much of it they trust.
What Entire has done is name the pressure point. The agent era turns Git from a developer-facing tool into machine-facing infrastructure. Once that happens, old assumptions about acceptable latency, clone frequency, review volume, and repository metadata start to break.
Timeline
2007 — Linus Torvalds, in a Google Tech Talk later quoted by Dohmke, framed Git’s distributed nature with the line: “If you’re not distributed, you’re not worth using.”February — Entire launched under founder Thomas Dohmke, the former Microsoft GitHub CEO.
Five months before the preview announcement — Entire attracted $60 million in seed money at a $300 million valuation, described by Felicis as the largest seed round in developer tools history.
July 8, 2026 — Entire’s preview is open under waitlist, allowing developers to mirror existing GitHub repositories onto Entire’s distributed Git network.
What the Launch Actually Proves
Entire’s launch proves that serious capital and serious Git experience are now chasing the same conclusion: AI agents will stress developer infrastructure in ways that conventional human-centered workflows did not. It does not yet prove that Entire’s architecture will become the industry standard. It does show that the repository is becoming the next battleground for AI tooling.- Entire’s first wedge is GitHub mirroring, not a forced migration away from existing repository hosts.
- The company’s benchmark story is aimed at agent-scale clone and push pressure, especially repeated machine workflows.
- The semantic memory layer may matter as much as the network because it treats prompts, tool calls, checkpoints, and decisions as repository artifacts.
- Enterprises should evaluate session logs as sensitive supply-chain data, not as harmless AI telemetry.
- The promised decentralized and open-sourced network will need to prove governance, security, and operability as much as raw speed.
- Centralized Git hosting is not going away, but agent traffic may push more teams toward regional distribution and repository-local memory.
That is a reasonable bet because agent output without provenance is hard to trust. A branch generated by an AI assistant may compile, pass tests, and still embody a wrong assumption. If the repository can show the prompt, the session, the tool calls, the checkpoints, and the decision path, reviewers have a better chance of catching the gap between what the agent did and what the organization actually intended.
The challenge is that every gain in context creates a new burden in governance. More memory means more searchable truth, but also more sensitive material to protect. More distributed infrastructure means lower latency and fewer bottlenecks, but also more places where policy must be enforced. More agent participation means more productivity, but also more review debt unless the lifecycle changes with it.
Entire is entering the market at the moment when that tradeoff is becoming unavoidable. If AI coding agents remain occasional assistants, centralized Git hosts can probably absorb the change with incremental improvements. If agents become persistent, parallel participants in the development process, the repository layer will need to become faster, more local, more semantic, and more accountable.
That is the bet Entire is making with unusual clarity: Git’s distributed past may be the blueprint for its agent-saturated future, but only if the industry can add the missing pieces — trust, memory, governance, and scale — without turning the software supply chain into another opaque platform dependency.
References
- Primary source: SD Times
Published: 2026-07-08T15:53:12.737833
Loading…
sdtimes.com