Is Git good enough for AI coding agents?

Data Structures Matter

You can think of Git's data model as a one-to-many relational schema. On the one side: current_sha, parent_sha, title, description. On the many side: a collection of line-level diffs. This structure is an ancestry graph. Every commit points to the parent it came from, and the hash of a commit includes the hash of its parent, so the graph is a chain of "this came after that." It's strict, sequential, single-lineage, and it has to be, because that's the only kind of history a line-based diffing tool can safely rewind and replay.

Two agents working against the same lineage at the same time produce two different chains, and Git has exactly one mechanism for reconciling divergent chains: merge them line by line and ask a person to resolve whatever the algorithm can't. Worktrees exist to delay that reconciliation. They don't remove it.

Atomic's data model is different. It's a causal graph combined with patch theory, which produces a non-linear, convergent structure where the order of operations doesn't affect the outcome. It doesn't ask what came before, it asks what caused what: the edges are typed, content-addressed relationships between a decision, a change, its provenance, and the memory that decision leaves behind, and a change's identity comes from what produced it rather than where it sits in a shared timeline. Causal graph plus patch theory equals concurrency without coordination: every agent writes into the same graph at once, and nothing about that requires a person, a branch, or a merge step to keep the writes from colliding. Changes are stored as patches, and a patch is an algebraic operation that commutes: apply patch A then patch B, or B then A, and both orders land on the same state, which a commit can't do since it only makes sense replayed in the order it was recorded. It's the model multiple agents writing at once have needed all along, and pure lineage was never going to produce it.

Chain of Custody Matters

In Git, the four operations every team runs constantly all optimize for a clean-looking lineage at the cost of a stable one. A rebase replays a branch's commits onto a new base, and because a commit's hash includes its parent's hash, every replayed commit gets a new SHA. The commits look almost identical to the ones they replaced and share none of their identity. A squash merge takes a pull request's commits and collapses them into a single new commit on the target branch, and the originals stop being part of that branch's ancestry the moment the merge lands. A regular merge commit reconciles two lineages by pointing to both of their tips as parents, which preserves the fact that two branches joined but says nothing about why, or which change in one lineage relates to which change in the other. A cherry-pick reapplies a commit's diff somewhere else as a new commit with its own new SHA and no structural link back to the original; the -x flag can append a text note, but that's a comment, not a graph edge, and it doesn't survive the next rewrite.

In Atomic, chain of custody doesn't depend on any of that surviving. Identity comes from the causal relationship between a decision and its outcome, not from a position in a sequential timeline, so there's no timeline for a rebase to rewrite or a squash to collapse. Patches commute, so the order changes get applied in doesn't change the final state, and history stays append-only instead of something a team has to keep rewriting to look clean. Every change node carries its own intent and its own modification together, with a direct link back to whatever activity produced it. The audit trail is a structural property of the graph, not a discipline someone has to maintain by avoiding rebases.

Provenance Is a Semantic Web Problem

Once change storage moves from an ancestry model to a causal one, a commit message stops being an adequate provenance record, and it was never going to survive contact with agents anyway. The W3C solved most of this over a decade ago, for a different reason. PROV-O gives you three primitives: an Entity, something that exists, like a change; an Activity, a process that produces or consumes entities, like an agent's turn; and an Agent, whoever or whatever is responsible, a person, an organization, or a piece of software. A change wasGeneratedBy an activity, an activity wasAssociatedWith an agent, an entity wasDerivedFrom the entity it replaced, and the result is a typed graph, queryable in ways free text never will be. JSON-LD is what keeps that graph portable instead of proprietary: every node carries an @context and an @type, so the record is structured against a shared, dereferenceable vocabulary any tool speaking RDF can read without a custom parser, and it belongs to a standard rather than to one company's schema. The remaining problem is authoring, since nobody, person or agent, wants to hand-write RDF, and markdown container directives solve it by giving plain markdown a typed escape hatch: a directive name maps directly to an ontology class, so a person or an agent writes an ordinary markdown block, and that directive name tells the system whether the block is an intent, a decision, or a memory. The authoring surface stays as simple as a text file. The node it produces is a first-class, typed member of the graph the moment it's written.

SHACL is what keeps the graph honest. It's a W3C constraint language for validating RDF against shapes, and the useful move is treating those shapes as gates rather than documentation. A shape can require that every recorded intent carries a rationale and a link to the prior decision it extends, checked before the record is admitted to the graph at all, not flagged by a linter after the fact.

Atomic's CLI Is Better at Showing What Coding Agents Changed and Why

Put a query in front of that graph and the difference shows immediately. Ask Atomic's CLI what an agent changed and why for any file, function, or session, and it walks the graph directly: which agent produced the change, which activity generated it, which decision motivated it, and which prior state it derived from. That's a graph traversal, not a log scrape, and not a guess based on whatever a commit message happened to say. The answer comes back exact because the record was written as a typed node the moment the change happened, not reconstructed by reading between the lines afterward.

Native, Not Fetched

The causal graph is where all of this converges. Patch theory lets multiple agents write into the same graph at once without lineage getting in the way. PROV-O, JSON-LD, container directives, and SHACL give what gets written a typed, portable, self-validating shape. That's a different architecture than treating agent context as something to scrape after the fact from whatever a coding tool happened to leave behind on disk: Claude Code's JSON session files, Copilot's SQLite database, wherever the transcript ended up. One version of that approach stores a session's reasoning as a transcript committed to a dedicated branch, keyed to whatever commit it happened to sit next to at the time. The target branch never touches it, a squash makes it disappear from view, and it sits subject to the same garbage collection lifecycle as any other object nobody's referencing anymore. Reading it back later means reconstructing a session from logs once the work is already done, describing what happened after the fact rather than recording it as it happened. A system where the reasoning is a typed, content-addressed node in the same graph as the change it produced already has the record, generated at the moment of causation instead of recovered afterward.

That's the actual test for whether a provenance claim means anything: does it track causation from the initial prompt through to the resulting change, or does it reconstruct a plausible story from logs after the change already exists? Provenance scraped after the fact is forensics, a transcript read for clues about intent. Provenance generated at the moment of causation and stored inside the change record, not beside it in a sidecar log indexed by a hash that a rebase can orphan, isn't inferred. It's just there.

Is there a better way for agents to manage source code change? Only if the structure underneath shifts from an ancestry graph to a causal one.