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.

Follow development Read the docs
The engine, persistent CLI, lanes with three-way merge, workflows, vault, and Hub sync are working today.
sorrel — zsh 
$ sorrel lane create agent/ui-copy
$ sorrel slice inspect app/landing
$ sorrel run local test-web
$ sorrel propose --with-secrets redacted

lane agent/ui-copy
  changes:      7
  touched:      web/, docs/
  runner:       local-process
  secrets:      refs only
  export:       git-compatible
# proposal ready for review

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. Next

    Hub proposals and reviews

    Collaboration flows referencing lanes and stacks, consuming Core policy; write flows in the Hub web interface.

  5. Next

    Git bridge

    Import, export, and colocated mirroring so teams can adopt Sorrel without leaving Git.

  6. Later

    Embedding surface, SDKs, and apps

    A stable library/IPC contract, TypeScript and Rust SDKs, then desktop and mobile clients on the same core.

Current status

Sorrel is early, real, and moving quickly.

The engine, the persistent CLI (including lanes and a real three-way merge), the policy spine with cross-repo conformance tests, workflows, vault, and Hub sync with disk-backed storage all work today. The docs pages go deeper into each layer, and the API reference is generated from the code itself.

Browse the documentation Generated API reference Progress dashboard Architecture report

Early interest

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

Star or watch on GitHub Open an issue or idea