Most “Git for agents” pitches are really just “Git, but faster.” Oak is more interesting because it questions the data model, not only the throughput. Git’s atom is a commit with a human-written message — a narration of intent. An agent doesn’t narrate. It runs a session, emits a few hundred micro-edits, and needs the resulting state read back as structured data, not prose history.

That reframing shows up in the concrete choices. Branch-per-session replaces the per-commit message, so a unit of work maps to a problem, not to a keystroke buffer. Content-addressed lazy mounts hydrate only the files an agent actually touches, which is how they get setup-in-seconds instead of a full clone. Every state-bearing command emits JSON, and failures carry a documented exit-code taxonomy — retryable lock contention is code 3, a dirty tree is 4, a merge conflict is 5 — so the harness can branch on the failure mode instead of regexing stderr. The token-economy details look trivial until you multiply them by every tool call in an agent loop: printing a bare 12-char hash instead of commit <hash>, dropping zero-valued fields from status output, collapsing a branch review into one call that returns lineage, conflicts, and a merge preview together.

The hard part of agent VCS isn’t speed or token count — it’s attributing a coherent change to an incoherent process. Does branch-per-session survive the messy reality where one “session” actually spans a planning agent, a coding agent, and three retries? The HN thread has the predictable “why not just use git worktrees” pushback alongside genuinely good notes on merge semantics. And there’s a recursion worth sitting with: Oak says it was written almost entirely by AI under human oversight, which is exactly the workflow it exists to version. If your agents could branch and merge in milliseconds, would you keep using commits the way you do today — or is the commit itself a human abstraction we’re about to outgrow?