Git for AI Agent Teams: Branching, Review and Provenance When Most Commits Aren't Human

Posted on Oct 22 • Originally published at botslave.com

One of the most-discussed posts on daily.dev this week asks a question that sounds philosophical and turns out to be purely operational: Git was built for humans — what happens when your dev team is mostly agents? AI coding agents now open pull requests, fix failing CI, refactor modules and update dependencies. They produce changes faster than any human team can read them. And they do it inside a version-control system whose every assumption — authorship, commit messages, code review, blame — was designed around people.

We run multi-agent workflows in our own automation practice, and the lesson arrived quickly: the first thing that breaks is not Git itself. It is the workflow around Git. This article is the practical version of the trend: what actually breaks when agents join the team, and the concrete Git practices — isolation, commit discipline, review tiers, provenance — that keep a human–agent codebase healthy. It is the same philosophy as how we work: automate the routine aggressively, and spend human judgment exactly where it changes the outcome.

Git was designed in 2005 for a very specific social structure: a network of trusted human maintainers exchanging patches. Its workflow layer (the part your team adds on top: branches, PRs, reviews) quietly assumes:

Agents violate all four. An agent's "intent" lives in a task specification and a conversation, not in its head. Its output scales independently of your review capacity. And left alone, two agents will happily edit the same files in the same working tree, producing a merge situation no human would create. The fix is not a new tool — agents work fine with plain Git. The fix is tightening the workflow at exactly the points where the assumptions crack.

Teams new to agent workflows expect conflict chaos. In practice, the failures arrive in a different order:

The single highest-leverage practice: every agent works in its own Git worktree on its own branch. A worktree is a separate working directory backed by the same repository — cheap to create, fully isolated files, shared object store:

# Give each task its own workspace + branch git worktree add../wt-fix-checkout-timeout -b agent/fix-checkout-timeout git worktree add../wt-bump-dependencies -b agent/bump-dependencies # List and clean up when tasks finish git worktree list git worktree remove../wt-fix-checkout-timeout Enter fullscreen mode Exit fullscreen mode Rules that make this work:

Agents should commit more strictly than humans, not less, because their history will be read during incident response:

Fix checkout timeout by retrying token refresh once Retry logic added to the payment session client; falls back to a fresh token on 401 instead of failing the checkout. Task: checkout-timeout-2026-10-21 Agent: builder-2 Verified: unit tests 42/42, staging smoke check Enter fullscreen mode Exit fullscreen mode Git trailers ( git commit --trailer "Agent: builder-2" ) are parseable with git interpret-trailers, so provenance stays queryable instead of becoming folklore.

Since review capacity is the constraint, design for it explicitly:

When something breaks at 2 a.m., agent-era Git hygiene pays off in three ways:

Keep the task specification itself with the code: a short spec file committed alongside the change (or linked from the commit body) means the "why" survives even when the chat that produced it is long gone.

Putting it together, a sane human–agent Git workflow looks like this:

None of this requires new tooling. It requires admitting that the scarce resource moved: code production is now abundant, and verified, reviewable, reversible change is the thing your workflow must manufacture.

Do agents need their own GitHub accounts? Effectively, yes — a bot identity (machine user or GitHub App) per team or per role. It keeps permissions scoped, audit logs honest, and human blame meaningful.

Should agent commits be signed? Signing proves which key produced a commit, which is genuinely useful once multiple agents and automations write to the same repo. Bot identities with managed keys (e.g., GitHub App–generated commits are marked verified) give you most of the value with little ceremony.

How do you review fifty agent PRs a day? You don't — that is the point of tiering. Most agent PRs should be small, mechanically verified and auto-mergeable; human attention concentrates on the risky minority. If everything needs deep human review, the agents are producing the wrong size of change.

What about two agents editing the same file? Prevent it structurally: separate worktrees, task partitioning by module, and short-lived branches. Conflict resolution heroics are a symptom of missing isolation, not a workflow.

Originally published on botslave.com. Botslave is an automation studio — see what we build and how we work.