Agent Loops und Loop Engineering: Alter Wein in neuen Schläuchen?

Alter Wein in neuen Schläuchen? Eine kritische Einordnung zu "Agent Loops"

Im Juni 2026 verbreitete sich ein Tweet von Peter Steinberger mit über 6,5 Millionen Aufrufen in der AI-Community. Die Botschaft: Entwicklerinnen und Entwickler sollten nicht mehr jeden Prompt selbst tippen, sondern Loops designen, die Agenten automatisch anstoßen, prüfen und erneut ausführen. Boris Cherny, Leiter von Claude Code bei Anthropic, sagte im Acquired-Podcast sinngemäß: "Ich tippe Claude keine Prompts mehr. Ich schreibe Loops, die Claude anstoßen und entscheiden, was als Nächstes passiert." Addy Osmani bündelte das unter dem Begriff "Loop Engineering" und veröffentlichte ein Framework aus fünf Bausteinen plus Memory.

Wir haben uns gefragt: Ist das tatsächlich ein neuer Ansatz, oder wird hier ein etabliertes Konzept mit neuem Marketing-Etikett versehen? Diese Einordnung ordnet die aktuelle Diskussion kritisch ein.

Was genau wird unter "Agent Loops" und "Loop Engineering" verstanden?

Loop Engineering, wie Osmani es beschreibt, bedeutet: Statt selbst jeden nächsten Prompt zu tippen, designt man ein kleines System, das Arbeit findet, sie an Agenten delegiert, Ergebnisse prüft, Fortschritt speichert und wiederholt. Sechs Bausteine werden genannt: Trigger, Kontext, Aktion, Verifikation, Memory und Eskalation an einen Menschen.

Klingt zunächst nach klarer Abgrenzung von klassischem Prompting. Die Realität ist differenzierter. Claude Code und Codex haben in den letzten Monaten Produktfunktionen ausgeliefert, die das angeblich Neue operationalisieren: /loop für zeitgesteuerte Wiederholungen, /goal mit einem Evaluator-Modell, das nach jedem Turn prüft, ob eine Stopp-Bedingung erreicht ist, Cloud Routines, Sub-Agents, Worktrees. Das ist neu als Produktmerkmal, nicht als Konzept.

Was ist tatsächlich neu an Loop Engineering?

Drei Aspekte verdienen die Bezeichnung neu:

1. Produkt-Reife statt Bastelei. Was vorher handgepflegte Bash-Skripte mit Cron und ein paar Wrappern waren, ist jetzt in Claude Code und Codex als native Funktion verfügbar. /goal etwa nutzt ein kleines, schnelles Modell (standardmäßig Haiku), das ausschließlich den Transkript liest und nach jedem Turn entscheidet, ob die Bedingung erfüllt ist. Diese Trennung von Worker und Evaluator ist als Pattern nicht revolutionär, aber als sofort einsetzbares Produktfeature schon.

2. Stop-Bedingungen als erste Klasse. Die Diskussion verschiebt sich von "Was soll der Agent tun?" zu "Wann muss er aufhören?". Diese Frage ist nicht neu, wird aber in der aktuellen Welle konsequent in den Vordergrund gerückt. Osmani nennt Tests, Type-Checks, reale Fehler, Review-Queues und Budget-Limits als Werkzeuge. Die Haltung dahinter: Eine Schleife ohne klare Stopp-Bedingung ist kein Produktivsystem, sondern ein Agent, der mit sich selbst einig ist.

3. Verifikation als Kette von Signalen. Statt nur "Tests grün, fertig" propagiert die aktuelle Welle eine Hierarchie: deterministische Orakel (CI, Lint, Type-Check) als stärkste Signale, visuelle oder perzeptuelle Checks (Playwright, Screenshots) als mittlere, Critic-Sub-Agents und Self-Critique als schwächste. Diese Hierarchie ist eine wertvolle Orientierung, auch wenn die einzelnen Signaltypen lange bekannt sind.

Was ist nicht neu und wird trotzdem als Revolution verkauft

Hier beginnt der Teil, der uns kritisch stimmt.

Iterative Tool-Use-Loops gibt es seit LangChain 0.1 im Jahr 2023. Jeder Agent, der in einer Schleife "Thought, Action, Observation" durchläuft, ist ein Loop. Das 2022 vorgestellte ReAct-Paper von Yao et al. beschreibt genau dieses Muster. Wer 2024 einen AutoGPT aufgesetzt hat, hat ein Loopsystem betrieben. Das ist weder neu noch überraschend.

Reflexion und Self-Critique sind seit 2023 als Pattern dokumentiert. Das Reflexion-Paper von Shinn et al. (2023) und die LangChain-Implementierungen zeigen, wie ein Agent seine eigenen Ausgaben kritisch bewertet und iterativ verbessert. Die "Critic-Sub-Agents" aus dem aktuellen Loop-Engineering-Framework sind eine Neuverpackung dieses Musters mit dem Zusatz, dass Critic und Worker unterschiedliche Modelle sein können. Das ist eine nützliche Praxisempfehlung, aber kein neues Pattern.

Persistent Memory in Form von Dateien ist älter als jeder aktuelle AI-Agent. Jeder Entwickler, der Konventionen in eine README, eine CONTRIBUTING.md oder ein Wiki geschrieben hat, betreibt External State. Was Loop Engineering als sechsten Baustein verkauft, war schon immer die Grundlage jedes langlebigen Softwaresystems: Dokumentation.

HITL als Konzept stammt aus der Steuerungs- und Regelungstechnik der 1950er Jahre und ist in der Mensch-Maschine-Interaktion seit Langem etabliert. In der Softwareentwicklung kennt man es als Code Reviews, Pair Programming und Vier-Augen-Prinzip. Die Eskalation an einen Menschen ist und bleibt ein organisatorisches Muster, kein technisches Novum.

Triggermuster wie Cron, Event-driven oder Webhook-basiert sind so alt wie Unix selbst. at, cron, systemd-Timer, GitHub Actions, Cloud-Run-Jobs: nichts davon ist 2026 erfunden worden.

Warum die aktuelle Welle trotzdem wichtig ist

Diese Einordnung soll den Wert der Diskussion nicht schmälern. Drei Effekte sind real und nützlich:

1. Die Begriffsschärfung hilft beim Verkauf an Entscheider. Wer einem Geschäftsführer erklären muss, warum ein Coding-Agent "jetzt autonomer" ist, gewinnt mit "Loop Engineering" mehr Aufmerksamkeit als mit "Wir haben Cron auf einen Wrapper gesetzt". Das ist Marketing, aber produktives Marketing, weil es Investitionen in Verifikation und Stop-Bedingungen legitimiert.

2. Die Verlagerung der Designfrage. Der Diskurs verschiebt sich weg von "Wie formuliere ich den perfekten Prompt?" hin zu "Welche Verifikationssignale und Stop-Bedingungen brauche ich?". Diese Frage ist die richtige Frage, und sie wurde vor 2026 in vielen Teams zu selten gestellt.

3. Produktfeatures zwingen zur Disziplin. Wer /goal mit Evaluator-Modell nutzt, muss eine messbare Stopp-Bedingung formulieren. Wer Sub-Agents mit isolation: worktree einsetzt, muss Verantwortung trennen. Diese strukturellen Zwänge sind wertvoll, auch wenn die zugrundeliegenden Ideen älter sind.

Wo Loop Engineering an Grenzen stößt

Die gleichen Quellen, die Loop Engineering befeuern, liefern auch die warnenden Beispiele. Ein japanischer Feldbereicht dokumentiert 129 erfolgreiche automatisierte Branch-Löschungen mit klarer Verifikationsregel, aber auch 43 Commits eines PR-Babysitter-Loops an einem Tag, von denen fast alle abgelehnt wurden, weil der Scope unklar war und die Schleife driftete.

Drei Probleme bleiben, auch mit dem schönsten Framework:

Verifikation bleibt menschliche Verantwortung. Ein zweiter Agent, der den ersten prüft, teilt dessen Trainingsdaten und macht ähnliche Fehler. Die Vorstellung, ein Critic-Sub-Agent könne den Worker-Agent verlässlich kontrollieren, überschätzt die Diversität der Modelle. In der Praxis fängt eine gut formulierte Stopp-Bedingung mehr Fehler ab als ein zusätzlicher LLM-Check.

Komprehension-Drift. Die Schleife kann schneller Code produzieren, als das Team ihn versteht. Das ist kein neues Problem, aber Loop Engineering verschärft es, weil die Frequenz steigt. Ein Team, das nicht mehr liest, was sein Agent schreibt, sammelt technische Schuld in Hochgeschwindigkeit.

Kognitive Kapitulation. Wenn Loops erst laufen, wird es verlockend, jede Ausgabe zu akzeptieren. Die Schleife verstärkt Confirmation Bias, weil der Critic-Agent im selben Kontext trainiert wurde. Osmani selbst nennt dieses Risiko, ohne eine Patentlösung zu bieten.

Was Unternehmen mitnehmen sollten

Wer in einem KMU, einer Behörde oder einer mittelständischen IT-Abteilung über den Einsatz von Loop Engineering nachdenkt, sollte vier Punkte sortieren:

1. Welche Aufgabe hat eine klar messbare Stopp-Bedingung? Branch-Cleanup, Dependency-Updates, CI-Failure-Triage, strukturierte Migrationen. Diese Aufgaben lohnen sich.

2. Welche Aufgabe hat das nicht? Recherche mit offenem Suchraum, kreative Designentscheidungen, Kundenkommunikation. Hier produziert die Schleife Token-Kosten und Drift, selten Wert.

3. Wer liest die Outputs? Eine Schleife, die niemand prüft, ist ein Aktenvernichter mit API-Anbindung. Audit-Trails, Approval-Flows und regelmäßige Reviews sind keine Option, sondern Voraussetzung.

4. Welche Berechtigungen bekommt die Schleife? Niemals menschliche Credentials. Service-Accounts mit minimalen Rechten, getrennt vom operativen Alltag. Diese Disziplin ist nicht neu, wird aber im Hype häufig vergessen.

Fazit

Agent Loops und Loop Engineering bündeln vorhandene Praktiken zu einem leicht verständlichen Framework und erzwingen durch neue Produktfeatures diszipliniertere Stopp-Bedingungen. Die Konzepte darunter sind nicht neu. Wer "Loop Engineering" als Revolution verkauft, hat entweder Reflexion, ReAct und cron noch nie genutzt oder möchte ein neues Etikett auf alte Ideen kleben. Beides ist im Markt 2026 zu beobachten.

Wertvoll ist die Diskussion trotzdem, weil sie Verifikation, Stop-Bedingungen und External State ins Zentrum rückt. Diese Themen verdienen Aufmerksamkeit, unabhängig davon, ob man das Kind Loop Engineering, Recursive Goal System oder einfach "besser automatisierte Agenten" nennt.