Loop Engineering: Von Prompts zu dauerhaften Agent-Loops

Agent Observability with OpenTelemetry: Tracing LLM Calls and Agent Loops in Production

How to trace AI agents in production with OpenTelemetry — gen_ai.* semantic conventions, invoke_agent/execute_tool spans, conversation grouping, and token-usage metrics on your own stack.

Das Ende des Promptings

Peter Steinberger (PSPDFKit) brachte es auf den Punkt: "Man sollte Coding-Agenten nicht mehr prompten. Man sollte Loops entwerfen, die die Agenten prompten." Boris Cherny, der Claude Code bei Anthropic leitet, arbeitet genauso: "Ich prompte Claude nicht mehr. Ich habe Loops laufen, die Claude prompten und herausfinden, was zu tun ist. Mein Job ist es, Loops zu schreiben."

Das ist Loop Engineering — man ersetzt sich selbst als die Person, die den Agenten promptet, durch ein kleines System, das die Arbeit findet, sie verteilt, prüft, dokumentiert, was erledigt wurde, und den nächsten Schritt festlegt. Sie definieren einen Zweck; die KI iteriert, bis dieser erfüllt ist. Der Hebel hat sich verschoben: weg vom Entwerfen einzelner Prompts hin zum Design von Steuerungssystemen, die Agenten über einen längeren Zeitraum orchestrieren.

Das Überraschende ist, dass dies keine reine Tooling-Übung mehr ist. Vor einem Jahr bedeutete ein Loop noch einen Haufen benutzerdefinierter Bash-Skripte, die man ewig warten musste. Heute sind die Bausteine direkt in den Produkten enthalten — Codex und Claude Code haben sie beide in nahezu identischer Form. Sobald man bemerkt, dass die Struktur dieselbe ist, hört man auf, über das Tool zu streiten, und entwirft einfach einen Loop, der funktioniert, egal in welcher Umgebung man sich gerade befindet.

Die Anatomie eines Loops

Ein Loop benötigt fünf Bausteine und einen Ort, um Dinge zu speichern. Jeder hat eine spezifische Aufgabe:

Automations: Der Herzschlag

Automations sind das, was einen Loop zu einem tatsächlichen Loop macht und nicht zu einem einmaligen Durchlauf. Ein geplanter Task, ein CI-Job, der weiterläuft, nachdem man den Laptop geschlossen hat, ein Hook, der an einem bestimmten Punkt im Lebenszyklus des Agenten feuert — all das qualifiziert sich.

In der Codex-App erstellen Sie eine Automation im Automations-Tab: wählen Sie das Projekt, den auszuführenden Prompt, die Häufigkeit und ob sie in Ihrem lokalen Checkout oder in einem Hintergrund-Worktree laufen soll. Durchläufe, die etwas finden, landen in einem Triage-Posteingang; Durchläufe, die nichts finden, archivieren sich selbst. OpenAI nutzt diese intern für die tägliche Issue-Triage, die Zusammenfassung von CI-Fehlern, das Schreiben von Commit-Briefings und die Jagd nach Bugs, die letzte Woche eingeführt wurden.

Claude Code erreicht dasselbe über Scheduling und Hooks:

• /loop 5m /babysit — einen Prompt in einem Intervall erneut ausführen
• /loop 30m /slack-feedback — einen Kanal pollen und reagieren
• /loop 1h /pr-pruner — veraltete PRs bereinigen
• Cron-Tasks und Lifecycle-Hooks für Shell-Befehle bei Agent-Events
• GitHub Actions, falls der Loop überleben muss, wenn der Laptop geschlossen ist

Chernys eigene laufende Loops lesen sich wie eine To-do-Liste: /loop 5m /babysit, /loop 30m /slack-feedback, /loop /post-merge-sweeper, /loop 1h /pr-pruner. Sein kanonischer "Babysit-Loop" in ausführlicher Form: "Überwache alle meine PRs. Behebe Build-Probleme automatisch, und wenn Kommentare eingehen, nutze einen Worktree-Agenten, um sie zu korrigieren."

Worktrees: Parallele Sicherheit

In dem Moment, in dem man mehr als einen Agenten laufen lässt, beginnen Dateien zu kollidieren. Zwei Agenten, die in dieselbe Datei schreiben, verursachen genau die gleichen Kopfschmerzen wie zwei Engineers, die ohne Absprache in dieselben Zeilen committen.

Ein Git-Worktree löst dies: ein separates Arbeitsverzeichnis auf einem eigenen Branch, das dieselbe Repository-Historie teilt. Die Edits eines Agenten können den Checkout eines anderen buchstäblich nicht berühren.

• Codex hat Worktree-Support integriert — mehrere Threads greifen auf dasselbe Repo zu, ohne sich gegenseitig zu behindern.
• Claude Code bietet die gleiche Isolation via git worktree, einem --worktree-Flag, um eine Session in einem eigenen Checkout zu öffnen, und isolation: worktree für Sub-Agenten, sodass jeder Helfer einen frischen Checkout erhält, der sich selbst bereinigt.

Die mechanische Kollision verschwindet, aber Sie bleiben der Flaschenhals: Ihre Kapazität für Reviews entscheidet darüber, wie viele parallele Agenten Sie tatsächlich betreiben können, nicht das Tool.

Skills: Kodifiziertes Wissen

Ein Skill ist die Methode, mit der man verhindert, in jeder Session den gleichen Projektkontext erneut erklären zu müssen. Beide großen Tools nutzen dasselbe Format: ein Ordner mit einer SKILL.md darin, die Anweisungen und Metadaten enthält, plus optionale Skripte, Referenzen und Assets.

Zwei Eigenschaften machen Skills in Loops effektiv:

• Lazy Loading: Ein Skill wird nur geladen, wenn er verwendet wird, sodass er fast nichts an Kontext kostet, bis er benötigt wird.
• Trigger Matching: Codex führt einen Skill via $name oder /skills aus, oder eigenständig, wenn ein Task mit der Skill-Beschreibung übereinstimmt — weshalb eine präzise, nüchterne Beschreibung besser ist als eine clevere.

Cherny checkt Slash-Commands in .claude/commands/ ein für jeden Inner-Loop-Workflow, den er mehrmals täglich ausführt, damit sowohl sein Team als auch Claude sie wiederverwenden können.

Connectors: Zugriff auf echte Tools

Ein Loop, der nur das Dateisystem sehen kann, ist ein winziger Loop. Connectors, basierend auf MCP (Model Context Protocol), ermöglichen es dem Agenten, Ihren Issue-Tracker zu lesen, eine Datenbank abzufragen, eine Staging-API aufzurufen oder eine Nachricht in Slack zu posten.

Sowohl Codex als auch Claude Code sprechen MCP, sodass ein Connector, den Sie für das eine schreiben, normalerweise auch im anderen funktioniert. Plugins bündeln Connectors und Skills, sodass ein Teamkollege Ihr gesamtes Setup auf einmal installieren kann, anstatt es aus dem Gedächtnis nachzubauen.

Sub-Agents: Die Maker/Checker-Trennung

Die übliche Aufteilung in beiden Tools: ein Agent exploriert, einer implementiert, einer verifiziert gegen die Spezifikation. Codex definiert Agenten als TOML-Dateien in .codex/agents/; Claude Code nutzt .claude/agents/ und Agent-Teams, die Arbeit untereinander weitergeben.

Die Verifizierung ist die effektivste Ergänzung für jeden Loop. Cherny: "Geben Sie Claude eine Möglichkeit, seine Arbeit zu verifizieren. Wenn Claude diesen Feedback-Loop hat, wird sich die Qualität des Endergebnisses verdoppeln oder verdreifachen." Der Loop läuft, während Sie nicht zusehen, daher ist ein Verifizierer, dem Sie wirklich vertrauen, der einzige Grund, warum Sie den Platz verlassen können.

Dasselbe Prinzip gilt für die Stop-Bedingung: /goal läuft so lange weiter, bis eine von Ihnen geschriebene Bedingung tatsächlich wahr ist — nach jedem Durchgang prüft ein frisches, kleines Modell, ob die Bedingung erfüllt ist. Das ist die Maker/Checker-Trennung angewandt auf das "Fertigsein" selbst: Der Agent, der die Arbeit erledigt hat, entscheidet nicht mehr, wann die Arbeit abgeschlossen ist.

Kostenhinweis: Sub-Agenten verbrauchen mehr Token — jeder führt seine eigenen Modell- und Tool-Operationen aus. Setzen Sie sie dort ein, wo eine zweite Meinung den Preis wert ist.

Das sechste Element: State

Eine Markdown-Datei, ein Linear-Board, irgendetwas, das außerhalb der einzelnen Konversation existiert und festhält, was erledigt ist und was als Nächstes ansteht. Es klingt zu simpel, um wichtig zu sein — und doch ist es derselbe Trick, auf den jeder langlebige Agent angewiesen ist. Das Modell vergisst zwischen den Durchläufen alles, daher muss das Gedächtnis auf der Disk liegen, nicht im Kontext. Der Agent vergisst; das Repo nicht.

In einem Loop ist die State-Datei das Rückgrat: Sie merkt sich, was versucht wurde, was bestanden hat und was noch offen ist, sodass der Durchlauf am nächsten Morgen dort anknüpft, wo der heutige aufgehört hat.

Chernys Regel für langfristige Arbeit: "Jedes Mal, wenn Claude einen Fehler macht, sage ich ihm nicht, dass er es anders machen soll. Ich sage ihm, er soll es in die CLAUDE.md schreiben, einen Skill erstellen oder Ähnliches. Wenn man das tut, kann Claude einfach ewig weiterlaufen." Beachten Sie den Unterschied: CLAUDE.md ist Kontext, keine Erzwingung — um eine Aktion hart zu blockieren, benötigen Sie einen PreToolUse-Hook.

Die Plattform als Runtime des Loops

Hier trifft Loop Engineering auf klassisches DevOps. Die Plattform — insbesondere GitOps — wird zur Runtime des Loops:

• GitOps ist die Memory-Layer. ArgoCD und Flux überwachen Repositories und gleichen Cluster automatisch ab. Der Loop muss kein State-Management erfinden; er erbt es von der Plattform.
• Infrastruktur ist ein besseres Orakel als Applikationscode. Ein Plan-Diff ist deterministisch und maschinenlesbar. Ein Policy-Check liefert ein eindeutiges Urteil. Drift und Kosten sind Zahlen, für die man Schwellenwerte festlegen kann.
• Outer und Inner Loops. Der Outer Loop achtet auf neue Releases, Compliance-Änderungen und Security-Patches. Er delegiert an Inner Loops, die Updates stufenweise über Cluster ausrollen. Jeder Inner Loop berichtet zurück: Drift erkannt, Policy bestanden, Tests grün. Der Outer Loop entscheidet, ob er zur nächsten Stufe übergeht oder stoppt und einen Menschen alarmiert.

Teams in großem Maßstab setzen heute bereits Variationen davon ein. Das ist der Unterschied zwischen einem Agenten, der sagt "hier ist der Fix", und einem Loop, der den Fix ausliefert, verifiziert und das Ergebnis kommuniziert.

Budgets, Guardrails und Escape Hatches

Osmani ist explizit hinsichtlich der Risiken: Token-Verbrauchsmuster können stark variieren, je nachdem, ob man "token-reich" oder "token-arm" ist, und Loops laufen, während man schläft. Setzen Sie die Guardrails vor dem ersten Durchlauf des Loops:

• Iteration Cap — eine maximale Anzahl von Loop-Durchläufen pro Run.
• Token/Dollar-Limit — der Loop bricht ab, wenn er diesen Wert erreicht.
• Bedingungsbasierter Stopp — z. B. Stopp bei zwei aufeinanderfolgenden identischen Fehlern.
• Human Gates — prüfen Sie das Ergebnis, nicht jeden einzelnen Schritt; halten Sie die gleiche Qualitätslatte für KI-geschriebenen Code wie für menschengeschriebenen Code.
• Triage-Posteingang — alles, was der Loop nicht bewältigen kann, landet dort, sodass Sie die Eskalationsinstanz sind, nicht der Scheduler.

Ein Produktions-Loop: Tägliche Triage

Dies ist derselbe Loop in Codex, Claude Code oder opencode, da die Bausteine identisch sind. Eine morgendliche Automatisierung ruft einen Triage-Skill auf, der die CI-Fehler von gestern, die offenen Issues und die letzten Commits liest und die Ergebnisse in eine Markdown-Datei schreibt. Für jeden relevanten Befund öffnet ein Thread einen isolierten Worktree und sendet einen Subagenten, um den Fix zu entwerfen; ein zweiter Subagent prüft den Entwurf anhand der Projekt-Skills und bestehender Tests. Connectors öffnen den PR und aktualisieren das Ticket. Alles Unbehandelte landet im Triage-Posteingang. Die State-Datei speichert alles, sodass der nächste Durchlauf dort fortsetzt, wo er aufgehört hat.

Sie haben dies einmal entworfen. Sie müssen keinen dieser Schritte erneut prompten.

War Story: 259 PRs in 30 Tagen

Cherny berichtet, in 30 Tagen 259 PRs gelandet zu haben – jede Zeile geschrieben von Claude Code –, nachdem er Ende November 2025 seine IDE deinstalliert hatte. Die Zahl ist als Richtwert zu verstehen: Seine dramatischen Behauptungen zur Skalierung (Hunderte von Agenten, sein Anteil an GitHub-Commits) sollte man mit Skepsis betrachten, und die oft zitierte Zahl von „~4 % der öffentlichen GitHub-Commits“ ist eine Schätzung von SemiAnalysis ohne veröffentlichte Methodik. Aber der implementierbare Kern ist real und heute verfügbar: /goal, /loop, /schedule, Worktrees, Agent View, Hooks, Skills und CLAUDE.md, eingebettet in Loops, die Sie schreiben und verifizieren.

Das praktische Muster, das den Kontakt mit der Realität übersteht: Ein kleiner morgendlicher Loop, der CI-Fehler zusammenfasst und Fixes entwirft, spart die erste Stunde des Tages. Das PR-Review erfolgt immer noch durch einen Menschen – nur eben beim Kaffee statt davor.

Vorbehalte

• Es ist noch früh. Osmani, der den Begriff popularisiert hat, ist nach wie vor explizit skeptisch. Loops verstärken sowohl gute als auch schlechte Verhaltensweisen; ein schlechter Prompt in einem Loop scheitert für immer, nicht nur einmal.
• Kosten sind real. Loops multiplizieren den Token-Verbrauch. Budget-Obergrenzen sind nicht optional.
• Vertrauen vor Autonomie. Ein Verifizierer, dem Sie vertrauen, ist die Voraussetzung dafür, dass Sie sich zurückziehen können. Ohne einen solchen ist ein Loop lediglich unüberwachte Codegenerierung.
• Designen Sie den Loop, nicht den Vendor. Die Bausteine konvergieren über verschiedene Tools hinweg; Loops, die auf das UI eines bestimmten Anbieters zugeschnitten sind, werden obsolet, sobald sich das Produkt ändert.
• Schreiben Sie Dinge auf. Die State-Datei und CLAUDE.md machen den Loop dauerhaft – das Modell vergisst; das Repo nicht.

Weiterführende Literatur

• DevOps in the Age of AI — wie KI die Delivery-Pipeline neu gestaltet
• From Manual to Automated Operations — die Automatisierungsprogression, auf der Loops aufbauen
• Agent Observability with OpenTelemetry — Beobachtung der Loops, sobald sie unbeaufsichtigt laufen
• Kubernetes GitOps with ArgoCD — die Memory-Layer, die Loops erben
• CI/CD Pipeline Optimization — die Pipeline, in die Loops eingehängt werden