Loop Engineering: prüfen, korrigieren und aufhören
Ein Agent-Loop braucht mehr als Wiederholung. Ich zeige, wie Prüfungen, begrenzte Korrekturen und klare Stopps aus einem Dauerlauf verlässliche Arbeit machen.
TL;DR
Loop Engineering verbindet Arbeit mit einer Prüfung, die scheitern darf. Ein brauchbarer Loop kann gezielt korrigieren und erkennt, wann er fertig ist oder nicht weiterkommt. Für mich gehören deshalb Erfolgsbedingung, Budget und ein dokumentierter Stopp genauso zum Entwurf wie der nächste Modellaufruf.
Noch einmal ist kein Plan
„Mach weiter, bis alles passt“ klingt wie ein guter Auftrag an einen Coding-Agenten. Es verschiebt aber die entscheidende Frage: Woran erkennt er, dass es passt?
Ohne Antwort kann der Agent denselben Test wiederholen, einen anderen Test auswählen oder so lange am Ergebnis arbeiten, bis es ihm plausibel erscheint. Das produziert Aktivität. Ob dabei das eigentliche Problem kleiner wird, bleibt offen.
Ich beginne deshalb am anderen Ende. Welcher Zustand soll am Schluss nachweisbar gelten? Nicht „die Landingpage verbessern“, sondern beispielsweise: Die vereinbarten Inhalte sind in beiden Sprachen vorhanden, die Links führen zu den richtigen Zielen und die Seite bleibt auf einem kleinen Bildschirm bedienbar. Diese Prüfungen haben unterschiedliche Messwege. Keine einzelne davon ersetzt die anderen.
Loop Engineering braucht eine Rückmeldung
Anthropic unterscheidet in Getting started with loops unter anderem zielbezogene, zeitgesteuerte und proaktive Schleifen. Die Einteilung hilft bei der Auswahl. Für den konkreten Ablauf brauche ich zusätzlich eine Antwort auf die Frage, welche Beobachtung den nächsten Schritt verändert.
Auftrag → Arbeit → Prüfung
↑ |
| konkreter Befund
| |
+-- Korrektur erlaubt?
|
nein → Stopp mit Grund
Prüfung bestanden → Ergebnis festhalten → Ende
Eine solche Rückmeldung ist kein allgemeines „versuch es besser“. Sie nennt den geprüften Stand, den Fehler und das erwartete Verhalten. Ist eine Überschrift auf Mobile abgeschnitten, geht dieser Befund an die Darstellung zurück. Es braucht dafür keine neue Recherche und keinen neuen Artikel.
Ich trenne dabei zwei Rückwege. Ein Ergebnis kann mangelhaft sein, dann wird es korrigiert. Es kann aber auch die Annahme hinter dem Auftrag falsch sein, dann muss der Plan zurück. Wenn die gewünschte Schnittstelle eine Funktion gar nicht anbietet, hilft kein vierter Implementierungsversuch.
Retry, Reparatur und Termin sind verschiedene Dinge
Ein Retry wiederholt einen Aufruf nach einem vorübergehenden Fehler. Ein Reparatur-Loop verändert das Artefakt nach einem Befund. Ein zeitgesteuerter Lauf prüft später erneut, ob sich die Welt verändert hat. Diese Fälle sollten nicht dieselbe blinde Wiederholung auslösen.
Bei einer vorübergehend überlasteten API kann ein späterer Versuch sinnvoll sein. Fehlt eine Berechtigung, braucht es eine andere Aktion. Ist der Auftrag bereits ausgeführt worden und nur die Antwort verloren gegangen, könnte Wiederholen sogar eine zweite Außenwirkung erzeugen. Die Amazon Builders’ Library zu idempotenten APIs behandelt genau diese Grenze: wiederholte Aufrufe sollen nicht ungewollt wiederholte Ergebnisse erzeugen.
Für einen Agenten heißt das praktisch: erst Fehlerklasse und beobachteten Zustand klären. Danach entscheiden, ob Warten, Reparieren, Nachlesen oder Stoppen angebracht ist.
Ein konkreter Prüfvertrag
Für einen begrenzten lokalen Korrekturlauf würde ich vorab folgenden Vertrag festhalten. Die Zahlen sind ein Beispielbudget, keine gemessene optimale Einstellung:
Ziel: Die vereinbarte Darstellung besteht die festgelegten Prüfungen.
Scope: Nur die betroffene Komponente und ihre Sprachtexte.
Prüfung: Funktion, DE/EN-Parität und definierte Browseransichten.
Grenze: Höchstens zwei Korrekturrunden und 15 Minuten.
Stopp: Gleicher Fehler ohne neue Diagnose oder Scope-Erweiterung nötig.
Ergebnis: Geprüftes Artefakt oder offener Befund mit letztem Nachweis.
Warum zwei Runden? Nicht weil zwei eine besondere Zahl wäre. Ich will für diesen kleinen Versuch vorher einen endlichen Rahmen setzen. Bei einer größeren Migration wäre das Budget anders. Entscheidend ist, dass es nicht unbemerkt wächst, sobald der erste Versuch scheitert.
Ein Modell darf außerdem nicht seine eigene Messlatte absenken. Wenn der Test rot wird, weil die Anforderung verletzt ist, darf der Loop nicht einfach die Anforderung entfernen. Änderungen an der Prüfung brauchen eine eigene Begründung: War der Test falsch, oder ist das Produkt noch falsch?
Woran ich feststelle, dass der Loop feststeckt
Ich vergleiche Befunde, nicht nur Exit-Codes. Taucht derselbe Fehler nach einer Korrektur unverändert auf, brauche ich eine neue Diagnose. Wechseln zwei Fassungen ständig hin und her, fehlt möglicherweise ein gemeinsamer Vertrag. Fehlt ein Zugang oder eine Entscheidung, ist „blockiert“ ein ehrlicher Zustand.
Ein guter Loop erkennt nicht nur Erfolg. Er erkennt auch, dass ein weiterer Durchlauf gerade nichts lösen wird.
Dieser Stopp braucht ein brauchbares Ergebnis: welches Artefakt zuletzt geprüft wurde, was offen bleibt und welcher konkrete Schritt weiterhelfen würde. Dann kann ich die Arbeit übernehmen oder später fortsetzen, ohne den ganzen Verlauf neu zu lesen.
Zeitgesteuert heißt nicht dauerhaft betreut
Für Claude Code dokumentiert /loop wiederkehrende Aufgaben innerhalb einer Sitzung, mit einer begrenzten Lebensdauer. Das ist ein anderes Betriebsmodell als ein dauerhafter Dienst. Der Stand der Dokumentation ist hier vom 4. Oktober 2026; konkrete Versionsdetails können sich ändern.
Ein fester, rein mechanischer Check braucht nicht automatisch bei jedem Tick ein Sprachmodell. Ein normaler Scheduler kann einen Zustand messen und nur eine relevante Änderung zur Auswertung geben. Das senkt nicht nur Aufwand. Es macht auch den Unterschied sichtbar zwischen „keine Änderung“ und „die Prüfung ist gar nicht gelaufen“.
Vom einzelnen Loop zum System
Im Graph-Engineering-Beitrag geht es darum, welche Aufgaben voneinander abhängen. Der Loop beantwortet innerhalb dieses Ablaufs, wie ein einzelnes Ergebnis verbessert wird. Harness Design stellt dafür Kontext und Werkzeuge bereit.
In den Materialien meiner Lernplattform Agentic Builders greifen getrennte Schreibbereiche und mechanische Prüfungen ineinander. Ich würde dabei nie allein aus einem grünen Check folgern, dass das gesamte System sicher ist. Der Check trägt nur die Aussage, für die er tatsächlich gebaut wurde.
Bei session-orchestrator steckt diese Idee im Ablauf zwischen Arbeit und Verifikation. Die Methode ist aber auch ohne Plugin nützlich: ein klarer Auftrag, eine belastbare Prüfung und ein endlicher Korrekturpfad.
Wenn du einen vorhandenen Agenten-Loop prüfen willst, fang bei seinem Ende an. Was gilt dort als Beleg? Was passiert bei fehlendem Fortschritt? Und bleibt nach einem Abbruch genug übrig, um sinnvoll weiterzuarbeiten? Über Kontakt kannst du mir einen konkreten Fall schicken.
Häufige Fragen
Was ist Loop Engineering?
Ich meine damit den Entwurf einer Arbeits- und Prüfschleife mit eindeutigem Ziel, Rückmeldung und Abbruchbedingungen. Wiederholung allein macht aus einem Agenten noch kein zuverlässiges System.
Was unterscheidet einen Retry von einer Korrekturschleife?
Ein Retry wiederholt einen vorübergehend fehlgeschlagenen Aufruf. Eine Korrekturschleife verändert das Ergebnis anhand eines fachlichen Befunds. Beide brauchen Grenzen, lösen aber unterschiedliche Probleme.
Ist ein erfolgreicher Test schon der Abschluss?
Nur wenn der Test den vereinbarten Abschluss tatsächlich abdeckt. Ein bestandener Build beweist beispielsweise noch keine erfolgreiche Veröffentlichung oder funktionierende Zahlungsstrecke.