Stemma: a version control system for the age of agents

Status: version 0.3.0, Phase 3 of 6 complete.

Version control is so old and so taken for granted that we rarely think about it any more. We type git commit, open a pull request, and wait for a review. It works because it was built for a particular rhythm: a handful of changes per day, one branch per task, one person per branch, and a human who checks before anything is merged.

That rhythm is changing. In this article I explain why we at Talent Factory are building our own version control system, what Stemma can do today, and what it expressly cannot do yet. I also describe its limitations, because a project in Phase 3 of 6 has them.

The starting point: agents change the tempo

Agents produce changes in rapid succession, in parallel and in large numbers. They work without breaks, have several branches open at once, and leave traces that can no longer be attributed to a single person in any straightforward way.

Anthropic provides a telling example. In October 2026, the company described in its engineering blog Scion, an internal version control system that replaced Git for its own monorepo. Daily merges there rose from around 2,500 in May to over 30,000 in September 2026. Scion is not publicly available, and the article itself states that it is not a replacement for Git in general use, and that its concepts only make sense for truly enormous monorepos.

We do not need to replicate Scion, then. But the example shows the direction the pressure is heading, and it raises a question that matters for small teams too: Which of Git’s assumptions still hold when a large proportion of changes come from agents?

What is good about Git and will remain so

Before we get to the limitations: Git is in many respects a solid foundation for agents.

• The data model is strong. Content is addressed by hashes, and the history is an immutable graph.
• Agents use Git reliably. The commands and their output appear in public code and in Documentation, and therefore in the training data of the models as well.
• The pull request bundles diff, discussion, checks, and approvals into a single object that humans and agents can read equally well.
• Tools, integrations, and experience are available everywhere.

Stemma therefore adopts the core principle: content-addressed, immutable objects and a history as a graph. Where Stemma diverges, there is a reason.

Where the assumptions break

In analysing our workflows, we found six points at which Git’s assumptions come under pressure from agentic load. These are observations, not measurements.

Some of these follow from the data model — provenance and conflicts in particular. Others follow from the platform — enforcement, for instance. Stemma changes the data model itself. The platform will later be replaced by a dedicated Hub (Phase 5).

Why Stemma?

The short answer: because the questions a version control system must answer are shifting.

The most important question used to be: What has changed? Today, three more have become urgent in the context of agents:

1. Who was permitted to make that change? Before the question of how a conflict is resolved arises, an earlier question must be answered: who is allowed to write here at all?
2. Where does the change come from? A change originates from a commission, a model, a session, and a human who stands behind it. Git records only the author and timestamp.
3. What happened, and can I undo it? When an agent touches dozens of files in a single minute, every state must be restorable — including states that nobody ever committed.

These questions can be answered with conventions and platform rules, and that is exactly what all of us do today. Stemma tries something different: it places the answers in the data model and in the core, so that no client can bypass them by forgetting they exist.

The name fits. Stemma (Greek στέμμα, wreath) is the term in textual criticism for the family tree of manuscripts: the reconstruction of which copy was derived from which, and who wrote it. That question of provenance is precisely what a version control system in the age of agents must answer.

The guiding principles

1. The working copy is a commit

In Git there is the working directory, the index, and the commit. Anything that has not been staged is absent from the commit and does not appear in any history. If an agent stops mid-task, its state is gone.

In Stemma, the working copy is itself a commit — the Working-Copy-Commit. Before every command that modifies it, Stemma takes a snapshot. The index is gone. Which files belong to the working copy is determined by track; commit names the current Working-Copy-Commit and places a new, empty one on top.

The consequence is a guarantee that matters for agents: the state of a working copy is never lost simply because it was never committed.

2. Every operation is recorded in the Operation Log

Every command that changes something writes an entry to the Operation Log: actor, operation, state before, and state after. The log is local and structured as a hash chain. stemma op verify checks the chain; stemma op restore restores an earlier state.

The log records every commit that an operation has made unreachable — in particular the Working-Copy-Commit that a snapshot replaces. Without the log, the promise that “no agent state is ever lost” would be hollow. That is why no snapshot is taken before the log exists.

Because the log is local and not part of the history, there is an escape hatch for serious situations: stemma purge removes an accidentally committed secret from both the history and the log. Only a human may do this, and without --apply the command only shows the plan.

3. Every operation knows its actor

An actor is either a human or an agent. An agent carries the model version, the session, and the human who sponsors it. Every commit and every log entry names the actor.

The command line takes the actor from --actor or STEMMA_ACTOR. There is deliberately no default value such as the operating-system username: an agent must never present itself as a human without saying so. Without an actor, the command aborts and creates nothing.

Every operation that modifies a repository — or merely plans a change — also requests an authorisation (authorize(actor, operation, target)). This is anchored in the type system: anyone who wants to write requires an argument of type Allowed, which only a positive decision can produce. A write path that skips authorisation does not compile. For now, the check still permits everything; the actual policy comes in Phase 4. But the hook is already in place everywhere, and that is the difficult part.

4. One actor per working copy

A snapshot saves everything in the directory and records the actor of the command. Two actors in one directory would attribute each other’s work to the wrong party. Each actor therefore works in its own working copy, and the programme rejects a snapshot belonging to a different actor. stemma worktree add gives a second actor its own.

That is precisely how we develop Stemma itself — more on that below.

5. Conflicts are data, not aborts

In Git, a conflict halts the process and demands an immediate decision. In Stemma, a conflict is an object in the history (a commit with multiple trees, commit2) that can be resolved later. Merge and rebase run to completion; status, log, and diff show the open conflict; and a subsequent merge reads it as an operand rather than failing. The rules governing this form a small algebra over sums of trees, in which terms can cancel one another out.

This suits agents: an agent need not force a conflict decision in the middle of a task when a human would be better placed to make it later.

6. A branch belongs to one actor (planned)

The central idea for collaboration is write ownership: a branch belongs to exactly one actor, who alone may advance it, and the server enforces this. Silent overwrites are thereby ruled out.

This is the part that does not exist yet. ADR-004 describes it as a proposal, with a time-limited lease that an agent extends via heartbeats, and an owner-override for humans requiring a justification and an audit entry.

The figure shows the flow and the open question: if actor A crashes, the branch remains locked until the lease expires. How long the lease lasts has not yet been decided. I show it here because it explains the direction, not because it is finished.

Safe even after crashes

Agents stop mid-flight: a process is killed, the connection drops, the machine restarts. A version control system must therefore know, for every step, what holds after a crash.

In Stemma, every write command follows a fixed sequence, and the book describes for each step what a crash at that point leaves behind. The example op restore illustrates this:

After every crash, the lock refs.lock remains in place, and the next write command takes it over (on the same machine). An entry snapshot records any unsaved changes. If the entry is present but no pointer has yet moved, nothing has happened. If the files have already been written, the same invocation completes the restore before any other command can proceed.

This is less spectacular than a new data model, but probably more important for operating alongside agents. Errors that only surface after a crash are otherwise found in production.

What works today

Version 0.3.0 covers the first three phases:

• Phase 1, local core: objects, references, Working-Copy-Commit, Operation Log, restore, purge.
• Phase 2, diff and output: readable diffs between commits and the Working-Copy-Commit, including a terminal interface (stemma diff --tui).
• Phase 3, branches and merge: branch, switch, tag, merge, rebase, worktree, conflicts as objects, Windows support.

The commands: init, track, commit, status, diff, log, tag, branch, switch, merge, rebase, worktree, op log, op restore, op verify, and purge. The test suite comprises nearly 2,000 tests, and error paths are checked with injected filesystem errors — not just the happy path.

What does not work yet

To avoid any false impressions:

• Stemma is not a replacement for Git. It is expressly not compatible with Git repositories (API-first, with a Git-style command line). For our own repository, Git remains the single source of truth; Stemma runs alongside it as the book’s working example.
• There is no enforcement. Authorisation is wired in everywhere but still permits everything. Write ownership, pull requests, and approvals within the system follow in Phase 4.
• There is no networking. Synchronisation between clones and a Hub with permissions come in Phase 5; API and MCP servers for agents in Phase 6.
• An actor proves nothing. The value supplied via --actor is checked for validity only, not to verify who is actually running the command.

Anyone looking for a production system today should continue using Git. Stemma is a design being built and documented in small steps; at this stage it is intended for study, experimentation, and feedback.

How Stemma is built

Stemma is also an experiment in developing with agents, and in experiencing first-hand the problems the system is meant to solve.

• Decisions are recorded in ADRs. Nineteen architecture decision records document what has been decided, what has merely been proposed, and what remains open. The text states in each case what has been confirmed and what has not.
• The book is written in parallel with the code. A change that affects behaviour, format, or a decision updates the corresponding chapter in the same pull request. At the end of each phase, the book is reviewed against the code, and the state of the last check (code, ADRs, book, figures) is recorded as release 0.3.0.
• Agents work in parallel; humans review and merge. Each ticket gets its own worktree, its own terminal, and its own Claude session. The session implements the work, runs CI, opens the pull request, and addresses the review. Merging is never done by an agent — only by a human.

This is precisely the mode of operation for which Stemma is being built: multiple actors, each in their own working copy, with a human who stands behind the result. In doing this we continually encounter the points where Git and the tools around it reach their limits.

A book, a teaching resource

Stemma is more than a programme. The book (ConTeXt, currently in German; an English edition will follow) has four purposes: it explains how Stemma works; it serves as the reference manual for humans and agents; it functions as a textbook for courses on data structures and algorithms and on AI-assisted software development; and it is aimed at computer scientists at master’s level.

The phase chapters therefore explain every data structure and every algorithm at the point where it is introduced: the hash graph, the computation of best common ancestors for the merge, the cost of a rebase. And every function for agents names the problem it solves.

Licence

The core, the command line, and the book are available under either the MIT Licence or the Apache Licence 2.0. The Hub from Phase 5 may additionally be offered by Talent Factory GmbH as a paid service.

Conclusion: does Stemma matter in the age of agents?

I want to answer carefully. As a product, Stemma does not yet. But the questions it asks do:

• Who is permitted to write here, and who enforces that?
• Where does a change come from: commission, model, session, responsible human?
• How does a system handle crashes when crashes are part of normal operation?
• How long may a conflict remain as data before someone resolves it?

Git and its platforms will answer these questions with conventions, rules, and extensions, and that will be sufficient for many teams. Stemma takes the other path: it places the answers in the core, to see how far that gets you and what you learn about the subject along the way.

What comes next

Next is Phase 4, Actors and Collaboration: write ownership, pull requests, and approvals will be enforced by the system, not merely recommended. After that come the Hub with networking and permissions (Phase 5) and the interfaces for agents (Phase 6).

The code, architecture decisions, and book are all in the repository. Feedback, questions, and objections are welcome — especially on the points where our thinking differs from Git’s.