One change through an Entire Trail: where agents step in, where people decide

On October 26, Entire, the company former GitHub CEO Thomas Dohmke started, launched a Git forge for people and agents writing code together. It has three parts: a review model called Trails, Git hosting across regions, and Continuous Memory, which stores agent sessions in the repository.¹ The headline was pushes “up to 89x faster than GitHub”. If you merge code every day, Trails matter more: which steps a change goes through, where agents act and where a person signs off.

Seven steps from Trail to merge

The launch post doesn’t lay out one ordered workflow. I pieced these seven steps together from the post and the docs.¹²

1. Open a Trail. A Trail starts from a bug report or a feature request, or an agent opens one, and it can span several repositories.¹ entire trail create --title "..." makes one in the Planning phase; entire trail link attaches a remote branch, and each linked branch is one change.²

2. A coding agent writes and pushes. On commit, Entire offers to link the commit to the agent session behind it.³ The session and prompts then live in the repository, so a later agent can look up why something changed.¹

3. Review agents score the push. This is where a Trail parts ways with a PR. Every push triggers the project’s review agents. Each runs on its own in a cloud sandbox and returns a score, a rationale and findings with severity and suggested fixes.¹ Presets cover code quality, security and “slop” (careless agent output), and you can add your own. Scores are recalculated on every push, and the page shows the current run next to the last five.²

2 ↔ 3. Low score, push again. If a score looks bad, the developer tells the coding agent to keep fixing and pushing; the post admits it takes several rounds to settle.¹ A push can mark older findings stale, but stale is not resolved: each still has to be resolved or dismissed.²

4. People look at the results. People read the scores and findings, add their own, resolve or dismiss the agents’ findings, and approve.¹

5. CI builds. Each push builds on Buildkite, Depot or your own machines; a failed build blocks the merge.¹

6. Gates. Each repository sets its merge conditions under Settings → Gates: a fresh branch, human approvals, cleared findings, passing CI.²

7. Merge. Once a change is eligible, a person selects Merge. Each change merges on its own, not the whole Trail.²

Agents write and review; people open, approve and merge

Agents act at three nodes: writing and pushing (2), scoring (3), and fixing after a low score (the loop). They can also drive CI through Buildkite’s API, CLI or MCP.¹ People act at three: opening the Trail (1), handling findings and approving (4), and merging (7). CI and gates are the platform applying rules.

What shifts is the object of review. A PR asks a person to read the diff line by line. In a Trail, agents read it first and turn it into scores and findings; the person reads those and how the scores move between pushes. The job changes from reading every line to deciding which findings must be fixed. Locally, entire review works the same way: several reviewers and a judge agent produce one verdict, and you pick the blockers.³

Two things to watch. First, approvals are only required when a gate requires them. Without that gate, nobody has to approve.² A human sign-off exists only if the team configures it. Second, if Entire only mirrors a GitHub repository, the linked GitHub pull request handles CI and merging; approvals on one side don’t count on the other, and GitHub branch rules can still block a merge.²

Read 89x and 71% as vendor numbers

The 89x comes from Entire’s own table: 418 pushes per second for Entire, 4.7 for GitHub.¹ The benchmark tool, forgemark, is open source. It has many simulated agents push small commits to their own refs in a tight loop (by default 1 to 10 files of 2 KB each), so it measures push throughput under heavy concurrency.⁵ The repository publishes no results, regions or run counts. The number says Entire can absorb a lot of agents pushing at once. It doesn’t mean your own push will feel 89 times faster.

The open-source code graph, entire-graph, claims token savings “up to 71%” depending on the scenario; the same page reports that injecting graph results into the first prompt was token-neutral (+0.7%).⁶ Tech Times notes that public repositories, self-hosting and an enterprise tier aren’t available yet, and that none of these figures has been independently replicated.⁴

Data teams can borrow score-on-push today

A merge gate of agent scores, human approval and CI doesn’t require Entire. A dbt or pipeline repository can run review agents on every push today, have them return scores and findings, and make “findings cleared” a merge condition. In the post on Snowflake’s pipeline repair agent I argued that an agent’s work should end in a PR you can review and revert. Trails move one step earlier and hand the first pass of the review to agents too. Price it first: every push runs a review round, so in the first month log what each review costs and how many findings people dismiss.