A mathematically sound distributed version control system — built for the age of AI.

Git was designed for humans writing code in text editors. It tracks lines in files. That worked for 20 years.

Now AI agents write most of the code. They work in sessions and turns, use multiple models, cost money per token, and produce changes that need to be audited, attributed, and explained. Git doesn't know about any of this — you're bolting on external tools to answer basic questions like "which model wrote this?" or "how much did this session cost?"

Atomic is version control that understands AI-assisted development from the ground up.

Enable agent hooks once. Every turn is recorded automatically.

# Enable for your agent (auto-detects Claude Code, Gemini CLI, OpenCode)
atomic agent enable

# That's it. Every agent turn now produces an Atomic change with:
#   - Model and provider identity
#   - Session and turn number
#   - Token usage and cost
#   - Cryptographic signature
#   - Provenance graph (why the agent made each decision)

Every agent session builds a causal decision DAG. Not just what changed, but why:

Goal: "Fix the authentication bug"
  ├── Exploration: read src/auth.rs
  ├── Exploration: grep "verify_token"
  ├── Commitment: edit src/auth.rs (fix token validation)
  ├── Verification: bash "cargo test"
  └── PatchProposal: Change XMJZ3IPF (2 files)

These graphs are content-addressed, stored alongside changes, and pushed to remotes. Your team can review not just the code, but the agent's reasoning.

When a session ends, Atomic creates an attestation — a graph-level audit node covering the session:

$ atomic agent attest

  XMJZ3IPF OpenCode · claude-sonnet-4-5 · 12.4k tokens · 3m 42s · 2 changes
  R3KQP7YN Claude Code · claude-sonnet-4-5 · 8.1k tokens · 1m 15s · 1 change

──────────────────────────────────────────
Total: $0.12 · 3 changes covered · 20.5k tokens

Agents work on isolated stacks — lightweight views of the same underlying graph. No branch divergence, no merge commits, no orphaned history.

# Agent session creates an isolated stack automatically
# Stack: agent-ses_3781fc7a6ffet5c6r1ILy1BEbv (Local, parent: dev)

# When done, apply changes to the parent stack
atomic apply @~1 --to dev

# Delete the agent stack — cascade-deletes its edges, zero orphans
atomic stack delete agent-ses_3781fc7a6ffet5c6r1ILy1BEbv

Atomic's CRDT semantic layer (Trunk → Branch → Leaf) tracks changes at the token level. Two agents editing different words on the same line produce independent patches that merge cleanly — Git would flag this as a conflict.

# Initialize a new repository
atomic init

# Add files and record a change
atomic add src/
atomic record -m "Initial commit"

# Enable AI agent hooks
atomic agent enable

# Create a stack
atomic stack new feature-x

# Push to a remote
atomic push origin

Changes are composable, commutative operations on a directed graph:

• Merging A then B gives the same result as merging B then A (when no conflicts)
• Every change has a well-defined inverse
• Conflicts are represented as data, not failures

Files are directed acyclic graphs (DAGs) where vertices hold content chunks, edges define ordering, and changes are transformations that add or remove vertices and edges. This is not a commit graph — it's the actual file structure.

Every change stores two parallel representations:

• Graph layer — Content-addressed nodes and edges for mathematically sound merging
• Semantic layer — Files (Trunk), Lines (Branch), Tokens (Leaf) for human-readable diffs and token-level blame

Full documentation at docs.atomic.dev.

• Getting Started — Installation and first repository
• Concepts — How Atomic works under the hood
• Agent Integration — Setting up AI agent hooks
• Command Reference — Complete CLI reference
• AGENTS.md — Development guide for contributors and AI agents

# Build all crates
cargo build --release

# Run tests
cargo test

# Install CLI
cargo install --path atomic-cli

# Verify installation
atomic --version

atomic/
├── atomic-cli/               # CLI application
├── atomic-core/              # Core VCS engine (types, pristine, change, diff, CRDT)
├── atomic-agent/             # AI agent integration (hooks, turns, provenance)
├── atomic-config/            # Configuration management
├── atomic-identity/          # User identity & Ed25519 signing
└── atomic-repository/        # High-level repository operations

1. Mathematical Soundness — Operations are well-defined transformations with provable properties
2. AI-Native — Provenance, attestation, and agent identity are core concepts, not afterthoughts
3. Correctness Over Speed — Validate invariants aggressively, prefer clarity over micro-optimizations
4. Efficiency — O(n) file operations via inode indexing, not O(N) repository-wide scans
5. Cryptographic Identity — Every change is attributable via Ed25519 signatures

Because version control should have no doubt about what changed, when, why, and who — human or machine. Every change is a well-defined, composable transformation. Atomic in the mathematical sense.

Copyright 2025-2026 Atomic Software, Co.

Licensed under the Apache License, Version 2.0. See LICENSE for the full license text.

• Website: atomic.dev
• Documentation: docs.atomic.dev
• GitHub: github.com/atomicdotdev/atomic

Atomic builds on decades of research in patch theory, drawing inspiration from academic work on categorical semantics of version control and practical implementations that explored these ideas.