On this page
Agents write code faster than most teams can decide whether that code is safe to ship. The useful question is not “will some forge replace GitHub overnight,” but who decides merge—an AI review score, a CI gate, a human approver, or some combination of all three. On October 26, 2026, Entire—CEO and co-founder Thomas Dohmke—opened an independent Git forge built around that question. The company says Entire is available to every developer today. This piece summarizes the launch news and the workflow blog as of 2026-10-27; a bake-off against GitHub, GitLab, or Cursor Origin has not been run on this site.
Nearby DigIntoAI reading on AI review economics: CodeRabbit Covers Up to $5,000 in Deep Scan Usage Through November 8.
Trails vs pull requests: what changes on the page
A classic pull request centers the diff. Comments stack in a timeline; CI shows a status near the merge button; humans (and increasingly review bots) argue in the thread. Entire’s blog argues that when agents author most of the change, that timeline becomes an audit log the agent re-reads more than the human does—and it still leaves the developer without a clear “stable enough to merge?” signal.
A Trail is Entire’s alternative HUD. Official materials describe it as bringing requirements, session traces, code changes, and review into one place—closer to a pilot’s instrument panel than to a linear comment feed. Lifecycle in three steps from the workflow blog:
- Open a Trail. Start from a bug or feature request on Entire, or from an agent before or after implementation—similar in spirit to opening a PR when you are ready to push. A Trail can span multiple repositories so related changes stay grouped.
- Score on every push. Review agents run customizable evals, each returning a score and a rationale (Entire’s ice-skating-jury metaphor). Example evals Entire says it uses on many of its own repos: Security, Slop, and Human Review Required. The last five runs plus the current run are shown so one-shot noise is visible.
- Clear findings, then merge. Agents can return specific findings with severity and suggested fixes. Open findings stay visible; resolved ones are hidden but retrievable. Findings can be addressed or dismissed by agents or humans. Humans can still post findings and comments the way they would on a PR.
The open-source Entire CLI is part of the loop: coding agents can address findings in a closed loop while a human validates progress. That is the product claim summarized here—not a claim that risky diffs can be skipped forever.
Under the hood, Entire’s blog says review agents can use stacks such as Claude Code and Codex, running in isolated cloud sandboxes (Daytona and E2B are named). This piece treats that as Entire’s stated review stack, not as an endorsement of those tools for every repo. For a price-and-limits comparison of those two agent CLIs on DigIntoAI, see Claude Code or Codex? How Their Prices and Usage Limits Compare.
Gates: what scores, tests, and humans each control
Gates are the merge policy layer. Entire says they can be enabled per repository and can require, among other checks:
| Control | What it typically answers | What it does not answer alone |
|---|---|---|
| AI eval scores / findings | Did review agents flag Slop, Security, or “human review required”? Are open findings cleared or dismissed? | Is the code safe in *your* threat model? Scores are signals, not a security guarantee. |
| CI (Buildkite / Depot) | Did build and test pipelines pass on this push? | Did tests cover the failure mode you care about? Green CI ≠ proven correct. |
| Human approval | Did a named person accept residual risk? | Did that person actually read the risky paths? Approval is accountability, not omniscience. |
In plain language: scores surface whether agent review loops have stabilized; CI checks whether automated builds and tests still pass as agents ship faster; human approval is the remaining “someone owns the merge” switch. Entire’s pitch is that you merge when confidence is high, risk is low, and findings are cleared—not that you must re-read every line of every agent-written diff. Whether that policy fits a regulated or high-stakes repo is a team decision.
That three-way split also explains why this piece skips a scare headline. A forge that scores agent work and gates merge is answering a workflow question—how to keep shipping when humans cannot line-review every agent commit. It is not proof that a current host is obsolete, and it is not a reason to rip out GitHub Actions before knowing whether Buildkite or Depot conversion fits the secrets model and runner fleet.
For GitHub-side permission and merge-adjacent tooling covered separately on DigIntoAI: GitHub Copilot Assisted Permissions Is Generally Available.
Buildkite and Depot: how CI lands in a Trail
Entire partners with Buildkite and Depot so build/test pipelines keep up with agent push volume. Official workflow notes:
- Buildkite: CI is configured at the project level (often shared across repos in a project). Once connected, every push builds on Buildkite’s or your own infrastructure; results show as a check on the Trail; a failing build can block merge. Agents can drive the loop via Buildkite’s API, CLI, or MCP. GitHub Actions users can convert workflows with
bk pipeline convertwithout a full rewrite. - Depot: Depot CI is positioned as running existing GitHub Actions–compatible workflows without GitHub in the middle. Connect from Entire, then
depot ci migratediscovers Actions workflows, promotes them to Depot CI, and flags items that need review; companion commands import secrets and variables.
Either path is “CI as a gate next to agent findings,” not “CI replaces human judgment.” Entire’s CI latency and migration cost on a sample monorepo have not been timed on this site.
Hosting boundaries: private today, public and self-host later
As of the launch materials read for this piece:
- Teams can create, migrate, and natively host private repositories on Entire.
- Regions live today: US, EU, India, and Australia (further expansion on Entire’s roadmap).
- Teams can mirror from GitHub and keep GitHub as source of truth, or migrate (Detach from GitHub in US mirroring, or the
entire-migrateplug-in, or fetch/push yourself). - Public repositories and self-hosted Git nodes are listed under upcoming / road-ahead items—not as features treated as generally available on launch day.
That boundary matters for open-source maintainers and for enterprises that need on-prem Git nodes: Entire’s launch is explicitly private-repo first. Do not plan a public-forge cutover from these two pages alone.
Mirroring deserves a careful read if evaluating without moving the source of truth. Entire describes authorizing a GitHub App, picking repos and regions, and even using Trails on top of pull requests while GitHub remains canonical. In a disruption, the blog says Entire can keep serving clones and fetches from the regional mirror, with agents able to push to Entire-native branches prefixed entire/unmirrored/ until GitHub returns. That is operational detail from Entire—not an uptime test run on this site—but it clarifies that “try Trails” and “leave GitHub” are different decisions.
Vendor speed and memory claims
Entire’s news and blog promote two performance-adjacent numbers this piece will not treat as site measurements:
- Push speed: up to about 89× faster than GitHub and about 6× faster than Cursor Origin, with an open-source benchmark table (Entire 418 pushes/sec vs GitHub 4.7, Cursor 65, and others). That is vendor-reported / vendor open-source benchmark language.
- Continuous Memory: powered by entire-graph (codebase map) and entire-brain (session memories bound to the graph). Entire says graph work saved up to about 71% on tokens in its testing. Again: vendor claim, not a token audit run on this site.
Continuous Memory is worth understanding as a product idea—sessions and prompts synced into the repo so agents stop re-learning every new context window—but the 71% figure should stay labeled as Entire’s own testing. Plan pricing, seat cost, and CI bill-by-the-second totals have not been verified from the two primary sources. This article does not recommend buying, migrating, or leaving GitHub.
How to read Trails if you are choosing a merge workflow
If the pain is “agents open PRs faster than reviewers can keep up,” Trails is aimed at that bottleneck: stabilize eval scores, clear findings, keep CI green, then let a human approve. If the pain is public OSS contribution, self-hosted compliance, or a priced migration spreadsheet, the launch pages leave those questions open—and this piece will not invent answers.
A practical checklist teams can run without adopting Entire:
- Separate three merge controls. Write down what the org already requires: automated review findings, CI green, and named human approvers. Map which failures block merge today.
- Decide what a “score” means. If adopting agent evals (on Entire or elsewhere), define whether orange Slop means “agent must continue” or “human must look.” Scores without a gate policy are dashboards, not safety.
- Keep security review out of the score alone. Treat Security evals as triage. High-risk paths, secrets, and auth still need human or specialized review. An AI review score is not a code-security guarantee.
- Match hosting to the repo shape. Private multi-region hosting may fit; public OSS and self-hosted nodes may not yet.
- Treat push-speed and token-savings slides as marketing until measured. Run local push and token baselines if those numbers matter to budget.
Entire’s push latency, Continuous Memory token savings, CI migration effort, and day-to-day Trail review quality have not been tested on this site; feedback can go through the site-owner contact link in the footer.