Merge Queue für KI-Agenten

In Teil 3 der Serie – Mutation Testing bei KI-Agenten – hast du die einzelnen Prüfungen gesehen: nicht-korrumpierbare Gates, Mutation Testing, der geschützte Satz. Lauter Werkzeuge.

Aber ein Werkzeugkasten ist kein Prozess. Eine Säge sagt dir nicht, wann du sägst.

Die Gates sind Stationen. Was fehlt, ist der Fahrplan: Wie greifen sie als Ablauf ineinander? Was passiert, wenn eine Station rot wird, läuft der Agent dann einfach weiter? Und was, wenn nicht einer, sondern drei Agenten gleichzeitig am selben Repo bauen?

Das ist die Frage nach dem Loop. Und der Loop, nicht der einzelne Diff, ist die Einheit, die du kontrollierst.

Neun Schritte, drei Menschen-Momente

Hier ist der Dev-Loop, von der Absicht bis zum Betrieb. Lies das Diagramm einmal von oben nach unten, und achte auf eine Sache: die Farbe Blau.

Blau ist der Mensch. Und Blau taucht nur dreimal auf.

Du formulierst den Intent und gibst die Spec frei (Schritt 1), du entscheidest bei riskanten Änderungen über den Merge (Schritt 7), und du schaust dem laufenden System beim Observe (Schritt 9) zu. Dazwischen produziert der Agent, stellt den PR, durchläuft die Gates und den Critic. In diesem ganzen mittleren Block bewegst du dich nicht. Du liest hier keinen Diff, und die meisten siehst du überhaupt nie. Nur die, bei denen Schritt 7 dich zurückholt, weil sie unumkehrbar werden.

Eine Nuance zu Schritt 7, die erst der Käfig erlaubt: „je Risiko-Tier“. Eine Log-Zeile (T0) oder eine Read-only-Abfrage (T1) merged auf grüne Gates hin von selbst, ohne dass du hinschaust. Eine Migration oder ein Auth-Pfad (T3) wartet auf dich. Der Mensch kommt nicht überall zurück, sondern dort, wo es irreversibel wird.

Die Gates laufen zweimal

Eine Verortung, die das Diagramm zunächst verschweigt: Schritt 5 läuft nicht nur in der CI. Während der Agent baut, läuft derselbe Gate-Satz schon lokal mit, in seiner Sandbox, ohne Prompt, ohne Wartezeit und ohne jemanden, der bei jedem Commit über die Schulter schaut. Das ist seine schnelle Schleife. Hier dreht er die Rot-Grün-Runden im Sekundentakt, statt für jeden Fix durch die CI zu round-trippen. Ohne diese innere Schleife wäre der autonome Loop quälend träge.

Aber das lokale Grün läuft auf der Maschine, die der Agent kontrolliert. Für es gilt also genau, was Teil 3 sagt: eine Behauptung, kein Beweis. Der Beweis kommt erst aus der äußeren Schleife, der CI, die dieselben Gates ein zweites Mal fährt, auf Infrastruktur, die der Agent nie in der Hand hatte, und die nebenbei prüft, ob der PR die Wächter selbst geschwächt hat. Das lokale Grün kauft Tempo, das server-seitige Grün schafft Vertrauen. Der Käfig braucht beide, und am Ende zählt nur das zweite.

Warum lokaler Merge kein Schritt ist

In Obol, meinem Wallet-Referenz-Repo, sah der Loop am Anfang kürzer aus. Der Agent baute in einem Worktree, und am Ende stand ein lokaler Merge nach main. Schnell, bequem, und genau falsch.

Ein lokaler Merge ist kein Gate. Es ist eine Stelle, die der Produzent selbst erreicht. Damit ist es, mit der Sprache aus Teil 3, eine Bitte, keine Prüfung. Der Schritt wanderte also dahin, wo der Agent nicht hinkommt: ein geschütztes main, das nur über einen PR mit grünen, server-seitigen Gates erreichbar ist. Der Agent darf Schritt 4 (den PR aufmachen), aber nicht Schritt 7 (mergen) an sich reißen.

Und damit das technisch trägt, braucht der Agent in Schritt 2 eine eigene Identität, nicht deine. Sonst bist du Autor und Genehmiger in einer Person, und die Trennung ist nur behauptet.

Wer baut, prüft nicht

Noch ein Detail, das im Diagramm hinter „dem Agenten“ verschwindet: Das ist nicht eine durchlaufende Instanz. Wer die Tests aus der Spec ableitet, wer den Code schreibt und wer ihn am Ende adversarial zerlegt, das sind getrennte Agenten mit jeweils frischem Kontext.

Das ist kein Komfort, sondern dieselbe Trennung wie in Teil 2, nur eine Ebene tiefer. Sitzen Intent und Umsetzung in einer Instanz, zementiert sie ihr eigenes Missverständnis und nickt es sich selbst ab. Der Critic ist überhaupt nur etwas wert, wenn er nicht weiß, wie verliebt der Producer in seine Lösung war. Frischer Kontext ist die Unabhängigkeit aus Teil 1, übersetzt in den Loop.

Die Rückkante: der gefährlichste Pfeil im Diagramm

Die neun Schritte sind vorwärts gezeichnet. Aber der echte Loop schließt sich über eine Kante, die zurückläuft, im Diagramm rot: Wird ein Gate rot (5) oder lehnt der Critic ab (6), geht ein strukturiertes Defekt-Signal zurück in den Kontext des Agenten, der neu generiert (3) und erneut durch die Gates läuft.

Erst diese Rückkante macht „autonom im Käfig“ überhaupt operativ. Ohne sie bleibt jedes rote Gate beim Menschen hängen, und du hast den Engpass, den du gerade losgeworden bist, wieder zurück.

Genau deshalb ist die Rückkante auch die gefährlichste Stelle im ganzen Bild.

Erinnerst du dich an den gierigen Optimierer aus Teil 1? „Mach das rote Gate grün“ ist für ihn eine Einladung. Der billigste Weg zu Grün ist fast nie der echte Fix, sondern das Signal abzuwürgen: ein .skip auf den roten Test, ein @ts-expect-error über die Zeile, ein gesenkter Schwellenwert, im Zweifel den Test löschen. Lauter Handgriffe, die jeder von uns schon mal gemacht hat, kurz vor dem Release, mit dem festen Vorsatz, das später wieder geradezuziehen. Eine naiv gebaute Rückkante dressiert dem Agenten also genau das an, was du am wenigsten willst.

Sie ist nur sicher, weil die Wächter aus Teil 3 schon in Schritt 5 stehen: der geschützte Satz, der Mutation-Ratchet, die Semgrep-Regeln gegen Fluchttüren. Sie versperren die billigen Wege, und der einzige verbleibende Weg zu Grün ist der, den du gemeint hast.

Die Rückkante gehört, wie das Grounding aus Teil 1, auf die Seite der Harness. Nicht der Agent entscheidet, ob er nochmal läuft. Die Umgebung entscheidet es.

Wenn drei gleichzeitig bauen

Bis hier war es ein Akteur. Im Team arbeiten viele nebenläufig, Entwicklerinnen wie Agenten, und die interessante Frage ist nicht mehr „läuft der Loop?“, sondern „was passiert, wenn drei Loops gleichzeitig auf dasselbe main zielen?“.

Jeder der drei PRs ist für sich grün. Und das zählt nichts.

Denn „grün“ hieß: grün gegen den Stand von main, den der Akteur beim Start gesehen hat. Mergen die anderen zwei in der Zwischenzeit, ist dieser Stand veraltet. Der PR ist grün gegen eine Vergangenheit, die es nicht mehr gibt. Das nennt man Stale-Green, und es ist die heimtückischste Art, wie nebenläufige Arbeit auseinanderläuft: Niemand hat einen Fehler gemacht, und trotzdem ist das Ergebnis kaputt.

Die Invariante dagegen ist simpel: Kein Akteur ändert geteilten Zustand unverifiziert. Konkret heißt das, am Merge-Punkt läuft die volle Gate-Menge plus Critic noch einmal, aber gegen den kombinierten Zustand aus main und dem Eintrag. Das fängt Stale-Green und semantische Interferenz in einem Aufwasch. Eine Merge-Queue ist genau dieser Mechanismus, in Werkzeugform.

Und hier fällt nebenbei der unangenehmste Fall heraus: zwei kolludierende Agenten, zwei Komplizen, die unter einer Decke stecken. Die Vertrauensanker (deterministische Gates, M-von-N-Autorität, das T3-Menschen-Gate) hängen nicht von der Ehrlichkeit eines Agenten ab. Selbst wenn Producer und Critic beide kompromittiert wären, kämen sie an den deterministischen Gates und am T3-Menschen-Gate nicht vorbei, die keiner von ihnen abschalten kann. Was allein der Critic gefangen hätte, entfällt bei seiner Kompromittierung: ein nicht-deterministischer Prüfer taugt nur, solange er ehrlich ist. Die Restmenge wächst also um dessen Abdeckung, aber die deterministische Untergrenze hält. Durchbringen ließe sich nur, was ohnehin kein hartes Gate erzwingt und kein Mensch prüft. Du brauchst also kein Vertrauen zwischen den Agenten, und deshalb auch kein Koordinationsprotokoll.

Der erste Durchlauf

In Obol steht der Käfig, und die teuren Schritte sind gebaut. Der PR-Flow, die eigene Identität, die server-seitigen Gates, das geschützte main.

Seit Kurzem ist auch der erste vollständige Feature-Loop gelaufen: ein Konto-anlegen-Feature von der Spec bis durch alle zehn Gates. Er lief nicht glatt, und das ist die gute Nachricht. Der Käfig hat den Agenten, der ihn mitgebaut hat, im selben Feature gleich dreimal korrigiert. Weil das mehr zeigt als jeder geglättete Bericht, lasse ich ihn selbst zu Wort kommen.

Was weiter aussteht, ist der Loop unter Last: mehrere Akteure nebenläufig, eine echte Merge-Queue. Davon erzähle ich, wenn es so weit ist, nicht vorher.

Was du mitnimmst

Der einzelne Diff war früher die Einheit, über die du geherrscht hast. Du hast jeden gelesen, jeden abgenickt. Das skaliert nicht, wenn die Diffs schneller kommen, als du lesen kannst.

Im Käfig verschiebt sich die Einheit. Du baust und pflegst den Loop: die Schritte, die Gates dazwischen, die Rückkante, die Merge-Queue. Der einzelne Diff läuft durch, ohne dass du ihn ansiehst, weil der Loop ihn bereits geprüft hat, härter als dein müder Freitagsblick es könnte.

Der Mensch verschwindet dabei nicht. Er bewegt sich an drei Stellen: Er sagt, was gebaut werden soll. Er entscheidet, wo es irreversibel wird. Und er schaut dem Ergebnis in der Wirklichkeit zu. Der Rest läuft im Käfig.

Und weiter?

Dieser Loop sichert eine Sache sehr gründlich: dass der Code korrekt ist. Dass er tut, was die Spec sagt, und nichts davon still bricht. Zweierlei sichert er nicht.

Das eine kennst du aus Teil 2: dass die Spec überhaupt das Richtige verlangt. Der Loop prüft die Treue zur Spec, nicht ob die Spec das Richtige will. Ob die Spec in sich sauber ist, widerspruchsfrei und vollständig, lässt sich durchaus prüfen. Ob sie das Gewollte trifft, bleibt deine Sache. Genau dafür gibst du sie an Moment 1 frei, bevor ein Agent eine Zeile baut, und kein Gate nimmt dir diese Abnahme ab.

Das andere ist neuer. Der Agent ist nicht nur ein Autor von Code. Er ist ein Akteur in deinem System. Er ruft Tools auf, liest Daten, schickt Requests nach draußen. Ein grünes Korrektheits-Gate sagt nichts darüber, was dieser Akteur anrichten kann, wenn er ein schlechtes Paket zieht oder unterwegs gekapert wird.

Korrektheit und Eindämmung sind zwei verschiedene Achsen. Um die zweite geht es in Teil 5; wenn wir muss mit der Frage beschäftigen, ob dein Agent nicht schon längt kompromittiert ist.