How VEX keeps engineers and AI agents working from the same source of truth.
Source control assumed a person was on the other end of every commit. That assumption is breaking. VEX rebuilds source control around one live graph and one continuous loop, so humans and agents can both operate on the same source of truth at machine speed.
Git's model fit a world of sparse human commits and slow, sequential review: a person edits, pushes, waits for a human to look, and the remote quietly stores objects in between. That world is already gone. A modern codebase is touched by agents, CI workers, deployment controllers, and runtime monitors as often as it's touched by people — and none of them fit neatly into a workflow built for one human at a time.
VEX treats the repository as a living system instead of a static archive. Every actor — human or automated — reads the same graph, proposes a change, proves it against real checks, ships it, watches how the system responds, and feeds that outcome back into the next change. The remote isn't passive storage waiting on the next push; it's the control surface every agent, pipeline, and person acts through.
We didn't invent this from nothing. VEX combines ideas that already proved themselves at scale, applied to a problem none of them were built to solve alone:
- JJ / Mercurial lineage: content-addressed storage and explicit, replayable operations instead of Git's mutable index and reflog.
- Sapling working-copy scale: filesystem monitoring and a virtual filesystem so a repository can feel present on disk without every file actually being there yet.
- Google Piper / CitC: the source of truth lives in the cloud; a thin, FUSE-backed local view is what your editor, shell, and agents actually touch.
- Enterprise-scale governance: one platform, strong tenant and team boundaries, instead of policy bolted on as an afterthought.
- Modern agent-native workflows: humans and automation reading and writing the same live state, not waiting in separate queues for each other.
Live in production
4 major systems
Managed infra add-ons, Modal elastic CI, PlanetScale Postgres, and two-way native GitHub sync are shipped and verified live.
In final verification
13+ roadmap plans
CI runner, VPC data plane, secure nodes, remote CI cache, fast clone, CDN, and stacked-diff projection are implemented and passing checks.
Tracked plans
40+ PRDs
Every roadmap item below is synced from the internal delivery index, last updated 2026-07-10.
New source-control primitives
A faster Git remote isn't enough. Machine-speed coordination needs primitives Git never had to expose: isolated workspaces that don't require a human PR for every fork, policy that attaches directly to the graph, and a shared truth that many actors can safely write to at once.
High-throughput workspaces
Many agents need isolated overlays, cheap fork points, leases, and deterministic merge/rebase loops without turning every action into a human PR.
Graph-native governance
Policy must attach to paths, actors, automation levels, deployment targets, and object transitions instead of living in a separate approval tool.
CAS-backed shared truth
Compare-and-swap refs, operation heads, and explicit object presence make machine-speed updates safe to reject, replay, or audit.
Runtime feedback into source
Logs, health checks, incidents, releases, and cache misses become graph events that can trigger the next diagnosis or rebuild.
Live source graph
One Jujutsu-native repository as the unit of truth for code, policy, docs, runtime signals, and automation state.
Runtime close to code
Infrastructure and operations are defined next to the source they govern so deployment feedback can become the next source-control input.
One infinite loop
Humans, CI workers, bots, and copilots read, mutate, test, deploy, observe, repair, and repeat through the same control plane.
Policy as a graph primitive
Folder and file boundaries, workspace leases, audit trails, and automation levels are part of the source-control model.
Why this exists now
Scattered repos and infrastructure that lives outside source control were an annoyance when people were the bottleneck anyway. They become the bottleneck once agents can produce, validate, and deploy changes faster than any dashboard can track. VEX keeps identity, permissions, cache behavior, deploy state, and audit history attached directly to the code they govern — not off in a separate tool that quietly drifts out of sync.
Virtual filesystem plan
VEX should not require every developer, CI runner, or agent to clone and hydrate the entire repository before useful work can start. The long-term plan is a VFS mode: a FUSE-backed virtual filesystem that mounts a VEX/JJ workspace as an ordinary directory while keeping most cold content in the remote graph and shared object cache.
The shape is deliberately close to the systems that proved this works at monorepo scale. Sapling treats file-count scale as a working-copy problem: track changed files, allow sparse checkout, and use a compatible virtual filesystem so files download on first access. Piper and CitC point at the same product truth from the Google side: keep the source of truth remote and cloud-backed, then expose a small local filesystem view that existing editors, build tools, grep, test runners, and agents can use directly.
Full tree illusion
A FUSE-backed mount should make the repository feel present even when only the active working set is local.
Lazy file materialization
Tree metadata arrives first; file contents are fetched, cached, and promoted when editors, agents, shells, or build tools touch them.
Local-first hot paths
Recent paths, object chunks, directory listings, and write overlays stay on local SSD with explicit cache budgets and eviction policy.
Snapshot-backed writes
Edits land in a VEX workspace overlay that can become a JJ change, be shared with an agent, or be discarded without corrupting the base tree.
Strategic targets
In-memory + fs-aware caching
Fast metadata lookups, object indexes, and workspace state using memory-first caches and tight file-system locality.
Native-first agent loop
JJ-native operations, content-addressed storage, and repository-native remote semantics for both humans and automated workers.
Inspired by proven systems
Borrowing strong ideas from Mercurial/JJ lineage, Sapling working-copy scale, Google Piper/CitC, and modern monorepo tooling.
Software as a living system
The codebase can continuously rebuild itself because graph state, runtime state, and policy state feed the same loop.