Version Control for AI Agents: Atlas

Git tells you a line changed and who ran git commit. It has never told you why, and for the ten years that answer lived in a human head, nobody needed it to. That stopped being true the month a coding agent started writing most of the diff, because the reasoning now lives in a terminal session that scrolls away. Atlas is version control for AI agents built around exactly that gap: it records the session behind each commit and makes the pair queryable months later.

Atlas is a macOS desktop app from a developer who goes by pacifio, MIT licensed, written mostly in Rust, 2,980 stars and 193 forks as of 3 September 2026 against a repository created on 14 May. The current release is tagged alpha-0.3.0, shipped 25 August. Take the alpha seriously; more on what it costs you further down.

What a checkpoint actually holds

A commit records the after state. A checkpoint records how you got there: the prompts you sent, the messages back, the tool calls the agent made, the files each one touched, and the patches it applied, all written to .atlas/sessions.db inside the project and linked to the commit that came out the other end.

The design decision that makes this work is small and easy to miss. Commits are observed, not intercepted. Atlas does not wrap git commit or install a hook you have to remember. It watches, so a commit you make from a terminal, from another editor, or with Atlas closed entirely still finds its session. Every tool that tried to own the commit path in the last decade lost to the fact that developers commit from wherever they happen to be standing.

You also do not have to read a transcript to get the context back. Select a checkpoint and talk to it: it answers from what actually happened in that session rather than from a summary written afterwards.

That inversion is the whole argument for version control for AI agents as a separate layer. Code review assumes the reviewer can reconstruct intent from the diff, which works when a colleague wrote it and can be asked. When an agent wrote it across forty tool calls at two in the morning, the diff is all that survives, and a reviewer approving it is approving a decision nobody can now explain. The record does not make the change correct. It makes the change answerable.

Why the links survive a rebase

This is the part that convinced me the project has thought past the demo.

If a checkpoint were just a commit SHA in a table, the first git rebase -i would shred the whole record. Atlas re-points links through amend and rebase by reconciling patch ids rather than hashes, so the history rewrite that every team does before merging does not cost you the reasoning behind it.

And when a squash makes a link genuinely ambiguous, it orphans the checkpoint instead of guessing. That is the right call and an unusual one. A record that quietly attaches the wrong session to a commit is worse than no record, because you would never audit it; you would just believe it. Choosing a visible gap over a plausible lie is the sort of thing you only do if you have imagined someone relying on the output nine months later.

On top of the raw record sits a dashboard the project calls mission control: agent activity over time, a consumption breakdown, timelines, and a filterable log table. Whether you need that on a solo project is doubtful. On a team where four people each point two agents at the same repository, "which agent has been burning the budget and on what" stops being a curiosity and starts being a question somebody asks in a planning meeting.

There is a transcript import too, which backfills existing Claude Code history so the record starts before you installed anything. Secrets are scrubbed before persistence rather than before upload, which is the correct order given that nothing is uploaded in the first place. And capture reports one health signal per workspace, OK, Degraded or Stopped, each with a reason and a next step, so a silently broken recorder announces itself.

One memory, several agents

Version control for AI agents is only half of what the app does. The other half is making several agents behave like they are working on the same project.

Claude Code and Codex run as external subprocesses over ACP, the agent client protocol from the Zed team. Atlas's own agent runs in-process on Cersei, their Rust framework. Beyond those it can spawn anything in the ACP registry, pulling each one's official binary automatically, though the README is honest that QA on the long tail is still ongoing.

What they share is an on-device semantic index: local embeddings with HNSW search, holding the active plan, decisions, file changes, failures and architecture notes written by any agent. A decision Claude Code reached shows up in Codex's next prompt, which neither can do on its own since neither can read the other's history. The first message of a new session carries a curated fact pack plus the tail of your last one, even when that session ran on a different agent.

There is a catch in that design worth naming, because it is the same catch every local-first agent tool has. The shared index is on-device, so "every agent reads from it" means every agent running on that device. Point a scheduled job or a teammate's session at the same project and they start from nothing. A hosted cloud AI computer like MoClaw is the other half of that answer rather than a competitor to it: the agent work that has to be reachable from more than one machine runs somewhere that is always reachable, and Atlas keeps being the thing that explains what happened on yours.

Your existing files feed it without conversion. CLAUDE.md, AGENTS.md, Claude Code's memory files, Codex's history and any markdown you dropped in .atlas/knowledge/ fold into one index every agent reads from. That is a better answer than asking you to migrate notes into a proprietary format, and it means the setup cost is close to zero.

One detail worth stealing regardless of whether you install this: @-mentioning a folder sends a path the agent reads on demand, not a paste. @ a 5,000-line file and it resolves to a pointer, so one mention does not occupy your context window for the rest of the session.

The embedding runs on your machine, which is the privacy answer and also a load answer. Indexing a large repository, holding a local model in memory, and running two agent subprocesses in parallel is real work for a laptop that is also driving your calls. This is the seam where MoClaw sits next to a tool like Atlas rather than against it: a hosted cloud AI computer takes the agent runs that do not need to be on the machine in front of you, and the fan stays quiet during the standup.

The alpha reality, and the platform problem

Here is what the marketing page will not lead with.

macOS is the supported platform. The README says so in a note, and the releases page backs it up: alpha-0.3.0 ships two files, Atlas_0.3.0_aarch64.dmg and Atlas_0.3.0_x86_64.dmg, and nothing else. Linux and Windows build from the same Tauri codebase and are explicitly untested, which in practice means you are the person who finds out. If your team is mixed, this is not yet a team tool; it is a tool some of your team can use.

It is alpha and the version numbers agree. Three tagged releases since early August, plus experimental prereleases in between, with 15 open issues and 11 open pull requests on the day I looked. There is no Homebrew tap yet, only a .dmg and a #todo comment in the README where the tap should go.

Anonymous usage analytics are on by default. Coarse metadata, never code or prompts, and there is a TELEMETRY.md documenting what is collected and how to switch it off. I would rather it defaulted the other way in a tool whose entire pitch is that your material stays local, but at least it is written down where you can find it before you install.

It does not replace git. Atlas reads and writes an ordinary repository, shows a real commit graph, and stages and commits like anything else. The checkpoint record is the one piece that lives outside git, as SQLite in the gitignored .atlas/, because it gets queried rather than read. Everything else is a file on disk: notes are markdown, canvases are JSON, sessions are JSONL. Close Atlas and pick up in vim.

Who this is for right now

You, if you are on Apple silicon, already run more than one coding agent against the same repository, and have lost the reasoning behind a change at least once in a way that cost you an afternoon. That last condition matters more than the first two. If you run one agent, review its diffs the same day, and merge before you forget, Atlas is solving a problem you do not have yet.

Not you, if you need something stable enough to standardise a team on this quarter, or if half your engineers are on Linux.

For the wider pattern, we have written up running several coding agents in parallel and what self-improving coding agents actually do, both of which describe the mess Atlas is trying to record.

One last practical note about where these sessions live. The checkpoint database is per-project and per-machine, so the record of what your agents did is only as available as the machine that made it, and a laptop that spends its evenings closed in a bag is not a good host for work that wants to keep running. Putting the long-running half on MoClaw means an overnight refactor has somewhere to land and a session that outlives the tab it started in, while Atlas keeps doing the thing it is good at: explaining the commit after the fact.

FAQ

How do you do version control with multiple AI coding agents?

Ordinary git for the code, plus a separate record layer on top; version control for AI agents in practice means keeping the session and the commit together rather than replacing git. Atlas is one implementation: it captures prompts, tool calls and applied patches per session, then links each session to the commits it produced. Several agents can run in parallel against the same repository, each writing into a shared on-device memory index.

Is Atlas free and open source?

Yes, MIT licensed, confirmed on the repository on 3 September 2026. Sign-in is optional and only needed to create an organisation and sync across devices or teammates. Local mode works fully offline with no account.

Does Atlas replace git?

No. It reads and writes a normal git repository and shows a real commit graph with file-level diffs. The only thing it keeps outside git is the checkpoint record, in SQLite under the project's gitignored .atlas/.

Which agents does it work with?

Claude Code and Codex over ACP, its own native agent on the Cersei runtime, and anything else in the ACP registry including Cursor, OpenCode and Kilo Code. The maintainer notes that testing on the wider registry is still in progress, so treat the two named agents as the tested path.

Does it run on Windows or Linux?

Not as a shipped build. The releases page carries macOS .dmg files only. Linux and Windows compile from the same Tauri source, and the README says plainly that those builds are untested.