Sorrel

Building in public

Version control for human and AI-agent teams.

Sorrel is an open, agent-native version-control project for parallel development, portable workflows, secrets-aware execution, and collaboration that still respects Git.

Follow development Read the architecture report
Protocol, core storage, CLI, vault, runners, slices, and Hub skeleton are underway. 
$ 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 paths: web/, docs/
  runner: local-process
  secrets: refs only
  export: git-compatible

Why Sorrel exists

Git is essential. It is not the whole workflow anymore.

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 being designed 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 should 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 planned as 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 are being built into 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 development 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. Now

    Public product page

    Make Sorrel visible and explain the project while the implementation matures.

  2. Next

    Core lanes and stacks

    Layer Lane and Stack objects on top of changes and snapshots.

  3. Next

    Workflow parser

    Parse simple sorrel.workflow.yml files and execute jobs through local runners.

  4. Next

    Vault CLI/dev integration

    Import env files, list refs, grant access, and redact runner logs.

  5. Later

    Hub proposal and review expansion

    Grow the collaboration layer after the Hub skeleton is confirmed on main.

Current status

Sorrel is early, real, and moving quickly.

The project already has module-level foundations for protocol schemas, core storage, CLI shape, vault specs, runners, slices, and the Hub skeleton. The next phase is about turning those foundations into a coherent agent-native workflow.

View roadmap/progress dashboard Read 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