Loop Engineering: The Guide for AI Agents

Kernpunkte

1. Definition in einem Satz. Loop Engineering baut Systeme, die Agenten nach Zeitplan und zielgerichtet prompten, statt einzelne Prompts einzutippen. Der Hebel verschiebt sich von der Qualität eines Prompts hin zum Design des Systems.
2. Zwei Loop-Ebenen. die innere Loop (Wahrnehmen-Denken-Handeln-Beobachten bei jedem Turn, bereits nativ in Agenten) versus die äußere Loop, die man entwirft (Planung, Helfer, sich selbst nährende Arbeit, Persistenz über viele Turns hinweg).
3. Dreistufige Genealogie. (jede Schicht schließt die vorherige ein): Prompt Engineering (1 Anweisung) → Context Engineering (Inhalt des Fensters) → Loop Engineering (System, das entscheidet, was, wann geprompted wird und ob das Ergebnis akzeptabel ist). Prompt und Kontext bleiben essenziell — ein schlechter Prompt erzeugt nur schneller schlechte Arbeit.
4. Ursprung des Begriffs. popularisiert von Addy Osmani (Google) im Juni 2026, aufbauend auf Beobachtungen von Peter Steinberger ("you should be designing loops that prompt your agents") und Boris Cherny (Claude-Code-Leiter bei Anthropic: sein Fokus verschob sich zum Schreiben von Loops statt direktem Prompten).
5. Ralph-Technik. (Geoffrey Huntley, Anfang 2026, benannt nach Ralph Wiggum): den Agenten in einer einfachen while-Schleife laufen lassen, derselbe Prompt bei jeder Iteration, gegen eine schriftliche Spezifikation, mit frischem Kontext bei jedem Turn. Die nicht offensichtliche Innovation ist der Kontext-Reset (vermeidet Degradation durch lange Sitzungen). Die Intelligenz kommt aus klaren Spezifikationen + überprüfbaren Ergebnissen + externem Memory (PLAN.md, STATUS.md), nicht aus heroischen Läufen.
6. Loop Engineering produktisiert Ralph. Aus dem while wird eine geplante Automation, aus den Resets werden Worktrees/Sub-Agenten, aus der Prüfung "ALL TASKS DONE" wird eine von einem separaten Modell verifizierte /goal-Bedingung.
7. 5 Bausteine + Memory. (1) Automations (geplante Discovery-/Triage-Trigger); (2) Worktrees (parallele Agenten ohne Kollisionen); (3) Skills (dokumentiertes Projektwissen); (4) Plugins/Connectors (MCP, Zugriff auf reale Werkzeuge); (5) Sub-Agenten (Trennung von Generierung und Verifikation); (6) Memory (Markdown, Linear-/GitHub-Boards — außerhalb des Kontextfensters). "Agents forget. Repositories remember."
8. Claude Code und Codex bilden die 5 Bausteine + Memory ab. unter unterschiedlichen Namen, aber identischen Strukturen → Loops entwerfen, die einen Werkzeugwechsel überleben.
9. Automations. Codex (Tab Automations, läuft in einer Triage-Inbox, leere Läufe archivieren sich selbst); Claude Code (/loop + Hooks + GitHub-Actions-Integration). Zentrale In-Session-Primitive = /goal: hält die Arbeit aufrecht, bis die angegebene Bedingung nachweislich zutrifft, ein separates, kleineres Modell bewertet die Fertigstellung bei jedem Turn (der Agent bewertet sich nicht selbst).
10. Stand Mitte 2026. /goal erschien in Claude Code v2.1.139 (11. Mai 2026), dem 2.1.x-Zweig mit Opus 4.8 als Standard sowie dynamischen Workflows, die große Sub-Agenten-Flotten orchestrieren; Codex fügte /goal in CLI 0.128.0 hinzu. Praktiker berichten von Agenten, die dutzende Stunden unbeaufsichtigt arbeiten → Abbruchbedingungen werden zum kritischsten Element.
11. Abbruchbedingungen als Verträge formulieren. Endzustand + Nachweis + Beschränkungen + Obergrenze für Turns/Budget. Z. B. "Testabdeckung von src/billing ≥ 90 %; npm test beendet sich mit Exit-Code 0; keine öffentliche API geändert; Abbruch nach 25 Turns oder 5 $."
12. Drei Praktiken für zuverlässige Loops. (Claude-Code-Teams): Fehler bewahren (damit die Loop lernt, statt sie zu wiederholen), Verifikation von Anfang an einbauen, rote Tests / rote CI als Ehrlichkeitssignale behandeln. Eine Loop ohne Fehlernachweis glaubt immer, erfolgreich gewesen zu sein.
13. Worktrees. = echte git-Isolation (separate Verzeichnisse auf unterschiedlichen Branches, gemeinsame History). Aber "You remain the ceiling": Nicht die Anzahl der Worktrees, sondern die menschliche Review-Kapazität bestimmt, wie viele Agenten tatsächlich parallel laufen.
14. Maker-Checker-Sub-Agenten. = die wirkungsvollste strukturelle Änderung: ein gegnerischer Verifizierer-Agent (starkes Modell, hohes Reasoning, angewiesen, alles Unbewiesene zurückzuweisen), der vor dem menschlichen Review als Gate fungiert. Modelle, die ihre eigene Arbeit bewerten, sind zu großzügig.
15. Reifegradskala (Stufen 0→4). 0 Manual → 1 Triage (Befunde in Markdown, kein Code) → 2 Draft (Fixes auf isolierten Branches) → 3 Verified PR (Sub-Agent als Verifizierer-Gate) → 4 Auto-merge (risikoarme Kategorien bei grüner CI). Nur eine Stufe aufsteigen, wenn die aktuelle Ergebnisse liefert, die man selbst erzielt hätte.
16. 3 Risiken, die sich verschärfen (nicht abnehmen). Die Verifikation bleibt in der eigenen Verantwortung ("erledigt" ist eine Behauptung, kein Nachweis); die Verständnisschuld wächst schneller (Code wird schneller ausgeliefert, als er verstanden wird); kognitive Kapitulation (Ergebnisse ohne Urteilsvermögen akzeptieren) — zwei Personen, die dieselbe Loop bauen, erzielen gegensätzliche Ergebnisse, je nachdem, ob sie damit Arbeit vorantreiben, die sie verstehen, oder ob sie Verständnis vermeiden.
17. Auf die Tokens achten. geplante Loops + Verifizierer-Modelle nach jedem Turn verbrauchen schnell Tokens. Mit langsamer Kadenz und engen Bedingungen beginnen, Kosten mehrere Tage lang beobachten, erst nach Nachweis nützlicher, gemergter Arbeit skalieren.
18. Sicherheit. Autonome Loops mit Connectors, die Produktion berühren → Guardrails, Berechtigungen, Audit-Logging erforderlich.