Software development has entered a new phase. AI agents now author 41 to 46 percent of all new code, and that share is growing. The industry has noticed. A new category of tools has emerged that hooks into existing Git workflows and stores agent session data alongside commits, promising provenance without asking teams to change how they work. It is a reasonable pitch. It is also a structural dead end.
Checkpoints stored in Git history are only as durable as Git history itself. A squash merge, a rebase, a cherry-pick, and the commit SHA those checkpoints are indexed against no longer exists in the branch that matters. The context is not lost in a dramatic failure. It is orphaned quietly, by the most routine operations in every engineering team's daily workflow. Bolting attestation data onto a system that was designed to rewrite history does not solve the provenance problem. It defers it.
Atomic was built to solve it at the foundation. The problem is not that teams lack a tool to capture agent sessions. The problem is that the version control layer underneath those sessions was never designed to preserve them.
Why the problem cannot be patched
Understanding why requires looking at what Git's most common workflow operations actually do to any provenance chain attached to commits.
Squash merge, the default pull request merge strategy on GitHub, combines N commits into one new commit with a new SHA. The original commit objects are discarded from the target branch history. Any system that recorded model identity, token cost, or decision chain against the original commit hashes now references objects that no longer appear in the canonical history.
Rebase replays commits onto a new base, producing new commit objects with new SHAs. Git's commit hash includes the parent hash. Changing the parent changes the identity. External provenance indexed to the original SHAs is orphaned regardless of whether the code content changed at all.
Cherry-pick creates a duplicate commit with a different SHA and no structural link to the source by default. The -x flag appends a text note to the commit message, but this is a prose convention, not machine-readable structured metadata, and it does not survive further history rewriting.
The root cause is architectural. Git's identity model is the content hash of the commit object, which includes the parent hash. Any operation that changes the parent, combines commits, or replays patches produces a new identity. This is not an oversight. Git was designed for a world where commits are disposable intermediates that can be freely rewritten to produce clean history. Stable commit identity was never part of Git's contract.
Why new ref types are a red herring
A common response to this problem is to propose a new Git ref type, a parallel namespace like refs/provenance/ or refs/notes/ai that stores attestation data alongside the commit graph rather than inside it. The approach is well-intentioned. It is also structurally insufficient for auditing purposes, and understanding why matters.
A ref in Git is a pointer. It can survive a rebase or a squash as a data object in the object store. What it cannot do is remain meaningful when the commit it points to has been removed from the canonical history of the branch being audited. An auditor reviewing the main branch after a squash merge does not see commit B, the one the provenance ref attests to. They see commit S, the squash. The provenance record for B exists. The history does not acknowledge B ever reached main. The ref and the canonical history have diverged, and there is no mechanism in Git that prevents this divergence or flags it when it occurs.
The deeper problem is that Git permits any developer or agent with write access to rewrite branch history at any time. Force push is not a restricted operation by default. Interactive rebase is a standard daily workflow. The moment history rewriting is permitted, any provenance system that depends on history stability is no longer structurally accurate for auditing purposes. It is accurate until someone rebases, and then it is not, and there is no audit log of the rewrite itself.
This is the distinction between a provenance record that is durable and a provenance system that has integrity. Durability means the record survives. Integrity means the record accurately describes the canonical history an auditor will inspect. An audit trail that might be accurate is not an audit trail.
What Atomic is
Atomic is a semantic change graph built from the ground up for human and AI collaboration to extend what we have understood of legacy version control systems. It integrates with the agents teams already use (including Claude Code, Cursor, Codex, GitHub Copilot, OpenCode, Kilo and others) and does something none of them provide natively. Every agent turn is recorded as a cryptographically signed, content-addressed change that carries the full causal graph of how it was produced: what the human requested, what the agent explored, what it read, what it modified, and why.
That record is stored alongside the change itself, bound to an immutable identity that no subsequent workflow operation can alter. In Git, a squash merge or rebase produces a new commit SHA and silently orphans any provenance attached to the original. In Atomic, changes have permanent identities. Views are reorganized. Changes are not.
Under the hood, Atomic enriches every repository with AST analysis and tree-sitter entity extraction, building a semantic graph that operates at the function, class, and token level rather than the line level. That graph replaces traditional grep and find with structured graph traversal, giving agents a queryable index of what code means rather than what it contains. When two agents modify different tokens on the same line, Atomic resolves the merge automatically. The conflicts that surface are the ones that genuinely require human judgment.
The Vault stores goals, intents, architectural decisions, and accumulated knowledge, giving every developer and every agent immediate context on what the team is building and why. A new developer joining the team does not start from zero. A new agent session does not start from zero.
Because intents are first-class citizens in the graph alongside code changes and semantic structure, the Vault enables queries that no conventional version control system can answer. Not which files contain the authentication library, but who changed it, which agent made those changes, under what intent, and how that decision connects to everything else the team has recorded. That distinction is the difference between a search index and an institutional memory.
The Vault is not a one-time enrichment. It is a compounding asset. Every change recorded against the repository makes it richer. Every agent that runs against it (whether local or in CI, inner loop or outer loop) benefits from everything that came before. Over time the repository does not just store what your team built. It understands how it was built, why decisions were made, and what patterns have emerged across every human and agent contribution. That is a fundamentally different foundation than a version control system with context attached as an afterthought. In Atomic, the context and the repository are one.
The performance implications of that structural difference are documented in detail in Why Semantic Call Graph Queries Outperform Traditional Agent Search.
From inner loop to outer loop
Atomic and Circuit Breaker address the full development lifecycle. The inner loop is where developers and agents work locally in fast iterative cycles. The outer loop is where that work is verified, promoted, and deployed through platform engineering and DevOps pipelines.
Circuit Breaker connects these two loops by treating workflow steps as first-class artifacts with explicit inputs, outputs, and provenance. The result is a traceable execution graph from initial intent to shipped code, maintained inside the repository rather than scattered across external systems.
How the Atomic team works
The team building Atomic operates as a small, fully distributed group and uses Atomic as the foundation for its own development. That is not incidental. It reflects a deliberate belief that the future of software development is built on shared intent rather than shared location.
In Atomic, intent is established before code is recorded. Humans and agents align on what a change is meant to accomplish, refine that intent collaboratively, and only then commit work to the graph. The reasoning behind a decision travels with the decision.
Every developer on the team selects their own editor, their own agents, and their own local workflow. The constraint is not tooling choice but contribution quality: whatever a developer runs must integrate with the shared skills layer that keeps provenance and attestations intact across the full graph. Developers bring their preferred agents. The shared infrastructure ensures the record is complete.
The business case for Atomic
Engineering leaders evaluating version control infrastructure for AI-native development face a decision that is easier to defer than to make. The cost of deferral is accumulating quietly.
AI-generated code entering production today without structured provenance is technical debt of a specific and increasingly regulated kind. The EU AI Act, evolving FDA software validation requirements, and emerging DoD contractor frameworks are all moving toward mandatory attribution for AI-generated code. Organizations that have built on Atomic will have that record automatically, from the first change ever recorded. Organizations that attempt to reconstruct it from a Git history of squashed merges and rebased branches will find the record is not there.
Compliance pressure is the structural benefit that arrives at no additional cost. The operational advantages (measurably faster agent performance, token-level merge resolution, a complete and tamper-evident audit trail) are what make the case today.
The immediate case does not require regulatory pressure to be compelling. Atomic delivers measurably faster agent performance, automatic merge resolution at the token level, a complete and tamper-evident audit trail for every human and AI contribution, and a development culture where intent and execution are connected rather than siloed. These are operational advantages that compound over time. These are operational advantages that compound over time.
Build on a foundation that remembers.
Install the CLI and start recording from the next agent turn. No account required.