loop-engineering: Ein Musterkatalog für Agenten-Loops statt Prompt-Handwerk

Welches Problem der Musterkatalog adressiert

Der Ausgangspunkt ist eine Beobachtung über die Arbeitsweise mit Coding-Agenten: Wer Claude Code, Codex oder Grok einzeln aufruft, schreibt bei jeder Aufgabe einen neuen Prompt. Das Repository nennt das den Gegensatz zu dem, was es anbietet. Statt zu prompten, soll ein System entworfen werden, das Arbeit selbst findet, sie an Agenten übergibt, Ergebnisse prüft und Zustand speichert. Die Zielgruppe sind nach der Beschreibung Teams, die wiederkehrende Aufgaben rund um eine Codebasis haben: offene Issues, CI-Fehler, veraltete Abhängigkeiten, Pull Requests, die betreut werden müssen. Die Tabelle in docs/jobs.md ordnet diesen Aufgaben konkrete Einstiegspunkte zu. Wer dagegen ein Werkzeug sucht, das ein Modul auf Zuruf umschreibt, wird im README ausdrücklich abgewiesen: Es sei keine solche Taste, sondern eine Musterbibliothek für den Betrieb von Agenten um eine Codebasis herum.

Der Loop als System: Entdecken, Übergeben, Verifizieren, Speichern

Die Architektur ist als Kreislauf beschrieben, nicht als einzelner Aufruf. Ein Loop entdeckt Arbeit, übergibt sie an einen Agenten, verifiziert das Ergebnis und persistiert Zustand. Der persistierte Zustand liegt in einer Datei namens STATE.md, die im Repository mitgeführt wird. Die Patterns unterscheiden sich vor allem in Taktung und Kosten. Daily Triage läuft im Abstand von einem Tag bis zwei Stunden und startet in Woche eins als L1-Report. PR Babysitter läuft alle fünf bis fünfzehn Minuten und ist in der Kostenspalte als hoch eingestuft. CI Sweeper teilt sich dieselbe Taktung, startet aber als L2 und ist als sehr teuer markiert. Dependency Sweeper läuft alle sechs bis vierundzwanzig Stunden und bleibt zunächst auf Patches beschränkt. Diese Einordnung ist der eigentliche Inhalt des Katalogs: Die Frequenz bestimmt, wie oft ein Modell aufgerufen wird, und damit direkt die Rechnung.

Reifegrade L1 bis L3 und die Gewichtung des Loop Ready Score

Das Projekt arbeitet mit drei Stufen. L1 bedeutet Bericht, L2 bedeutet Unterstützung mit Prüfung, L3 bedeutet unbeaufsichtigter Betrieb. Der empfohlene Weg ist ausdrücklich sequenziell: erst nach einer Woche, in der der Verifier zuverlässig richtig lag, darf die nächste Stufe folgen. Die Begründung steht im Repository selbst: Unbewachte Loops machen unbeaufsichtigte Fehler. Bemerkenswert ist eine Änderung am Bewertungsmaßstab. Der Loop Ready Score gewichtet laut README aktuelle Läufe stärker als Dateien auf der Festplatte. Eine dreißig Tage alte STATE.md gilt damit nicht mehr als Nachweis für L3. Das ist eine sinnvolle Korrektur an einer naheliegenden Fehlannahme, denn eine Zustandsdatei zu besitzen ist nicht dasselbe wie einen funktionierenden Loop zu betreiben.

Erste Schritte mit init, doctor und cost

Der Einstieg ist als Fünf-Minuten-Pfad beschrieben und besteht aus zwei Befehlen. Zuerst npx @cobusgreyling/loop init . --pattern daily-triage --tool claude, danach npx @cobusgreyling/loop doctor . Der Parameter --tool ist optional und fällt auf claude zurück; alternativ sind grok, codex und opencode vorgesehen. Für die Kostenplanung gibt es npx @cobusgreyling/loop cost --pattern daily-triage --level L1. Die CLI hat laut README fünf Unterbefehle: init, doctor, status, audit und cost. Ältere Einzelpakete wie loop-init und loop-audit bleiben weiterhin unterstützt, was für bestehende Installationen relevant ist. Wer ohne Zustandsdatei arbeiten will, findet unter starters/thin-loop/ einen Starter für GitHub Actions, der laut Beschreibung kein STATE.md benötigt. Ein vollständiger Durchlauf von einem leeren Repository bis zur ersten STATE.md ist als Skript scripts/empty-to-state-demo.sh hinterlegt.

Kosten und Fehlermodi: die offenen Stellen der Dokumentation

Das README benennt die Risiken selbst. Token-Kosten können explodieren, und Loop Engineering verstärkt Urteilsvermögen, aber eben auch Fehlurteile. Die Kostenspalte der Pattern-Tabelle ist grob gerastert (niedrig, mittel, hoch, sehr hoch) und nennt keine Zahlen. Wer ein Budget planen muss, bekommt aus dem Repository keine belastbare Grundlage außer dem cost-Befehl, dessen Ausgabe von der eigenen Konfiguration abhängt. Verweise auf docs/failure-modes.md und docs/anti-patterns.md existieren, der Inhalt dieser Dateien ist im vorliegenden Material jedoch nicht enthalten. Ob dort konkrete Abbruchbedingungen oder Rollback-Schritte beschrieben sind, lässt sich von hier aus nicht beurteilen. Das ist die größte Unsicherheit für alle, die einen Loop unbeaufsichtigt laufen lassen wollen.

Abgrenzung zu einfachen GitHub-Action-Skripten

Die naheliegende Alternative ist ein gewöhnlicher geplanter Job, etwa ein Cron-Workflow, der ein Skript ausführt und ein Issue öffnet. Der Unterschied liegt nicht im Auslöser, sondern im Zustand und in der Prüfstufe. Ein Skript hat keinen STATE.md, es weiß beim nächsten Lauf nicht, was es zuvor entschieden hat, und es kennt keine Unterscheidung zwischen Bericht und unbeaufsichtigter Aktion. Das vorliegende Projekt setzt genau dort an: Der Verifier und die L-Stufen sind der Mechanismus, der einen Agenten-Lauf von einem Skriptlauf unterscheidet. Wer allerdings nur einen nächtlichen Bericht über offene Issues braucht, für den ist der schlanke Starter unter starters/thin-loop/ die passendere Wahl, weil er laut Beschreibung ohne Zustandsdatei auskommt. Der volle Katalog lohnt sich erst, wenn mehrere Loops nebeneinander laufen und sich einen Zustand teilen sollen.

Pflege, Versionen und Lizenz

Das Repository ist nicht archiviert und wurde zuletzt am 9. September 2026 aktualisiert. Die jüngsten Releases sind v1.6.0 vom 20. Juli 2026 mit der Notiz Foundry funnel + loop-gate und v1.5.0 vom 30. Juni 2026 mit der Notiz Community Tools Drop. Der Abstand zwischen den beiden Veröffentlichungen beträgt rund drei Wochen, was auf eine aktive Pflege hindeutet, ohne dass sich daraus ein Versprechen für die Zukunft ableiten lässt. Die Lizenz ist MIT, was die Nutzung und Weitergabe mit urheberrechtlichem Hinweis erlaubt. Wer den Code in ein eigenes Produkt einbettet, sollte dennoch prüfen, ob die im Repository genannten Begleitprojekte wie memory-engineering, harness-foundry oder outerloop unter derselben Lizenz stehen; das Material sagt dazu nichts. Das README rät ausdrücklich davon ab, diese Begleitprojekte hinzuzunehmen, bevor ein Loop tatsächlich gelaufen ist.

Redaktionelles Fazit

Wer wiederkehrende Repository-Arbeit wie Issue-Triage, Dependency-Updates oder CI-Auswertung regelmäßig von Hand erledigt, findet hier einen strukturierten Einstieg mit klaren Sicherheitsstufen. Wer eine schnelle Refactoring-Automatik sucht, ist falsch: Das README sagt ausdrücklich, das Projekt sei kein Knopf zum Umschreiben eines Moduls. Vor dem ersten unbeaufsichtigten Lauf sollte man die Failure-Modes- und Anti-Patterns-Dokumente lesen, den Verifier eine Woche im L1-Report-Modus beobachten und mit npx @cobusgreyling/loop cost --pattern daily-triage --level L1 die Token-Kosten gegen den Nutzen rechnen.

Offizielle Quellen

1. cobusgreyling/loop-engineering on GitHub
2. License: MIT
3. Project website
4. README
5. Releases