Sorrel

Building in public

Version control built for humans and AI agents.

Sorrel is an open, agent-native version-control project for parallel development, portable workflows, and secrets-aware execution — without abandoning Git.

Get started See what works
Local VCS loop is real: init, changes, lanes, merge, push/pull. Hub API + read-only UI run locally; this site is live on Cloudflare.
sorrel — zsh 
$ sorrel init
$ sorrel change create -m "add landing"
$ sorrel lane create --name feature
$ sorrel merge <lane-id>
$ sorrel remote add origin http://127.0.0.1:3000
$ sorrel push origin

status  clean
lane    lane_main
remote  origin / HEAD
# working tree restored after pull

Why Sorrel exists

Git is essential. It is no longer the whole workflow.

Git remains the right compatibility layer for source history, remotes, and migration. But modern development now includes many parallel AI agents, cloud workspaces, generated code, selective context sharing, secrets, and portable execution.

Sorrel treats those concerns as first-class objects instead of forcing every agent handoff, review, runner, and environment decision through branches and ad hoc scripts.

01

Parallel agents need lanes, not branch noise.

Independent AI work should be isolated, inspectable, resumable, and easy to stack.

02

Context should be sliceable.

Agents often need a focused dependency closure, not the whole repository.

03

Runners should travel with the work.

Local, container, and user-owned remote compute need a common portable job model.

04

Secrets should never become patch text.

Environment access, grants, and redaction belong inside the workflow layer.

Architecture

Open core primitives with a collaboration layer on top.

Sorrel Hub

Proposals, reviews, projects, policies, runs, and team coordination.

Lanes + Slices + Runners + Vault

Agent workspaces, dependency manifests, portable jobs, and secrets refs.

Sorrel Core

Content-addressed objects, blobs, trees, snapshots, changes, and future merge models.

Git compatibility

Import, export, mirror, and migrate without locking teams into Sorrel.

Sorrel Core

Core-native permissions.

Sorrel Core is built around a permission spine for humans, agents, runners, workflows, services, and apps. Scoped grants and policy decisions belong with the protocol for paths, lanes, slices, runners, workflows, environments, and secrets.

Authority is evaluated from prior authority.

Local clones can edit bytes, but peers, runners, Hub, and remotes accept permission changes only when they are signed by an already-authorized authority chain. Agents cannot simply edit their own grant files to gain power.

Hub administers; Core remains the source of truth.

Hub is an administration and collaboration surface over Core policy, not the place where permissions get bolted on later. SecretRef semantics, redaction behavior, policy decisions, and audit records live in Core.

Sorrel Core

The version-control engine.

Core is the protocol, object store, local runtime, CLI foundation, and SDK surface. It models snapshots and changes directly so agent-native concepts can be built without pretending every unit of work is just a Git branch.

Sorrel Hub

The collaboration product.

Hub is the server and UI layer for organizations, projects, proposals, review comments, workflow runs, policy, and agent coordination. It sits above the open core.

System primitives

Built for how agent-assisted software is actually produced.

Lanes

Isolated streams of work for humans or agents, designed for stacks and resumable context.

Slices

Focused manifests that describe the files and dependencies an agent or review needs.

Portable runners

A JobBundle model for local process execution, containers, and future user-owned compute.

Vault

Secrets and environment management with refs, grants, local backends, and redaction.

Git bridge

Compatibility for import, export, mirroring, and migration so teams can adopt gradually.

Building in public

Progress is tracked in the open as each module moves from skeleton to integrated system.

Migration path

No hard fork from the ecosystem.

Sorrel is not trying to make teams abandon Git on day one. The architecture keeps Git as an interoperability layer for source history, hosting, export, and escape hatches.

The goal is a better native model for agent work while preserving a practical path back to repositories, pull requests, and existing developer infrastructure.

Roadmap

Current build sequence.

  1. Done

    Persistent local VCS

    Real object store, snapshots, changes, line-level diff, and history in the CLI — state persists on disk across runs.

  2. Done

    Lanes and three-way merge

    Per-lane heads, lane switch, and an engine-level merge with merge bases, conflict markers, and stored Conflict objects.

  3. Done

    Sync transport + persistent Hub

    Push/pull of content-addressed objects against sorrel-hub, with disk-backed object, ref, and metadata storage.

  4. Now

    Git bridge

    One-way sorrel git import is in; export and colocated mirror come next.

  5. Next

    Hub write flows

    Proposals and reviews consuming Core policy, plus hub-web mutations.

  6. Later

    Embedding surface, agents, SDKs

    Stable Core library API, then agent control plane and language SDKs.

Current status

Working local VCS. Collaboration UI still read-only.

Protocol, engine, CLI, vault, runners, slices, Hub API, and Hub UI foundations are real and tested. Git export/colocated, merge continue, hub write flows, agents, SDKs, and CI are still ahead.

Working

  • Local init / change / diff / log
  • Lanes, merge, push & pull
  • One-way Git import
  • Hub API + FS persistence
  • Read-only Hub UI + this site

Still missing

  • Git export / colocated
  • Merge resolve / continue
  • Hub write UI & production auth
  • Agents, SDKs, CI
Full status doc How to run it Browse the documentation Generated API reference Progress dashboard

Early interest

Follow the build, inspect the architecture, and help shape the workflow.

Star or watch on GitHub Read getting started