Ein Schwarm von KI-Agenten arbeitet gleichzeitig an einem gemeinsamen Wissensspeicher. Jeder Agent sucht, liest und schreibt Seiten, während andere dieselben Seiten bearbeiten. Das ist ein Nebenläufigkeitsproblem aus Datenbanksystemen – mit einem Unterschied: Die Arbeit der Agenten kostet Minuten an Rechenzeit und Dollar an Tokens.
Wer mit Coding-Agenten gearbeitet hat, kennt das Muster: Ein einzelner Agent wird von einem Menschen entlang eines Ziels geführt. Will man mehrere Aufgaben parallel bearbeiten, isoliert man die Agenten oft über Git-Worktrees. Die Konflikte holen einen beim Merge ein. Alle editieren denselben Zustand, nur mit aufgeschobenem Krach. Bei Code funktioniert das halbwegs, weil Code zeilenbasiert ist und Merge-Konflikte oft lokal bleiben. Bei natürlichsprachlichem Wissen, wie es in Wikis oder Wissensdatenbanken liegt, gilt das nicht. Prosa wird zusammengefasst, umgeschrieben, neu organisiert und verworfen. Ein früher Prototyp von Chromas Speicherschicht Foundation hat das versucht: Git für Konfliktlösung. Er hat mehr fertige Arbeit verworfen als jeder andere Ansatz – mehr dazu weiter unten.
Warum klassische Datenbanktransaktionen für Agenten versagen
Foundation ist die neue Speicherschicht von Chroma. Sie nimmt Traces von Coding-Agenten und Unternehmensdaten auf und baut daraus ein dauerhaftes, durchsuchbares Gedächtnis. Auf hoher Ebene arbeitet Foundation als ein Schwarm von Agenten, die gemeinsam ein Wiki aufbauen. Auch das ist Nebenläufigkeitskontrolle – nur für Agenten statt für Code. Die Lehrbuchmethoden der Datenbankwelt stoßen hier an Grenzen.
Die Gründe sind zwei Beobachtungen. Erstens dauert eine einzelne Verarbeitungsrunde mehrere Minuten. Zweitens bestimmt nicht ein Index den Lesebereich, sondern Suchen und Schlussfolgerungen des Agenten. Optimistische Nebenläufigkeitskontrolle (OCC) validiert erst beim Commit. Bei einer Transaktion, die Minuten läuft, erzeugen Konflikte einen Sturm aus Wiederholungen. Jede Wiederholung kostet den Agenten seine Suche und Argumentation neu. Eine Datenbanktransaktion ist im Millisekundenbereich neu gestartet, weil sie denselben Code nochmal ausführt. Ein Agent muss nach einem Abbruch seine Entdeckungsarbeit erneut leisten.
Die Zahlen: Datenbanktransaktionen haben billige Arbeit, kurze Retry-Dauer und deterministischen Code. Agenten haben teure Arbeit, minutenlange Runden und sind nichtdeterministisch. Ein Abort verwirft nicht nur ein paar Zeilen, sondern wertvolle Denkarbeit. Dieses Problem musste Chroma mit Foundation lösen.
Fission: Fortschritt ohne Rollback
Die Lösung von Chroma heißt Fission. Auf den ersten Blick ähnelt das Protokoll dem klassischen Zwei-Phasen-Sperrverfahren mit Wound-Wait zur Deadlock-Vermeidung. Jeder Agent sperrt eine Seite exklusiv, bevor er sie liest. Die Sperren werden inkrementell beim ersten Seitenzugriff erworben, nicht über Suchergebnisse. Konfliktregel: Jüngere Transaktionen warten auf ältere, ältere verletzen jüngere. Eine verletzte Transaktion gibt ihre Sperren sofort frei und versucht es mit ihrem ursprünglichen Zeitstempel erneut. Deadlocks sind damit strukturell ausgeschlossen.
Der Unterschied zu klassischen Protokollen: Fission bricht die Atomarität explizit auf. Transaktionen rollen nie zurück. Stattdessen wird ein Abbruch wie ein vorzeitiger Commit behandelt. Alles, was die Transaktion bis zum Abbruch geschrieben hat, bleibt im Wiki stehen. Das erinnert an Eventual Consistency und CAP, ist aber etwas anderes. Fission garantiert weiterhin Isolierung beim Denken: Ein Agent kann eine Seite lesen, darüber nachdenken und einen Patch anwenden, ohne währenddessen Konflikte zu sehen. Pro Seite bleibt die Schreiboperation atomar, abgesichert durch die OCC-Transaktionen von Chroma Cloud. Die Konsistenz der Inhalte verantwortet das Reasoning-Modell, das logisch saubere Edits produzieren soll.
Das Protokoll ist einfach: Exklusive Sperren für Seiten, Erwerb beim ersten Lesen, Wound-Wait über Ankunftszeitstempel, Haltbarkeit über Chroma Cloud. In der ersten Prototyp-Version teilt der Lock-Manager eines Jobs dessen Schicksal. Mehr ist es nicht. Diese Einfachheit ist seine Stärke.
Was Fission opfert und warum sich das lohnt
Jedes Nebenläufigkeitsprotokoll tauscht eine Ressource gegen eine andere. Klassische Protokolle nehmen an, dass Arbeit billig ist, Wiederholung fast nichts kostet und Atomarität vor allem zählt. Fission dreht das um: Die teure Ressource ist die Reasoning-Arbeit des Agenten. Deshalb opfert Fission die Atomarität, um diese Denkarbeit zu erhalten. Ein einmal gemachter, logisch valider Edit wird nie verworfen – auch wenn die ursprüngliche Transaktion nicht zu Ende lief.
Diese Entscheidung hat Konsequenzen. Eine verletzte Transaktion hinterlässt ihre Teilergebnisse im Wiki, und andere Agenten können sie entdecken. Das setzt voraus, dass die Schreibfolge des Modells so strukturiert ist, dass jeder Präfix gültig ist. Dafür haben die Entwickler den Agenten ein TODO-Werkzeug gegeben: Der Agent schreibt erst den Inhalt, dann den Backlink – und nicht umgekehrt. Dadurch entstehen keine verwaisten Verweise. In Tests zeigten sich alle Anomalien, die das Protokoll zulässt, als harmlos, wenn die Updates in dieser präfix-sicheren Reihenfolge erfolgen.
Die Zahlen zeigen Muster. Bei etwa 39,7 Prozent der verletzten Transaktionen greift das Modell später erneut auf die Seite zu, die zur Verletzung geführt hat. Bei 28,2 Prozent der Modifikationen während eines Retrys teilen sich die Änderungen ein Präfix oder Suffix mit der Seite, die den Abbruch ausgelöst hat. Chroma schließt daraus, dass diese Blockaden kein False Sharing sind: Ein nennenswerter Teil der abgebrochenen Transaktionen kehrt zu genau der Seite zurück, an der sie gescheitert ist. Ein früherer Prototyp mit getrennten Lese- und Schreibsperren hatte deutlich höhere Abbruchraten; die Aufwertung von Lese- zu Schreibsperren brachte keinen Fortschritt.
Warum Git und Dateisysteme als Fundament scheitern
Die naheliegende Frage lautet: Warum nicht einfach das Wiki in Git speichern und über ein Dateisystem zugänglich machen? Chroma nennt zwei Gründe. Erstens braucht man einen sekundären Index für die Suche, sonst explodieren die Token-Kosten. Zweitens ist Git miserabel bei Merge-Konflikten. Ein früher Prototyp von Foundation nutzte genau diesen Ansatz: Git zur Konfliktlösung auf einer Dateisystem-Abstraktion. Die Ergebnisse waren ernüchternd.
Von acht Konfliktfällen brachen drei explizit ab, nachdem derselbe Konflikt wiederholt auftrat. Vier weitere gaben auf, weil ihr Lesebereich veraltet war oder sie wegen einer zwischenzeitlichen Schreiboperation neu lesen mussten. Nur einer kam zur richtigen Schlussfolgerung, dass der Schreibvorgang unnötig war, und brach deshalb ab. Besonders aufschlussreich sind die Aussagen der Modelle: „Ich überspringe das Aktualisieren der Root-Seite, um weitere Merge-Konflikte zu vermeiden.“ Oder: „Es gibt Merge-Konflikte von einem anderen Worker – ich überspringe das Aktualisieren der Root-Seite.“ Nach einem erneuten Lesen stellt ein anderes Modell fest: „Die Root-Seite wurde bereits aktualisiert, also ist kein separates Update nötig.“ Und schließlich: „Anstatt weiter zu kämpfen, überspringe ich das Root-Seiten-Update.“
Das Muster ist eindeutig. Die Modelle geben auf, nicht weil sie fachlich falsch liegen, sondern weil Git sie in eine Sackgasse führt. Sie ziehen sich zurück, obwohl ihre Absicht korrekt war. Git ist für Code konzipiert, nicht für zusammengefasste, umgeschriebene und zurückgenommene Prosa. Der Versuch, Agenten-Konflikte mit Git zu lösen, verwirft genau die Arbeit, die man erhalten will.
Was das für verteilte Systeme bedeutet
Fission ist kein Allheilmittel. Es ist ein Protokoll mit einer klaren Annahme: Die schrittweise Verbesserung eines Wissensbestands ist wertvoller als die Garantie, dass eine Transaktion ganz oder gar nicht sichtbar wird. Das passt zu einer Welt, in der Agenten zunehmend parallel an gemeinsamen Gedächtnissen arbeiten. Chroma grenzt Fission selbst ab: Es ist weder CALM noch ein CRDT. Sagas ähnelt es durchaus, allerdings ohne kompensierende Aktionen — zurückgenommen wird nie etwas. Es sitzt auf einer linearisierbaren Historie und erlaubt trotzdem, dass Modelle Zustände durch Überschreiben zurücknehmen.
Wer mit verteilten Systemen arbeitet, sieht hier ein bekanntes Muster: Die klassischen Werkzeuge sind nicht falsch, sie sind für andere Kostenmodelle gebaut. Wenn eine Transaktion Minuten dauert und ihre Wiederholung viel kostet, ist der Abbruch die teuerste Operation im System. Jedes Protokoll, das Abbrüche vermeidet oder ihre Kosten senkt, hat einen Vorteil. Fission zeigt einen Weg: Atomarität aufgeben, wo sie nicht gebraucht wird, und Intelligenz dort einsetzen, wo sie die Wiederaufnahme steuern kann. Das ist keine Absage an ACID, sondern eine pragmatische Erweiterung für eine neue Klasse von Workloads. Ohne sie kommen Agenten-Schwärme nicht in Produktion.
Quelle: trychroma.com
