---
title: "git-ai Review: Concurrent Agent Merges and Verification"
canonical: https://wavect.io/blog/git-ai-concurrent-agents-merge-verification/
language: en
description: "A source-based git-ai review: concurrent agent merges, exact-tree conflict checks, graft-verify, benchmark limits and a practical rollout evaluation."
image: "https://wavect.io/img/blog/headers/header_git-ai-concurrent-agents-merge-verification.png"
author: ["Kevin Riedl"]
published: "2026-10-21"
updated: "2026-10-21"
reviewed: "2026-10-21"
---

# git-ai Review: Concurrent Agent Merges and Verification

[**Back**](/blog/overview/)

[![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/)

[Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt

14 min read · 21 Oct 2026 Last reviewed October 21, 2026

[**Next**](/blog/gitbutler-parallel-ai-agents-one-workspace/)

TL;DR

feder-cr/git-ai, or gitai, is a source-control backend for concurrent coding agents. Its optional model conflict resolver needs enabled verification on the exact tree that would land. Clean merges do not automatically run that resolver gate; graft-verify separately tests accepted revisions. Evaluate it when measured branch contention justifies another service, and connect release decisions to a verified revision. Published batching benchmarks do not establish a speedup over GitHub.

**git-ai, published as `feder-cr/git-ai` and called gitai, is a source-control backend for concurrent coding agents. It moves repository operations to a server and batches changes arriving at the same branch.** Its most useful adoption question is whether your team can shorten the wait for integration while retaining evidence for the exact revision it releases.

Generating a patch, accepting it into a branch and proving that the resulting product works are different events. gitai provides mechanisms for the middle step and for checking selected results. Your engineering workflow still has to connect them.

Source review: 21 October 2026, commit `6b0ab81e6e37`. The reviewed README identifies gitai as version 0.3.0. This article is a documentation and source-code analysis, not a Wavect deployment or independently executed performance benchmark. The evaluation cases below are our recommendations.

## What is feder-cr/git-ai, and how does it relate to Scion?

The [project README at the reviewed commit](https://github.com/feder-cr/git-ai/blob/6b0ab81e6e3766824920ec18e17593fe8db714fd/README.md) describes an independent MIT-licensed implementation inspired by Anthropic's public source-control design. It started from GitLab's Gitaly server. The executable and configuration names retain `graft`, and ordinary Git repositories remain underneath.

Anthropic's [Scion engineering article](https://www.anthropic.com/engineering/redesigning-source-control) describes infrastructure for its own exceptional repository and agent workload. gitai is a separate project. Scion's reported infrastructure savings cannot be transferred to gitai, and installing gitai does not install Anthropic's internal system.

| Name | Primary job | Relevant decision |
| --- | --- | --- |
| feder-cr/git-ai, or gitai | Server-side repository operations and concurrent change landing; CLI named graft | How should completed agent changes enter a busy branch? |
| git-ai-project/git-ai | Attribution of AI-generated code, as described in its [separate project repository](https://github.com/git-ai-project/git-ai) | Which code came from an AI tool? |
| Graft repository-context tooling | Repository maps for agent context, covered in our [Graft repo-map review](/blog/graft-review-agent-repo-map/) | How does an agent find the relevant code? |

Check the repository owner before following installation instructions. The shared names do not make their commands or integrations interchangeable.

## Which bottleneck does concurrent landing solve?

**Landing means integrating a proposed change into a target branch. It does not mean deploying it.** When many agents finish together, each can prepare a change against a branch tip that another agent advances first. Repeatedly rebuilding and retrying that integration can become its own workload.

The [landing implementation guide](https://github.com/feder-cr/git-ai/blob/6b0ab81e6e3766824920ec18e17593fe8db714fd/doc/graft/LAND-BATCHING.md) explains the batching approach: a lane groups requests for one repository branch within one server process, integrates them against a running tip and publishes accepted changes through a compare-and-swap reference update. That update succeeds only if the expected previous reference still matches.

There is still scheduling and an internal queue. The distinction is how competing updates are coordinated. Batching applies to eligible standalone requests; the documentation explicitly excludes the GitLab-integrated mode. A batch lane also belongs to one process, so adding server nodes does not create one shared lane across all nodes.

| Observed problem | Useful first investigation |
| --- | --- |
| Agents overwrite local files or need incompatible dependencies | Workspace and runtime isolation. Start with our [worktrees and Jujutsu guide](/blog/git-worktrees-vs-jujutsu-ai-coding-agents/). |
| Compatible tasks need one running application for feedback | Local composition and branch ownership, covered in our [GitButler shared-workspace guide](/blog/gitbutler-parallel-ai-agents-one-workspace/). |
| Finished changes repeatedly race to update one server branch | Measure landing retries, contention and integration latency. This is gitai's relevant evaluation. |
| Code merges cleanly but breaks product behavior | Improve behavioral tests, dependency checks and release evidence. Faster reference updates cannot establish correctness. |

## How does gitai verify AI-generated merge conflict resolutions?

**A model-generated conflict resolution is a proposal until configured verification passes on the tree that would actually land.** The [resolution protocol](https://github.com/feder-cr/git-ai/blob/6b0ab81e6e3766824920ec18e17593fe8db714fd/doc/graft/RESOLVE.md) separates the server from an optional resolver command or HTTP service. Resolution must be enabled and requested. The resolver can use deterministic rules or a model.

For model output, the operator must configure and enable `verify.command`. Without a successful check, the caller receives a conflict package that can include the proposed content. Deterministic rule resolutions can land without this verification; enabling the gate checks those resolutions too. A custom command that calls an LLM must be identified as model-based. Calling it a rule would misrepresent its origin.

The crucial implementation detail is the candidate's identity. The [landing code](https://github.com/feder-cr/git-ai/blob/6b0ab81e6e3766824920ec18e17593fe8db714fd/internal/gitaly/service/operations/land_resolve.go) compares the verified tree object ID with the actual merged tree. If a concurrent update changes that candidate, an earlier passing result cannot simply authorize the different tree.

Consider a hypothetical billing change. Agent A renames a total-calculation function. Agent B adds a tax parameter to the previous function. A resolver can produce plausible code while dropping the tax behavior. A useful verifier includes an assertion for the taxed total. Compilation alone may not catch the mistake. If another change then alters rounding, the resulting combined tree needs evidence appropriate to that state.

The repository's [verification tests](https://github.com/feder-cr/git-ai/blob/6b0ab81e6e3766824920ec18e17593fe8db714fd/internal/gitaly/service/operations/land_verified_test.go) cover cases such as verifier failure, timeout, changed candidates and reuse for an unchanged tree. These are useful implementation evidence. We inspected them; we did not execute this project's suite. Passing a configured command establishes only what that command checks.

## Does a clean merge automatically pass the same test gate?

**No. The resolver's verification is not a universal test suite for every accepted change.** In the reviewed [ordinary landing path](https://github.com/feder-cr/git-ai/blob/6b0ab81e6e3766824920ec18e17593fe8db714fd/internal/gitaly/service/operations/land_attempt.go), fast-forward and clean integrations do not invoke the conflict-resolution verifier. Other configured policies still apply.

A textual conflict and a behavioral conflict are different. One agent can change an authorization default while another adds a new endpoint in another file. Git may combine both changes cleanly even if the resulting endpoint now has the wrong access behavior.

For a team evaluating gitai, this changes the acceptance question. Ask which paths run your required checks: ordinary clean changes, deterministic resolutions, model resolutions and manually supplied resolutions. Do not infer coverage for every path from a successful demonstration of one AI-resolved conflict.

## What does graft-verify check after landing?

The separate [`graft-verify` tool](https://github.com/feder-cr/git-ai/blob/6b0ab81e6e3766824920ec18e17593fe8db714fd/doc/graft/VERIFY.md) watches branch updates, materializes a tip and runs the operator's test command. A pass advances a green reference, by default `refs/graft/green/<branch>`. Automatic bisection and reversion require separate opt-in configuration; they are disabled by default.

This creates two relevant positions: the integration branch can continue moving while the green reference identifies a checked tip. **Our release recommendation is to select an explicitly verified revision and bind the build artifact to it.** Reading a green reference and then building the latest `main` would discard the very distinction the verifier creates.

| Stage | Record | What it establishes |
| --- | --- | --- |
| Agent proposal | Base revision, submitted commit and actor | The requested change and its starting assumptions |
| Resolver verification | Candidate tree ID, command and result | The configured check passed for that conflict-resolution candidate |
| Accepted integration | Returned landed revision and branch update | The change was accepted into the repository |
| Post-merge verification | Tested tip, test result and green reference | The selected checks passed for that integrated revision |
| Release | Chosen revision, artifact digest and release approval | Your delivery process uses the artifact built from the approved state |

The last row is our proposed delivery contract, not an automatic gitai deployment feature. The same applies to rollback: reverting source cannot undo a payment, an email or a destructive database migration.

One CI integration detail deserves attention: `graft-verify --once` can exit with status zero for a skipped batch as well as a passing one. Read its JSON outcome, including `passed`, `skipped` and the tested `tip`. A successful process exit alone is insufficient release evidence.

## Is gitai faster than GitHub or ordinary Git?

**The published landing benchmark does not establish that comparison.** The [benchmark documentation](https://github.com/feder-cr/git-ai/blob/6b0ab81e6e3766824920ec18e17593fe8db714fd/doc/graft/BENCH.md) compares batching enabled versus disabled on the same server. Its highlighted workload has 50 agents submitting five changes each to one branch, with 20 percent deliberately conflicting.

Without a resolver, the batched workload lands 200 of 250 changes. The remaining 50 are planned conflicts. A deterministic resolver can handle the demonstration's constructed conflicts, but that does not measure whether an LLM preserves arbitrary application behavior.

The README and benchmark document also show different throughput and latency ranges at the reviewed commit. We therefore do not derive a headline speed multiplier from them. The supported takeaway is narrower: batching can reduce competing retries in this synthetic workload.

For your own comparison, measure time from a finished change to a verified revision, alongside failures, human intervention and operating cost. Include the actual test suite and realistic file overlap. A higher number of accepted commits per minute is useful only if verification and recovery keep up.

## What must a self-hosted team check about permissions and code exposure?

The [agent security model](https://github.com/feder-cr/git-ai/blob/6b0ab81e6e3766824920ec18e17593fe8db714fd/doc/graft/AGENT-SECURITY.md) provides per-agent identities and reference policies. The shared token remains an operator credential. In the reviewed implementation, the post-merge `graft-verify` tool uses that operator credential and agents cannot directly access the reserved `refs/graft/` namespace. Plan a controlled release integration instead of handing every coding agent the verifier's authority.

Self-hosting the repository does not decide where a resolver sends code. An enabled external resolver can receive allowed conflicting file contents. Decide which paths and providers may be used, including source code that contains personal data or credentials. The documented glob behavior matters: `*.env` does not recursively cover nested `.env` files. The resolver does not automatically discover and redact every secret.

The [pre-land verifier implementation](https://github.com/feder-cr/git-ai/blob/6b0ab81e6e3766824920ec18e17593fe8db714fd/internal/gitaly/service/operations/land_verify.go) executes a configured command against repository content. Treat that content as executable input from the agents and resolver. A reduced environment is not a sandbox: isolate the runner, remove unnecessary credentials, restrict network access and bound resource consumption. Test output can itself expose data, so network restrictions alone are insufficient.

## Does adopting gitai mean replacing the existing code host?

Start by defining which system owns the branch and which system owns review, CI and release. A repository backend is only part of a development platform. Our [code-hosting migration analysis](/blog/cursor-origin-vs-github-code-hosting/) covers the broader forge decision; this article focuses on accepting and checking agent changes.

The [review subsystem documentation](https://github.com/feder-cr/git-ai/blob/6b0ab81e6e3766824920ec18e17593fe8db714fd/doc/graft/REVIEW.md) identifies an important boundary: recording an approved review does not yet make that approval a mandatory landing check. If your workflow requires independent approval, verify its enforcement separately.

The [storage-core documentation](https://github.com/feder-cr/git-ai/blob/6b0ab81e6e3766824920ec18e17593fe8db714fd/doc/graft/STORAGE.md) distinguishes optional shadow mode from authoritative storage. It describes SQLite for one node and PostgreSQL with shared object storage for multiple nodes. Local Git repositories still need hydration and disk capacity. Moving authority therefore deserves its own recovery exercise.

Some overview documentation lags newer implementation details. For example, the current storage documentation describes optional pack garbage collection, and the tree includes [multi-node storage tests](https://github.com/feder-cr/git-ai/blob/6b0ab81e6e3766824920ec18e17593fe8db714fd/internal/graft/e2e/storage_multinode_test.go). Neither justifies assuming that your chosen cloud backend, failure pattern or production load has been validated. Use a pinned revision and verify the actual deployment path.

## How should you evaluate gitai before moving a production branch?

**Use a disposable repository, representative agent tasks and explicit failure cases.** Keep deployment disconnected while you establish what gets accepted, checked and recovered. Begin with the current Git workflow as the comparison; an integration bottleneck needs to be measured before it becomes a reason to operate another service.

The upstream quickstart requires Linux or macOS, Git, make, the OpenSSL CLI, Go 1.26, a C toolchain, Meson and Ninja. These commands pin the source reviewed here and then invoke its example. We have not executed them as part of this article:

```
git clone https://github.com/feder-cr/git-ai.git
cd git-ai
git checkout --detach 6b0ab81e6e3766824920ec18e17593fe8db714fd
make build
examples/graft/quickstart.sh
```

The quickstart's server and example agents demonstrate a workflow. They do not establish a production permission model, representative throughput or a tested recovery plan.

| Case to exercise | Evidence to collect |
| --- | --- |
| Several clean changes target one branch | Which changes land, retries, rejected requests and latency including unsuccessful attempts |
| A model resolution fails a behavioral assertion | The candidate remains a proposal and the branch does not accept that resolution automatically |
| The target moves during verification | A changed candidate is checked again; a stale success does not authorize it |
| A deterministic rule handles a conflict | The difference between verification disabled and enabled is understood and matches the intended policy |
| A clean integration breaks a product rule | The selected post-merge checks catch it and the failing revision does not enter the release path |
| The verifier skips, times out or encounters a flaky test | The release integration distinguishes those outcomes from a pass and avoids an unjustified revert |
| An agent requests a forbidden branch or reserved reference | Permission rejection, correct actor attribution and separation from operator authority |
| A server restarts or loses its local repository cache | Recovery of the expected reference and objects, measured recovery time and retained verification evidence |

Compare verified delivery time, reviewer intervention, regressions and total operating cost. Add disk growth and recovery time if testing authoritative storage. Decide the acceptable limits before the trial, so a faster demonstration cannot quietly redefine success.

Wavect's [AI enablement work](/services/ai-enablement/) can help a team define this evaluation and its release criteria. Our [Hyperstate AI case study](/case-studies/hyperstate-ai/) describes separate engineering work, not a gitai deployment. Use the [pre-launch software QA checklist](/software-development-guide/software-qa-checklist-before-launch/) to scope the behavioral checks, or [discuss a concurrent-agent integration bottleneck](/contact/) with examples of recent retries and failed integrations.

## gitai merge verification: frequently asked questions

### Is feder-cr/git-ai the AI code-attribution tool?

No. feder-cr/git-ai is a source-control backend for coding agents, using a CLI named graft. git-ai-project/git-ai is a separate project for tracking AI-generated code. Check the repository owner before using installation instructions.

### Is gitai an official open-source release of Anthropic Scion?

No. It is an independent project inspired by publicly described Scion ideas. Anthropic's internal implementation and reported infrastructure results are not gitai releases or performance guarantees.

### Can gitai automatically resolve an AI-generated merge conflict?

It supports an optional resolver. Model-generated resolutions require configured, enabled verification that passes on the exact tree that would land. Otherwise they remain proposals. Deterministic rule resolutions have different defaults.

### Does verify.command test every clean merge?

No. In the reviewed commit, the conflict-resolution verifier is not a universal test gate for clean integrations. Define checks for those changes separately and use verified revision evidence in the release workflow.

### Does graft-verify automatically revert failing commits?

Only when auto-revert is explicitly enabled. By default, failing checks are reported and the green reference stays at its previous position. A source revert also cannot undo external side effects such as a database migration.

### Does a zero exit code from graft-verify prove the revision passed?

No. A one-shot run can exit successfully when a batch is skipped. Inspect the structured outcome and identify the tested revision before treating the result as release evidence.

### Should a small team replace Git worktrees with gitai?

They address different layers. Worktrees separate local checkouts. Evaluate gitai when measured server-side landing contention warrants the extra service and verification integration. A few parallel tasks alone do not establish that need.

Architecture and platforms

## Read next

Framework, platform and system-design choices that affect delivery over the long term.

[Start here**Smart City Architecture Best Practices: MQTT, LoRaWAN, Kubernetes and Terraform**](/blog/smart-city-architecture-best-practices-2026/)

- [Enterprise Software: Adding a Specialist Alongside Your System Integrator](/blog/enterprise-software-specialist-system-integrator/)
- [NVIDIA Run:ai Open Source: GPU Fleet vs Software Factory](/blog/nvidia-runai-open-source-gpu-software-factory/)
- [GitButler for Parallel AI Agents: Multiple Branches, One Build](/blog/gitbutler-parallel-ai-agents-one-workspace/)
- [Vendo for SaaS: Tenant Isolation and Approval Boundaries](/blog/vendo-saas-tenant-isolation/)
- [AgentMail for SaaS: Tenant Isolation and Duplicate-Send Recovery](/blog/agentmail-saas-duplicate-sends-recovery/)

[Next article**Enterprise Software: Adding a Specialist Alongside Your System Integrator**](/blog/enterprise-software-specialist-system-integrator/)

[**Back**](/blog/overview/)

[![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/)

[Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt

14 min read · 21 Oct 2026 Last reviewed October 21, 2026

[**Next**](/blog/gitbutler-parallel-ai-agents-one-workspace/)