What is agent-native version control?
Most tools let agents use Git. A few let thousands of agents use Git at once. Almost none were designed for the thing agents actually produce: autonomous software change. This page defines what that design requires, and what Atomic has built against it.
Agent-native version control is a source-control architecture designed to represent, coordinate, and verify software changes produced by humans and autonomous agents. It combines durable change identities, causal dependencies, semantic relationships, intent, provenance, and evidence with infrastructure capable of supporting concurrent autonomous workloads.
These are architectural characteristics, not mutually exclusive product categories. A system can be all three at once. Faster Git operations, agent session recording, and AI-assisted code review may be useful capabilities, but they do not individually establish an agent-native architecture. The defining characteristic is whether the underlying change model, infrastructure, and workflows are designed around autonomous software change.
What must an agent-native system of record represent?
Not a commit log with metadata bolted on. A data model in which change, structure, intent, and evidence are first-class, durable, and addressable. The simplest test is to look at what one change carries.
- Durable change identity independent of branch ancestry. A change is identified by its content and causal dependencies, not by its position in a mutable ancestry chain. A snapshot hash that includes its parent dies on rebase; a content-addressed patch survives reorganization.
- Patch-based transformations with explicit causal dependencies. Dependencies travel with the change, so independent work commutes, duplicate work deduplicates, and partial histories reconstruct safely.
- Safe composition of independent changes. When two agents touch unrelated parts of the graph, their changes compose without manual merge resolution.
- Queryable semantic relationships among code entities. Files, functions, classes, tokens, and their call and dependency relationships are graph nodes, not text locations.
- First-class intent, acceptance criteria, and tasks. The request that motivated a change is linked to the change itself, not parked in an external ticket system.
- Provenance and attestation bound to change identity. Who or what produced the change, and the evidence behind it, travel with the change across every workflow operation.
- Logical software state independent of materialized files. The repository is a graph state that can be queried and reasoned about before any file is written to disk.
- Consistent partial projections of graph state. Agents read coherent slices of the repository without materializing the entire working tree.
Illustrative. A system that stores context as external metadata around commit IDs has different identity and composition guarantees from a system that makes causal change fundamental. In the former, a rebase or squash severs the link between the metadata and the canonical history. In the latter, the provenance is part of the change object itself.
Atomic implements this through a dual-layer representation: a graph layer for mathematically sound patch application and a semantic layer for human- and agent-readable file, line, and token review. Read about change identity, patch theory, and the dual-layer diff in the documentation.
What must agent-native version control enable?
Once change, intent, and evidence are first-class in the record, these are the workflows that become possible. Read them in the order an agent meets them.
- Start from intent Intent-driven and specification-driven development · acceptance criteria and task traceability · shared persistent agent memory
- Understand before touching Semantic code search and graph queries · zero-materialization impact and blast-radius analysis · on-demand materialization of relevant files and dependency closures
- Change alongside others Concurrent multi-agent writes · causal views and dependency-aware composition · session and turn recording
- Prove it Intent-scoped review · provenance and cryptographic attestations · policy-driven validation and promotion
- Ship and reproduce Reproducible change and release state · interoperability with different coding agents and IDEs
Real, lightly compressed. An agent (pi) is asked to make the CLI repeat until Ctrl+C. It edits the code, runs the tests, and opens an intent. Then Atomic shows what it left behind: the intent with its criteria and evidence, the change with the model and session that produced it, and a triage verdict of blocked, because nobody independent has reviewed it yet. The agent’s turn is sped up; the checks are at reading pace.
Notice what is absent from that sequence: cloning a repository, opening a worktree, grepping for a function, reconstructing context from a transcript. In an agent-native system those are not steps an agent takes. They are costs the architecture has removed.
The reason is where the agent talks to. Instead of a local checkout that has to be synchronized, the agent speaks to the Atomic server over RPC: it queries the graph, reads only the files and dependency closures it needs, and records changes directly against the shared record. Changes become visible to other agents and reviewers as they happen, with no push or pull step in between, and the agent never has to hold a full copy of the repository to do its work. Each step is shown in more detail on the Features page.
What infrastructure do autonomous coding agents require?
The data model and the workflows above are necessary and not sufficient. Agents operate in large numbers, often unattended, on laptops, in containers, and inside customer environments far from any central server. The infrastructure has to hold up under that, or the record does not.
- Bounded RPC streaming
- Queries and responses stream incrementally so agents do not block on full repository materialization.
- Incremental replication
- Changes and graph metadata propagate without requiring full repository clones.
- Push-based and pull-based synchronization
- Agents in different network conditions need both models.
- Selective file and directory materialization
- Agents read only the files and dependency closures they need, not entire working trees.
- Near-zero recovery point objectives for acknowledged changes
- Once a change is acknowledged, its loss is a failure mode, not a routine risk.
- Rapid failover and recovery time objectives
- Agent sessions resume against available infrastructure without manual intervention.
- High availability and multi-region replication
- Teams distributed across regions need consistent access to the graph.
- Horizontal scaling for concurrent agent workloads
- Capacity comes from adding nodes, not vertical upgrades to a single server.
- Offline operation and eventual reconciliation
- Agents record changes and query local state without continuous connectivity.
- Observability, resource efficiency, and reproducibility
- The system exposes metrics that make agent behavior inspectable and resource use accountable.
- Multi-tenant SaaS
- Shared infrastructure with isolation between organizations.
- Dedicated single-tenant deployments
- For organizations that require hardware-level or network-level isolation.
- Customer-controlled self-hosted deployments
- For customers who must run the system inside their own infrastructure.
- Data sovereignty and residency controls
- Source code, prompts, memories, provenance, and agent session records may all contain sensitive intellectual property and must remain in the jurisdictions the owner specifies.
- Encryption, identity, access control, and intellectual-property protection
- All repository data, metadata, and transport are encrypted; access is cryptographically verifiable.
These are architectural characteristics, not product specifications. A system that is agent-native must be capable of satisfying them; how it does so is an implementation decision. Atomic's status against each is in the implementation table.
How do you know whether an AI-generated change can be trusted?
You can't trust a change you can't explain. Everything above exists so that five questions have answers that are already in the record when a reviewer, an auditor, or another agent asks them.
-
What changed?
The exact patch, its semantic scope, and the entities it touched.
From change identity and the semantic graph -
Why did it change?
The intent, acceptance criteria, and task that motivated the work.
From first-class intent -
Who or what produced the change?
The human identity behind the agent session, the model and provider used, and the causal chain of exploration that led to the edit.
From provenance and session recording -
What else could the change affect?
The blast radius across callers, dependencies, and related entities in the semantic graph.
From graph queries and causal dependencies -
What evidence supports accepting it?
Verification results, review attestations, policy checks, and the freshness of the approval relative to the current graph state.
From attestation and policy-driven promotion
The data model makes these questions answerable, because intent, provenance, and evidence are bound to change identity. The infrastructure guarantees make them reliably answerable, because acknowledged changes are durable and auditable. The functional workflows make them routinely answerable, because review, attestation, and triage are built into the graph rather than assembled after the fact. Atomic implements these assurances through triage, attestations, and intent verification.
How does Atomic implement agent-native version control?
Requirement, mechanism, and where to verify it. Of the sixteen rows below, fourteen are implemented in the current CLI and documented; two are proposed and not yet demonstrated in production builds. The requirements themselves are meant to be useful whether or not you are evaluating Atomic.
| Requirement | Atomic mechanism | Status | Verify |
|---|---|---|---|
| Durable change identity | Content-addressed patches (Blake3) | Implemented | Change identity |
| Explicit causal dependencies | Patch dependency graph | Implemented | Patch theory |
| Safe composition of independent changes | Commutative patch application | Implemented | Patch theory |
| Queryable semantic relationships | Atomic Vault graph queries | Implemented | Querying the graph |
| First-class intent | Typed intent and acceptance criteria | Implemented | Atomic Vault |
| Provenance and attestation | Signed provenance graph (ed25519) | Implemented | Attestations |
| Change assurance | Triage and intent verification | Implemented | Triage |
| Concurrent multi-agent writes | Causal views and dependency-aware composition | Implemented | Views |
| Selective materialization | RPC-based file and directory projection | Implemented | Commands |
| Offline operation | Local patch recording with eventual sync | Implemented | Getting started |
| Shared persistent agent memory | Atomic Vault memory types | Implemented | Atomic Vault |
| Session and turn recording | Native agent hooks | Implemented | Agent workflows |
| Blast-radius analysis | Semantic call-graph queries | Implemented | Semantic call graph |
| Policy-driven promotion | Triage gates and attestation policy | Implemented | Triage |
| Multi-region replication and SaaS tenancy | — | Proposed | Architecture in development |
| Customer-controlled self-hosted deployments | — | Proposed | Architecture in development |
For the specific commands, protocols, and configuration behind each mechanism, see docs.atomic.dev. For how Git's identity model got here, read the Background.
See the requirements running on your own repository.