Anfang dieses Jahres haben wir Experimente durchgeführt, um die Grenzen der Skalierung von Agenten auszuloten, damit sie gemeinsam auf ein Ziel hinarbeiten. Unsere Hypothese war, dass sich damit eine neue Stufe bei Umfang und Komplexität von Aufgaben erschließen lässt.

Das Vorzeigeprojekt war ein lang laufender Schwarm, der einen Webbrowser von Grund auf erstellte. Als Machbarkeitsnachweis war er erfolgreich, blieb aber weit hinter ausgereifter Software zurück.

Diese Arbeit war bewusst empirisch angelegt. Wir begannen bei null und arbeiteten uns schrittweise zu einem stabilen, effektiven System vor. Seitdem war es unser Ziel, den Agent-Schwarm gut genug zu verstehen, um ihn gezielt entwickeln zu können.

Um diesen Fortschritt zu überprüfen, kehrten wir zu einer Aufgabe zurück, mit der der alte Schwarm zu kämpfen hatte: SQLite in Rust von Grund auf zu erstellen, allein auf Basis seiner Dokumentation.

Unsere ersten Ergebnisse waren vielversprechend. Wir ließen den alten und den neuen Schwarm dieselbe Aufgabe mit denselben Modellen und demselben Zeitbudget bearbeiten und maßen, wie viel von einer separaten SQL-Test-Suite jeder bestehen konnte.

Der neue Schwarm war in jeder Modellkonfiguration besser. Mit Grok 4.5 erreichte er in vier Stunden 80 %, während der alte Schwarm ins Schleudern geriet und noch vor Ablauf der zweiten Stunde pausiert werden musste.

Wir variierten außerdem, welche Modelle welche Aufgaben übernahmen. In einigen Durchläufen übernahm ein Modell alles, in anderen plante ein Frontier-Modell, während ein schnelles, günstiges Modell die Arbeit ausführte. Jeder Mix lieferte eine ähnliche Qualität, aber die Kosten unterschieden sich enorm.¹

#Bäume und Blätter

Beschreibungen großer Aufgaben folgen natürlicherweise einer Baumstruktur, mit einem Ziel an der Wurzel, das sich rekursiv in elementare Arbeitseinheiten verzweigt. Unser Schwarm hat zwei Rollen, die beide um dieselbe baumartige Zerlegung herum organisiert sind:

• Planner-Agents, gestützt auf die leistungsfähigsten Modelle, teilen ein Ziel in Teilaufgaben auf und delegieren diese.
• Worker-Agents, die in der Regel auf schnelleren und kostengünstigeren Modellen basieren, führen diese Teilaufgaben aus.

Das Design geht über starrere Orchestrierungssysteme hinaus. Anstatt dem Problem eine feste Topologie aufzuzwingen, wächst die Form des Schwarms entlang der Konturen des Problems, und Rechenleistung und Kontext skalieren proportional zur Komplexität der Aufgabe.

Wir glauben, dass dies der Grund ist, warum sich das Design auf so unterschiedliche Aufgaben anwenden lässt wie einen Browser zu erstellen, mathematische Probleme zu lösen und GPU-Kernel zu optimieren. Wir haben es auch intern genutzt, um Schwachstellen in Open-Source-Software zu finden und zu beheben, die Testabdeckung unserer eigenen Codebasis zu erhöhen und Milliarden von Token synthetischer Trainingsdaten zu generieren.

#Was der Baum für den Speicher leistet

Wenn ein einzelner Agent eine vollständige Aufgabe übernimmt, muss er den gesamten Baum selbst durchlaufen und bis zu jedem Blatt hinabsteigen, während er seine übergeordneten Knoten, seine aktuelle Position und das übergeordnete Ziel die ganze Zeit im Kontext behalten muss.

Wir glauben, dass das erklärt, warum einzelne Agenten bei lang laufenden Aufgaben abdriften. Sie können sich entweder auf die unmittelbar vor ihnen liegende Arbeit konzentrieren und dabei das große Ganze aus den Augen verlieren, oder das große Ganze im Blick behalten und den jeweiligen Teil schlechter ausführen.

In einem Schwarm implementiert ein Planner nie selbst, daher füllt sich sein Kontext nie mit Details auf niedriger Ebene, und ein Worker plant nie, sodass er seinen gesamten Kontext auf einen einzelnen, eng abgegrenzten Teil der Arbeit verwenden kann.

Wir vermuten, dass die Fähigkeit, den Agent-Schwarm zu skalieren, eher auf dieser Kontexteffizienz beruht als auf dem Parallelismus selbst. Diese Effizienz ist im Schwarm auf jeder Größenordnung vorhanden, weshalb diese Zerlegung die Leistung von Agenten selbst bei Aufgaben mittlerer Größe verbessert.

Ähnliche Strukturen finden sich auch anderswo. Der Ökonom Ronald Coase, der sich fragte, warum Unternehmen überhaupt existieren, argumentierte, dass Koordinationskosten schneller wachsen als die Arbeit selbst, weshalb sich Organisationen in abgegrenzte Einheiten auf mehreren Ebenen gliedern, statt alle mit allen sprechen zu lassen.

#Ein Versionskontrollsystem für Agenten

In einem früheren Beitrag über den Schwarm haben wir darauf hingewiesen, dass Tools wie Git und Cargo bei der Nebenläufigkeitskontrolle auf grobe Sperren setzen. Das funktioniert für einen einzelnen Entwickler, ist aber für die Menge an Arbeit, die von Hunderten gleichzeitig arbeitenden Agenten erzeugt wird, nicht praktikabel.

Der Browser-Schwarm von Anfang dieses Jahres erreichte auf Git Spitzenwerte von ungefähr 1.000 Commits pro Stunde. Das neue System erreicht Spitzenwerte von etwa 1.000 Commits pro Sekunde.

Um dieses Aktivitätsniveau zu ermöglichen, haben wir von Grund auf ein neues Versionskontrollsystem (VCS) entwickelt. Der Durchsatz war nicht der einzige Grund, diese Ebene selbst in der Hand zu haben. Jede Änderung im System läuft durch das VCS, daher werden Konflikte dort zuerst sichtbar, und mehrere der Koordinationsmechanismen im nächsten Abschnitt sind direkt darin implementiert.

#Fehlermodi bei 1.000 Commits pro Sekunde

Menschliche Engineering-Teams verfügen über etablierte Koordinationsmechanismen wie Code-Reviews, Zuständigkeiten, Standups und Merge-Queues. Diese Systeme funktionieren im menschlichen Tempo, aber bei der Commit-Frequenz eines Schwarms treten Fehlermodi auf, mit denen menschliche Teams normalerweise nicht konfrontiert sind.

#Split-Brain-Design

Zwei Planner, die nichts voneinander wissen, setzen dasselbe Konzept in unterschiedlichen Teilen der Codebasis auf verschiedene Weise um.

Das haben wir durch Prompting behoben. Planner treffen Designentscheidungen selbst, statt sie zu delegieren, und wir verlangen von ihnen sicherzustellen, dass nicht zwei delegierte Teilbäume dieselbe Frage entscheiden.

#Konflikte zwischen Plannern

Eine schwierigere Form von Konflikten entsteht, wenn zwei Planner voneinander wissen und sich mit wechselseitigen Änderungen an denselben Dateien gegenseitig behindern.

Das Problem sind zwei unterschiedliche Vorstellungen der Realität, und Merge-Tools können eine Meinungsverschiedenheit nicht auflösen. Stattdessen lassen wir Agenten Entscheidungen in gemeinsamen Design-Dokumenten festhalten. Code, der von einer Entscheidung abhängt, enthält einen vom Compiler geprüften Verweis zurück auf das zugehörige Dokument. Wenn Planner einander unbemerkt widersprechen, führt ein Reconciler die Dokumente zusammen, und die Verweise tragen die Auflösung an nachgelagerte Abhängigkeiten weiter.

#Merge-Konflikte

Innerhalb des Schwarms geraten Agenten ständig wegen derselben Dateien aneinander. Um einen Konflikt aufzulösen, müssten sie anhalten, den Kontext des anderen Agenten aufnehmen und ihn zusammenführen. Worker-Agenten sind darin schlecht und überschreiben in der Praxis entweder die Änderung des anderen oder geben ihre eigene auf.

Um das zu beheben, haben wir ein System entwickelt, bei dem bei Merge-Konflikten ein neutraler Agent als dritte Instanz eingreift und sie im Namen aller Beteiligten auflöst. Sein einziges Ziel ist es, unparteiisch und effizient zu sein – ähnlich wie Merge-Queues in Engineering-Teams funktionieren.

#Megadateien

Einige Dateien sind besonders beliebte Stellen, an denen Agenten arbeiten. Jeder Agent fügt vielleicht nur wenig Code hinzu, und kein einzelner Agent ist dafür verantwortlich, diese Dateien klein zu halten.

Diese „Megadateien“ legen alles lahm. Sie sind teuer zu transportieren, zu diffen und zu mergen und werden ständig zum Schauplatz von Konflikten.

Um das zu beheben, haben wir Worker-Agenten die Möglichkeit gegeben, aufgeblähte Dateien zu kennzeichnen. Sobald eine Datei gekennzeichnet ist, blockieren wir neue Commits, und ein separater Agent zerlegt die übergroße Datei in kleinere Module.

#Verkrustung

Agenten haben durch die Arbeit in bestehenden Codebasen mit Menschen im Loop gelernt, den Kerncode nicht anzufassen, selbst wenn er geändert werden müsste.

Um das zu beheben, lassen wir absichtliche Brüche zu. Ein Agent, der eine Änderung am Kerncode für sinnvoll hält, kann außerhalb seines Aufgabenbereichs einen gezielten Patch vornehmen und einen Kommentar hinterlassen, der erklärt, warum er das getan hat.

Der Compiler zieht die Änderung durch den Rest des Systems, und alles, was vom alten Design abhängt, schlägt beim Build fehl. Jeder Agent, der auf einen dieser Fehler stößt, findet den Kommentar, liest die Begründung und aktualisiert seinen eigenen Teil der Arbeit entsprechend.

#Review-Perspektiven

In einem System, das sowohl lange läuft als auch mit mehreren Agenten arbeitet, häufen sich Fehler an, und der Schwarm braucht eine Möglichkeit zur Selbstkorrektur, bevor kleine Fehler grundlegend werden.

Wir haben mit vielen Arten von Review-Perspektiven experimentiert, etwa indem wir einem Review-Agenten das vollständige Transkript des Workers gegeben haben, oder nur seinen Output, oder nichts außer der Codebasis. Wir haben auch Reviewer ausprobiert, die auf unterschiedlichen Modellen laufen, mit unterschiedlichem Training und unterschiedlicher Persönlichkeit.

Keine einzelne Perspektive erfasst alles, aber unkorrelierte Perspektiven ergänzen sich – so wie selbstfahrende Systeme eine übermenschliche Zuverlässigkeit erreichen, ohne dass es eine einzelne perfekte Komponente gibt. Die für Reviews eingesetzten Rechenressourcen bringen eine hohe Rendite, da Reviews deutlich günstiger sind als die Arbeit, die sie prüfen. Wir vermuten, dass dieses gestapelte Review-System wesentlich zur dauerhaft hohen Qualität der Läufe beigetragen hat.

#Agenten die Umgebung prägen lassen

Stigmergie ist der Mechanismus, durch den Schwarmorganismen wie Ameisen und Termiten sich ohne direkte Kommunikation koordinieren. Sie prägen die Umgebung, und die Umgebung prägt den nächsten Organismus.

In früheren Durchläufen hatten wir Regeln wie „Notizen machen“ und „Entscheidungen dokumentieren“ eingebaut, weil sie offensichtlich sinnvoll erschienen. Rückblickend halfen sie Agenten dabei, Wissen für ihr zukünftiges Selbst und ihre Teamkollegen festzuhalten.

Das haben wir mit einem Experiment zu selbst verfasstem, gemeinsam genutztem Kontext weitergetrieben, das wir Field Guide nennen. Dabei handelt es sich um einen Ordner, der vollständig den Agenten gehört und dessen index.md beim Start automatisch in jeden Agenten eingespeist wird. Es ist die Aufgabe der Agenten, zu kuratieren, was in den Leitfaden aufgenommen wird; ihre einzige Einschränkung ist ein Zeilenbudget.

Die zugrunde liegende Logik des Leitfadens ist, dass die Modellgewichte eingefroren sind. Deshalb lohnt es sich gerade, Unerwartetes festzuhalten, damit die nächste Agenten-Trajektorie kürzer wird.

Der Field Guide ist ein frühes Experiment mit vielversprechenden Ergebnissen. Wir gehen davon aus, dass die Vorteile bei Codebasen, die Agenten nicht vollständig kontrollieren, noch größer sind. Modelle darauf zu trainieren, für ihre Nachfolger zu schreiben – wobei besseres Festhalten zu besseren Belohnungen führt –, ist ein interessantes Feld für weitere Forschung.

#Das SQLite-Experiment

Wir wiesen die neue Version des Schwarms, ausgestattet mit allen oben beschriebenen Verbesserungen, an, das gesamte 835-seitige SQLite-Handbuch in Rust zu implementieren. Quellcode, Test-Suites, die SQLite-Binärdatei und Internetzugang hielten wir dabei zurück.

Um den Fortschritt zu messen, bewerteten wir anhand von sqllogictest, einer Test-Suite des SQLite-Projekts, die entwickelt wurde, um zu prüfen, ob verschiedene Datenbank-Engines für dieselben Abfragen dieselben Ergebnisse liefern. Sie enthält Millionen von Abfragen mit bekannten korrekten Antworten, und die Bewertung entspricht dem Anteil der Anfragen, die die Datenbank des Schwarms richtig beantwortet. Im Verlauf eines Durchlaufs zeigt sich der Fortschritt als ansteigende Kurve.

Dem Schwarm wurde nie mitgeteilt, dass diese Suite existiert. Nach jedem Durchlauf überprüften wir den Code und den Durchlauf selbst manuell, achteten auf Betrug und Abkürzungen und stellten sicher, dass das System gleichmäßig aufgebaut war, statt nur dort, wo die Tests hinschauen.

Wenn du die Kurven liest, denke daran, dass die Agenten ihre eigenen Strategien wählten. Einige legten ein breites Fundament und erzielten stundenlang niedrige Scores, bevor es spät zu einem starken Anstieg kam, während andere tief in einen Bereich einstiegen, früh punkteten und dann auf einem Plateau blieben, während sie den Rest ergänzten. Trends sind wichtiger als exakte Scores zu bestimmten Zeitpunkten.

#Ergebnisse für verschiedene Modell-Mixe

Wir haben vier Konfigurationen getestet, die unterschiedliche Fähigkeit und Kosten abdecken:

1. GPT-5.5 als Planner und Worker. Durchgehend ein starkes Frontier-Modell.²
2. Grok 4.5 als Planner und Worker. Unser kosteneffizientes Frontier-Modell als Vergleichspunkt.
3. Opus 4.8 als Planner und Composer 2.5 als Worker. Frontier-Urteilsvermögen gepaart mit effizienter Ausführung.
4. Fable 5 als Planner und Composer 2.5 als Worker. Um zu sehen, ob ein Planner der nächsten Tarifstufe den Hybrid lohnender oder weniger lohnend macht.

Das neue Harness übertraf das alte in jedem Mix.

Der Fable-5-Hybrid bestand innerhalb der ersten Stunde etwa zwei Drittel der Testsuite. Bis zum Vier-Stunden-Limit lagen die neuen Ausführungen zwischen 73 % und 85 %, während die alten Ausführungen zwischen 11 % und 77 % lagen.

Die alte Grok-4.5-Ausführung wurde vor der Zwei-Stunden-Marke pausiert (mehr dazu weiter unten). Jede neue Konfiguration bestand schließlich 100 % der Testsuite.

Künftig möchten wir die vollständige N×N-Matrix der Planner-Worker-Kombinationen ausführen. Für diesen Zyklus ist jedoch der Vergleich zwischen den Harness-Versionen entscheidend, und die Unterschiede im Verhalten fielen letztlich deutlich größer aus, als die Score-Unterschiede vermuten lassen.

#Ein tieferer Einblick in die Ausführungen

Beginnen wir mit dem einfachsten Maß für Aktivität: Hier sieht man, wie sich die Commit-Rate von Grok 4.5 unter dem alten Harness im Vergleich zum neuen verändert hat. Die alte Ausführung erzeugte in den ersten zwei Stunden 68.000 Commits — ungefähr 70-mal so viele wie die neue Ausführung im gleichen Zeitraum.

Eine mögliche Lesart ist, dass er produktiver war. Eine andere ist, dass die meisten dieser Commits bloße Scheinproduktivität waren (thrash, contention, churn).

Die Daten zu Merge-Konflikten sprechen für Letzteres. Die alte Ausführung häufte mehr als 70.000 Konflikte an, bevor wir ihn pausierten, und die Zahl stieg weiter an, statt sich zu stabilisieren. Die neue Ausführung protokollierte über seine gesamten vier Stunden hinweg dagegen weniger als tausend.

Die Konflikte konzentrierten sich dort, wo Dateien am größten wurden. In der alten Ausführung wuchsen die größten Dateien während der gesamten Ausführung weiter, und die am stärksten umkämpfte Datei sammelte 7.771 Konflikte, an denen 1.173 verschiedene Agenten beteiligt waren. In der neuen Ausführung verzeichnete die am stärksten umkämpfte Datei in der gesamten Codebasis 47.

Der größte Koordinationsfehler des alten Schwarms — Split-Brain, also Planner, die die Arbeit der anderen duplizierten — zeigte sich in der Paketstruktur. Rust-Code ist in Pakete organisiert, die Crates genannt werden, und in einem Projekt wie diesem entspricht jedes Crate ungefähr einer größeren Komponente.

Die alte Ausführung wuchs auf 54 Crates an, einschließlich drei separater SQL-Pakete. Die neue Ausführung legte sich früh auf neun Crates fest und fügte nie ein weiteres hinzu.

All das zeigt sich in der endgültigen Codebasis. Im Fable 5 Mix bestanden am Ende sowohl der alte als auch der neue Schwarm die vollständige Suite, aber der alte brauchte 64.305 Zeilen Engine-Code, während der neue mit 9.908 auskam. Der Opus Mix zeigt dasselbe Muster: 19.013 Zeilen bei einer Bewertung von 97 % unter dem alten Harness und 4.645 Zeilen bei 100 % unter dem neuen Harness.

#Modellökonomie

Wir haben eingangs gesagt, dass jeder Modell-Mix eine ähnliche Qualität lieferte, während die Kosten stark variierten — von 1.339 $f\ddot{u}rdenOpus-4.8-Hybridbishinzu10.565$ für GPT-5.5 allein. Die Token-Daten zeigen, woher dieser Unterschied kommt.

Die Ausgabenstruktur war in jeder Ausführung konsistent: Worker machten mindestens 69 % der Token aus, in den meisten Fällen sogar über 90 %.

In Dollar verteilten sich die Kosten jedoch anders als die Token, weil Planner-Token teurer sind. In dem Mix aus Opus 4.8 und Composer 2.5 erzeugte Opus als Planner nur einen kleinen Teil der Token, verursachte aber rund zwei Drittel der Kosten, während Composer als Worker die überwältigende Mehrheit der Token übernahm — für das verbleibende Drittel der Kosten.

Nur wenige Momente in einer großen Aufgabe erfordern wirklich Frontier-Intelligenz, etwa die anfängliche Zerlegung, Designentscheidungen und bestimmte Abwägungen. Sobald ein Frontier-Planner die Mehrdeutigkeit in eine detaillierte, explizite Anweisung aufgelöst hat, müssen günstigere Modelle ihr nur noch folgen. Das ist ein enormes Potenzial für Kosteneinsparungen. In der Ausführung, bei dem GPT-5.5 sowohl für Planner als auch für Worker verwendet wurde, kosteten allein die Worker 9.373 $.InderAusf\ddot{u}hrung,beidemOpus4.8diePlanung\ddot{u}bernahmundComposer2.5dieArbeiterledigte,kostetediegesamteWorker-Flotte411$.

Ein bemerkenswertes Detail zeigt sich beim Vergleich der beiden Hybridausführungen. Der Fable-5-Planner verursachte eine etwas niedrigere Rechnung als der Opus-4.8-Planner, obwohl der Preis pro Token ungefähr doppelt so hoch war, weil er deutlich weniger Planungs-Token nutzte. Die Worker in der Fable-Ausführung verbrauchten jedoch ein Vielfaches an Token, und die Ausführung insgesamt war am Ende deutlich teurer.

#Specs als Prompts

Jeder Sprung in den KI-Fähigkeiten hat das Abstraktionsniveau erhöht, auf dem ein Ingenieur arbeiten kann.

Mit Autocomplete konnten Ingenieure jeweils eine einzelne Codezeile bearbeiten. Frühe Modelle erweiterten das auf einen Codeblock, und Agenten auf eine Datei oder ein Feature.

Mit Schwärmen wird die Spezifikation zur Arbeitseinheit.

Damit das funktioniert, muss der Schwarm der Spezifikation tatsächlich folgen — und genau darum geht es in weiten Teilen dieses Beitrags. Wir gaben dem Schwarm 835 Seiten Prosa, und er kam mit einer Datenbank zurück. Was in diesem Experiment knapp war — und was unserer Erwartung nach auch künftig in der Softwareentwicklung knapp sein wird —, ist die richtige Beschreibung der Absicht.

So betrachtet beginnt der Schwarm, einem Compiler zu ähneln. Ein Compiler übersetzt Quellcode über eine Reihe von Zwischenschritten in Maschinencode. Der Schwarm macht mit Absicht etwas Ähnliches. Planner zerlegen ein Ziel in Aufgabenbäume und überführen es dann Schritt für Schritt in ausführbare Arbeit. Der Unterschied besteht darin, dass ein Compiler die Bedeutung in jedem Schritt bewahrt, während der Schwarm bei jedem einzelnen Schritt probabilistisch arbeitet. Alles, was in diesem Beitrag beschrieben wird, dient dazu, diese Lücke zu schließen.

Wir laden dich ein, den Output des Schwarms zu erkunden. Die Codebasis aus der Solo-Ausführung mit Opus 4.8 ist öffentlich unter github.com/cursor/minisqlite verfügbar. Nach unserem ersten Eindruck sieht sie großartig aus, aber wir haben noch keine tiefergehende manuelle Analyse durchgeführt. Schau sie dir selbst an und sag uns, was du findest.