` made exactly one finding disappear. It normalized the remaining references, re-granted the completed state, and re-signed the review. The four original `UNREVIEWED_CHANGE` findings disappeared.
The important result is not that review encountered a normalization defect. It is that the investigation crossed multiple sessions, identities, and models without losing the chain that made correction possible:
```text
prompt
→ work intent
→ implementation
→ evidence
→ work memory
→ triage finding
→ independent review
→ review verification
→ review memory
→ diagnostic intent
→ controlled experiment
→ corrected edge
→ fresh attestation
→ promotion coverage
```
Beads preserves that work remains. Atomic preserves why it remains, what already failed, which graph predicate is unresolved, and what evidence would prove the correction.
That is continuity of investigation, not just continuity of queue.
## The technical comparison
| Capability | Beads | Atomic Vault |
|---|---|---|
| Durable task state | Yes | Yes |
| Typed issue dependencies | Yes | Yes |
| Acceptance criteria | Typed field | Typed graph nodes |
| Task history | Dolt history | Content-addressed change history |
| Prompt captured with implementation | Not inherently | Change ledger goal |
| Task connected to source files | By convention/integration | `task → TOUCHES → file` |
| Patch connected to same files | Separate VCS | `change → MODIFIES → file` |
| Met criterion requires evidence | Not a close invariant | Shape-gated |
| Evidence pinned to repository state | Not native | `observedAtMerkle` |
| Agent/model execution provenance | Not native | Recorded change ledger |
| Durable learning from the turn | Notes or new issues | Typed, attested memories |
| Independent review as a typed object | Can be modeled as an issue | `kind: review` + `REVIEWS` |
| Review signed by another identity | Not native | DID + Data Integrity proof |
| Invalid/stale review blocks promotion | Requires external policy | Triage gate |
| Review failure feeds later work | Through prose/history | Findings → memory → intent → correction |
The fair wording is "not native" or "not enforced," rather than "Beads cannot ever do this." A team could build hooks around Beads, Git, CI, signatures, and a review system. Atomic's claim is that these relationships are one protocol rather than an integration assembled from several databases.
## The invariant each system enforces
Beads fundamentally allows:
```text
issue.status = closed
```
It can store acceptance criteria and a close reason, but the issue's state does not inherently depend on a particular patch, repository state, signed review, or passing evidence graph.
Atomic's promotion model is closer to:
```text
promotable(change_set) =
every_change_is_covered_by_an_intent
∧ every_intent_conforms
∧ required_verifications_pass
∧ evidence_matches_the_reviewed_merkle
∧ an_independent_review_is_complete
∧ the_review_signature_is_current
```
This is the technical distinction readers can test.
It is not enough for the task, patch, and review to exist. Their edges must resolve, their signed contents must still match, and triage must be able to traverse from candidate changes to conforming work and review intents.
Try the adversarial case. Mark a criterion met without required evidence. Change a review after signing it. Point one review edge at the wrong node identity. Beads can retain the task and history around those events. Atomic's responsibility is to refuse the resulting graph as authority to promote code.
## What belongs to the change
The Train Tracks record answers the six-month questions in the repository:
- The original prompt says what the person noticed.
- The intent says why the work mattered.
- The acceptance criterion says what success meant.
- The activity ledger says what the agent did.
- The evidence says what was observed and against which state.
- The attestations say which identities made those claims.
- The patch says what changed.
- The review says who independently judged it.
- The memories preserve what the work and review taught the next model.
Take away the acceptance criterion and nobody can say whether the change succeeded. Take away the evidence and success becomes an unsupported assertion. Take away the reviewed Merkle state and the evidence floats free of the code. Take away the review provenance and nobody can tell whether approval came from an independent actor. Take away the memories and the next agent repeats an investigation whose conclusions the project had already earned.
They belong to the change because the change stops explaining itself once they are gone.
The edges separate the two designs. Beads links work to work so operations continue. Atomic links intent to criteria to activity to evidence to code to review, then uses those relationships to govern promotion. A question asked six months later has somewhere exact to travel.
A change is made of the reason, the bar, the activity, the evidence, the authorship, the patch, and the independent judgment that allowed it to move. Source code control for agents has to hold those relationships because the relationships are where the meaning went once it stopped living in someone's head.
## The obligations are opposite
Compaction is correct engineering for an operational ledger. Every closed task that stays verbose taxes the next agent's attention, so forgetting finished work is the feature.
That is fine for deciding what to do next. It breaks the first time someone needs a root cause analysis. The review asks why the change was made, what it was supposed to do, what evidence said it worked, and who approved it, about a quarter closed months ago. An operational ledger is under pressure to compact exactly the detail an audit record is obligated to retain.
The failure is not only that detail disappeared. Reachability disappeared with it. A pull request from three years ago may still be perfectly preserved, but if no structural path leads from the file in front of you to that review, finding it begins with somebody remembering its number, title, author, or that it existed at all. In practice, the person most likely to find it is the person who wrote it.
Compaction creates the same condition. A one-line summary can prove that work once happened while deleting the vocabulary, evidence, and relationships anyone would need to discover why it matters now. The record survives as storage and disappears as context.
Atomic keeps the path alive. Query an intent and walk through its criteria and tasks into the code and recorded changes. Query a current file and walk backward to the intents, evidence, memories, and reviews that produced it. Run triage and the system traverses those same edges without requiring a person to remember that an old record exists.
Operational memory has to forget so the agent can think. The record of change has to remember—and remain reachable—so anyone can audit.
Beads is an operational ledger. Atomic Vault is a change-integrity and review ledger. Use Beads to tell agents what to do next if it fits the workflow. Use Atomic to determine whether what they produced is connected, evidenced, reviewable, and promotable.
### Common questions
**What is the difference between Atomic Vault and Beads?**
Beads is a durable operational work ledger: it preserves issues, dependencies, acceptance criteria, and task history so another agent can continue the work. Atomic Vault is a change-integrity system: it connects the prompt, intent, criteria, activity, evidence, source files, signed review, and promotion decision in the same content-addressed change graph.
**Can Atomic Vault and Beads be used together?**
Yes. Beads can manage the operational queue and tell agents what to do next, while Atomic Vault records why a resulting change exists, what evidence supports it, which repository state was reviewed, and whether an independent signed review permits promotion.
**How does Atomic connect an AI agent task to the code it changed?**
An Atomic intent task has a typed TOUCHES edge to a repository file node, and the recorded change has a MODIFIES edge to that same file node. You can query from intent to criterion to code, or start from a current file and walk backward to the work and review that produced it; triage traverses the same path when deciding whether a candidate change is covered.
**Why isn't an old pull request or compacted task enough?**
A record can still exist and be effectively lost if nothing current points to it. Finding a three-year-old pull request usually requires someone to remember its number, title, author, or that it existed at all. Atomic keeps typed paths from current code to its intent, evidence, change, and review, so retrieval starts from the artifact in front of you rather than a person's memory.
**Does Atomic require evidence before an acceptance criterion is marked met?**
Atomic's closed-world, SHACL-style gate rejects a met criterion when its required verification evidence is absent or failing. Verification records can include the check kind, outcome, observation, and observedAtMerkle value that pins the evidence to the exact repository state reviewed.
**What happens when an Atomic review changes after it is signed?**
The attestation becomes stale because the signed content hash no longer matches the review. Atomic triage fails closed: it does not count the stale review as independent approval, and promotion to a shared view remains blocked until the current review is validated and signed again.
**Does Atomic use SHACL to validate intents?**
Atomic currently implements the documented SHACL-style closed-world shape semantics directly in Rust. The gate enforces required reasons, closed status vocabularies, evidence for met criteria, task-to-criterion referential integrity, review edges, authorship, and Data Integrity proofs; a general Turtle-backed SHACL evaluator is a later implementation milestone.
## Agents Need Views, Not Worktrees
Source: https://atomic.dev/blog/agents-need-views-not-worktrees/
Author: Lee Faus (Founder and CEO @ Atomic Software, Co.)
Author profiles: https://x.com/leefaus, https://www.linkedin.com/in/leefaus/
There's a pattern becoming standard in agentic development: give every coding agent its own Git worktree, let it work independently, then merge everyone's changes back together when it's done. It works, and it solves a real problem. Two agents can't safely edit the same working directory at once, so each gets its own copy of the repository instead. One works over here, one works over there, and Git gives each of them an isolated view of the tree.
But it's worth asking why agents need worktrees at all. They don't, not for the reasons that made worktrees necessary in the first place. What an agent actually needs is isolation: a known starting state, a place to record its own changes, visibility into whatever it depends on, and a way to reason about what happens when another actor touches something relevant to its work. None of that requires a second directory holding a materialized copy of the repository. That requirement comes from Git, not from what isolation actually means.
## Agents need closures, not codebases
Here's the actual claim, stated up front. An agent doesn't need a codebase in the abstract, it needs a closure scoped to whatever task it's doing right now. For building, that means walking from changed nodes through their transitive dependencies. For verification, it means walking the other direction to find affected callers and tests. For collaboration, it means incorporating whatever concurrent changes have become causal dependencies of the work. For provenance, it means keeping track of exactly which state, inputs, tools, and verification steps produced the result. Those are different traversals over the same graph. The tree was never the answer, just one possible way to serialize it.
That matters even more for a software factory running large numbers of agents concurrently. Giving every agent its own worktree means duplicating filesystem state just so the source control model can offer isolation. Giving every agent its own causal view means the underlying state stays shared, and each actor only sees the slice of the graph relevant to its work. That's a different scaling model, not just a faster version of the same one. The rest of this post is about why worktrees exist in the first place, and what has to change underneath them for that scaling model to actually work.
## Worktrees are spatial isolation
Git represents source code as trees of files at points in history, and a working directory is where one of those states becomes editable. That's a natural model for a person. A developer opens a repository, edits some files, runs a test, and eventually commits the result. The filesystem is both the interface and the workspace.
The trouble starts once more than one actor needs to work at the same time. If Agent A and Agent B operate on the same working directory, their uncommitted state gets tangled: one may edit a file while the other reads it, or change branches underneath the other's feet. Git's answer is to give each actor its own worktree.
```text
Agent A
|
v
/worktrees/agent-a/
|
v
repository files
Agent B
|
v
/worktrees/agent-b/
|
v
repository files
```
The isolation is physical: two actors get two filesystem-shaped realities. That's a reasonable abstraction for people. For agents, it's worth asking whether the filesystem needs to be the boundary at all.
## An agent needs a view of change
Think about what an agent actually needs while it works. A base state. The changes it's made since that state. Any other changes its work causally depends on. Possibly a sense of what its changes affect, what tests verify those parts, and whether some concurrent change has touched one of those relationships. None of that is a filesystem problem. It's a graph problem.
Suppose two agents start from the same state:
```text
S0
/ \
/ \
Agent A Agent B
```
Agent A creates two changes, `A1` and `A2`. Agent B creates `B1` and `B2`. Their isolated states don't require two directories to exist:
```text
Agent A view = S0 + A1 + A2
Agent B view = S0 + B1 + B2
```
The objects backing `S0` can stay shared. What differs isn't where the files live, it's which changes are visible within each actor's view.
Now suppose `B2` starts to depend on something `A1` introduced. The graph can represent that relationship directly:
```text
S0
├── A1 ───► A2
│ │
│ └────► B2
│
└── B1 ───► B2
```
Agent B's effective view is no longer just its original state plus its own work. Its closure now includes `A1`, because `B2` depends on it:
```text
closure(B2) = S0 + A1 + B1 + B2
```
Nothing had to be merged into Agent B's directory for that relationship to exist. The system resolved causality instead. That's the distinction that actually matters for agent-native development: Git uses spatial isolation. Agents need logical isolation.
## Worktrees go stale by construction
The limitation gets more obvious once agents collaborate in real time. Two worktrees created from the same starting point start out consistent:
```text
S0
/ \
/ \
A B
```
But the moment Agent A makes a meaningful change, Agent B is still working against its original materialized state. Say Agent A changes an authentication contract while Agent B is modifying code that calls into it. Agent A's worktree knows about the new reality. Agent B's doesn't, and won't until something makes it look.
Eventually the two states have to reconcile, and Git has an entire vocabulary built for exactly that:
```text
fetch
merge
rebase
cherry-pick
resolve
retry
```
Those mechanisms exist because each actor has been operating inside a separate materialized copy of reality, with no way to notice the other one changed.
A causal graph can approach this differently. When Agent A changes the contract, that change becomes part of shared graph state immediately:
```text
A1
├── modifies auth.rotateToken
├── introduces TokenError
└── changes session.Refresh contract
```
If Agent B is working on something that reads `session.Refresh`, the relationship between B's work and A's change can be discovered as the graph changes, not after a merge conflict surfaces it later. The event that matters isn't that Agent B fetched Agent A's files. It's that Agent B's causal closure changed. An agent doesn't need to synchronize a filesystem before the system can recognize that the world around its work moved. The relationship is first-class, not something reconstructed after the fact.
## Storage, workspace, and materialization aren't the same thing
Part of why worktrees feel inevitable is that Git collapses several separate concepts into one. There's the underlying source state, the workspace visible to a particular actor, and the filesystem representation that editors, compilers, and test runners actually consume. Those don't have to be the same thing, and in an agent-native system they aren't.
Storage is the durable source and change state: content-addressed objects, patches, causal relationships, semantic relationships, provenance, and the graph they form. Workspace is the subset of that state visible to one actor: base state plus that actor's changes plus its causal dependencies. Materialization is just whatever representation the tool currently consuming that state happens to need.
Sometimes that representation is still files. A TypeScript compiler expects `.ts` files, Rust tooling expects a crate layout, and plenty of software has spent decades getting attached to specific pathnames. None of that means those files have to be the authoritative workspace. They can be a projection of one instead.
## The filesystem becomes an adapter
Say an agent is modifying token rotation. Its current closure might contain the equivalent of:
```text
/auth/token.ts
/auth/session.ts
/crypto/signing.ts
/types/session.ts
/auth/token.test.ts
```
Today, that list gets constructed by checking out the whole repository first and then figuring out which files actually matter. A graph-native system can run that in the other order:
```text
causal + semantic graph
|
v
compute closure
|
v
execution view
|
v
filesystem adapter
|
v
compiler / tests
```
The compiler may believe it opened `/build/auth/token.ts`, but that path doesn't need to correspond to a durable file sitting on disk. The bytes can come from content-addressed objects exposed through an in-memory filesystem, a virtual filesystem, or some other compatibility layer built for exactly this. The important shift isn't RAM instead of SSD, it's graph-addressed state instead of filesystem-addressed state. The filesystem becomes an interface for tools that still require one. It stops being where the truth lives.
## What this does to CI
Once the working state is a causal view instead of a worktree, the same question applies to CI. Why does a build agent need a checkout at all?
Traditional CI reconstructs the world before it does anything else:
```text
remote repository
|
v
clone / fetch
|
v
materialize tree
|
v
restore caches
|
v
discover what changed
|
v
discover what depends on it
|
v
build / test
```
That order is backwards. It rebuilds the whole world first and only afterward figures out which small part of it was actually relevant.
An agent-native CI system can run that in reverse:
```text
intent
|
v
change
|
v
causal + semantic graph
|
v
compute closure
|
+----------------+
| |
v v
build closure verification closure
| |
+-------+--------+
|
v
execution view
|
v
build / test
|
v
verified artifact
```
No repository checkout is required anywhere in that path. A filesystem-shaped view may still show up at the very end, because today's compilers still expect one, but that's compatibility materialization now, not the architecture of the system. The runner receives the state necessary to execute the change, not an entire repository and instructions to go rediscover that state itself.
## Bazel already proved half of this
Bazel matters here because it already demonstrated that the whole source tree doesn't have to be the unit of execution. A Bazel build works from a dependency graph and computes only the inputs a target actually needs, which is what makes caching, sandboxing, and remote execution possible in the first place.
But that graph is still something maintained alongside the source, not derived from it. A `BUILD` file describes the relationships Bazel uses to decide what should run, and someone has to keep those relationships accurate by hand.
That raises the real question: what if source control itself already recorded enough of those relationships that a build system never needed a second, hand-maintained graph? A causal graph can record what changed and why. A semantic graph can record what code reads, calls, imports, or affects. The result isn't a second, manually maintained approximation of the codebase sitting next to the real one. It's a graph derived from the work itself, kept in sync because it was never a separate copy to begin with.
## From a worktree to an execution closure
Eventually, the handoff between an agent and CI stops looking like a repository, a branch, and a commit. It starts looking like intent, change state, a dependency closure, a verification closure, a toolchain, a policy, and provenance. That package is enough to describe the actual computation being asked for. A build worker doesn't need to understand the whole repository. It needs the inputs required to build, the checks required to verify, and enough provenance to attest to what happened. The resulting artifact traces back to the exact closure that produced it, not just a commit hash, which is what connects development, verification, and supply-chain provenance without asking every stage to reconstruct meaning from a tree on its own.
## The tree becomes derived state
A worktree was never really about isolation. It was about Git having no other way to give two actors two different realities. Once the graph can do that instead, a worktree isn't something Atomic optionally skips. It's something a causal graph never needed in the first place. Worktrees exist to satisfy a demand that only comes from the filesystem side of the system: a human who wants to open a directory, or a tool that was never built to read anything else. Strip that demand away and there's nothing left for a worktree to do. That's not a lighter version of source control. It's a more agent-native one.
### Common questions
**Why do AI coding agents use Git worktrees?**
AI coding agents use Git worktrees because two actors cannot safely edit the same Git working directory at once. A worktree gives each agent a separate materialized copy of repository state, preventing uncommitted edits and branch changes from interfering with one another.
**What is a causal view for an AI coding agent?**
A causal view is the exact set of changes visible to an agent: its base state, its own work, and the transitive dependencies that work requires. It provides logical isolation over shared graph state without requiring a separate repository directory for every agent.
**How are causal views different from Git worktrees?**
Git worktrees provide spatial isolation by materializing separate filesystem trees. Causal views provide logical isolation by filtering one shared change graph. Concurrent changes can become visible when they enter an agent's dependency closure, rather than waiting for a fetch, merge, or rebase to reconcile separate directories.
**Do causal views eliminate files and working directories?**
No. Compilers, editors, and test runners can still receive filesystem-shaped input. The difference is that files become a derived compatibility layer—materialized through a virtual, in-memory, or temporary filesystem when a tool needs them—instead of the authoritative source state or isolation boundary.
**Can CI build and test code without checking out the whole repository?**
Yes, if source control can compute the relevant build and verification closures. A CI worker can receive the content-addressed inputs, dependencies, tests, toolchain, policy, and provenance required for one change, then materialize only the filesystem view needed by current build tools.
**How is an execution closure different from a codebase checkout?**
A checkout materializes an entire repository state before discovering what matters. An execution closure starts from an intent or change and traverses causal and semantic dependencies to select only the source, tests, tools, and policy needed to perform and verify that work.
## A Git Alternative for AI Agents That Never Rewrites History
Source: https://atomic.dev/blog/the-dynamic-graph/
Author: Lee Faus (Founder and CEO @ Atomic Software, Co.)
Author profiles: https://x.com/leefaus, https://www.linkedin.com/in/leefaus/
## Structure You Decide Later, Not Sooner
An agent doesn't hand you a clean history. It hands you a firehose. It tries three approaches to the same problem and keeps one. It fixes a typo it introduced four changes back. It refactors something unrelated because it happened to be nearby. What comes back is a batch of work, and the real shape of that work only shows up once you can see all of it at once. Deciding which part is a real line of work, which part was an experiment worth setting aside, and which part belongs on a different track entirely: that's a decision you can only make after the changes exist.
Git requires you make it before. A commit's hash includes its parent's hash, so the moment you record work you've also recorded its position in a single lineage, and that position becomes part of its identity. If the shape you picked turns out wrong, there's one tool for fixing it, and it's a rewrite. Rebase, squash, or reset all produce new SHAs for everything downstream. They sever the identity of the commits they touch and take the provenance sitting next to those commits down with them. I made the case in the [previous post](/blog/is-git-good-enough-for-agents/) that an ancestry graph was never the right substrate for agents. This is what that costs you in practice: in an ancestry graph, the structure of your work is frozen the moment you write it, and the only way to change it is to rewrite it.
Atomic separates the two things Git fuses together. Content is one graph: a single canonical set of changes, each content-addressed, each carrying its own intent and provenance. Grouping is something else. It's a view, and a view is just a filter that says which changes are visible together and in what order. Views don't own changes and they don't duplicate them. They point at the one graph. Because grouping is a filter and not a lineage, you can change your mind about it as many times as you want without ever touching the content underneath.
// live workshop · aug 26
Do we have your attention yet?
Come learn more on August 26 at 11 AM EST, where we'll answer all your questions about Atomic, live.
Save your seat →
## Pulling a Change Out of the Middle
Here's an operation an ancestry graph can't do cleanly. Say you've got a line of work:
```
dev: [1, 2, 3, 4, 5, 6, 7]
```
Changes `4` and `5` were an experiment. They're independent of the work in `6` and `7`, they touched different files, and you've decided they belong somewhere else while `dev` keeps moving. What you want is:
```
dev: [1, 2, 3, 6, 7]
wip: [4, 5] (with everything they depend on)
```
In Atomic that's one command:
```
$ atomic view split wip 4a3f… b901… --from dev
✓ Split 2 change(s) out of dev into draft wip
ℹ 'dev' now has 5 change(s); draft 'wip' has 2 own change(s).
```
Nothing gets re-applied here. No diff gets computed and replayed onto a new base. The edges for `4` and `5` still live in the same canonical graph they always did. `dev`'s filter just stops including them, and a new view picks them up instead. It's an O(1) metadata operation per change. `6` and `7` keep their exact hashes. So do `4` and `5`. There's no `6'`, no `7'`, no rebase.
The operation is guarded by the thing that actually matters: real dependencies. Before it moves anything, Atomic computes the reverse-dependency closure of `{4,5}` inside `dev` and checks whether anything staying behind depends on what's leaving. If `6` had edited a line that `4` introduced, `6` depends on `4`, and the split gets refused unless you pass `--cascade` to pull `6` along with it. You can preview the whole analysis with `--dry-run` before you commit to anything. The operation is defined so that it's impossible in exactly the cases where it would leave a dangling reference, which is why it always exits clean.
## See It in Action
Here's the split running end to end — pulling changes out of the middle of a view, no rebase, no rewritten hashes.
## The Part That Trips Up a Git Brain
Here's the question everyone asks, because it's the question the ancestry model trains you to ask: once `4` and `5` are gone from the middle, doesn't `6` now depend on `3`? And if you re-insert `4` later, doesn't it end up depending on `7`, since `7` is what it now sits behind?
No, and that's the whole point of the design.
In Atomic, a change's dependencies get computed once, at record time, from the content it actually touched. When a change edits or deletes a vertex, it records the change that introduced that vertex as a dependency, and that set gets frozen into the change's identity. It never gets re-derived. `6`'s dependencies are whatever `6` genuinely built on, some subset of the changes before it, and that set is identical whether `4` and `5` are sitting in the view or not. Removing them doesn't "re-link" `6` to `3`. There's nothing to re-link, because `6 → 3` was never an edge unless `6` actually touched `3`'s content, and if it did, that edge already existed before the split and nothing about the split changes it.
The sequence `[1, 2, 3, 6, 7]` is just the order of references in the view's log. It isn't the dependency graph. Sequence position and dependency are different things, and treating them as the same thing is exactly the habit an ancestry graph trains into you, because in Git they are the same thing: the parent pointer means both "what came before" and "what this is built on" at once. Atomic pulls those apart. The only invariant a view has to hold onto is that a change's real dependencies show up somewhere before it in the sequence. Since `4` and `5` were never dependencies of `6` and `7`, dropping them can't violate that invariant.
Re-insert `4` and `5` later and the same rule still holds. `4`'s dependencies are still its original ones, some subset of `{1,2,3}`. It doesn't acquire a dependency on `7` just because `7` happens to already be sitting in the target view. Insert pulls in `4`'s forward dependencies, which are already present, and appends the reference:
```
dev: [1, 2, 3, 6, 7, 4, 5]
```
`4` now sits after `7` in the sequence, and there's still no edge from `4` to `7`. Because `4,5` and `6,7` are independent, they commute, and this sequence materializes byte-for-byte the same tree as the original `[1..7]`. You reordered the references and the content never moved, because the content was never a function of the order to begin with.
## Why This Makes Agent Workflows Dynamic
Dynamic is the right word for it. In an ancestry graph, structure is a write-time property. You commit into a shape and you live in that shape until you rewrite it, and rewriting destroys identity and provenance by construction. In a dependency graph, structure is a read-time property instead. The causal edges between changes are fixed and honest. Everything above them, how the work is grouped, which track it lives on, what counts as an experiment versus mainline, is a filter you compose now and can recompose later, as many times as the work demands, without rewriting a hash or breaking the link back to the agent turn that produced it.
For agents this is the difference between fighting the tool and using it. Say an agent returns fourteen changes. Some of them are the actual feature you asked for. A few are a dead-end experiment it tried and abandoned. A couple are an unrelated fix that belongs on a different track altogether, and the rest are cleanup it did along the way. In Git your options are to squash the whole thing into a fiction that throws away which decision produced what, or to rebase it into shape by hand and rewrite every SHA downstream, orphaning whatever provenance was keyed to them. In Atomic you split the experiment into a scratch view, insert the unrelated fix onto its own track, and leave the feature on the mainline, and every one of those changes keeps its hash, its recorded intent, and its provenance edge back to the turn that generated it. The regrouping is a decision about views. The content, and the chain of custody attached to it, never moved.
That's the model agents actually need. They don't produce linear history and they never will, so the substrate has to let you impose structure after the fact instead of demanding it up front, and it has to do that without laundering identity every time you change your mind. An ancestry graph can't give you that. Its whole premise is that position is identity. This is set-based patch theory made literal.
### Common questions
**Can you remove a change from the middle of a view without rewriting history?**
Yes. In Atomic, grouping is a filter over a content-addressed change graph, so pulling a change out of the middle of a view is an O(1) metadata operation. The surrounding changes keep their exact hashes and nothing is re-applied or rewritten, unlike a git rebase.
**Does reorganizing history in Atomic rewrite commit hashes like git rebase?**
No. A git rebase produces new SHAs for every downstream commit and severs their provenance. Atomic never rewrites hashes when you reorganize: a change's identity and its dependencies are fixed at record time, so splitting, moving, or regrouping work only changes which view references it.
**How is Atomic different from Git for AI coding agents?**
Git records each change's position in a single lineage, so restructuring an agent's messy output means rewriting history and losing provenance. Atomic stores changes in one content-addressed graph and treats grouping as a read-time view, so agent work can be reorganized after the fact without rewriting anything or breaking the link back to the agent turn that produced it.
## Is Git Good Enough for AI Coding Agents?
Source: https://atomic.dev/blog/is-git-good-enough-for-agents/
Author: Lee Faus (Founder and CEO @ Atomic Software, Co.)
Author profiles: https://x.com/leefaus, https://www.linkedin.com/in/leefaus/
## Why is Git's data model a problem for AI coding agents?
**Git forces concurrent agent work into divergent linear histories that must later be merged.**
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.
## Why does Git lose the chain of custody for agent changes?
**Git's routine history operations create new commit identities, so provenance keyed to the old SHAs no longer identifies the history that ships.**
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.
## How should AI agent provenance be represented?
**AI agent provenance should be a typed causal graph connecting the change, the activity that produced it, and the responsible human or software agent.**
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.
## How does Atomic show what a coding agent changed and why?
**Atomic answers provenance questions by traversing recorded relationships instead of reconstructing intent from commit messages and logs.**
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.
## Why must provenance be recorded when the change is made?
**Provenance captured at the moment of causation is evidence; provenance reconstructed from session logs afterward is forensics.**
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.
### Common questions
**Is Git good enough for AI coding agents?**
Git's data model is an ancestry graph built in 2005 for human edits: strict, sequential, single-lineage. It reconciles concurrent work with line-by-line merges and rewrites commit identity on rebase, squash, and cherry-pick, which orphans provenance. For many agents writing concurrently, and for auditable provenance, Git has a structural gap, not just a feature gap.
**Why does git rebase or squash lose provenance?**
A Git commit's hash includes its parent's hash, so any operation that changes the parent (rebase, squash, cherry-pick) produces a new SHA and a new identity, and provenance keyed to the old commit is orphaned. Atomic's identity comes from the causal relationship between a decision and its change, not a position in a timeline, so there is nothing for a rebase to rewrite.
**How can multiple AI agents work at once without merge conflicts?**
Atomic combines a causal graph with patch theory. Patches commute, so independent changes apply in any order and converge to the same state, and every agent writes into one shared graph at once with no branch or merge step. Only genuinely overlapping edits become conflicts, and those are first-class states in the graph.
**How does Atomic store provenance for agent changes?**
Every change carries its intent and reasoning as typed nodes built on W3C PROV-O and JSON-LD, linked to the agent turn that produced it and validated with SHACL. It is generated at the moment of causation and stored inside the change record, so it is queryable and cannot be orphaned by a later rewrite.
## Graph Engineering Is How Agents Prove Their Work
Source: https://atomic.dev/blog/graph-engineering/
Author: Lee Faus (Founder and CEO @ Atomic Software, Co.)
Author profiles: https://x.com/leefaus, https://www.linkedin.com/in/leefaus/
Prompt engineering, then context engineering, then loop engineering. Each shift fixed something real. Better prompts, richer context, agents that plan and correct themselves. None of it answered the question that actually matters, how do you know an agent did what it was asked to do?
Most systems answer that informally. The model looks at its own output, decides it looks done, and exits the loop. A test runs, a tool call succeeds, a file changes, and the connection between the original goal and the proof that it got met stays implicit until someone reconstructs it later. Orchestration wrapped around probabilistic guesses isn't an execution model. What's missing isn't another prompting technique. It's a proof model.
## An Intent Is More Than a Prompt
Engineers think in solutions. That's what ends up in a prompt, and it's all the LLM ever sees, one proposed fix with no view into why it's needed or what it's not allowed to break.
At Atomic, we start earlier. We search the Vault for previous related work before ever proposing a change, then convert that proposed solution into a structured problem statement we call an Intent. It captures why the change should exist, the outcome someone wants, the criteria that outcome has to meet, the boundaries of the work, and the ordered tasks required to get there. Tasks depend on each other, and each one ties to the specific criteria it's supposed to satisfy. Tasks, acceptance criteria, change records, Intents, Memories, Turns, and Sessions are all semantically linked using W3C ontologies, and the Vault is where that linked structure lives.
A prompt is text. An Intent is a searchable record of change, one an LLM can validate against using skills instead of guessing. Run an atomic query against the first-class elements in the Vault, and it returns the linked elements in the semantic change graph, so the system can tell you which tasks are ready, which are blocked, which criteria are still unsatisfied, and what evidence still has to exist before the Intent counts as done.
## Loop Engineering Needs a Definition of Done
A loop is only as good as its stopping condition. Without an external definition of success, the agent ends up deciding whether its own answer is good enough: the code compiles, a tool returned success, a self-check says it's fine. None of that proves the objective got met.
An Intent graph changes what the loop is doing. The agent iterates against explicit proof obligations instead of its own judgment, tracing back through the Vault to the TODO, the acceptance criterion, and the problem statement each one has to satisfy. SHACL keeps that structure honest: an Intent needs acceptance criteria, a task needs to reference the criterion it addresses, and anything malformed gets rejected before it becomes trusted context for the next step. A task can't advance until its dependencies clear and its evidence checks out. A change that violates something ruled out of scope hasn't succeeded, even with every test green.
The loop stops being open-ended and converges on a state defined in advance. The model underneath stays probabilistic. The conditions governing completion don't have to be.
## Provenance Is Not Logging
Most systems treat agent activity as logs: a stream you dig through later if something breaks. Logs explain what happened. They don't explain why an action was supposed to serve the objective.
Atomic represents every session, every turn, every tool call, and every resulting change as structured provenance, built on W3C PROV, connected directly to the Intent, the task, the criteria, and the evidence produced. That gives you a chain you can walk in either direction. From an Intent, you can see every task it spawned and every change that came out the other end. From a change, you can walk backward and ask why it exists, who authored it, and what evidence justified including it.
That's the difference between reconstructing intent after a session closes and having it already there. Our competitors log intent as a transcript on a checkpoint branch, so by the time you go looking, you're doing archaeology on a session that already ended. A graph built this way gives you the answer before the question comes up, which is the whole point of refusing to leave the why unrecorded.
## From Execution to Proof
There's a rough analogy to mathematical proofs. The Intent is the proposition. Tasks are intermediate obligations. Dependencies set the order they resolve in. Acceptance criteria define what has to be demonstrated. Provenance records the steps, and evidence backs the claim that each obligation got satisfied. When all of that closes out, the Intent hasn't just been declared finished by whoever's watching. It's been demonstrated, and the graph is what lets you check that instead of taking someone's word for it.
That's the gap between a harness and an execution system. A harness helps a model use tools and repeat actions. It doesn't establish correctness. A proof-oriented system defines the work, constrains how it proceeds, records the provenance, and checks the outcome against an explicit model of success. Making probabilistic models deterministic was never the goal, that's a category error. The goal is building deterministic systems around probabilistic models, since agents will keep generating uncertain output and needing correction, and good infrastructure assumes that instead of hiding from it.
Software delivery shouldn't run on an agent saying "I think I'm done." It should run on whether the system can prove the work satisfies the Intent.
### Common questions
**How do you know an AI coding agent actually did what it was asked?**
Most systems let the model decide its output looks done and exit the loop. Atomic uses a proof model instead: work is captured as an Intent with acceptance criteria and ordered tasks, execution is recorded as W3C PROV provenance linked to that Intent, and completion is demonstrated in a graph you can check rather than asserted by the agent.
**What is an Intent in Atomic, and how is it different from a prompt?**
A prompt is text describing a proposed solution. An Intent is a structured, searchable record of change: why it should exist, the outcome wanted, the acceptance criteria that outcome must meet, the scope boundaries, and the ordered tasks, all semantically linked with W3C ontologies so an agent can validate against it instead of guessing.
**How does Atomic give an agent loop a real definition of done?**
The agent iterates against explicit proof obligations traced through the Vault to each acceptance criterion and problem statement. SHACL enforces the structure, a task cannot advance until its dependencies clear and its evidence checks out, and a change that violates an out-of-scope rule has not succeeded even with every test green.
**How is provenance different from logging?**
Logs explain what happened; they do not explain why an action served the objective. Atomic represents every session, turn, tool call, and change as structured W3C PROV provenance connected to the Intent, task, criteria, and evidence, so you can walk from a change back to why it exists instead of reconstructing intent from a transcript after the fact.
## Why Semantic Call Graph Queries Outperform Traditional Agent Search
Source: https://atomic.dev/blog/semantic-call-graph/
Author: Lee Faus (Founder and CEO @ Atomic Software, Co.)
Author profiles: https://x.com/leefaus, https://www.linkedin.com/in/leefaus/
## The hidden cost of how agents navigate code
Before an AI coding agent can complete a task, it has to find the relevant code. In every standard agent today, that means grep, ripgrep, find, or directory listing followed by file reads. The process looks roughly like this: search for a keyword, get hundreds of matching lines, open several files to identify which one is actually relevant, discover the right file is named something different, search again, trace imports manually, and finally begin the actual task with a fraction of the context window remaining.
This is not an edge case. It is the default behavior of every major coding agent running against a real codebase today.
A typical session in a large codebase involves grepping for a likely keyword, getting 200 lines of matches, opening three or four files to figure out which one is actually relevant, realizing the right file is named something different and grepping again, then tracing imports manually before finally starting the actual task with significantly less context window left. **Larger context windows do not fix this; they just delay it.**
After 5 to 6 exploration turns, the context is polluted with rejected files, wrong matches, and dead-end grep results. Research shows that performance degrades by 30 percent or more when irrelevant content accumulates in the middle of the context.
> The industry has been treating this as a search quality problem. Better tools, faster ripgrep, smarter regex. The problem is not the search tool. The problem is that the repository has no structural understanding of itself.
Grep is excellent for finding exact string matches, but for the exploratory tasks common in agentic work, its limitations become clear. It has no understanding of indirection or semantic meaning, and it often returns large, noisy blocks of code that pollute the context window and degrade reasoning.
## Context window is a finite resource, not a buffer
The industry response to context exhaustion has largely been to expand the context window. Claude's 1M token window, Gemini's 2M token experiments, and sub-agent architectures that offload file reading to worker instances are all attempts to work around the same underlying issue.
Fitting a codebase into context does not guarantee that an LLM attends to the architecturally critical files for a given task. **Larger context windows do not eliminate the need for structural navigation; they shift the failure mode from retrieval capacity to navigational salience.**
For a modestly sized project with 200 files, a thorough codebase analysis can burn through 100,000 or more tokens before the agent produces a single useful answer. For larger codebases, agents hit context limits and rate limits before returning anything actionable.
The turn limit problem compounds this further. An agent that spends its early turns navigating has fewer turns available to reason, implement, and verify. Research from ETH Zurich found that context files consistently increase the number of steps required to complete tasks, with agents running more tests, reading more files, executing more grep searches, and performing more code quality checks, behavior that was often unnecessary for resolving the specific task at hand. More context loaded upfront does not help an agent finish faster. It gives the agent more to reason about before it can act.
One of the most common failure modes in agentic systems is bloated tool sets that cover too much functionality or lead to ambiguous decision points about which tool to use. Curating a minimal viable set of tools for the agent can lead to more reliable maintenance and pruning of context over long interactions.
## What Atomic does differently
Atomic does not ask agents to navigate the repository. **It gives the repository an understanding of itself.**
When a repository is imported into Atomic, it is enriched with AST analysis, tree-sitter entity extraction, and a syntext n-gram content index. The result is a semantic graph that operates at the function, class, and token level. When an agent needs to find where the authentication library was last modified, it queries the graph directly. The answer is a structured result set, not a list of file paths to manually inspect. The agent arrives at the relevant code in a single graph traversal rather than after five or six exploratory grep turns that leave the context window full of dead ends.
Benchmark · identical prompt, identical codebase
| Metric | Claude Code | Atomic | Difference |
| --- | --- | --- | --- |
| **Cost** | $0.3584 | $0.2822 | 21% cheaper |
| **API duration** | 1m 15s | 42s | 44% faster |
| **Wall duration** | 2m 27s | 1m 50s | 25% faster |
| **Output tokens** | ~5.5k | ~2.0k | 64% less verbose |
| **Cache reads** | ~1.14M | ~202k | 82% less context |
| **Cache writes** | ~76.5k | ~20.6k | 73% less written |
Atomic semantic graph vs. Claude Code grep/find: identical prompt, identical codebase.
The **82 percent reduction in cache reads** is the most significant number in this table. It represents how much of the codebase the agent had to touch in order to complete the task. In a standard agent session, that overhead is the tax paid for navigating a repository that does not understand its own structure. In Atomic, the graph answers the question directly.
## The architecture behind the query: RDF triples and ontologies
The reason Atomic can answer questions like _"who changed the authentication library"_ rather than simply _"which files contain the authentication library"_ comes down to how the knowledge graph is structured internally. Atomic's graph is built on an **RDF triple pattern**: every relationship in the repository is stored as a subject, predicate, object statement. In the codebase, this surfaces as typed node IDs and a formal `EdgeKind` ontology.
A node ID in Atomic is not a raw hash. It carries its type as a namespace prefix:
```
file:src/auth/login.rs
change:ABC12345
goal:swift-meadow-a3f2
intent:PIMO-1
entity:src/auth/login.rs::validate_token
```
Edges between those nodes are typed predicates drawn from a controlled ontology:
```
led_to : forward causal relationship
explored_via : a decision was informed by this exploration
committed_via : a decision produced this file change
verified_by : a commitment was validated by this verification
blocked_by : a human gate interrupted this work
failed_with : a tool call produced this error
```
A query asking _"who changed the authentication library"_ resolves as a graph traversal: find all nodes of kind `file` matching `auth`, follow `committed_via` edges back to `change` nodes, follow those to `goal` and `intent` nodes, and surface the associated identity and agent metadata. No file needs to be opened. No grep pattern needs to match. The answer is a structured subgraph retrieved directly from the triple store.
This is what makes the 82 percent reduction in cache reads possible. The agent is not reading files to infer structure. The structure was encoded into the graph at enrichment time, and every subsequent query retrieves only the nodes and edges that answer the specific question. The triple pattern also means the graph is composable: any query result is itself a valid subgraph that can be further traversed, filtered, or exported as DOT or JSON for visualization.
// command surface
atomic vault query graph exposes this directly.
Pass any search term and Atomic returns a force-directed graph of the connected subgraph, exportable to SVG via Graphviz or rendered inline as interactive HTML. The graph is not generated for display purposes. It is the actual data structure the agent queries.
## The compounding return
Every session run against an Atomic repository makes the graph richer. Provenance records, intent history, and semantic enrichment accumulate with each change. An agent running its hundredth session against a repository has access to everything every prior agent and developer recorded: what was changed, why it was changed, which model made the decision, and how that decision connects to the broader architecture.
Standard agents reset to zero with each new session. They re-navigate the same codebase, re-read the same files, and re-discover the same structure their predecessors already mapped. The problem with long, unplanned sessions is that they accumulate context organically. The agent explores, hits dead ends, backtracks, and all of that exploratory noise stays in the window. Atomic eliminates this by making prior navigation a permanent part of the repository rather than a discarded session artifact.
The efficiency gains in the benchmark above are from a single session. The compounding gains across a team running agents continuously against a shared repository are not yet fully measured. That research is ongoing.
References
1. [CodeCompass: Graph-Structured Dependency Navigation Outperforms Retrieval in Architecture-Heavy Tasks](https://arxiv.org/pdf/2602.20048), arXiv preprint · 2602.20048 (Feb 2026)
2. [Agentic Search: How Coding Agents Find the Right Code](https://www.morphllm.com/agentic-search), Morph · morphllm.com (Feb 2026)
3. [Your Agent Is Spending More Time Finding Code Than Understanding It](https://dev.to/akashgoenka/your-agent-is-spending-more-time-finding-code-than-understanding-it-38in), DEV Community · Akash Goenka (Apr 2026)
4. [Effective Context Engineering for AI Agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents), Anthropic Engineering (2025)
5. [Context Rot in AI Coding Agents, What It Is and How to Prevent It](https://www.mindstudio.ai/blog/context-rot-ai-coding-agents-how-to-prevent), MindStudio (Apr 2026)
6. [How to Use Sub-Agents for Codebase Analysis Without Hitting Rate Limits](https://www.mindstudio.ai/blog/how-to-use-sub-agents-for-codebase-analysis), MindStudio (Mar 2026)
7. [New Research Reassesses the Value of AGENTS.md Files for AI Coding](https://www.infoq.com/news/2026/03/agents-context-file-value-review/), InfoQ (Mar 2026)
8. [grep, ripgrep, and AI-Powered Text Search](https://ceaksan.com/en/grep-ripgrep-and-text-search-in-the-age-of-ai), ceaksan.com (Apr 2026)
9. [Beyond Grep and Vectors: Reimagining Code Retrieval for AI Agents](https://medium.com/@akshat_ilen/beyond-grep-and-vectors-reimagining-code-retrieval-for-ai-agents-85049e8cf9e9), Medium · Akshat Jain (Oct 2025)
### Common questions
**Why do AI coding agents waste so much context searching code?**
Standard agents navigate with grep, ripgrep, find, and file reads: search a keyword, get hundreds of matches, open several files, discover the right one is named differently, search again. After five or six exploration turns the context is full of dead ends, and research shows performance drops 30% or more when irrelevant content accumulates in the middle of the context.
**Do larger context windows fix the code-navigation problem?**
No. Larger windows delay context exhaustion, they do not fix it. Fitting a codebase into context does not make the model attend to the architecturally critical files, and it shifts the failure mode from retrieval capacity to navigational salience. The fix is structural navigation, not more tokens.
**How much faster is a semantic code graph than grep-based search?**
On an identical prompt and codebase, Atomic's semantic graph cut cache reads 82% (a proxy for how much of the codebase the agent had to touch), ran the API 44% faster (1m 15s to 42s), and cost 21% less than Claude Code's grep and find approach.
**How does Atomic's code knowledge graph work?**
On import, Atomic enriches the repo with AST analysis, tree-sitter entity extraction, and an n-gram content index into a semantic graph at the function, class, and token level, stored as RDF triples with a typed EdgeKind ontology. A question like who changed the authentication library resolves as a single graph traversal instead of five or six grep turns.
## The Challenge of Merge Conflicts at Agent Scale
Source: https://atomic.dev/blog/merge-conflicts/
Author: Lee Faus (Founder and CEO @ Atomic Software, Co.)
Author profiles: https://x.com/leefaus, https://www.linkedin.com/in/leefaus/
## Executive summary
The version control market is experiencing a structural disruption. **Git, the incumbent with 94 percent market share, was designed in 2005 for human developers editing text files.** Two decades later, AI agents generate 41 to 46 percent of all new code, and one in four AI-generated pull requests produces merge conflicts that Git's line-level architecture cannot resolve without human intervention.
This assessment evaluates whether next-generation version control systems, specifically Atomic VCS, represent a credible market opportunity or a niche technical curiosity. Findings are based on primary research including direct codebase inspection of 233,000 lines of Rust across 6,423 automated tests, peer-reviewed academic datasets, regulatory landscape analysis, and architectural evaluation against Git's data model.
> The conclusion is straightforward. The market opportunity is real. The technology is sound. Git has a structural inability, not merely a feature gap, to address the two problems that matter most in AI-native development: provenance integrity and fine-grained merge resolution.
## Key findings
- **One in four AI-generated pull requests hits a merge conflict in Git** (27.67%, n = 107,026 PRs). That rate will increase as AI-generated code volume grows.
- **Git's core workflow operations (squash merge, rebase, cherry-pick) systematically destroy provenance metadata.** This is not a feature gap. It is a data model incompatibility. Git's identity model ties commit SHA to parent hash. Any operation that changes the parent produces a new identity, orphaning any provenance attached to the original.
- **Workarounds exist but are fragile by design.** Diff-hash-indexed sidecars, git-notes standards, and replace refs can approximate provenance preservation, but all require explicit opt-in configuration, external tooling, and platform-level enforcement. None are default, automatic, or tamper-evident.
- **Atomic VCS provides provenance integrity structurally.** Its architecture separates immutable changes, content-addressed and Blake3-hashed, from mutable views, which are perspectives on which changes are active. No operation in Atomic can orphan provenance because no operation rewrites change identity.
- **Token-level merge reduces Git's conflict surface by an estimated 36 percent.** Microsoft's MergeBERT study across 220,000 real-world conflicts found that token-level diff3 auto-resolves 36.1 percent of line-level conflicts without any AI model, purely through finer granularity.
- **No enacted regulation currently mandates AI code provenance.** However, the trajectory is clear. The EU AI Act (August 2026), evolving FDA software validation requirements, and emerging DoD AI contractor frameworks point toward mandatory attribution within 18 to 36 months.
## Market context: the structural shift
### The scale of AI code generation
The shift from AI-assisted development to AI-generated development occurred between 2024 and 2025. **It was not a gradual trend. It was a phase transition.** The toolchain infrastructure built for human-authored code is now carrying a fundamentally different workload.
| Indicator | Value | Source |
| --- | --- | --- |
| Code written by AI (active Copilot users) | 46% | GitHub / Microsoft, 2025 |
| All code globally that is AI-generated | 41% | FinishKit State of AI Code, 2026 |
| US developers using AI coding tools | 92% | FinishKit, 2026 |
| GitHub Copilot active users | 20M+ | GitHub, mid-2025 |
| Fortune 100 companies using Copilot | 90% | Microsoft, 2025 |
| Merged code that is AI-authored (DX sample) | 22% | DX Research, 2025–2026 |
### Git's merge architecture as a scaling bottleneck
The AgenticFlict study (arXiv:2604.03551, April 2026) provides the first large-scale empirical measurement of merge conflicts in AI-generated contributions. The dataset covers 107,026 pull requests across 59,412 repositories.
| Metric | Value |
| --- | --- |
| AI agent PRs analyzed | 107,026 of 142,652 collected |
| Repositories represented | 59,412 |
| **PRs with merge conflicts** | **29,609 (27.67%)** |
| Fine-grained conflict regions | 336,380 |
| Avg. conflict regions per conflicting PR | 11.36 |
| Avg. conflicting lines per conflicting PR | 500+ |
| Conflict rate, OpenAI Codex (highest) | 32.31% |
| Conflict rate, GitHub Copilot (lowest) | 15.43% |
The data reveals a compounding negative dynamic. As AI generates more concurrent changes, merge conflicts increase. Longer integration cycles produce longer-lived branches. Longer-lived branches produce more conflicts. **Git's line-level three-way merge cannot break this cycle** because it reports a conflict whenever two branches modify the same line, regardless of whether the actual edits overlap at the character or token level.
### Git's absence of AI awareness
Git's data model stores commits as snapshots of a file tree. A commit records author name, author email, timestamp, parent hash, tree hash, and message. There is no field for AI model or provider identity, token usage or inference cost, session provenance or decision chain, confidence score or verification status, or delegation scope or authorization.
The `Co-authored-by: Copilot` convention is prose in a free-text message field. It is not structured data, not queryable, not cryptographically signed, and not preserved through standard Git workflows. **It is a naming convention, not a provenance system.**
## The provenance integrity problem
Git's core workflow operations (squash merge, rebase, and cherry-pick) systematically orphan any provenance metadata attached to commits. This is not a feature gap. It is a data model incompatibility: Git's commit identity includes the parent hash, so any operation that rewrites history produces new commit SHAs and silently severs any external provenance indexed to the originals.
Proposed solutions (new ref types, git-notes standards, and diff-hash sidecars) address the durability of the provenance record but not the integrity of the audit trail. As long as Git permits history rewriting by default, a provenance system built on top of it cannot guarantee that its records accurately describe the canonical history an auditor will inspect.
> A new ref type solves durability. It does not solve integrity. An audit trail that might be accurate is not an audit trail.
Atomic eliminates this problem structurally by separating change identity from change ordering. Changes are content-addressed and parent-independent. No workflow operation in Atomic rewrites change identity, which means no workflow operation can orphan provenance. The full technical and architectural case for this distinction is documented in [Atomic Code Intelligence: The Evolution of Version Control for the Age of Agents](/background/).
## The merge granularity gap
### Quantifying the conflict surface
Git's merge algorithm operates at line granularity. If two branches modify the same line, Git reports a conflict regardless of whether the actual edits overlap at the character or token level. Atomic's hierarchical CRDT operates at token granularity.
```
Git: Line-level
"same line modified" → CONFLICT
Atomic: Token-level
"same token modified" → CONFLICT
"different tokens on same line" → AUTO-MERGE
```
### Estimated conflict reduction
The most rigorous available proxy is Microsoft's MergeBERT study (FSE 2022, Svyatkovskiy et al.), which applied token-level diff3 to 220,000 real-world merge conflicts.
| Finding | Value |
| --- | --- |
| Conflicts auto-resolved by token-level diff3 (no AI) | 36.1% |
| Conflicts where more than 1 token-level sub-conflict exists | 5% |
| Token-level resolutions that are trivial (take A or take B) | 74% |
The Brindescu et al. (2019) conflict taxonomy, covering 6,979 conflicts across 143 Java projects, provides a complementary framework for understanding where finer granularity provides structural advantage.
| Conflict type | Frequency | Resolvable by finer granularity |
| --- | --- | --- |
| **Semantic** (entangled logic) | 59.5% | No, requires new code |
| **Formatting** (whitespace / style) | 23.2% | Yes, trivially. Also addressable by pre-commit hooks. |
| **Disjoint** (unrelated edits, same location) | 14.5% | Yes, this is the token-level CRDT's primary contribution. |
| Delete and other | ~2.8% | Case-dependent |
The estimated reduction for Atomic's token-level CRDT is consistent with the MergeBERT finding at approximately 36 percent. The unique contribution beyond what formatting tools already handle, the _disjoint_ category, accounts for approximately 14.5 percent of conflicts.
### Implications at enterprise scale
Applied to the AgenticFlict baseline, the productivity impact is material.
| Scenario | Conflict rate | Conflicting PRs per 100K |
| --- | --- | --- |
| Git (current) | 27.67% | 27,670 |
| Atomic (est. 36% reduction) | ~17.7% | ~17,710 |
| **Reduction** | | **~9,960 fewer conflicting PRs** |
For an enterprise running 100,000 AI-generated PRs per year, this represents approximately 10,000 merge conflicts that would require human attention under Git but resolve automatically under Atomic. At an estimated 30 to 60 minutes per conflict resolution, the productivity impact is **5,000 to 10,000 developer-hours annually**.
## Technology maturity assessment
### Architecture and implementation
Atomic is implemented in Rust and built on production-grade infrastructure. The codebase comprises **233,000 lines of Rust across 454 source files with 6,423 automated test functions**. The change format is at V3, indicating multiple design iterations. This is not a research prototype.
| Component | Implementation | Maturity |
| --- | --- | --- |
| **Storage engine** | redb (Rust embedded COW B-tree) | Production-grade |
| **Content hashing** | Blake3 (3–4× faster than SHA-256) | Industry standard |
| **Change format** | V3 streaming · per-section zstd | Custom, well-tested |
| **Graph model** | Pijul-lineage directed graph | Proven lineage |
| **CRDT layer** | Hierarchical Trunk / Branch / Leaf | Novel · implemented |
| **Merge engine** | Three-way token-level diff w/ semantic awareness | Implemented |
| **AI agent hooks** | Claude Code · Gemini CLI · OpenCode auto-detect | Implemented |
| **Provenance** | Causal decision DAG per session | Implemented |
| **Attestation** | Per-session: model, tokens, cost, Ed25519 sig | Implemented |
| **Identity** | Ed25519 identities with delegation scopes | Implemented |
### Current capability gaps
An honest assessment requires acknowledging the gaps that enterprise adoption will require closing.
| Gap | Severity | Assessment |
| --- | --- | --- |
| Hosted platform | Critical | No equivalent of GitHub or GitLab. Enterprise adoption requires hosted code review, access control, and CI integration. The single highest-priority investment. |
| Ecosystem integration | Critical | No GitHub Actions, no CI/CD hooks, no VS Code or JetBrains plugins. Workflow parity is a prerequisite for developer adoption. |
| Community | High | Long-term viability requires a team, corporate backing, or a strong open-source contributor base. |
| Performance benchmarks | High | No published benchmarks against Git on repositories at scale. Credibility requires numbers against Linux, Chromium, and enterprise monorepos. |
| Documentation | Medium | Technical depth is incomplete in several areas. |
| Large binary support | Medium | No documented equivalent of Git LFS. |
The absence of AI-mediated conflict resolution is a deliberate design choice, not a gap. Atomic minimizes conflicts algorithmically through finer granularity rather than resolving them with an LLM.
## Regulatory landscape
### Current state
**No enacted regulation in any jurisdiction currently mandates AI code provenance or attribution in source code.** The regulatory environment is one of trajectory, not immediate mandate.
| Regulation | Scope | Mandates AI provenance |
| --- | --- | --- |
| EU AI Act Art. 50 (Aug 2026) | Consumer-facing AI content. Carve-out for assistive editing. | No |
| FINRA 2026 Oversight Report | GenAI in business comms / financial decisions. Guidance. | No |
| CMMC | Audit trails for classified data access. | No (adjacent) |
| SOC 2 / ISO 27001 | Change management controls. No explicit AI language. | No (interpretive) |
| FDA Software Validation | Strictest software controls, no AI attribution mandate yet. | No (evolving) |
### The 18–36 month horizon
The regulatory trajectory is consistent across multiple jurisdictions and frameworks. The EU AI Act's framework is designed for iteration. As AI-generated code becomes the majority of new software, the assistive editing carve-out faces increasing pressure. The FDA already requires detailed development documentation for software in medical devices. The DoD NDAA FY2026 AI framework is actively defining requirements for AI tools used by defense contractors.
> Organizations that invest in provenance infrastructure now will be positioned to meet these requirements as they materialize. Organizations that defer will face retrofit costs against a Git history that has already squashed away the records they will need.
## Competitive dynamics
### The limits of GitHub's incremental approach
GitHub has taken initial steps toward AI provenance. The Copilot Coding Agent (March 2026) embeds an `Agent-Logs-Url:` trailer in commits and marks every Copilot-authored commit with `Co-authored-by: Copilot`. These are meaningful first steps with **four structural limitations**:
- **Coverage is partial.** Only GitHub's own agent is tracked. Claude Code, Cursor, Devin, OpenCode, and any agent running in CI are invisible.
- **Durability is not guaranteed.** Trailers are commit-message text. They survive squash only if GitHub's UI explicitly preserves them, a platform decision, not an architectural guarantee.
- **Depth is shallow.** No model version, no token counts, no cost metadata, no decision chain. Session logs are stored on GitHub's servers, making them platform-locked and non-portable.
- **Portability is absent.** Moving a repository from GitHub to GitLab severs the `Agent-Logs-Url` link entirely.
### Atomic's structural position
Atomic does not face this tension because it does not rewrite history. Changes are immutable. Views provide the clean history experience, showing only what is relevant to current work, without destroying the underlying change records. **This is a consequence of the data model, not a feature built on top of it.**
The competitive moat is not that Atomic can do things Git cannot. The moat is that Atomic does these things automatically, by default, with zero configuration, and with cryptographic guarantees, while Git requires opt-in tooling, platform enforcement, and careful maintenance to approximate the same outcome.
## Strategic recommendations
### For technology investors
The market opportunity is real and growing. AI-generated code is not a trend. It is the new default. Atomic is the most advanced implementation in this space: 233,000 lines of Rust with 6,423 tests, a working AI agent integration, cryptographic attestation, a semantic knowledge graph built on RDF triple patterns, and a principled CRDT-based merge engine.
**The primary risk is execution, not technology.** The architecture is sound. What remains is building a hosted platform, achieving ecosystem integration, growing a team and community, and executing go-to-market against a deeply entrenched incumbent.
### For enterprise technology leaders
- **Begin tracking AI code provenance now**, even within Git. Adopt the git-ai standard or AIIR diff-hash sidecar as an interim measure.
- **Evaluate Atomic for greenfield AI-native projects** where provenance requirements are anticipated: regulated industries, government contracts, safety-critical systems.
- **Quantify your actual merge conflict cost.** Run the AgenticFlict simulation pipeline against your own repositories. If it approaches 28 percent, the ROI case becomes concrete and measurable.
- **Do not assume GitHub will solve this at the foundation.** A multi-vendor AI development strategy requires vendor-neutral provenance infrastructure.
### For the Atomic team
- **The hosted platform is the single highest-priority investment.** Mercurial's technical superiority did not overcome GitHub's network effects. Technical merit without a hosted collaboration layer does not convert into adoption.
- **Publish benchmarks.** Running Atomic against Git on the Linux kernel, Chromium, and at least one large enterprise monorepo is required for enterprise credibility.
- **The regulatory wedge is the go-to-market entry point.** Defense, finance, and life sciences are the highest-priority verticals.
- **GitHub integration is the bridge strategy.** Adoption at the margin is more achievable than adoption as a migration.
## Conclusion
Git's dominance is not threatened by a better version of Git. It is threatened by a change in what version control must do. When AI generates the majority of code, version control must answer questions Git was never designed to answer: _who wrote this, human or machine, which model, at what cost, with what reasoning, and can you prove it_.
Atomic Code Intelligence provides structurally sound answers to those questions. Its architecture (immutable content-addressed changes, hierarchical CRDT merge, causal provenance graphs, and cryptographic attestation) addresses the AI era's requirements not as features bolted onto an existing system but as consequences of its data model.
> The technology is mature. The market need is demonstrated by data. The competitive moat is structural, not feature-wise. What remains is execution.
Sources & methodology
### Primary research
1. [github.com/atomicdotdev/atomic](https://github.com/atomicdotdev/atomic), 233K lines of Rust · 454 source files · 6,423 test functions (Codebase)
2. [docs.atomic.dev](https://docs.atomic.dev), Architecture & reference documentation review (Docs)
### Academic sources
1. [AgenticFlict: A Large-Scale Dataset of Merge Conflicts in AI Coding Agent Pull Requests](https://arxiv.org/abs/2604.03551), arXiv preprint · 2604.03551 (Apr 2026)
2. MergeBERT / DeepMerge, Svyatkovskiy et al. · Microsoft Research · 220K real-world conflicts; token-level diff3 auto-resolves 36.1% (FSE 2022)
3. Merge conflict taxonomy, Brindescu et al. · 6,979 conflicts, 143 Java projects (2019)
4. [Conflict-free Replicated Data Types](https://arxiv.org/abs/1805.06358), Preguica et al. · arXiv 1805.06358 (2018)
5. [A Categorical Theory of Patches](https://arxiv.org/abs/1311.3903), Mimram & Di Giusto · arXiv 1311.3903 (2013)
6. [CodeCompass: Graph-Structured Dependency Navigation Outperforms Retrieval in Architecture-Heavy Tasks](https://arxiv.org/pdf/2602.20048), arXiv preprint · 2602.20048 (Feb 2026)
### Industry sources
1. Copilot adoption & AI-generated code share, GitHub / Microsoft · 20M+ active users · 46% of code written by AI (2025)
2. The State of AI-Generated Code, FinishKit · 41% of all code globally AI-generated (2026)
3. AI-authored merged code share, DX Research · 22% of merged code AI-authored (2025–26)
4. VCS market share, CheckThat.ai · Git at 93.87% (2026)
5. [Patch theory & CRDT foundations](https://pijul.org/manual/theory.html), Pijul Manual · pijul.org (Reference)
### Provenance tooling referenced
1. AIIR: diff-hash-indexed provenance receipts, Invariant Systems (Project)
2. git-ai, Git AI Standard v3.0.0, refs/notes/ai with line-level attribution (Spec)
3. squash-tree, logical squash graph, widefix/squash-tree (Feb 2026)
4. Copilot Coding Agent provenance trailer, GitHub · Agent-Logs-Url: commit trailer (Mar 2026)
### Regulatory
1. EU AI Act, Article 50, Consumer-facing AI content marking · assistive-editing carve-out · enforceable August 2026 (Aug 2026)
### Common questions
**How often do AI-generated pull requests cause merge conflicts in Git?**
In the AgenticFlict study of 107,026 AI-agent pull requests across 59,412 repositories, 27.67% (about one in four) produced merge conflicts Git's line-level architecture cannot resolve without human intervention, and that rate rises as AI-generated code volume grows.
**Why do git rebase, squash, and cherry-pick destroy provenance?**
Git ties a commit's SHA to its parent hash, so any operation that changes the parent produces a new identity and orphans provenance attached to the original. It is a data-model incompatibility, not a feature gap. Atomic separates immutable, content-addressed changes from mutable views, so no operation rewrites change identity.
**Does token-level merging reduce conflicts compared to line-level?**
Yes. Microsoft's MergeBERT study across 220,000 real-world conflicts found token-level diff3 auto-resolves 36.1% of line-level conflicts through finer granularity alone, with no AI model involved. Atomic merges at token granularity for this reason.
**Is a Git alternative for AI agents a real market or a niche curiosity?**
Git holds about 94% market share but was designed in 2005 for humans editing text, while AI now generates 41 to 46% of new code. Analysis of 233,000 lines of Rust and 6,423 tests concludes the opportunity is real: Git has a structural inability, not a feature gap, on the two things that matter for AI-native development, provenance integrity and fine-grained merge resolution.