Fünf Loop-Muster für KI-Agenten, und warum das Erzeugen nie der Engpass war

Ein Prompt erzeugt einen Versuch. Eine Schleife erzeugt Versuche, bis ein Kriterium hält. Das klingt nach einer kleinen Änderung, ist aber eine kategorische: Sobald der Agent mehr als einmal läuft, braucht jemand eine Antwort auf zwei Fragen, die vorher der Mensch beiläufig beantwortet hat: ist das gut genug und wann hören wir auf.

Genau da entscheidet sich, ob eine Schleife etwas taugt. Nicht am Modell, nicht am Prompt, sondern an dem Teil, den man beim Bauen am liebsten überspringt: dem Bewerter.

Dieser Artikel sortiert die fünf Loop-Muster, die sich in der Praxis herausgeschält haben, und hält sie anschließend gegen ein System, das seit Monaten produktiv läuft. Die beiden Befunde daraus sind unbequemer als die Muster selbst.

Was ein Loop überhaupt ändert

Zwei Bauarten sind zu unterscheiden, und die Verwechslung kostet Geld.

Deterministisch heißt: Die Orchestrierung ist geskriptet. Ein Programm entscheidet, was als Nächstes läuft, wie oft und in welcher Reihenfolge; das Modell füllt nur die einzelnen Schritte. Der Ablauf ist damit reproduzierbar und die Kosten sind vorher abschätzbar. Die Ergebnisse nicht, denn das Modell bleibt in jedem einzelnen Schritt nicht-deterministisch.

Nicht-deterministisch heißt: Das Modell entscheidet selbst, was der nächste Schritt ist. Flexibler, und für offene Aufgaben oft der einzige Weg. Aber ohne harte Abbruchbedingung läuft so etwas gern länger, als jemandem lieb ist.

Alle fünf Muster unten gibt es in beiden Bauarten. Was sie voneinander unterscheidet, ist nicht die Technik, sondern wohin der Rückweg zeigt.

Die fünf Muster

Vier der fünf schließen sich auf die Arbeit: Das Ergebnis wird geprüft und neu angefasst. Nur das fünfte schließt sich auf den Ablauf. Es verbessert nicht das Ergebnis, sondern die Art, wie das Ergebnis zustande kommt. Deshalb steht seine Rückkante gestrichelt.

① Stateless: läuft, bis es hält

Die simpelste Form: Dieselbe Aufgabe läuft wieder und wieder, bis sie als erledigt gilt. Zwischen den Runden bleibt nichts zurück, weder Gedächtnis noch akkumulierte Erkenntnis. Der Reiz liegt genau darin: Es gibt keinen Zustand, der verderben kann.

Die Schwachstelle steckt im Wort gilt. Wenn der bauende Agent selbst entscheidet, wann er fertig ist, ist die Abbruchbedingung eine Meinung. Zwei Härtungen machen daraus ein Kriterium: Die Tests entstehen vor dem Bau, und ein zweites, kleineres Modell prüft das Ergebnis gegen die ursprüngliche Anforderung, nicht gegen die Behauptung des ersten, fertig zu sein.

Das kleinere Modell spart nebenbei Kosten; der eigentliche Punkt ist aber die Trennung der Rollen. Ein Prüfer, der ein Ergebnis gegen eine Anforderung hält, arbeitet an einer engeren Aufgabe als der Erzeuger. Kontext und Urteilsvermögen braucht er trotzdem, und in manchen Domänen ist Bewerten das Schwerere von beidem. Wie klein er ausfallen darf, ist eine Abwägung und keine Regel.

② Learning: verbessert die Fähigkeit, nicht das Ergebnis

Hier ist das Artefakt nicht das Ziel. Das Ziel ist die Fähigkeit, die das Artefakt erzeugt hat. Der Loop lässt sie laufen, beobachtet, und schreibt die Lehren in ein Journal, das die nächste Runde liest.

Der entscheidende und meist weggelassene Teil ist der Doppellauf: einmal mit, einmal ohne die Fähigkeit, dieselbe Aufgabe. Ohne diesen Vergleich sammelt man Behauptungen darüber, dass etwas hilft. Mit ihm hat man eine Messung.

Das Journal gehört dabei zur Fähigkeit, nicht in eine zentrale Ablage. Eine Lehre, die nicht dort liegt, wo sie gebraucht wird, wird nicht gelesen.

③ Multi-Agent-Review: mehrere Kritiker statt eines Prüfers

Statt eines Reviewers laufen mehrere parallel über dasselbe Artefakt, jeder mit einem eigenen Blickwinkel: Fakten, Fachlichkeit, Sicherheit, Stil. Die Befunde laufen zusammen, werden zu Änderungen, und die nächste Runde beginnt.

Der Wirkstoff sind die getrennten Blickwinkel. Vier gleich aufgestellte Kritiker liefern nicht etwa viermal exakt dieselbe Liste; dafür sorgt schon das Sampling. Sie teilen aber ihre blinden Stellen, und die bleiben dann zuverlässig unentdeckt, während die schiere Zahl der Durchgänge Absicherung suggeriert. Vier Stimmen, die dieselbe Frage stellen, sehen aus wie Konsens. Andrej Karpathy hat die Variante mit mehreren Modellen, die sich gegenseitig bewerten, unter dem Namen LLM council bekannt gemacht.

④ Verification: einer baut, einer benotet

Kein Fächer, sondern ein Gegenüber. Ein Agent implementiert, ein zweiter bewertet gegen eine Metrik und gibt eine Note zurück. Der Bauende hat genau einen Auftrag: die Note hochtreiben.

Zwei Details tragen das Muster. Erstens braucht der Bewerter einen Maßstab: eine Spezifikation, eine Rubrik, eine Testsuite. Ohne den bewertet er sein eigenes Bauchgefühl. Zweitens fehlen ihm die Werkzeuge zum Editieren, und das ist kein Versehen: Wer bewerten und zugleich reparieren darf, bewertet milder. Cursor liefert eine besonders strenge Ausprägung davon als Skill in seinem Team-Kit aus: thermo-nuclear review, in zwei Zuschnitten für Codequalität sowie für Sicherheit und Korrektheit. Beide laufen als eigene Subagenten parallel, ihre Befunde werden anschließend zusammengeführt.

⑤ Workflow-Improvement: der Loop verbessert den Loop

Der einzige, dessen Rückweg nicht auf die Arbeit zeigt. Drei Rollen: Ein Builder liefert, ein Scorer benotet gegen eine Rubrik, ein Process-Optimizer ändert daraufhin den Ablauf: die Reihenfolge der Schritte, die Aufteilung der Rollen, die Rubrik selbst.

Das ist der mächtigste und der heikelste der fünf. Mächtig, weil er das Einzige angreift, was die anderen vier unangetastet lassen. Heikel, weil ein Prozess, der sich selbst umschreibt, per Definition den Zustand verlässt, den jemand einmal freigegeben hat.

Welches Muster wann

Die Auswahl hängt an einer einzigen Frage: Gibt es einen harten Maßstab? Wenn ja, also eine Testsuite, ein Schema oder ein Compiler, dann braucht es keinen bewertenden Agenten, und die einfachste Schleife genügt. Erst wenn die Qualität nicht mechanisch prüfbar ist, lohnt sich ein Bewerter, und erst dann stellt sich die Frage nach seiner Bauart.

Der Test: fünf Muster gegen ein laufendes System

Muster sind billig zu beschreiben. Interessant wird es, wenn man sie gegen etwas hält, das wirklich läuft. Wir haben das mit unserem eigenen Agenten-Substrat gemacht, also dem Repo, aus dem heraus wir bei BKS-Lab arbeiten. Nicht als Gedankenspiel, sondern belegt: jede Zeile in der folgenden Übersicht hat eine Datei oder eine Messung hinter sich.

Zwei Muster sind da, zwei halb, eines gar nicht. Bemerkenswert ist weniger die Lücke als ihre Art. Alle Lern-Mechanismen in diesem System greifen nach der Arbeit: Der Rückblick am Ende einer Aufgabe, der periodische Audit, die Konsolidierung. Keiner greift währenddessen. Und die A/B-Messung aus Muster ②, der Teil, der aus Behauptung Messung macht, die gibt es nirgends. Ein Grep über das gesamte Repo nach A/B, Ablation, Baseline liefert keinen echten Treffer.

Das ist die Sorte Befund, für die man die Muster überhaupt aufschreibt. Ohne den Raster hätte niemand gefragt, ob es einen Loop gibt, der während der Arbeit lernt.

Befund 1: Der Bewerter ist der Loop

Beim Bauen der Diagramme für diesen Artikel lief das dritte Muster gegen die Seite selbst: drei unabhängige Kritiker, jeder mit einer eigenen Linse, alle über dasselbe Artefakt. Das Ergebnis war so ungleich, dass es zum eigentlichen Befund wurde.

Die Linse, die auf Fakten und Ton sah, fand nichts. Sie bestätigte. Die Linse, die das Ergebnis gegen die Quelle hielt, fand einen echten Fehler. Die messende Linse fand acht, mit Zahlen.

Zwei davon lagen für die ersten beiden Linsen praktisch außer Reichweite, und zwar nicht weil sie schlechter gearbeitet hätten, sondern weil sie diese Frage gar nicht erst stellten:

Die Umrisse der Diagrammkästen lagen bei einem Kontrastverhältnis von 1,18:1 gegen den Hintergrund. Die WCAG fordern für grafische Objekte, die zum Verständnis nötig sind, 3:1. Da die Legende die Kastenform ausdrücklich zur Bedeutung erklärt (durchgezogen heißt vorhanden, gestrichelt heißt fehlend), war der Rand tragend und nicht Dekoration. In einer Zeitleiste war dadurch das erste Segment praktisch unsichtbar, obwohl die Bildunterschrift „Breite = Laufzeit“ versprach.

Und die kleinste Beschriftung fiel real auf 8,51 Pixel, sobald die Mindestbreite der Grafik griff, also auf jedem Laptop unter etwa 1230 Pixel Breite und auf jedem Telefon.

Das sind keine Geschmacksfragen. Beide Befunde lassen sich mit einer Zahl belegen, und beide bleiben unsichtbar für einen Prüfer, der nach Sachfehlern und Tonlage sucht.

Daraus folgt eine Regel, die uns einiges erspart hätte: Ein Review ohne Befunde ist kein Gütesiegel, sondern ein Anlass, die Linse zu prüfen. Wenn ein Kritiker nichts findet, ist die erste Frage nicht „ist es gut“, sondern „konnte diese Linse überhaupt etwas finden“.

Ehrlicherweise gehört die Fortsetzung dazu: Beim Nachziehen derselben Korrektur für diesen Artikel stellte sich heraus, dass exakt derselbe Fehler ein zweites Mal in denselben Dateien steckte, nicht in den Kästen, sondern in den Verbindungspfeilen. Wir hatten die Kästen repariert und die Pfeile stehen lassen. Weder der messende Kritiker noch wir hatten danach gesehen. Eine Linse, die einmal etwas findet, findet nicht automatisch alles derselben Art.

Befund 2: Erzeugen läuft, Entscheiden staut

Der zweite Befund kam ungefragt und ist der unangenehmere.

Das System erzeugt Verbesserungsvorschläge über drei verschiedene Mechanismen. Jeder legt seine Vorschläge als Klartext-Datei in einen Ordner, aus dem ein Mensch sie annimmt oder ablehnt. Das ist die bewusst gesetzte Bremse: Der Agent schlägt vor, der Mensch entscheidet.

Fünf Vorschläge liegen unentschieden in der Warteschlange. Der älteste liegt dort seit dem 24. Mai, also knapp acht Wochen. Über die Laufzeit wurden acht angenommen und fünf abgelehnt, das Verfahren funktioniert also grundsätzlich. Aber der Stau sitzt nicht beim Erzeugen.

Das hat eine unmittelbare Konsequenz für die naheliegendste Reaktion auf diesen ganzen Artikel. Wer jetzt einen weiteren Lern-Loop baut, vergrößert die Warteschlange und löst nichts. Bevor man einen Generator hinzufügt, misst man die Warteschlange.

Ein Detail am Rande, das denselben Punkt trifft: Der Ordner, in dem dieses System seine Trend-Historie sammeln sollte, ist leer. Die beobachtende Hälfte des Lern-Loops hat nie Daten gesammelt, nicht weil sie kaputt wäre, sondern weil niemand sie je angestoßen hat. Ein Mechanismus, den niemand vermisst, wenn er nicht läuft, läuft irgendwann nicht mehr.

Und noch etwas: Der älteste unentschiedene Vorschlag beschreibt sinngemäß, dass Fähigkeiten mit Nachschlagetabellen einen Lern-Loop brauchen. Also genau das, was Muster ② beschreibt. Der Vorschlag lag zwei Monate herum, bevor uns die Systematik dazu über den Weg lief. Das Wissen war da. Die Entscheidung fehlte.

Was eine offene Schleife kostet

Eine Schleife ohne funktionierende Abbruchbedingung ist kein theoretisches Risiko. Ein Loop in unserem System hatte eine Obergrenze für seine Runden und einen Zähler, der sie hochzählen sollte. Nur zählte er nicht.

Vierzig bezahlte Durchläufe bei Zählerstand null, bevor es jemandem auffiel. Nach der Reparatur: drei Durchläufe, dann geparkt und ein Mensch benachrichtigt. Das ist kein gerechnetes Beispiel, sondern ein protokollierter Vorfall aus dem eigenen Betrieb.

Die Lehre ist unspektakulär und wird trotzdem ständig übersprungen: Die Abbruchbedingung ist nicht der langweilige Teil des Loops. Sie ist der Teil, der die Rechnung schreibt.

Die Grenze, die wir nicht überschritten haben

Bleibt Muster ⑤, der Loop, der den Loop verbessert. Wir haben ihn nicht gebaut, und der Grund ist keine technische Hürde.

Die Betriebsregel unseres Systems sagt, dass Beobachtungen und Trends vorschlagen, aber nicht anwenden. Jede dauerhafte Änderung am System geht durch ein menschliches Gate. Ein Process-Optimizer, der seine eigenen Schlüsse umsetzt, bricht diese Regel per Konstruktion.

Es gibt zwei ehrliche Lesarten. Eng gefasst wirkt der Optimizer nur innerhalb eines einzelnen Laufs, schreibt keine Datei und schickt seine Erkenntnis als Vorschlag durch dasselbe Gate wie alles andere, und die Regel bleibt intakt. Weit gefasst schreibt er selbst, und dann ist die Regel gefallen, egal wie man es nennt.

Das ist eine Haltungsfrage, keine Technikfrage, und sie ist bei uns bewusst offen. Wir schreiben sie hier hin, statt sie zu übergehen: Wer Loops baut, die sich selbst umbauen, sollte vorher wissen, welche Zusage er damit aufgibt.

Wo das alles überhaupt sichtbar wurde

Beide Befunde oben haben eine unauffällige Gemeinsamkeit, und die ist wichtiger als die Befunde selbst.

Wir konnten die Warteschlange zählen, weil sie eine Warteschlange ist: fünf Markdown-Dateien in einem Ordner, mit Datum im Dateinamen. Wir konnten sagen, dass die Trend-Historie leer ist, weil sie ein Verzeichnis ist, das man auflisten kann. Wir konnten belegen, dass die A/B-Messung fehlt, weil ein Grep über ein Repo eine belastbare Aussage ergibt. Und die vierzig bezahlten Läufe stehen in einem Protokoll, das jemand nachlesen kann.

Nichts davon wäre in einem gehosteten Dienst mit einem Dashboard sichtbar gewesen, das genau die Metriken zeigt, die sich jemand vorher ausgedacht hat.

Das Substrat, auf dem unsere Agenten arbeiten, ist deshalb bewusst langweilig: ein Git-Repository aus Markdown und YAML, das der Agent zu Beginn jeder Session liest und im Lauf der Arbeit beschreibt. Keine Datenbank, kein Daemon, nichts zu hosten. Der Zustand des Systems ist eine Menge von Dateien, die man klonen, diffen und zählen kann. Und ein Loop, dessen Ausgabe in solchen Dateien landet, ist von außen prüfbar, statt nur behauptet zu sein.

Wir haben dieses Substrat unter MIT-Lizenz veröffentlicht: open-bridge. Es ist bei BKS-Lab entstanden, um BKS-Lab zu betreiben, und es ist genau das Repo, dessen Warteschlange, leeres Trend-Verzeichnis und protokollierte vierzig Läufe in diesem Artikel vorkommen. Was es ist, wie es aufgebaut ist und wo es ehrlicherweise noch dünn ist, steht ausführlich im Artikel zur Freigabe.

Wer die fünf Muster hier interessant fand, braucht dafür kein bestimmtes Substrat. Aber irgendeinen Ort, an dem die Ausgabe der Schleife liegen bleibt und zählbar wird, braucht man. Sonst baut man Loops, deren Nutzen sich nie belegen lässt, und merkt den Stau erst, wenn er acht Wochen alt ist.

Quellen

• Die hier verwendete Sortierung in fünf Loop-Typen folgt der Darstellung von AI LABS, Loop Engineering Just 10x Claude Code (Juli 2026): youtube.com/watch?v=8wsM0euQOvc. Die Bestandsaufnahme, beide Befunde und alle Zahlen in diesem Artikel stammen aus unserem eigenen System.
• LLM council, Andrej Karpathy: github.com/karpathy/llm-council
• thermo-nuclear review, Cursor Team Kit: github.com/cursor/plugins und cursor.com/marketplace
• WCAG 2.2, Erfolgskriterium 1.4.11 „Non-text Contrast“ (3:1 für grafische Objekte): w3.org/WAI/WCAG22/Understanding/non-text-contrast
• open-bridge, MIT-lizenziert: github.com/bks-lab/open-bridge · Doku: bks-lab.github.io/open-bridge