Git for AI Agents: Version Control Built for LLM Coding Workflows

Run Claude Code or Cursor’s agent for an afternoon, then open git log. You will likely find a wall of commits you did not type, carrying messages you did not phrase, touching files you have not opened. Every diff is there. The reasoning behind them is not.

Git assumes a human made each change and can explain it. An agent inverts that assumption. It can land 40 commits in a single session, each one locally correct, while the explanation for any given commit lives in a chat transcript that may be closed and gone by tomorrow. When something breaks three days later, git blame points at a line and git bisect points at a commit — neither points at the decision that produced it.

A small category of tooling is forming around that gap: version control designed for agent workflows instead of retrofitted from human ones. re_gent, an open-source project on GitHub, is one example. It treats an agent session as a first-class object and stores the reasoning behind a change next to the change itself, instead of leaving it in an ephemeral chat window.

Why git breaks down when an agent holds the keyboard

Git’s unit of history is the commit, and for two decades human discipline made the commit message carry intent. You wrote “revert caching layer — it double-counted events” because you knew why. An agent breaks three of the assumptions that made that work.

First, volume. A human might make five or ten commits in a focused session. An agent can produce several times that, because committing is cheap and it has no reason to batch.

Second, authorship of the message. Agent-generated commit messages describe the diff accurately — “fix type error in request handler” — but describe it at the level of the change, not the goal. They are summaries, not rationale.

Third, and most damaging: the “why” is stored somewhere else entirely. The plan, the rejected alternatives, the file the agent read that convinced it to take one path — all of that lives in the transcript. Squash-merge the branch and even the intermediate commits collapse into one.

Picture a concrete case. The agent refactors your auth flow across 12 commits. You review the final diff, it looks reasonable, you squash-merge. A week later, sessions stop expiring correctly. git bisect lands on the squashed commit — accurate and useless. The reasoning you actually need (the agent moved token expiry into edge middleware because it assumed the worker ran on every request) was in a chat you closed days ago.

What an agent-native VCS records that git doesn’t

The shift agent-native version control makes is small to describe and large in practice: record the reasoning, not only the diff.

In that model the session becomes a unit of history alongside the commit. A change is linked to the prompt that triggered it, the plan the agent stated before writing code, the tool calls it made, and the files it read before deciding. The diff is still there. It is no longer the only thing there.

That is what makes agent bisect different from git bisect. Ordinary bisect narrows a bug to a commit. Bisecting through agent sessions narrows it to a decision — the point where the agent chose an approach, and the stated reason it chose it. You move from “which line changed” to “which decision was wrong,” which is the question you actually had.

re_gent frames its job around that second question — why did the agent do this — and it is built to sit alongside your existing agent rather than replace it. The agent writes code; the VCS captures the provenance. Because the reasoning is committed, it survives the chat window closing, a teammate picking up the branch, or you returning to the repo in a month.

Where this fits next to Claude Code and Cursor

These tools are deliberately agent-agnostic. They sit underneath whatever agent you run, so Claude Code and Cursor produce the sessions and the VCS records them. Cursor’s agent mode in particular generates the multi-commit bursts described above, which is where session-level provenance earns its place.

A reasonable way to adopt one is as observability first, source of truth later. Keep git as your real history. Let the agent-native layer record sessions in parallel for a few weeks, then check whether “why did the agent do this?” actually gets a useful answer when you go looking. If it does, you can lean on it harder. If it does not, you have lost nothing — the project is open source and the diffs were always still in git.

The honest status today is early. The category is new, no format has won, and you should expect churn. But the underlying problem is not speculative. It arrives the first day you let an agent commit on its own, and it compounds every session after.