WhoEngineering manager who just discovered an agent pushed to a protected branch and wants accountability per agent
The problemWith shared credentials you cannot tell which agent broke something or stop one from touching branches it should not.
The outcomeEach agent has its own identity and permitted actions, and each landed change is logged with the agent that made it.
Steps
Read doc/graft/AGENT-SECURITY.md to see how tokens, the RPC allowlist and branch policies are set
Add per-agent tokens and branch policies to your config.toml
Restart the server and have two agents land changes under different identities
Use the graft CLI to list the changeset log and check each entry shows its actor
Prompt for your agent
In feder-cr/git-ai, follow doc/graft/AGENT-SECURITY.md to create two agent tokens in <config.toml> with different branch policies. Show that one agent is denied on a protected branch, and verify the changeset log records which agent landed each accepted change.
Caveat. Exact config keys for tokens and policies live in the docs, not the README; follow the docs instead of guessing the TOML.
Run the repo's acceptance script to compare classic retry-based landing with batched compare-and-swap landing.
Intermediate
45 minutes
Any agent
Seen in the wild
Evidence (similar to what people reported): X, Oct 2026
WhoEngineer evaluating gitai who does not want to trust published numbers without running them
The problemThe README claims 200 landed changes versus about 100 for classic landing, but you need to see it on your hardware.
The outcomeYou get your own landed-count, attempts-per-change and latency figures for 50 agents landing 250 changes with planned conflicts.
Steps
Build the repo with: make build
Run the benchmark script at examples/graft/demo/acceptance-phase4.sh
Compare the classic and gitai columns for changes landed and attempts per landed change
Read doc/graft/BENCH.md for the other agent counts
Prompt for your agent
In feder-cr/git-ai, run examples/graft/demo/acceptance-phase4.sh after make build and report changes landed, attempts per landed change and p99 latency for classic versus gitai. Verify that the roughly 50 unlanded changes in the gitai run are the planned conflicts.
Caveat. The README numbers come from one 16-core machine and a run without a conflict resolver; a smaller machine will show different lands per minute.
WhoDeveloper running several coding agents who wants to see if a shared branch can survive them before changing their setup
The problemSeveral agents pushing to the same branch collide, retry and waste time, and you cannot tell if a different approach would help.
The outcomeYou have a running server, a cache daemon, two agents and one landed change in a temporary directory, so you can judge the model first-hand.
Steps
Clone the repo and enter it: git clone https://github.com/feder-cr/git-ai.git then cd git-ai
Build everything with: make build
Run the demo with: examples/graft/quickstart.sh
Inspect the CLI with: ./_build/bin/graft
Prompt for your agent
Clone feder-cr/git-ai, run make build, then run examples/graft/quickstart.sh and summarize what the two agents did and how their change landed. Verify the build finished and the script exited without errors.
Caveat. The build compiles a bundled Git and needs Go 1.26, Meson and Ninja, so the first build can be slow or fail on a missing toolchain.
WhoTeam lead whose parallel coding agents keep rebasing and retrying against one main branch
The problemA normal Git host makes every agent clone fully and fight over pushes, so throughput collapses as agent count grows.
The outcomeYou have a gitai server running from a config file, with agents landing on it through the graft CLI instead of pushing to a classic host.
Steps
Copy examples/graft/config.toml and adapt it to your paths
Start the server with: _build/bin/gitaly serve config.toml
Use the graft CLI (./_build/bin/graft) from each agent to clone and land
Read doc/graft/AGENT-SECURITY.md for tokens and the RPC allowlist
Prompt for your agent
Using feder-cr/git-ai, adapt examples/graft/config.toml for a server at <data-dir> and start it with _build/bin/gitaly serve. Show how an agent clones and lands one change, and verify the server accepted it.
Caveat. The README states version 0.2.0 and says interfaces may change before 1.0, so treat a real production repo with caution.
Plug in a deterministic tool or any LLM provider so conflicting lands resolve instead of bouncing back to the agent.
Advanced
1 hour
From the README
Any agent
WhoDeveloper whose agents touch overlapping files and keep getting conflicts returned
The problemConflicting changes are sent back to their agents, and without a resolver those changes simply do not land.
The outcomeConflicts are resolved through the versioned resolver protocol and all 250 changes in the demo land, as the README describes for the deterministic resolver.
Steps
Read doc/graft/RESOLVE.md for the resolver protocol
Open examples/graft/demo/resolve.toml, the deterministic resolver the README points to
Run the benchmark again using that resolver config
Compare landed counts with the earlier run without a resolver
Prompt for your agent
In feder-cr/git-ai, run the acceptance demo with examples/graft/demo/resolve.toml and report how many of the 250 changes landed. Verify the planned conflicts were resolved rather than returned.
Caveat. The README confirms the deterministic resolver in the demo; how to wire an LLM provider is covered in doc/graft/RESOLVE.md, and a model resolving real code conflicts can still produce wrong merges.
Use graft sparse and graft clone to materialize just the paths a short task touches instead of a full clone.
Intermediate
45 minutes
From the README
Any agent
WhoPlatform engineer whose agents each edit a few files in a large monorepo and waste time on full clones
The problemCloning the whole repository for a task that touches three files makes each agent slow to start.
The outcomeThe agent fetches only the requested paths and can still land its change through the server.
Steps
Build with: make build
Run ./_build/bin/graft to list the CLI commands
Use graft sparse or graft clone with the paths <paths> the task needs
Land the resulting change and confirm it appears in the changeset log
Prompt for your agent
Using feder-cr/git-ai, run ./_build/bin/graft to find the sparse and clone commands, then materialize only <paths> from <repo> and land one edit. Verify that unrelated directories were not downloaded.
Caveat. The README names graft clone and graft sparse but not their flags, so read the CLI help or docs before running them.
Run graft-verify so a failing tip is bisected and the change that broke it is reverted without a human.
Advanced
1 hour 30 minutes
From the README
Any agent
WhoMaintainer whose agents land fast and who needs broken builds caught after the fact, not before every land
The problemWhen many changes land at once, finding which one broke the tests means manual bisecting while main stays red.
The outcomeA failure on the tip is bisected to the offending change, which is reverted automatically.
Steps
Read doc/graft/VERIFY.md for how graft-verify is configured
Point graft-verify at your repository and test command
Land a deliberately failing change from one agent
Check that graft-verify identifies and reverts that change
Prompt for your agent
In feder-cr/git-ai, set up graft-verify per doc/graft/VERIFY.md against <repo-path> with the test command <test-cmd>. Land one change that fails the tests and verify it gets reverted.
Caveat. An automatic revert rewrites your branch, so only point it at a throwaway or fully backed-up repo first.
Have an agent watch every accepted update and report what matters to each component, including in Slack.
Advanced
1 hour 30 minutes
From the README
Any agent
WhoTech lead who wants to know which agent changed what in a repo receiving hundreds of changes a day
The problemOn a busy shared branch nobody can read every landed change, so risky edits go unnoticed.
The outcomeA monitoring agent follows the changeset stream and posts a short report per component, optionally to Slack.
Steps
Read doc/graft/SUPERFAN.md for how monitoring agents follow the changeset stream
Read doc/graft/SUPERFAN-CHAT.md for the Slack setup
Start the server and land a few changes from different agents
Use the graft CLI to list or watch the changeset log and confirm each entry shows its operation and actor
Prompt for your agent
In feder-cr/git-ai, follow doc/graft/SUPERFAN.md to set up a monitoring agent on a running server and have it summarize the last <n> landed changes by component. Verify each summary names the agent that made the change.
Caveat. Superfan agents and Slack chat have their own docs and config; the README only lists them, so expect to read those pages before it works.
Switch a gitai repo to a database plus object storage so any server node can be added or rebuilt.
Advanced
2 hours
From the README
Any agent
WhoInfrastructure engineer planning to run several gitai nodes behind one repository
The problemRepository state tied to one node's disk means you cannot add nodes or recover one that dies.
The outcomeYour repositories are imported and served in authoritative mode from a database and object storage, with nodes acting as rebuildable caches.
Steps
Read doc/graft/STORAGE.md
Add a [graft.storage] section to your config.toml
Start in shadow mode and import your repositories
Switch to authoritative mode once imports check out
Prompt for your agent
In feder-cr/git-ai, follow doc/graft/STORAGE.md to add a [graft.storage] section using <database-url> and <object-store>, start in shadow mode and import <repo>. Verify the import completed before suggesting the switch to authoritative.
Caveat. The README lists garbage collection of packs in the storage core as a known gap, so storage can grow without cleanup.
Who it is forBuilders who run several coding agents against one repository and are hitting merge queue and rebase-retry bottlenecks, plus infrastructure people curious about agent-native source control.
Why it is hot+1,271 stars today, 2.4k total, launched 4 days ago
DEDUPED