Die Risiko-Staffel gegen den Kontrollverlust beim Agenten

Am Ende von Teil 5 – wir hatten uns mit dem Blast Radius beschäftigt – stand eine unbequeme Bilanz. Korrektheits-Gates, eine Merge-Queue, Eindämmung, eigene Identitäten, Grounding: eine Menge Käfig, und nichts davon ist gratis. Rechenzeit, Pflege, ein bisschen Geschwindigkeit, hin und wieder ein Fehlalarm, der dich aufhält.

Also die Frage, die jeder Pragmatiker zuerst stellt: Lohnt sich das? Und wenn ja, wie viel davon? Ab wann baust du an Gates, die mehr kosten, als sie je verhindern werden?

Dahinter lauert eine Frage, die sich vernünftig anfühlt und es nicht ist: „Ist das hier perfekt geprüft?“ Perfektion ist nicht das Ziel, und sie ist nicht einmal die richtige Frage. Die schlechte Antwort lautet „mehr ist besser“. Die gute Antwort ist eine Kurve, und sie sieht für jede Änderung anders aus.

Eine halbe Hülle gibt es nicht

Fangen wir mit der einen Stelle an, an der „good enough“ eine Falle ist.

Stell dir den Käfig um eine Änderung als Hülle vor. Innerhalb dieser Hülle gilt: Eine einzige Naht, und sie ist durchlässig. Der Agent ist der gierige Optimierer aus Teil 1, er fließt wie Wasser zum geringsten Widerstand. Lässt du ein Schlupfloch offen, weil es „nur diese eine harmlose Stelle“ ist, nimmt er genau das. Eine Hülle mit einem Loch ist keine halbe Hülle, sie ist gar keine.

Beide Hälften zählen, und sie widersprechen sich nur scheinbar.

Die Tiefe ist binär. Hast du dich entschieden, eine Eigenschaft abzusichern, muss die Absicherung lückenlos sein. „Wir prüfen Migrationen, außer freitags“ ist keine Absicherung, das ist eine Einladung.

Die Breite dagegen darfst du staffeln. Wie viel du überhaupt in die Hülle legst, welche Fläche, welche Risikoklasse, das ist deine Entscheidung. Du musst nicht jede Zeile mit derselben Wucht prüfen wie eine Datenbank-Migration. Du musst nur, was du prüfst, ganz prüfen.

Die einzige verbotene Variante ist die Mischung aus beidem im selben Geltungsbereich: „wasch mich, aber mach mich nicht nass“. Eine Migration zur Hälfte absichern bringt nicht halbe Sicherheit, es bringt ein grünes Gate, dem du nicht trauen darfst, ohne es zu wissen.

Die Risiko-Staffel

Wenn die Breite gestaffelt sein darf, brauchst du eine Staffelung. Ich nenne sie die Risiko-Staffel, und sie besteht aus Stufen, den Tiers T0 bis T3. Sie sortiert jede Änderung nach zwei verbundenen Fragen: Wie schlimm ist es, wenn das hier schiefgeht, und wie schwer lässt es sich rückgängig machen?

Die Risiko-Staffel auf einen Blick

Tier	Typische Änderung	Merge	Was zusätzlich prüft
T0	reine Doku, ein Kommentar	automatisch	nur der Boden
T1	read-only, isolierte Logik	automatisch auf grüne Gates	nur der Boden
T2	normaler Service-Code	grün + ein unabhängiges Review	der Boden plus Domänentiefe
T3	Migration, Auth, Contracts, die Gate-Regeln selbst	grün + menschliches Gate	alles, plus Vorsorge gegen Irreversibles

Das ist das Modell, vier Stufen zur Veranschaulichung. In der Praxis fallen die unteren oft zusammen, Obol etwa kommt mit drei Stufen aus (gleich mehr). Zwei Dinge an dieser Staffel sind der ganze Trick.

Erstens: Der Boden ist immer an. Typen, Lint, die schnellen Unit-Tests, alles, was in Sekunden läuft, nicht in Minuten, laufen bei jeder Änderung, von T0 bis T3, und kosten praktisch nichts. Gestaffelt wird nur das Teure: das zweite Augenpaar, die langsame Mutationsanalyse, das menschliche Gate. Du sparst nie an der billigen Prüfung, du sparst nur dort, wo Prüfen wirklich Geld oder Zeit kostet.

Nichts an diesem Boden ist neu. Linter, statische Analyse, eine ordentliche Testsuite gehörten zum Handwerk, lange bevor der erste Agent eine Zeile schrieb, und wer sie ernst nahm, baute schon immer bessere Software. Geändert hat sich nicht das Werkzeug, sondern der Spielraum: Was früher die Kür war, die Disziplin, die man unter Termindruck auch mal ausließ, ist beim agentischen Tempo Pflicht, weil der Agent schneller Schrott produziert, als du ihn von Hand auffängst. Das ist das Leitmotiv aus Teil 3, eine Etage tiefer: Der Agent erfindet die Boden-Gates nicht, er nimmt dir nur die Freiheit, ohne sie zu arbeiten.

Zweitens, und das ist die Stelle, an der die meisten es falsch machen würden: Das Tier wird abgeleitet, nicht gewählt. Es ergibt sich deterministisch aus dem, was die Änderung berührt, nicht aus dem, was der Agent (oder du) darüber behauptet. Den Grund hast du in Teil 4 schon im Tagebuch gesehen: Lässt du den Produzenten seine eigene Risikoklasse setzen, ist über kurz oder lang alles „trivial“. Wer das Ergebnis grün haben will, redet das Risiko klein. Der Pfad entscheidet, nicht die Meinung über den Pfad.

Der Pfad ist dabei ein Stellvertreter fürs Risiko, kein Maß davon, und das gibt man besser offen zu. Eine Doku-Datei, die zufällig unter auth/ liegt, landet zu hoch; ein gefährlicher Default mitten im normalen Service-Code zu niedrig. Deshalb kalibrierst du die Ableitung bewusst konservativ: lieber zu viel Reibung (harmlose Änderung, hohes Tier) als ein Loch (gefährliche Änderung, niedriges Tier). Das ist kein Widerspruch zum „abgeleitet, nicht gewählt“ von eben: Ein Mensch darf eine Änderung nur hochstufen, also in die konservativere, strengere Richtung schieben, nie heruntersetzen. Wählen darfst du also allein den sichereren Weg. Sonst stünde die Wahl-Hintertür, die du gerade geschlossen hast, wieder offen.

Wann ist genug genug?

Jetzt zur eigentlichen Frage. Innerhalb einer Risikoklasse: Wie viele Gates baust du? Wann hörst du auf?

Die Stopp-Regel klingt zunächst simpel: Bau ein Gate, solange das nächste Gate weniger kostet als der Schaden, den es im Mittel verhindert. Kostet die nächste Prüfung mehr, als der Defekt, den sie fängt, dich erwartbar kosten würde, hörst du auf. Das ist Pareto, angewandt auf Verifikation. Gemeint ist hier die ökonomische Grenzkosten-Abwägung (die nächste Einheit Prüfung gegen ihren erwarteten Nutzen), nicht die populäre 80/20-Regel. Und die Risiko-Staffel von eben ist diese Kurve in Tabellenform: T3 schiebt die Grenze weit hinaus, T0 stoppt am Boden.

Nur gilt diese Regel nicht überall gleich. Es gibt nämlich zwei verschiedene Fragen, die sich beide wie „wie viel ist genug“ anfühlen, aber völlig verschieden gestoppt werden.

Die erste ist die Frage nach der Breite: Welche Defektklassen decke ich überhaupt ab? Brauche ich zusätzlich zu den Tests noch ein Architektur-Gate, einen Migrations-Linter, einen Security-Scanner? Die wird ökonomisch gestoppt, genau wie oben: Grenzkosten gegen erwarteten Schaden. Irgendwann fängt das nächste Gate eine so seltene oder harmlose Defektklasse, dass es sich nicht mehr lohnt.

Die zweite ist die Frage nach der Tiefe: Wie viele Prüfer stapele ich für dieselbe Eigenschaft übereinander? Und die wird nicht über Geld gestoppt, sondern über etwas anderes.

Das ist die Begründung für einen Merksatz, der den ganzen Post trägt:

Pareto auf der Breite, nie auf der Tiefe.

Auf der Breite darfst du sparen, das ist die ehrliche ökonomische Abwägung. In der Tiefe sparst du nicht aus Geiz, sondern hörst auf, wenn Unabhängigkeit erschöpft ist. Was du nie tust, ist eine einzelne abgesicherte Eigenschaft halb prüfen.

Drei Zonen, in denen Pareto nichts zu suchen hat

Die Stopp-Regel rechnet mit Erwartungswerten: Wahrscheinlichkeit mal Schaden. Das funktioniert, solange beide Größen sich halbwegs schätzen lassen. An drei Stellen tut es das nicht, und dort ist die Erwartungswert-Rechnung das falsche Werkzeug.

• Irreversibilität. Manche Defekte haben keinen begrenzten Schaden. Eine gelöschte Produktionstabelle, ein ausgezahlter Betrag, ein Event, das schon andere Systeme ausgelöst hat. Hier hilft kein „selten mal Wahrscheinlichkeit“, weil der Tail ruinös ist. Gegen diese Klasse rechnest du nicht, du machst sie strukturell unmöglich: Der Agent bekommt gar nicht erst die Rechte, eine Migration auf der Produktion anzuwenden. Das ist Vorsorge statt Erwartungswert, und es ist der Grund, warum T3 ein menschliches Gate trägt.
• Unknown unknowns. Manche Defektklassen kennst du noch nicht, also kannst du sie nicht gaten, ein Gate braucht eine bekannte Fehlerform. Die fängst du nicht vorab ab, die managst du: Observability, die anschlägt, wenn etwas Unerwartetes passiert, und ein Weg, das Beobachtete hinterher in ein neues Gate zu falten. Dazu gleich mehr.
• Der Intent-Abgrund. Ob die Spec überhaupt das Richtige will, kann kein Gate beantworten. Das war die Grenze aus Teil 2 und Teil 4, und sie bleibt menschlich. Pareto sagt dir, wie gründlich du prüfst, ob der Code die Spec trifft. Es sagt dir nichts darüber, ob die Spec das Gewollte trifft.

Diese drei Zonen sind keine Randnotiz, sie sind die teuren Fälle. Und das schärft, was Pareto überhaupt regelt: nicht „wie viel Qualität insgesamt“, sondern die Verifikationstiefe im reversiblen Mittelfeld. Wo der Schaden begrenzt und schätzbar ist, rechnest du. Wo er es nicht ist, rechnest du nicht, sondern machst ihn strukturell unmöglich oder gibst ihn an einen Menschen. Das ist kein Selbstwiderspruch, das ist die eigentliche Aussage: Rechne, wo Rechnen erlaubt ist, und mach unmöglich, wo Rechnen versagt.

Was der Käfig kauft

Bis hierhin ging es darum, wo du die Gates setzt. Jetzt die Frage, ob sich das Ganze rechnet. Und die zerfällt in zwei Teile, die man gern verwechselt: was der Käfig einbringt und was er kostet.

Zuerst: Was der Käfig kauft, ist nicht überall dasselbe. Bei T0 und T1, wo der Merge automatisch läuft und der Agent sich selbst prüft, kauft der Käfig Tempo. Die Änderung geht durch, ohne dass ein Mensch sie je ansieht. Bei T2 und T3 holst du den Menschen an beiden Enden zurück, beim Spec-Review vorne und am Merge-Gate hinten. Dort kauft der Käfig nicht Tempo, sondern Sicherheit. Das ist kein Webfehler, das ist die richtige Priorität: Bei einer Migration soll der Mensch der Engpass sein. Irreversibel schlägt schnell. Eine Domäne, die fast nur aus T3 besteht, wird sich langsam anfühlen, und das ist korrekt, nicht kaputt.

Und der Ertrag? Hier widerstehe ich der Versuchung, dir erfundene Zahlen hinzulegen. Das Argument ist stärker, wenn es über die Gestalt läuft, nicht über Werte.

Das deckt sich mit dem, was außerhalb dieser Serie gemessen wird. Der DORA-Report 2024 fand, dass mehr KI-Einsatz die Doku-Qualität leicht hebt, aber die Delivery-Stabilität senkt, unter anderem, so eine plausible Lesart, weil KI größere Change-Batches begünstigt. Mehr Generator ohne mehr Struktur macht es schlechter, nicht besser. Das bestätigt die Diagnose dieser Serie, nicht ihre Therapie: dass der Generator allein nicht trägt. Dass ausgerechnet gestaffelte Gates die richtige Antwort darauf sind, bleibt die Wette, die diese Serie eingeht.

Was der Käfig kostet: Bau, Betrieb, Wartung

Bau ist billiger, als es klingt. Die Boden-Gates werden konfiguriert, nicht geschrieben. tsc, der Mutations-Runner, die Architektur- und Pattern-Wächter sind Massenware, die du montierst, nicht Maßanfertigung. Den Boden baust du nicht, du stellst ihn auf.

Betrieb ist die unterschätzte Rechnung. CI-Minuten (die kosten echtes Geld), der Durchsatz der Merge-Queue, die Latenz pro Rückkante-Runde, flaky Tests, die Pflege der Ratchets, die Frage, wer auf den Alarm reagiert. Tier-Staffelung dämpft das (nicht jede Änderung zahlt den vollen Preis), macht es aber nicht weg: Ein einziger flaky Test am Queue-Head rollt einen ganzen Batch zurück, und „wer reagiert auf den Alarm“ ist im Solo-Repo trivial, im Acht-Team-Setup ein eigener Job. Ab einer gewissen Größe ist der Betrieb des Käfigs eine laufende Investition, kein Restposten. Das gehört ehrlich auf die Rechnung, nicht weggeredet.

Wartung ist Dazulernen, nicht Fron. Jedes Leck, das die Observability findet, wird zum nächsten Gate. Der Käfig wächst mit der Domäne, statt einmal teuer fertiggebaut zu werden. Das ist keine zusätzliche Kostenart, das ist die Rest-Management-Schleife selbst, und sie macht den Käfig mit der Zeit besser, nicht teurer.

Auch die Eindämmung hat ein Pareto

Bis hier ging es um Korrektheits-Gates. Die andere Achse aus Teil 5, die Eindämmung, kostet auch, nur in einer anderen Währung: Reibung.

In Teil 5 habe ich dir versprochen, hier sei der Ort, an dem diese Abwägung kippt. Erinnerst du dich an den ersten Obol-Lauf? Die Sandbox sperrte den Schlüssel der Agenten-Identität aus und ließ die API-Domain nicht durch. Die Eindämmung tat ihre Arbeit, und sie kostete mich spürbar Zeit, bis die Schichten aufeinander abgestimmt waren. Zu eng ist nicht gratis: Ein Agent, der ständig an Grenzen stößt, die er für seine legitime Arbeit braucht, bekommt nichts fertig.

Nur ist die Eindämmung kein einheitliches Pareto, und das ist die wichtige Unterscheidung. Bei den kritischen Rechten gibt es keine Abwägung: der Pfad zur Produktions-Datenbank, die Egress-Allowlist, das Recht, Geld zu bewegen. Das sind Tiefe und Zone 1, der Schaden im Kompromiss-Fall ist unbegrenzt, also rechnest du nicht, du machst ihn unmöglich. Eine Egress-Allowlist mit einem Loch ist keine halbe Allowlist, das ist die halbe Hülle vom Anfang.

Die Pareto-Abwägung bleibt für die bequemen Rechte: Welche Lese-APIs gibst du großzügig frei, welche Tools darf der Agent ohne Rückfrage rufen? Dort wägst du Reibung gegen Risiko ab, genau wie bei der Breite der Gates. Least Privilege heißt also nicht „so wenig Rechte wie technisch möglich“, sondern: die gefährlichen gar nicht, die harmlosen großzügig, und nur dazwischen die ehrliche Rechnung.

Obol als gelebtes Pareto

Genug Theorie, schauen wir auf das echte Repo. Obols Risiko-Staffel steckt in einer kleinen Datei, und sie ist bewusst kurz:

{
  "T3": ["services/*/migrations/**", "**/auth/**", "packages/contracts/**", "tools/**"],
  "T2": ["services/**"],
  "T1": ["**"]
}

Lies sie von unten nach oben. Alles ist erst mal T1, der billige Boden. Normaler Service-Code ist T2, bekommt also ein unabhängiges Review obendrauf. Und vier Dinge sind T3: Migrationen, alles unter auth, die Event-Contracts zwischen den Services und, das ist die feine Pointe, tools/ selbst, also die Gate-Logik. Wer die Wächter ändert, löst das höchste Tier aus. Der Käfig stuft seine eigene Bauanleitung als das Riskanteste ein, was es gibt.

Diese Staffelung ist nicht nur konfiguriert, sie wurde im Pilotbetrieb auch schon teuer gelernt. An einer Stelle war das Merge-Gate zwischenzeitlich tier-blind: Es verlangte für jeden Merge ein menschliches Approval, egal welche Risikoklasse. Klingt sicher, war aber ein Eigentor. Denn damit verlor T1 seinen automatischen Merge, und die Tempo-Hälfte der ganzen These fiel weg. Selbst die billigste Doku-Änderung wartete plötzlich auf einen Menschen, der Engpass für triviale Arbeit war zurück. Der Fix war, das Gate das Tier wieder lesen zu lassen: T1 läuft automatisch durch, T2 verlangt ein Review, T3 das menschliche Gate. Ein Wächter, der das Risiko nicht kennt, kollabiert die ganze Staffel auf „alles maximal“, und genau das frisst den Durchsatz, den die Staffelung kaufen soll.

Und es blieb nicht bei diesem einen Gate. Dieselbe Tier-Blindheit, ein Wächter, der das Risiko zwar ableitet, aber nicht nutzt, tauchte im Piloten gleich mehrmals an verschiedenen Stellen der Kette wieder auf, jedes Mal mit demselben Effekt: die Staffel kollabiert auf „alles maximal“. Das ist die eigentliche Lehre. Tier-Blindheit ist kein einmaliger Ausrutscher, sondern eine Fehlerform, die an jeder Naht neu entstehen kann, an der ein Gate sitzt, und die man dort jedes Mal aufs Neue schließt.

(Ehrlich bleibt auch hier: Dass T1 in Obol ohne Approval durchläuft, ist vertretbar, weil Obol ein Referenz-Repo ist, kein Produkt mit echten Nutzern. In einer echten Produktion zieht man den Boden eine Stufe höher.)

Das Gegenbild: die Bullshit Factory

Was passiert, wenn man die Staffelung ganz weglässt und nur den Generator aufdreht, hat außerhalb dieser Serie schon einen Namen. Das ist kein Obol-Befund, sondern eine Beobachtung aus einem anderen Mayflower-Artikel (AI Dark Factory Patterns), und sie taugt als Kontrast gut.

Der Name ist die Bullshit Factory: hoher Output ohne Validierung, das genaue Gegenteil des gestaffelten Käfigs. Spannend an derselben Quelle ist die Quality Inversion: ab einer gewissen Komplexität schlägt das automatische Gate den menschlichen Review, weil der Mensch ermüdet und die Maschine nicht.

Das ist von außen genau die Tier-Asymmetrie dieses Posts: Die billige, unermüdliche Prüfung trägt den Boden, der Mensch kommt nur dort zurück, wo es irreversibel wird.

„Good enough“ ist die nächste Fluchttür

Eine Warnung zum Schluss, denn dieser ganze Post öffnet eine Tür, die ein Agent zu nutzen weiß.

„Pareto“, „good enough“, „das lohnt sich hier nicht“ sind die nächste Fluchttür, das neue .skip. Ein Produzent, dessen Belohnung grün ist, hat allen Grund, eine Änderung als T0 auszugeben, die eigentlich T3 ist, und sich auf „wir staffeln doch“ zu berufen. Genau deshalb gilt für die Schwelle dasselbe wie für jedes Gate aus Teil 3: Sie gehört in den geschützten Satz, nicht in die Hand des Produzenten. Das Tier wird aus dem Pfad abgeleitet, die Ableitung selbst steht unter CODEOWNERS, und eine Änderung an der Tier-Regel ist, du ahnst es, T3. „Good enough“ ist eine Entscheidung der Harness, nie des Agenten.

Was du mitnimmst

„Good enough“ ist keine Eigenschaft des Codes, sondern eine Eigenschaft des Kostenverlaufs. Perfektion war nie das Ziel. Die Frage ist nicht „ist das gut genug geprüft?“, sondern „kostet die nächste Prüfung weniger, als sie im Mittel verhindert?“. Und die Antwort hängt davon ab, was die Änderung berührt.

In der Tiefe alles oder nichts, in der Breite gestaffelt: Auf der Breite stoppt dich die Ökonomie, in der Tiefe die Unabhängigkeit. Drei Zonen nimmst du aus der Rechnung, weil ihr Schaden nicht beschränkt ist. Und die Schwelle selbst hältst du dem Produzenten aus der Hand.

Und weiter?

Du hast jetzt einen Käfig, der sich rechnet, gestaffelt nach Risiko, gestoppt an der richtigen Stelle, getrieben bis an die ökonomisch sinnvolle Grenze.

Und selbst an dieser ausgereizten Grenze bleibt etwas übrig. Ein Rest, den keine Verifikation je erreicht, egal wie viel du baust. Nicht, weil dein Käfig zu billig wäre, sondern weil manche Fragen sich grundsätzlich keinem Gate beugen. Drei davon hast du gerade als Zonen kennengelernt, in denen Pareto nichts zu suchen hat. Sie waren nur die Vorboten.

Um diesen Rest, und um den Menschen, der an ihm sitzt, geht es in Teil 7: Warum der wichtigste Teil dem Menschen gehört.