Ein Loop ist ein Arbeitszyklus, den ein KI Agent so lange wiederholt, bis ein vorher definiertes Abbruchkriterium erreicht ist. Loop Engineering beschreibt die Disziplin, diese Zyklen bewusst zu bauen: Ziel festlegen, Auslöser setzen, Prüfschritt definieren, Stop Bedingung formulieren.

Der Begriff Claude Loops kursiert dabei als umgangssprachliche Bezeichnung für Loops in Claude Code. Gemeint ist meist der Befehl für zeitgesteuerte Wiederholungen oder ein zielgetriebener Dauerauftrag. Die Mechanik ist aber nicht an ein Produkt gebunden. Dieselben Bausteine finden sich in OpenCode, Codex und in jedem selbstgebauten Bash Skript.

Der Unterschied zum klassischen Prompting ist der Platz des Menschen. Beim Prompting ist der Mensch der Motor der Schleife: Er schreibt den nächsten Auftrag, prüft das Ergebnis, schreibt wieder. Im Loop übernimmt ein System diese Rolle. Der Mensch entwirft das System einmal und prüft danach nur noch das Ergebnis.

Bei Never Code Alone laufen Coding Agenten täglich in Schleifen. Der Agent schreibt Code, startet die Testsuite, liest den Fehler, korrigiert. Genau dieser Zyklus ist unser Arbeitsalltag, mit PHPStan, PHPUnit und Cypress als festem Prüfschritt am Ende jeder Runde. Wir kennen deshalb beide Seiten aus der Praxis: den Loop, der über Nacht sauber durchläuft, und den Loop, der sich um sich selbst dreht und Tokens verbrennt.

Aus dieser Erfahrung beraten wir Teams, die Agenten ernsthaft einsetzen wollen. In der Vibe Coding Beratung ordnen wir Loop Architekturen ein, von einfachen Agent Loops bis zur Orchestrierung mehrerer Agenten. Wie ein Loop sich selbst prüft, zeigen wir in unseren Artikeln zu Code Qualität mit KI Agenten und zu Vise Coding mit Guardrails. Für die Modellauswahl im Loop hilft der Blick auf Ollama und lokale Modelle sowie auf Agentic Engineering als Begriff.

Im Juni 2026 setzte ein einzelner Post die Debatte in Gang. Peter Steinberger, Gründer von OpenClaw, schrieb, man solle Coding Agenten nicht mehr prompten, sondern Loops entwerfen, die die Agenten prompten. Der Beitrag sammelte Millionen Aufrufe.

Boris Cherny, Kopf hinter Claude Code bei Anthropic, sagte kurz zuvor auf einer Bühne dasselbe in anderen Worten: Er prompte nicht mehr, er habe Loops laufen, und seine Aufgabe sei es, Loops zu schreiben. Addy Osmani prägte daraufhin den Begriff Loop Engineering.

Die Reaktionen waren geteilt. Ein großer Teil der Antworten hielt die Aussage für einen echten Denkwechsel, ein noch größerer Teil für verfrüht oder für ein Rebranding. Beide Lager haben einen Punkt. Wer jemals eine CI Pipeline oder einen Kubernetes Reconciliation Loop gebaut hat, entwirft seit Jahren Schleifen. Neu ist nicht das Prinzip, neu ist, dass ein Sprachmodell im Regelkreis sitzt und selbst entscheidet, was der nächste Schritt ist.

Das Claude Code Team unterscheidet Loops danach, wer den nächsten Durchlauf auslöst und wann die Schleife endet. Diese Einteilung lässt sich auf jedes Agent Tool übertragen.

Turn based. Der klassische Agent Loop. Jeder Prompt startet einen Zyklus: Kontext sammeln, handeln, Ergebnis prüfen, antworten. Der Mensch entscheidet, ob es weitergeht. Geeignet für kurze Aufgaben ohne festen Rhythmus.

Goal based. Ein Ziel wird formuliert samt Angabe, woran der Agent erkennt, dass es erreicht ist. Der Agent arbeitet daran, bis die Prüfung durchläuft. Das ist der Typ mit dem größten Hebel und dem größten Risiko, weil ein schwaches Prüfkriterium den Agenten in falscher Sicherheit wiegt.

Time based. Ein Prompt wird in festem Intervall erneut ausgeführt, etwa alle fünf oder zwanzig Minuten. Sinnvoll, wenn der Agent auf einen Zustand wartet: ein Testergebnis, ein Log, ein Review Kommentar, ein CI Lauf. Diese Loops laufen lokal auf dem Rechner und stoppen, wenn die Maschine aus ist.

Proactive. Der Agent reagiert auf Ereignisse statt auf die Uhr. Ein neues Issue, ein fehlgeschlagener Build, eine eingehende Nachricht. Hier verschwimmt die Grenze zur klassischen Workflow Automatisierung, wie sie auch mit Paperclip oder LangGraph abgebildet wird.

Nicht jede Aufgabe braucht den komplexesten Typ. Die Empfehlung lautet, mit der einfachsten Variante zu starten und erst dann aufzurüsten, wenn die einfache Schleife nachweislich zu wenig leistet.

Loops, die unbeaufsichtigt laufen, sind keine langen Prompts. Sie sind kleine Systeme. Fehlt einer dieser Bausteine, driftet die Schleife, läuft endlos oder meldet Erfolg, obwohl Tests rot sind.

• Messbares Ziel. Das Ergebnis muss so beschrieben sein, dass man es prüfen oder messen kann. Nicht "mach die App besser", sondern "alle Tests grün, keine PHPStan Fehler auf Level 8".
• Kleine Schritte. Eine begrenzte, umkehrbare Änderung pro Runde. Leichter zu prüfen, leichter zurückzunehmen.
• Fester Prüfschritt. Nach jeder Änderung derselbe Test, dieselbe Messung, dieselbe Freigabe. Der Check entscheidet, nicht die Selbsteinschätzung des Modells.
• Klare Stop Bedingung. Erfolg definieren und zusätzlich ein hartes Limit setzen: maximale Iterationen, maximale Laufzeit, maximales Tokenbudget.
• Zustand außerhalb des Kontexts. Eine Datei, die festhält, was versucht wurde, was durchlief und was offen ist. Ohne sie fängt jeder Durchlauf bei null an.

Ein guter Nebeneffekt: Wer alles, was der Agent bauen soll, hinter ein CLI legt, macht die Prüfung trivial. Der Agent ruft das Kommando selbst auf und liest den Rückgabewert. Damit schließt sich die Schleife ohne menschliches Zutun.

Vor einem Jahr war ein Loop ein Haufen Bash, den man selbst pflegen musste. Inzwischen liefern die Agent Tools die Bausteine mit. Claude Code kennt einen Befehl für zeitgesteuerte Wiederholungen, der einen Prompt in festem Intervall erneut ausführt. Der Zwilling dazu ist der zielgetriebene Befehl, der so lange arbeitet, bis die Verifikation durchläuft. OpenAI Codex hat sich auf sehr ähnliche Primitive eingependelt.

Genau das macht die Loop Form weitgehend werkzeugunabhängig. Wer das Muster einmal verstanden hat, baut es im offenen OpenCode Terminal Agenten genauso nach wie in einem proprietären Tool. Die Verifikation lässt sich als SKILL.md hinterlegen, damit der Agent mehr seiner eigenen Arbeit prüfen kann, und über Agent Skills teilen.

Ein wichtiger Punkt zur Erwartungshaltung: Zeitgesteuerte Loops laufen in der Regel lokal. Wer den Rechner zuklappt, stoppt die Schleife. Für Loops, die wirklich durchlaufen sollen, braucht es eine Maschine, die an bleibt, und eine Ablage für den Zustand.

Die bekannteste einfache Loop Variante stammt von Geoffrey Huntley und trägt den Namen Ralph Loop. Technisch ist sie fast beleidigend simpel: Eine Prompt Datei wird in einer Schleife immer wieder in den Agenten gepipet.

Die eigentliche Erfindung steckt nicht im Skript, sondern in der Disziplin. Jeder Durchlauf setzt den Kontext auf einen festen Satz Ankerdateien zurück, statt die Konversation wachsen zu lassen. Damit bleibt das Verhalten über hunderte Iterationen berechenbar, und die Tokenkosten explodieren nicht mit der Laufzeit.

Für Teams ist das die wichtigste Lehre aus dem Thema. Ein Loop wird nicht dadurch gut, dass er komplex ist. Er wird gut durch einen sauberen Kontext Reset, einen harten Prüfschritt und eine ehrliche Stop Bedingung. Wer diese drei Dinge hat, kommt mit erstaunlich wenig Werkzeug aus.

Die drei häufigsten Probleme sind keine Randfälle, sondern der Normalfall in der Produktion.

Endlosschleife. Der Agent wiederholt dieselbe fehlerhafte Aktion, weil er den Fehler nicht als Fehler erkennt. Abhilfe schafft eine Loop Detection, die wiederholte identische Aktionen bemerkt und ausbricht, plus ein hartes Iterationslimit.

Goal Drift. Das Ziel verwässert über die Durchläufe hinweg. Der Agent optimiert am Ende etwas anderes als am Anfang. Ein fester Kontext Reset gegen unveränderliche Ankerdateien ist hier die wirksamste Gegenmaßnahme.

Tokenkosten. Der unterschätzte Punkt. Agenten verbrauchen ein Vielfaches gegenüber einem einfachen Chat, bei mehreren parallelen Agenten steigt der Verbrauch noch deutlich. Ein Loop, der über Nacht läuft, kann ohne Budgetgrenze unangenehm teuer werden. Ein Proxy wie LiteLLM setzt harte Limits, Langfuse macht sichtbar, wohin die Tokens gehen.

Dazu kommt die Frage, was überhaupt in den Loop darf. Eine Schleife, die Code schreibt und Tests laufen lässt, ist harmlos. Eine Schleife, die deployt, Tickets schließt oder Mails verschickt, braucht eine Freigabe vor der kritischen Aktion. Wir nennen das den kontrollierten Agent Loop.

Ein Loop ist nur so gut wie sein Prüfschritt. Das ist der Satz, der die ganze Diskussion zusammenfasst. Wer einen Agenten ohne belastbare Verifikation in eine Schleife schickt, bekommt keinen zweiten Mitarbeiter, sondern einen sehr fleißigen Generator von Änderungen, die niemand geprüft hat.

Deshalb steht in einem gesunden Loop nicht die Selbsteinschätzung des Modells am Ende, sondern eine Maschine, die ein hartes Urteil fällt. Statische Analyse mit PHPStan oder Psalm. Unit Tests mit PHPUnit. Funktionale Tests. End to End Tests mit Cypress, die einmal durch den echten Ablauf klicken.

Die Reihenfolge ist dabei nicht verhandelbar. Erst die Quality Gates, dann der Loop. Wer eine gewachsene Codebasis ohne Tests hat und dort einen autonomen Agenten in Dauerschleife ansetzt, automatisiert das Chaos. Der sinnvolle Weg führt über den Aufbau der Prüfschicht, und erst danach wird die Schleife scharf geschaltet. Wie das konkret abläuft, beschreiben wir in Code Qualität mit KI Agenten und in der Dokumentenkette aus ADR, PRD und BDD.

Für parallele Läufe gilt zusätzlich: Jeder Agent braucht seinen eigenen Arbeitsbereich. Git Worktrees sind dafür das einfachste Mittel, unabhängig vom eingesetzten Tool.

Ein Hinweis zur Einordnung, weil die Debatte fast ausschließlich um zwei amerikanische Produkte kreist. Bei Never Code Alone laufen Loops mit Open Weight Modellen. Lokal über Ollama mit Qwen3 Coder und Llama, für schwere Coding Loops GLM über Z.ai oder Ollama Cloud.

Das sind chinesische Open Weight Modelle, und das ist eine bewusste Entscheidung. Offene Gewichte, starke Ergebnisse im Agent Loop, kein US Anbieter. Die Modelle sind auf genau diese Zyklen trainiert und liefern brauchbare Tool Disziplin, was für Loops wichtiger ist als ein guter Wert in einem Einzelaufgaben Benchmark. Details dazu in unserem Vergleich lokaler Modelle für Tool Calling und MCP und bei Kimi mit Agent Swarm.

Die Regel dazu ist hart und gilt ohne Ausnahme: Coding aus der Cloud, Datenverarbeitung im eigenen Netzwerk. Große Coding Modelle laufen nicht auf Kundenhardware, dafür fehlt jede wirtschaftliche Grundlage. Sie laufen bei einem Anbieter, und deshalb arbeiten Loops bei uns gegen lokale Entwicklungsumgebungen mit Testdaten, nie gegen echte Kundendaten. Wer DSGVO konforme Inferenz mit Zero Data Retention braucht, fährt über EU souveräne Anbieter wie TensorX oder über gehostete Inferenz bei unserem Netzwerkpartner Conversis in Duisburg. Nur kleine Modelle laufen sinnvoll komplett On Premise.

Wir bauen Loops nicht als Selbstzweck. Der Einstieg ist fast immer derselbe: Wir schauen uns an, was im Team heute manuell wiederholt wird, und prüfen, ob es dafür ein verlässliches Prüfkriterium gibt. Gibt es keines, wird zuerst das Prüfkriterium gebaut. Erst danach lohnt sich die Schleife.

Die Einführung dauert realistisch fünfzehn bis dreißig Tage bis zum ersten belastbaren Ergebnis: Regeln und Rechte gesetzt, erste Quality Gates in der Pipeline, ein Review Agent im täglichen Ablauf. Am unteren Ende liegt, wer bereits Versionskontrolle, Tests und Pipeline hat. Danach kommen einige Tage pro Monat dazu, damit Regeln, Gates und Agenten mit dem Projekt wachsen. Das sind Aufwandsschätzungen, keine Pakete. Wir starten mit einem kostenlosen Kennenlernen, schätzen den Aufwand und rechnen transparent nach Minuten ab.

Weiterführend passen unsere Artikel zu parallelen Agenten Teams, zu Multi Agent Swarm Engines, zur Agenten Orchestrierung mit TDD, zum A2A Protokoll und zu OpenSpec für Spec Driven Development. Wer den Loop tokenschonend fahren will, findet in Ubuntu 26 mit lokaler KI und im werkzeugagnostischen Worktree Setup die passenden Bausteine.

Die Fragen, die uns zum Thema Loops am häufigsten erreichen, mit kurzen und ehrlichen Antworten.