Entire 推出專為代理人與人類協作的 Git Forge

After more than a year of hammering the iron, we’re excited to introduce the first Git forge built specifically for agent-human collaboration. Entire is built on three primitives:

1. The Trail. Unlike the classic pull request model of reviewing code changes with a diff, Trails offers developers a heads-up display similar to an airline pilot, with automated customizable evals that are scored by agents on every code push.
2. Distributed Git hosting. Entire is built on a new source control server compatible with Git, which pushes up to 89x faster than GitHub and 6x faster than Cursor Origin. You can host your repo and replicate it in multiple regions around the world, offering data residency and scale for agentic traffic.
3. Continuous Memory, a new approach for agents and developer teams that sync sessions and prompts into the Git repository, and makes that data constantly available and searchable to coding agents.

Plus, we are building an open ecosystem, so developers can pick the best tools for the job. At the start, we are partnering with Buildkite and Depot for Continuous Integration (CI), so your build and test pipelines keep up with how fast agents ship.

Entire is available for any developer today, and especially optimized for AI-native teams and their agents. Let’s jump into the new multiverse.

Review with Trails

In a pull request (PR), developers post their comments in a linear timeline, and continuous integration (CI) provides a status at the bottom followed by the merge button. Now coding and code review are spamming this timeline with long descriptions. Developers request their coding agent to address the code review agents’ feedback and then do another review. The pull request has become an audit log that only the agent reads. It does not provide the information for the developer to decide whether they can merge with confidence.

The Trail changes this. It brings the relevant information to the top of the page as eval scores, which are calculated on every push. The goal is simple: Give all the information you need to decide whether enough loops between your coding agent and the review agents have happened to achieve a stable state. Or not, and another iteration is needed. Only when the confidence is high, risk is low, and all findings are cleared, the merge should happen.

Here’s how the Trail lifecycle works in 3 steps:

1. Spinning Up a Trail

A Trail can begin on Entire by filing a bug report or a feature request. Or you can start a Trail straight from your agent, before or after the implementation has started, like you would open a PR when you are ready to push code. A Trail can span multiple repositories, so changes that belong together are grouped together.

2. Scoring the Trail with Evals

When code is pushed to a Trail, Entire triggers review agents to review the commit. Think about it like a jury judging an ice skating performance. Each agent runs independently in a cloud sandbox and submits a score and a rationale. For example, across many of our repositories at Entire, we use Security, Slop, and Human Review Required evals. If the Slop score is orange, you can instruct your agent to continue correcting and pushing based on that data until the score turns green. The last 5 runs and the current run are shown for each eval. We believe this is crucial as one-shot loops are often missing a critical issue. Repeating the loops and stabilizing the scores is crucial for the success of agentic coding.

Each project on Entire comes with pre-defined agents for code quality, security, and slop that can be enabled on a per-repo basis. You can configure your own agents via the Entire user interface or as .json config in the repo. Under the hood, Entire utilizes Claude Code and Codex with the latest models, running on isolated cloud sandboxes provided by Daytona and E2B.

3. Close All Findings, Then Merge

On every push, agents can also return specific findings and suggested fixes with different severity levels. Open findings are always visible in the Trail, while resolved findings are hidden, but can be retrieved via the menu. This way, you always stay alert on what is still open. A finding can be addressed or dismissed, you guessed it, by agents or human developers. You can also post findings and comments, just like in a pull request.

To make sure the merge doesn’t happen without addressing the agent findings, Gates can be enabled per repo to define what is required before approval. These also include human approvals and passing CI checks.

CI with Buildkite and Depot

Continuous Integration was first proposed by Grady Booch all the way back in 1991. It has been crucial to the success of the modern software development lifecycle, enabling teams to deploy hundreds of times per day. Now that agents write all the code, it’s even more important to have CI as a safeguard, so the agent isn’t changing what the prompt didn’t intend. As such, we are excited to offer first-class integrations of leading CI providers into Trails, starting with Buildkite and Depot today.

Buildkite

On Entire, CI is configured at the project level as often multiple repositories within a project use the same infrastructure. Once Buildkite is connected, every push builds on either Buildkite’s or your own infrastructure. Like it would on a PR, the result shows up as a check on your Trail, and a failing build will block merging. Of course, agents can automate the entire loop on their own, via Buildkite’s API, CLI, or MCP.

If you are a GitHub Actions user, you can migrate your workflow by running bk pipeline convert without rewriting.

Depot

Depot provides fast, reliable software delivery infrastructure for developers and coding agents, compatible with GitHub Actions. Depot CI runs existing workflows without GitHub in the middle.

Teams can connect Depot from Entire in a few clicks and create a Depot account in the same flow. Then depot ci migrate discovers your GitHub Actions workflows, promotes them to Depot CI workflows, and flags anything that needs review. Companion commands support importing secrets and variables, so migrated workflows run within minutes. Teams keep the workflows they’ve built and get fast and reliable CI from the first run, billed by the second, so faster jobs cost less.

Host Repos in Your Region

Before distributed version control went mainstream, the repository and its history lived on systems like Subversion. Git changed that. Developers could create commits and branches, merge, or even rewrite history, all locally, and reconcile later when needed. The Git protocol supported distribution and even decentralization, but forges never lived up to it. Git distributed the repository to the client, and various forges centralized the server side, again and again. We believe this centralized model is not fit for the future as it lacks scalability, resilience, and control where to store our code.

Starting today, you can create and natively host a repository on Entire, or mirror one from GitHub. Entire is powered by a new source control server, scaled with a distributed object store and a transactional ref database that remains compatible with Git. Due to this architecture, Entire is the fastest Git forge in production today. According to our open-source benchmarks, pushes are up to 89x faster than GitHub and 6x faster than Cursor Origin. Users and orgs can replicate their projects and repositories across multiple regions, or keep it in the region they reside in, for example for data residency requirements. We are live today in the US, EU, Australia, and India.

Create a New Repository

To get started, you can create a new repository on Entire from our web interface or from your agent using the Entire CLI. Repositories live inside projects belonging to an organization or a personal account. When you create a project, you pick a primary region and then replicate your repository across one or more regions.

Mirror Your Repository (Keep GitHub as Source of Truth)

If you’d like GitHub to remain the source of truth, no problem. Mirror your repository by authorizing the GitHub App for Entire, then picking the repo and the regions on Entire. You can even use Trails on top of pull requests, just as you would with a repository natively hosted on Entire. When mirroring, push traffic routes back through GitHub. If there is a disruption in service, Entire will keep serving clones and fetches from your regional mirror, and your agents can keep pushing to Entire-native branches (any branch prefixed entire/unmirrored/) until GitHub is back.

Migrate Your Repository

If you’d like to migrate your repository from GitHub, there are two options available to you. When mirroring in the United States, you can detach your mirror by opening the repository’s settings, then clicking Detach from GitHub, and choosing the project to move it into. Or, if you’d like to migrate directly from GitHub without mirroring, you can use the entire-migrate plug-in which takes care of the process. And, of course, you can always just fetch from GitHub and push to Entire, on your local machine or as part of your CI/CD workflow.

Turn Sessions Into Continuous Memory

Every day, developers and agents make decisions, discover constraints, try new approaches, and learn what works while building features and squashing bugs. But most of that knowledge disappears when the session ends. When you start a new session, your agent opens a new context window and has to re-learn everything which is not only slow but also expensive.

Today, we are introducing a new concept that we are calling Continuous Memory. Think about it this way: CI brings code together. CD ships it. Continuous Memory carries the understanding forward. The repository is the only memory your agent should need.

Two new commands in the Entire CLI make Continuous Memory possible: entire-graph, which maps how your code fits together and in our testing saved up to 71% on tokens, and entire-brain, which indexes your agent sessions and attaches them to the graph to create durable memories that the agent can retrieve faster than grepping through the codebase. Both plugins are open source and local first, and they’re designed to work together: entire-brain builds on entire-graph’s map of your code.

A Map of Your Codebase

entire-graph hands your agent a precomputed map of your Git repository: ranked code search plus definitions, callers, types, routes, and change impact, each with file:line locations. The built-in analyzer parses the repository locally with tree-sitter and makes no network requests, model calls, or API-key lookups.

entire-brain

entire-brain creates a durable memory layer for your repository. This allows agents to always have the right context at the right time, aka the “why” behind the “what changed.” Under the hood, entire-brain indexes entire-graph’s map of your code and binds it with past agent sessions that are recorded in your Git history via the Entire CLI.

For example, if you were fixing a rounding bug that created a mismatch error in your billing system, entire-graph traces the invoice calculation through every caller and test, while entire-brain gives your agent the intent behind the current logic, the fixes already shipped and why, or what tests broke the last time someone changed it.

entire-brain can also be connected to the Entire backend, enabling your team’s agent memories to live in one shared space instead of individual machines. Every Trail then shows the memories that the agent created, so reviewers see what decisions the developer made and what facts the agent learned. To get started, set up entire-graph and entire-brain in your repository.

Join the Rebellion

A year after we started, we couldn’t be more excited about what Entire has already become and what our agents are working on next. But building a new developer platform can only be done in collaboration with the community. So we want to hear from you, learn from you, and improve the product with you. Try it out. Tell us what you love or want improved via Discord so we can design the forge of the future, together.

Let’s strike while the iron is hot. Welcome to the rebellion.