Entire can put AI review scores behind the merge button without publishing their error rates

Trails preserve agent evidence and can authorize merges, but Entire has not published the error rates needed…

The short version

Entire’s Trails connect agent activity, evaluations, CI results and approvals, then use Gates to authorize code merges.
Entire claims pushes up to 89 times faster and Graph token savings up to 71%, without sufficient validation.
Teams should pilot non-critical mirrored repositories and measure Trail errors before moving critical source code or review authority.

Entire can turn a green Trail into permission to merge code. Ask how often that Trail approves a bad change, though, and the launch material goes quiet.

That silence matters more than the shiny dashboard.

I have lost enough afternoons inside giant pull requests to deserve emotional compensation, so I get the appeal. Entire’s Git forge, launched Monday, October 26, replaces pull requests with Trails built for agent-generated code. Teams configure review agents, merge Gates, CI checks and human approvals around each change.

My recommendation: pilot Entire through a GitHub mirror if agent review is your bottleneck. Keep critical repositories where they are until you have measured Trail error rates and accepted the limits around private repositories, integrations and self-hosting.

Entire has made review programmable. Useful, yes. But when a model score can authorize a merge, engineers must define that score, measure its failures and preserve enough evidence to explain why the gate opened.

Whenever a complex decision turns green, I get suspicious.

Pull requests assumed humans could keep up

I once reviewed a pull request at my kitchen counter while reheating the same pasta twice. Fixes landed faster than I could read them. By the bottom, comments near the top referenced vanished code, CI was rerunning, and dinner had entered a legally questionable state.

Thomas Dohmke, Entire’s CEO, described the workflow’s historical importance in the company’s launch announcement:

The Pull Request revolutionized first open-source and later enterprise software development.

He is right. A pull request compresses work into a diff and chronological conversation: the author pushes, reviewers comment, automation reports, and the author revises. That works when creation and review move at human speed. A coding agent can produce another implementation while the reviewer is in a meeting or doing the radical activity known as sleeping. Correction loops stack bot findings beside human questions and explanations made obsolete three pushes ago. Human attention becomes the queue, while the final diff preserves far less context than the original request and abandoned approaches.

Trust makes that queue heavier. A survey of practitioners across dozens of countries found that 65% began with lower trust in AI-authored pull requests than human-authored ones. When uncertainty remained, 44% would block the AI-authored change, versus 19% for a human-authored change. These were stated preferences from matched survey questions, not observed production decisions, but the gap is huge.

The researchers argue that review tools should expose provenance, distinguish generated claims from human-validated evidence and show uncertainty. I agree. An agent saying “tests pass” means less than a result tied to the exact commit and environment.

Entire has a credible answer. A Trail keeps the request, agent activity, findings and evaluation history connected to the change. Reviewers get more than a final diff produced by a machine with the confidence of a Roman taxi driver.

Teams with modest agent output can keep reading diffs. I would for authentication code, billing logic and destructive migrations. Entire gets interesting when machine output already overwhelms reviewers, but the launch provides no evidence that ordinary engineering teams have universally reached that point.

Trails turn every push into a policy decision

A Trail can start with a bug report, feature request or agent workflow, and group changes across several repositories. Every push triggers configured review agents running independently in isolated cloud sandboxes. They return scores, rationales and findings. A coding agent or developer can fix a finding, dismiss it with a reason and push again. Repository-level Gates can block merging while findings remain open, and require passing CI plus human approval. Once those rules authorize a merge, the senior engineer owns a policy system whose mistakes look like clean status checks.

The CI path is simple. Connect Buildkite, and a matching branch or tag push starts a build because the integration subscribes to the Entire repository. Buildkite checks out the code and reports its status to Entire. Depot reads compatible workflow files, runs the jobs on its own compute and returns a check. A failed build can hold the Gate closed beside an unresolved reviewer finding. The corrected push restarts the loop.

Kyle Galbraith, Depot’s co-founder and CEO, put the bet clearly in Entire’s launch announcement:

The bottleneck has shifted from writing code to everything after it, and Depot CI gives developers and agents fast, reliable CI that runs the GitHub Actions workflows they already have.

I buy the diagnosis. I am more careful about grouping every result under “check.” A build result records whether a specified command succeeded in a specified environment. A security evaluator makes a probabilistic judgment that may be wrong. Human approval adds somebody’s name, although any founder who has merged code at 1 a.m. knows humans are hardly deterministic.

Green metal blocks, a translucent resin cube and a wax seal rest in a shallow beige tray.

Trails improve the evidence available to reviewers. The original request stays beside the agent trace, repeated evaluations and CI output, directly addressing the demand for provenance around machine-written code. Cross-repository Trails also suit changes where an application update requires matching documentation or website work.

The dangerous part is the green color. New Runtime’s analysis makes the strongest skeptical case: Entire has not published false-positive or false-negative rates for its reviewer agents. To buyers, its merge checks remain unmeasured probabilistic classifiers. A team can pass every visible evaluation without evidence that those evaluations catch the failures it cares about.

Nobody outside Entire knows how Trail accuracy varies by repository, language, model or severity. Nor is there evidence that Trails reduce review time, escaped defects or rollbacks versus pull requests. The interface looks finished before its confidence has been earned.

Continuous Memory can preserve mistakes too

Git remembers what landed. It usually forgets why.

A commit may preserve a refactor but lose the failed attempts and the developer’s warning that a working solution violated retry policy. The next agent must reconstruct intent from what survived. Entire Graph maps definitions, callers, types and likely change impact. Entire Brain connects captured sessions and checkpoints with project documentation, Git history and code understanding. Later agents can retrieve that material through the CLI before editing a subsystem. Saved context can prevent repeated exploration and stop an old argument restarting every Tuesday. It can also give a later agent a polished, outdated explanation detailed enough to look authoritative.

Entire says Graph can reduce token use by up to 71% versus agent exploration without the Graph approach. Results vary by coding scenario, and the company did not disclose the underlying scenario set in its launch announcement. “Up to” claims remain software’s frozen-lasagna photo: related to the product, emotionally optimistic.

The deeper question is whether curated memory beats raw-history retrieval. He and co-authors found in their Memory Tax preprint that many dedicated agent-memory systems underperformed naive retrieval in the cases evaluated. They did not test Entire Brain, so applying that result directly would be lazy. It still establishes a useful burden of proof.

Memory changes agent behavior because retrieved context determines what it investigates next. If compression drops a caveat, later work begins from an incomplete premise. If stale branch knowledge ranks highly, the agent may repeat a decision reversed elsewhere. A confident answer discourages further searching, turning a retrieval error into code. Gates may catch it if their evaluators cover the same failure mode. Otherwise, persistent memory amplifies the original mistake across sessions.

I would treat captured prompts and sessions as governed project data. Teams need deletion rules, branch-aware verification and access controls for material containing customer details or secrets. They should periodically compare Brain answers with raw history and record disagreements.

Entire has published no production evidence that Continuous Memory improves task success, prevents repeated mistakes or lowers total token cost. That absence matters more than a demo where an agent remembers a convenient architectural decision.

I would pilot Entire without surrendering the keys

Entire’s distributed hosting keeps full repository copies in regions where agents run, enabling nearby reads without routing every operation through one central location. Sensible for machine-paced traffic. But the launch material does not explain write conflicts, replication lag, failover or consistency during a regional incident.

The performance claim needs similar caution. Entire reports push performance up to 89 times faster than GitHub using its open-source ForgeMark benchmark. The announcement lacks enough workload detail to reproduce the comparison across network locations, repository shapes and concurrency levels. Open-sourcing the benchmark is good. I would still run it from my team’s actual regions before moving source control.

My pilot would use one non-critical, agent-heavy repository mirrored from GitHub. For several weeks, senior reviewers would manually inspect samples from passed and blocked Trails. We would compare every verdict with reviewer judgment and group misses by repository, language and severity. False negatives reveal bad changes the Gate allowed; false positives reveal good changes it delayed. Then I would compare queue time and escaped defects with the existing workflow. Only afterward would I test credential expiry, memory deletion and regional recovery.

Integration edges matter too. Buildkite’s Entire integration is in preview. Depot lacks pull-request events from Entire, with Trail-specific triggers still coming. Entire supports native private repositories today, while public repositories and self-hosted Git nodes remain roadmap items. That rules it out for many open-source projects and companies required to control their source-control infrastructure.

Pricing, adoption, availability guarantees and detailed security commitments also remain unknown from the launch material. Those purchasing questions have operational consequences when the product holds source code and captured agent sessions.

By mid-2027, I expect agent-heavy engineering teams to make evaluator calibration a named senior responsibility, much as release engineering outgrew whoever owned the shell script. That person will version gate rules, investigate misses and audit retained memory.

“The model said green” will still be an alibi. A flimsy one.

Frequently asked questions

What are Trails in Entire’s Git forge?

Entire Trails are change records designed for agent-generated code. They connect the original request, agent activity, findings, evaluation history and CI output across one or more repositories. Configured review agents score each push, while repository Gates can require resolved findings, passing CI and human approval before merge.

Does Entire support private repositories, Buildkite, Depot and self-hosted Git?

Entire currently supports native private repositories and connects with Buildkite and Depot. Buildkite’s Entire integration is in preview, and Depot does not yet receive pull-request events from Entire, with Trail-specific triggers still planned. Public repositories and self-hosted Git nodes remain roadmap items.

How should a team evaluate Entire before migrating?

Teams should begin with a non-critical, agent-heavy repository mirrored from GitHub. Senior reviewers should inspect samples of passed and blocked Trails, compare verdicts with human judgment, classify false negatives and false positives, and measure queue time and escaped defects before moving critical repositories or expanding automated merge authority.