Stemma: ein Versionskontrollsystem für das Zeitalter der Agenten

Stand: Version 0.3.0, Phase 3 von 6 abgeschlossen.

Versionskontrolle ist so alt und so selbstverständlich, dass wir kaum noch darüber nachdenken. Wir tippen git commit, öffnen einen Pull Request und warten auf ein Review. Das funktioniert, weil es für einen bestimmten Rhythmus gebaut wurde: wenige Änderungen pro Tag, ein Branch pro Aufgabe, eine Person pro Branch und ein Mensch, der prüft, bevor etwas zusammengeführt wird.

Dieser Rhythmus ändert sich gerade. In diesem Artikel erkläre ich, warum wir bei der Talent Factory ein eigenes Versionskontrollsystem bauen, was Stemma heute kann, und was ausdrücklich noch nicht. Ich beschreibe dabei auch die Grenzen, denn ein Projekt in Phase 3 von 6 hat sie.

Die Ausgangslage: Agenten ändern den Takt

Agenten erzeugen Änderungen in kurzer Folge, parallel und in grosser Zahl. Sie arbeiten ohne Pausen, haben mehrere Branches gleichzeitig offen und hinterlassen Spuren, die sich nicht mehr einfach einer Person zuordnen lassen.

Ein Beispiel liefert Anthropic. Im Oktober 2026 beschrieb das Unternehmen in seinem Engineering-Blog Scion, ein internes Versionskontrollsystem, das für den eigenen Monorepo Git ersetzt hat. Die täglichen Merges stiegen dort von rund 2500 im Mai auf über 30000 im September 2026. Scion ist nicht öffentlich verfügbar, und der Artikel sagt selbst, es sei kein Ersatz für Git im allgemeinen Gebrauch und seine Konzepte ergäben nur für wirklich riesige Monorepos Sinn.

Wir brauchen Scion also nicht nachzubauen. Aber das Beispiel zeigt, in welche Richtung der Druck geht, und es stellt eine Frage, die auch für kleine Teams gilt: Welche Annahmen von Git tragen noch, wenn ein Grossteil der Änderungen von Agenten kommt?

Was an Git gut ist und bleibt

Bevor es um Grenzen geht: Git ist für Agenten in vieler Hinsicht eine gute Grundlage.

• Das Datenmodell ist stark. Inhalte sind über Hashes adressiert, der Verlauf ist ein unveränderlicher Graph.
• Agenten bedienen Git zuverlässig. Die Befehle und ihre Ausgaben kommen in öffentlichem Code und in Dokumentation vor und damit auch in den Trainingsdaten der Modelle.
• Der Pull Request bündelt Diff, Diskussion, Prüfungen und Freigaben in einem Objekt, das Menschen und Agenten gleichermassen lesen können.
• Werkzeuge, Integrationen und Erfahrung sind überall vorhanden.

Stemma übernimmt deshalb das Grundprinzip: inhaltsadressierte, unveränderliche Objekte und ein Verlauf als Graph. Wo Stemma abweicht, hat das einen Grund.

Wo die Annahmen brechen

In der Analyse der Arbeitsabläufe haben wir sechs Stellen gefunden, an denen die Annahmen von Git unter agentischer Last unter Druck geraten. Das sind Beobachtungen, keine Messungen.

Teils sind das Folgen des Datenmodells, etwa bei der Herkunft und bei den Konflikten. Teils sind es Folgen der Plattform, etwa bei der Durchsetzung. Das Datenmodell ändert Stemma selbst. Die Plattform ersetzt später ein eigener Hub (Phase 5).

Warum Stemma?

Die kurze Antwort: weil sich die Fragen, die ein Versionskontrollsystem beantworten muss, verschieben.

Früher lautete die wichtigste Frage: Was hat sich geändert? Heute kommen drei hinzu, die für Agenten dringlich sind:

1. Wer durfte das ändern? Bevor sich die Frage stellt, wie ein Konflikt gelöst wird, steht eine frühere: Wer darf an dieser Stelle überhaupt schreiben?
2. Woher kommt die Änderung? Eine Änderung entsteht aus einem Auftrag, einem Modell, einer Session und einem Menschen, der dafür einsteht. Git speichert davon nur Autor und Zeitstempel.
3. Was ist passiert, und kann ich es zurücknehmen? Wenn ein Agent in einer Minute Dutzende Dateien anfasst, muss jeder Zustand wiederherstellbar sein, auch der, den niemand committet hat.

Diese Fragen lassen sich mit Konventionen und Plattformregeln beantworten, und genau das tun wir heute alle. Stemma versucht etwas anderes: Es legt die Antworten ins Datenmodell und in den Kern, sodass kein Client sie umgehen kann, weil er sie vergessen hat.

Der Name passt dazu. Stemma (griechisch στέμμα, Kranz) heisst in der Textkritik der Stammbaum der Handschriften: die Rekonstruktion, welche Abschrift aus welcher entstand und wer sie geschrieben hat. Genau diese Herkunftsfrage soll ein Versionskontrollsystem im Zeitalter der Agenten beantworten.

Die Leitideen

1. Die Arbeitskopie ist ein Commit

In Git gibt es das Arbeitsverzeichnis, den Index und den Commit. Was nicht vorgemerkt ist, fehlt im Commit und steht in keinem Verlauf. Wenn ein Agent mitten in der Arbeit abbricht, ist sein Stand weg.

In Stemma ist die Arbeitskopie selbst ein Commit, der Working-Copy-Commit. Vor jedem Befehl, der sie ändert, nimmt Stemma einen Snapshot. Der Index entfällt. Welche Dateien dazugehören, bestimmt track; commit benennt den aktuellen Working-Copy-Commit und legt darüber einen neuen, leeren an.

Die Folge ist eine Zusicherung, die für Agenten wichtig ist: Der Stand einer Arbeitskopie geht nicht verloren, nur weil er nie committet wurde.

2. Jede Operation steht im Operation Log

Jeder Befehl, der etwas ändert, schreibt einen Eintrag ins Operation Log: Akteur, Operation, Zustand vorher und nachher. Das Log ist lokal und als Hash-Kette aufgebaut. stemma op verify prüft die Kette, stemma op restore stellt einen früheren Zustand wieder her.

Das Log hält jeden Commit fest, den eine Operation unerreichbar gemacht hat, vor allem den Working-Copy-Commit, den ein Snapshot ersetzt. Ohne das Log wäre das Versprechen «kein Zustand eines Agenten geht verloren» leer, deshalb gibt es keinen Snapshot, bevor das Log existiert.

Weil das Log lokal ist und nicht Teil des Verlaufs, bleibt eine Hintertür für den ernsten Fall: stemma purge entfernt ein versehentlich committetes Geheimnis aus Verlauf und Log. Das darf nur ein Mensch, und ohne --apply zeigt der Befehl nur den Plan.

3. Jede Operation kennt ihren Akteur

Ein Akteur ist ein Mensch oder ein Agent. Ein Agent trägt Modellversion, Session und den Menschen, der für ihn einsteht (den Sponsor). Jeder Commit und jeder Eintrag im Log nennt den Akteur.

Die Kommandozeile nimmt den Akteur aus --actor oder STEMMA_ACTOR. Es gibt bewusst keinen Standardwert wie den Namen des Betriebssystembenutzers: Ein Agent darf nie als Mensch auftreten, ohne es zu sagen. Ohne Akteur bricht der Befehl ab und legt nichts an.

Jede Operation, die ein Repository ändert oder eine Änderung nur plant, fragt ausserdem eine Autorisierung (authorize(actor, operation, target)). Das ist im Typsystem verankert: Wer schreiben will, braucht als Argument einen Wert vom Typ Allowed, den nur eine positive Entscheidung erzeugen kann. Ein Schreibpfad, der die Autorisierung auslässt, kompiliert nicht. Heute erlaubt die Prüfung noch alles, die eigentliche Policy kommt in Phase 4. Der Haken ist aber schon überall eingebaut, und das ist der schwierige Teil.

4. Ein Akteur pro Arbeitskopie

Ein Snapshot speichert alles, was im Verzeichnis liegt, und trägt den Akteur des Befehls ein. Zwei Akteure in einem Verzeichnis würden sich gegenseitig zuschreiben, was der andere getan hat. Deshalb arbeitet jeder Akteur in einer eigenen Arbeitskopie, und das Programm lehnt den Snapshot eines anderen Akteurs ab. Mit stemma worktree add bekommt ein zweiter Akteur seine eigene.

Genau so entwickeln wir Stemma selbst, dazu unten mehr.

5. Konflikte sind Daten, keine Abbrüche

In Git stoppt ein Konflikt den Vorgang, und die Entscheidung muss sofort fallen. In Stemma ist ein Konflikt ein Objekt im Verlauf (ein Commit mit mehreren Bäumen, commit2), der später aufgelöst werden kann. Merge und Rebase laufen durch, status, log und diff zeigen den offenen Konflikt, und ein weiterer Merge liest ihn als Operand, statt zu scheitern. Die Rechenregeln dafür sind eine kleine Algebra über Summen von Bäumen, in der sich Terme gegenseitig aufheben können.

Das passt zu Agenten: Ein Agent muss nicht mitten im Auftrag eine Konfliktentscheidung erzwingen, die ein Mensch besser später trifft.

6. Ein Branch gehört einem Akteur (geplant)

Die zentrale Idee für die Zusammenarbeit lautet Schreibhoheit: Ein Branch gehört genau einem Akteur, der ihn als Einziger bewegen darf, und der Server erzwingt das. Stille Überschreibungen sind damit ausgeschlossen.

Das ist der Teil, den es noch nicht gibt. ADR-004 beschreibt ihn als Vorschlag, mit einer zeitlich begrenzten Lease, die ein Agent durch Heartbeats verlängert, und einem Owner-Override für Menschen mit Begründung und Audit-Eintrag.

Die Abbildung zeigt den Ablauf und die offene Stelle: Stürzt Akteur A ab, bleibt der Branch bis zum Ablauf der Lease gesperrt. Wie lang die Lease dauert, ist noch nicht entschieden. Ich zeige sie hier, weil sie die Richtung erklärt, nicht weil sie fertig wäre.

Sicher auch bei Abstürzen

Agenten brechen ab: Ein Prozess wird beendet, die Verbindung reisst, der Rechner startet neu. Ein Versionskontrollsystem muss deshalb für jeden Schritt wissen, was nach einem Absturz gilt.

In Stemma hat jeder schreibende Befehl eine feste Reihenfolge, und das Buch beschreibt für jeden Schritt, was ein Absturz an dieser Stelle hinterlässt. Das Beispiel op restore zeigt es:

Nach jedem Absturz bleibt die Sperre refs.lock liegen, und der nächste schreibende Befehl übernimmt sie (auf demselben Rechner). Ungesicherte Änderungen hält ein Eintrag snapshot fest. Steht der Eintrag, aber noch kein Zeiger hat sich bewegt, ist nichts geschehen. Sind erst die Dateien geschrieben, beendet derselbe Aufruf das Restore vor jedem anderen Befehl.

Das ist weniger spektakulär als ein neues Datenmodell, aber für den Betrieb mit Agenten vermutlich wichtiger. Fehler, die nur nach einem Absturz sichtbar werden, findet man sonst im Betrieb.

Was heute funktioniert

Version 0.3.0 deckt die ersten drei Phasen ab:

• Phase 1, lokaler Kern: Objekte, Referenzen, Working-Copy-Commit, Operation Log, Wiederherstellen, purge.
• Phase 2, Diff und Ausgabe: lesbare Diffs zwischen Commits und Working-Copy-Commit, auch als Oberfläche im Terminal (stemma diff --tui).
• Phase 3, Branches und Merge: branch, switch, tag, merge, rebase, worktree, Konflikte als Objekte, Windows-Unterstützung.

Die Befehle: init, track, commit, status, diff, log, tag, branch, switch, merge, rebase, worktree, op log, op restore, op verify und purge. Die Testsuite umfasst knapp 2000 Tests, und die Fehlerpfade werden mit eingespritzten Dateisystemfehlern geprüft, nicht nur der Normalfall.

Was noch nicht funktioniert

Damit kein falscher Eindruck entsteht:

• Stemma ist kein Ersatz für Git. Es ist ausdrücklich nicht mit Git-Repositories kompatibel (API-first, mit Git-artiger Kommandozeile). Für unser eigenes Repository bleibt Git die einzige Quelle der Wahrheit; Stemma läuft daneben als Beispiel des Buchs.
• Es gibt keine Durchsetzung. Die Autorisierung ist überall eingebaut, erlaubt aber noch alles. Schreibhoheit, Pull Requests und Freigaben im System folgen in Phase 4.
• Es gibt kein Netzwerk. Synchronisation zwischen Klonen und ein Hub mit Berechtigungen kommen in Phase 5, API- und MCP-Server für Agenten in Phase 6.
• Ein Akteur beweist nichts. Die Angabe in --actor wird nur auf Gültigkeit geprüft, nicht darauf, wer den Befehl wirklich ausführt.

Wer heute ein Produktivsystem sucht, nimmt weiterhin Git. Stemma ist ein Entwurf, der in kleinen Schritten gebaut und dokumentiert wird, und er ist heute für Studium, Experiment und Rückmeldung gedacht.

Wie Stemma entsteht

Stemma ist auch ein Versuch, mit Agenten zu entwickeln und dabei das nachzuvollziehen, was das System lösen soll.

• Entscheidungen stehen in ADRs. Neunzehn Architekturentscheidungen halten fest, was entschieden ist, was nur vorgeschlagen und was offen. Der Text sagt jeweils dazu, was bestätigt wurde und was nicht.
• Das Buch entsteht parallel zum Code. Eine Änderung, die Verhalten, Format oder Entscheidung berührt, ändert im selben Pull Request das Kapitel. Am Ende jeder Phase läuft ein Review des Buchs gegen den Code, und der Stand der letzten Prüfung (Code, ADRs, Buch, Abbildungen) ist als Release 0.3.0 festgehalten.
• Agenten arbeiten parallel, Menschen prüfen und mergen. Jedes Ticket bekommt einen eigenen Worktree, ein eigenes Terminal und eine eigene Claude-Session. Die Session setzt um, lässt CI laufen, öffnet den Pull Request und arbeitet ein Review ab. Gemergt wird nie von einem Agenten, sondern von einem Menschen.

Das ist genau der Betrieb, für den Stemma gebaut wird: mehrere Akteure, jeder in seiner Arbeitskopie, mit einem Menschen, der für das Ergebnis einsteht. Wir erleben dabei laufend, wo Git und die Werkzeuge darum herum an ihre Grenzen kommen.

Ein Buch, ein Lehrmittel

Stemma ist mehr als ein Programm. Das Buch (ConTeXt, derzeit auf Deutsch, eine englische Fassung folgt) hat vier Aufgaben: Es zeigt, wie Stemma funktioniert, es ist das Referenzhandbuch für Menschen und Agenten, es dient als Lehrbuch für Kurse zu Datenstrukturen und Algorithmen sowie zu KI-gestützter Softwareentwicklung, und es richtet sich an Informatikerinnen und Informatiker auf Masterstufe.

Deshalb erklärt das Phasenkapitel jede Datenstruktur und jeden Algorithmus an der Stelle, an der sie eingeführt werden: den Hash-Graphen, die Berechnung der besten gemeinsamen Vorfahren für den Merge, die Kosten eines Rebase. Und jede Funktion für Agenten nennt das Problem, das sie löst.

Lizenz

Kern, Kommandozeile und Buch stehen wahlweise unter der MIT-Lizenz oder der Apache-Lizenz 2.0. Den Hub aus Phase 5 kann die Talent Factory GmbH zusätzlich als kostenpflichtigen Dienst anbieten.

Fazit: Ist Stemma im Zeitalter der Agenten wichtig?

Ich will vorsichtig antworten. Stemma als Produkt ist es heute noch nicht. Aber die Fragen, die es stellt, sind es:

• Wer darf an dieser Stelle schreiben, und wer setzt das durch?
• Woher stammt eine Änderung: Auftrag, Modell, Session, verantwortlicher Mensch?
• Wie geht ein System mit Abstürzen um, wenn Abstürze zum Normalbetrieb gehören?
• Wie lange darf ein Konflikt Daten sein, bevor jemand ihn entscheidet?

Git und seine Plattformen werden diese Fragen mit Konventionen, Regeln und Erweiterungen beantworten, und das wird für viele Teams genügen. Stemma wählt den anderen Weg: Es legt die Antworten in den Kern, um zu sehen, wie weit man damit kommt und was man dabei über das Fach lernt.

Wie es weitergeht

Als Nächstes folgt Phase 4, Akteure und Zusammenarbeit: Schreibhoheit, Pull Requests und Freigaben werden im System erzwungen, nicht nur empfohlen. Danach kommen der Hub mit Netzwerk und Berechtigungen (Phase 5) und die Schnittstellen für Agenten (Phase 6).

Code, Architekturentscheidungen und Buch liegen im Repository. Rückmeldungen, Fragen und Einwände sind willkommen, besonders zu den Stellen, an denen wir etwas anders sehen als Git.