Oak — the agentic substrate

Oak is solving problems developers have had with Git for decades, along with fitting it to current agentic workflows. Making an agent native substrate allows us to improve these workflows directly rather than trying to build something on top.

You wait minutes to read one file. Git makes you clone the entire history before you can open a single path. On a big repo that's minutes of dead time, with tokens spent watching a progress bar, before you've done any work. oak mounts without a full clone · files stream in on first read

Worktrees fight you back. Running tasks in parallel means one shared, corruptible .git, detached-HEAD foot-guns, and half-applied state bleeding between worktrees. One bad index and every session stalls. oak gives every task its own mount + branch · tear one down, the rest are untouched

The commit-message tax. Git demands prose on every commit. You burn tokens writing "wip", "fix", and "address review", messages no human will ever read, just to checkpoint your own progress. oak checkpoints carry no message · describe the branch once, at the end

Big files break it. A 4GB checkpoint chokes git. LFS is a separate quota, extra config, and another thing to get wrong; it still re-uploads the whole file when one tensor changes. oak chunks + dedupes natively · change one tensor, only that chunk travels

Familiar surface, improved internals. Anyone coming to Oak is going to be familiar with the concepts. Your mental model of commits, branches, and repos still apply. Likewise, your agents already know the flow.

One branch, one description. Iterate freely on a feature branch with any number of intermediate commits and no messages required. Land a single squash on main with the branch description as the message.

$ oak switch -c feat/oauth $ oak desc "Replace REST auth with OAuth + PKCE" $ oak mergesquashed onto main

Mount remote repos as filesystems. oak mount projects a repo into a working tree without a full clone. Files hydrate on first access, so large repos become usable before git clone finishes counting objects. $ oak mount acme/app fetched manifest · 2.4MB · 0 blobs mount ready at ./app (lazy) · files hydrate on read

Built to feel instant. Speed is the feature. A Rust core, content-addressed storage, and lazy hydration keep the CLI snappy: no re-hashing the whole tree, no waiting on a clone, no spinners between you and the code. snapshot 50k files 29.7s → 1.4s −95% mount large repo no full clone up front push only changed chunks travel

Built for large files. Content-defined chunking deduplicates across versions and across the repo. Push a 4GB checkpoint, change one tensor, push again; only the changed chunks move.

You're never locked in. oak export ./dest replays your branch history into a fresh git repo with author, email, and timestamp preserved on every commit. Your data is yours, in standard formats, on demand.

Oak does not train on your code. Oak makes no AI calls on your behalf and trains no models on your code. Whatever agent you bring is its own integration with its own privacy posture. Oak is just the VCS underneath.

Local feature branches.Server main. One squash. 01You're always on a feature branch locally.oak init creates one parented onto main. main only exists on the server, so there's no local main to drift away from. 02Intermediate commits carry no message.The branch description is the source of truth. Checkpoint as often as you like without inventing prose; set one good description before landing.

03Merge is a server-side squash.The single mainline commit's message is the branch description. The pre-squash chain stays reachable for tooling. 04Direct pushes to main are refused.Except the first push of an empty repo, Oak refuses direct pushes to main. No accidental fast-forwards from a misconfigured agent.

graph acme/app, last 14d 4 branches · 23 commits

A mount per task. oak mount projects a repo into a working tree without a full clone. The manifest comes down on mount, file contents stream in on first read, and every task gets its own working tree on its own branch. Mounts live inside an oak space — one working area for a whole org, not a single repo.

$ oak mount acme/app ./fix-auth Spin up three tasks at once, each in its own mount on its own branch. Tear one down and the rest are untouched — no shared .git to corrupt, no detached-HEAD foot-guns. The git equivalent: clone the whole repo first (minutes), then git worktree add once per task, all sharing one .git that's easy to corrupt. $ oak space new acme Those mounts don't float free — a space opens one working area for the whole org, where each task is its own subdirectory. Inside it you oak mount whichever repos the task touches, so a cross-repo change keeps its branches side by side. One subdirectory is one task; spin up the next one and it's near-instant — no clone behind it.

~/acme/app/fix-auth fix-auth--mount src/auth/login.rs4.1Klocal src/auth/session.rs6.8Klazy src/main.rs2.0Klocal api/12 fileslazy Cargo.toml1.2Klocal Cargo.lock186Klazy README.md8.1Klocal

We solve problems that GitHub can't. GitHub does a hundred things Oak doesn't: issues, GitHub-style code review, Actions, an ecosystem a decade deep. But git and GitHub share a model that was never built for agents.

for agent workflows oak github + git branch model ✓ branch-per-session; description-as-message ~ branch + commit messages + PR title large files ✓ native; fastcdc dedupes across versions ~ via LFS, separate quota, extra config first working tree ✓ lazy mount; no full clone ~ full clone up front; minutes on big repos parallel tasks on one repo ✓ a mount per task, each its own branch ~ git worktree; one shared, fragile .git snapshot speed ⚡ up to 95% lower p50; instant re-snapshot ~ re-hashes the tree; seconds on big repos commit ergonomics for agents ✓ intermediate commits are messageless · every commit needs a message data portability ⇄ oak export → fresh git repo ✓ native training on your code ✕ never; Oak makes no AI calls ?