> ## Content Index > Fetch the complete content index at: https://t01.li/llms.txt > Use this file to discover other available public pages before exploring further. # Loop Engineering: Der Agent ist nicht der Prozess - URL: https://t01.li/ki-systemdesign/loop-engineering-agenten-prozess/ - Published: 2026-09-22T05:44:14.000Z - Updated: 2026-09-22T05:44:23.000Z - Description: Loop Engineering ersetzt den nächsten manuellen Prompt durch ein System aus Triggern, Verifikation, Zustand und Grenzen. Was daran Substanz hat und wo nur ein neues Label auf alten Mechaniken klebt. - Author: Tobias Glawe - Tags: KI Systemdesign, #hub-prompt-engineering Ein KI-Agent löst eine Aufgabe, meldet sich zurück und wartet auf den nächsten Prompt. Das ist total nützlich, aber noch kein belastbarer Prozess. Solange ich nach jedem Lauf prüfen, korrigieren und den nächsten Arbeitsauftrag formulieren muss, bin ich selbst die Steuerungsschicht. Der Agent arbeitet und ich halte den Laden zusammen. Loop Engineering verschiebt genau diese Aufgabe: Nicht mehr der Mensch schreibt nach jedem Durchlauf den nächsten Prompt, sondern ein System startet Agentenläufe, prüft ihre Ergebnisse, speichert den Zustand und entscheidet anhand vorher definierter Regeln, ob es weitermacht, abbricht oder einen Menschen dazuholt. Das klingt zunächst nach einem Cronjob mit etwas LLM obendrauf und ganz falsch ist dieser Einwand nicht. Neu ist weniger die Schleife als der Worker darin: Er handelt probabilistisch, kann Werkzeuge auswählen und produziert gelegentlich überzeugenden Unsinn. Das Engineering steckt deshalb nicht im Timer, sondern in den Grenzen, Prüfschritten und Rückkopplungen drumherum. ## TL;DR - Loop Engineering steuert wiederkehrende Agentenläufe über Trigger, Prüfschritte, Zustand und Stoppbedingungen. - Die eigentliche Arbeit beginnt beim Verifier. Ohne messbares Erfolgskriterium lässt sich auch kein sinnvoller autonomer Loop bauen. - Loops eignen sich vor allem für wiederkehrende, reversible Aufgaben, deren Ergebnisse günstig geprüft werden können. - Der Begriff ist jung und die Evidenz dünn. Als Architekturgedanke ist er trotzdem brauchbarer als die übliche Agenten-Autonomie-Folklore. ## Der nächste Prompt kommt nicht mehr von dir Addy Osmani beschrieb [Loop Engineering am 7\. Juni 2026](https://addyosmani.com/blog/loop-engineering/?ref=t01.li) als Ablösung des Menschen in seiner Rolle als fortlaufender Promptgeber. Statt den Agenten interaktiv von Schritt zu Schritt zu führen, gestaltest du ein System, das Arbeit findet, verteilt, prüft und den nächsten Lauf auslöst. Der Begriff ist also noch frisch. Ein Ende August 2026 veröffentlichtes [Preprint zu Loop Engineering](https://arxiv.org/abs/2608.21884?ref=t01.li) ordnet ihn eine Ebene oberhalb des Agent Harness ein und leitet aus der bisherigen Praxisdiskussion eine Arbeitsdefinition ab: Wiederkehrende Agentenläufe werden zeit- oder ereignisgesteuert gestartet, durch maschinell prüfbare Stoppbedingungen begrenzt und über mehrere Runs hinweg mit Zustand versorgt. Das Paper ist explorativ und befindet sich im Review. Wer daraus schon den nächsten Merksatz für die KI-Beratungsfolie ableiten will, deutet aktuell zu viel hinein. Es ist eine erste Systematisierung eines Praxisbegriffs und nicht mehr. Die Autoren sagen selbst, dass die großen Produktivitätsversprechen bislang vor allem auf Erfahrungsberichten und Selbstangaben beruhen. Ein bisschen weniger „Software Factory“, ein bisschen mehr Bestandsaufnahme tut dem Thema gut. ## Prompt, Context, Harness – und eine Etage darüber Wie [Prompt Engineering, Context Engineering und Harness Engineering](https://t01.li/prompt-engineering-context-engineering/) zusammenhängen, habe ich an anderer Stelle auseinandergenommen. Loop Engineering ersetzt keine dieser Ebenen, aber es setzt sie voraus und organisiert mehrere Agentenläufe über die Zeit. | Ebene | Worum es geht | Typische Artefakte | | ------------------------------------------------------------------ | -------------------------------------------- | ------------------------------------------------------------------- | | [Prompt Engineering](https://t01.li/glossar/#prompt-engineering) | eine einzelne Anweisung | Prompt, Prompt-Template | | [Context Engineering](https://t01.li/glossar/#context-engineering) | alles, was das Modell für einen Aufruf sieht | Dokumente, Regeln, Beispiele, RAG-Ergebnisse | | [Harness Engineering](https://t01.li/glossar/#harness) | die Umgebung eines Agentenlaufs | Tools, Skills, Hooks, Berechtigungen, Sandbox, MCP | | [Loop Engineering](https://t01.li/glossar/#agentic-loop) | die Steuerung wiederkehrender Runs | Trigger, Stoppbedingungen, Zustandsdateien, Logs, Budgets, Verifier | Der Prompt bestimmt die aktuelle Aufgabe, der Kontext liefert das dafür notwendige Wissen. Das Harness regelt Werkzeuge und Spielraum; erst der Loop entscheidet, wann ein neuer Lauf beginnt, ob das Ergebnis genügt und wann Schluss ist. Damit liegt Loop Engineering näher an Prozessdesign und Controlling als an einer neuen Modelltechnik. Schleifen, Zustandsautomaten, Webhooks, CI/CD, Monitoring und automatisierte Tests gab es vorher. Was sich ändert, ist der teilweise autonom handelnde Agent in der Mitte. Klassische Software führt Regeln aus, ein Agent interpretiert sie – das macht ihn flexibler. Genau dieser Teil läuft nachts aber auch einmal in die falsche Richtung weiter. ## Der Verifier kommt vor dem Agenten Wer einen Loop bauen will, beginnt gern mit dem Worker: Welches Modell soll handeln, welche Tools bekommt es und wie viel Reasoning darf es verbrennen? Die wichtigere Frage steht vorher. Woran erkennt das System, dass die Arbeit akzeptabel erledigt wurde? Ohne belastbaren Verifier gibt es keine sinnvolle Stoppbedingung. Dann läuft der Agent entweder so lange, bis er selbst zufrieden ist, oder bis das Budget leer ist. Beides sind erstaunlich schlechte Qualitätskriterien. Ein Verifier kann ein deterministischer Test, ein Schema-Validator, eine Regel, ein zweites Modell oder ein Mensch sein. Häufig braucht es mehrere Ebenen. Bei Code können Build, Tests und Linter einen großen Teil der formalen Prüfung übernehmen. Ob die Änderung architektonisch sinnvoll ist, das eigentliche Problem löst und später noch jemand warten kann, steht auf einem anderen Blatt. Wenn sich Qualität in prüfbare Kriterien zerlegen lässt, etwa „alle Daten belegt“, „keine Floskeln“, „vorgegebene Struktur eingehalten“, kann ein zweites Modell als [LLM-as-a-Judge](https://t01.li/glossar/#llm-as-a-judge) diese Liste abarbeiten und den Entwurf bewerten. Ein zweites Modell ist aber nicht automatisch unabhängig, nur weil „Evaluator“ auf seinem Namensschild steht. Es kann dieselben blinden Flecken besitzen, oberflächlich prüfen oder sich von einem plausibel klingenden Ergebnis bequatschen lassen. Verifier-Theater skaliert genauso gut wie echte Qualitätssicherung und ist leider billiger einzurichten. ## Aus einer Schleife wird noch kein belastbarer Loop Ein Prompt in einer Endlosschleife ist technisch ein Loop. Produktionsreif ist daran ungefähr nichts. Ein brauchbares System braucht mindestens sechs Dinge: 1. einen Trigger wie Zeitplan, Webhook, Ticket oder Fehlermeldung, 2. ein konkretes Ziel mit maschinell prüfbaren Erfolgskriterien, 3. persistenten Zustand außerhalb einer einzelnen Modellsitzung, 4. eng begrenzte Tools und Berechtigungen, 5. Limits für Versuche, Laufzeit, Tokens und Kosten, 6. Regeln für Abbruch, Rollback und menschliche Eskalation. Der persistente Zustand ist leicht zu unterschätzen. Ein Modell startet einen neuen Run ohne Erinnerung an den vorigen. Deshalb müssen offene Aufgaben, Prüfergebnisse, Fehlversuche und Entscheidungen in einer Datei, Datenbank oder einem Ticketsystem landen. [Memory](https://t01.li/glossar/#memory) ist hier kein vages Langzeitgedächtnis, sondern, übersetzt, profane Buchhaltung. Der Agent vergisst, das System darf es nicht. Ebenso wichtig sind Grenzen: Eine Stoppbedingung beschreibt neben dem Erfolg auch das kontrollierte Scheitern, etwa maximal fünf Versuche, höchstens 20 € Inferenzkosten, Abbruch nach 30 Minuten oder sofortige Eskalation, sobald eine produktive Datenbank verändert werden müsste. Der [praktische Agenten-Guide von OpenAI](https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/?ref=t01.li) empfiehlt solche Exit Conditions und menschliche Übergaben ausdrücklich bei überschrittenen Fehlerschwellen oder riskanten Aktionen. Wer den Loop später verbessern will, braucht vollständiges [Tracing und Observability](https://t01.li/glossar/#observability). Ohne nachvollziehbare Runs bleibt nur das Endergebnis. Dann weißt du zwar, dass etwas schiefging, aber nicht, ob der Worker falsch handelte, der Kontext fehlte, der Verifier schlief oder die Stoppbedingung Unsinn war. ## Vier Loops – samt Hersteller-Sternchen LangChain beschreibt in [The Art of Loop Engineering](https://www.langchain.com/blog/the-art-of-loop-engineering?ref=t01.li) vier aufeinander aufbauende Ebenen. Die Taxonomie ist nützlich, solange man sie nicht mit einer Norm verwechselt. Sie ist zugleich die Produktlogik rund um *LangSmith*. Der **Agent Loop** ist der innere Zyklus, in dem das Modell Tools aufruft, Ergebnisse bewertet und weiterarbeitet, bis es die Aufgabe für erledigt hält. Der **Verification Loop** legt einen Grader darum und schickt fehlerhafte Ergebnisse mit Feedback zurück. Im **Event-driven Loop** starten Webhooks, Zeitpläne oder andere Ereignisse neue Agentenläufe. Der **Hill-climbing Loop** wertet Traces und Fehler aus, um Prompts, Tools, Skills oder Prüfkriterien zu verbessern. Bei der vierten Ebene lohnt ein genauer Blick auf die Wortwahl. Der Agent verbessert dabei normalerweise nicht sein Basismodell, sondern verändert Konfigurationen im Harness oder schlägt Änderungen daran vor. Diese Änderungen gehören versioniert, mit [Evals](https://t01.li/glossar/#eval) geprüft und wie ein neuer Release behandelt. Ein System, das gleichzeitig arbeitet und seine eigenen Prüfregeln unbeaufsichtigt lockert, hat zwar einen Loop gebaut. Nur keinen, den ich in der Nähe produktiver Daten haben möchte. ## Wo Loop Engineering effizient funktioniert Die besten Einsatzfelder haben drei gemeinsame Eigenschaften: Das Ergebnis lässt sich günstig prüfen, Fehler bleiben begrenzt und Aktionen sind reversibel. Deshalb taucht der Begriff zuerst rund um Coding-Agenten auf. Repositories liefern mit Tests, Builds, statischer Analyse und isolierten Worktrees mehr maschinelle Rückmeldesignale als fast jede andere Domäne. ### Coding: viel Feedback, trotzdem kein Selbstläufer Ein Loop kann CI-Fehler untersuchen, eine Änderung in einem isolierten Branch umsetzen, Tests starten und bei Fehlschlägen erneut ansetzen. Erst wenn die Prüfungen bestanden sind, öffnet er einen Pull Request. Das ist deshalb ein sinnvoller Autonomiegrad, weil Änderungen bis zum Review eingegrenzt bleiben. Trotzdem gilt die Empfehlung von Anthropic, [agentische Systeme nur dann komplexer zu machen, wenn einfachere Muster nicht reichen](https://www.anthropic.com/engineering/building-effective-agents?ref=t01.li). Ein klassischer Workflow ist für feste, deterministische Abläufe oft günstiger und besser zu debuggen. Nicht jede Schleife braucht einen Agenten, und nicht jeder Agent braucht noch drei Subagenten, die einander bedeutungsvoll anschauen, munter miteinander quatschen und dabei lustig Tokens verbrennen. ### Der Whitepaper-Loop Ein Beispiel aus meiner Praxis skizziere ich nur, denn so etwas nicht komplett breitzutreten, gehört bei Kundenprojekten einfach zum guten Ton. Auf den ersten Blick ein einfaches Ziel: Am Ende der Pipeline fällt ein schlüsselfertiges Whitepaper heraus. Davor liegen 133 Knoten und bis zu 20 Modellaufrufe, verteilt auf Rechercheur, Architekt, Autor, Lektor und Faktenchecker, jede Rolle mit eigenem Modell und eigenem Prompt. Fest vorgegeben sind ein Tone-of-Voice-Dokument und die Anweisungen zum Ablauf. Der Rest ist ein Loop. Der größte Teil der Qualitätssicherung braucht kein Modell. Vor jeder weiteren Modellstufe steht ein deterministischer Guard, der die Länge des Dossiers, die Zahl unterschiedlicher Quellen-URLs oder die Sektionsanzahl zählt und zu dünne Zwischenstände gar nicht erst weiterreicht. Erst danach urteilt ein Modell, dann ein Faktenchecker mit Websuche, am Ende ein simpler Regex-Scan auf Hype-Vokabular und Beraterfloskeln. Jede Rückgabe darf ein einziges Mal repariert werden. Danach geht es weiter, und was übrig bleibt, landet als interner Prüfhinweis im Dokument statt in einer weiteren Runde. Zwischenstände liegen in einer Artefakttabelle, Recherche, Gliederung und Erstentwurf sind gecacht. Ein Neustart nach Abbruch zahlt die teuren Stufen nicht doppelt. Streng betrachtet fehlt dem Ganzen ein Stück zum Loop im Sinne des Preprints. Der Trigger zu Beginn ist ein Briefing im Chat und fehlt darin etwas, fragt das System zurück, bevor es Geld ausgibt. Alles danach läuft ohne Nutzer, bis das Markdown fertig ist. Um den Loop zu schließen, müsste das System nur noch selbst nach Themen recherchieren und daraus ein Briefing bauen. ### Google Ads: erst beobachten, dann über Autonomie reden Auch die Analyse von *Google Ads* und *GA4* ist ein relevantes Beispiel. Ein wiederkehrender Loop kann Daten abrufen, auffällige CPA-Veränderungen erkennen, mögliche Treiber nach Kampagne oder Gerät untersuchen und einen Bericht mit Handlungshypothesen erstellen. Solange der Loop nur liest, bleibt er nachvollziehbar und der mögliche Schaden bleibt überschaubar. Budgets, Gebote oder Kampagnen automatisch zu verändern, ist eine andere Risikoklasse. Dafür braucht es engere Schwellenwerte, vollständige Protokolle und mindestens ein menschliches Gate. [MCP](https://t01.li/glossar/#mcp) löst den Zugriff auf die Daten. Es löst nicht die Frage, wer für eine schlechte Entscheidung geradesteht. ## Mehr Output löst kein Review-Problem Loops können Arbeit skalieren. Sie skalieren aber ebenso Fehler, Kosten und Review-Bedarf. Wenn nachts zwölf Pull Requests, fünf Reports und drei neue Eskalationen entstehen, hat das System vor allem einen größeren Posteingang gebaut. In der Praxisdiskussion, die das Preprint auswertet, heißt dieser Effekt **Comprehension Debt**. Das System wächst schneller als das Verständnis der Menschen, die dafür verantwortlich sind. Ein Team kann mehr Code erzeugen, als es noch inhaltlich durchdringt. Dann wird das menschliche Gate irgendwann zum Rubber Stamp, weil niemand jeden Lauf ernsthaft prüfen kann. Hinzu kommt die Optimierung auf das Gate. Ein [Coding-Agent](https://t01.li/glossar/#coding-agent) kann alle Tests grün bekommen, indem er einen Test abschwächt. Ein Content-Agent kann eine formale Faktenprüfung bestehen und trotzdem am Thema vorbeischreiben. Gute Metriken ersetzen kein Urteil, wenn die Metrik nur einen Teil der eigentlichen Absicht abbildet. Relevant ist deshalb nicht der Preis des einzelnen Modellaufrufs, sondern der Preis pro akzeptiertem Ergebnis – inklusive Wiederholungen, Verifier, menschlichem Review und der Zeit, die für missglückte Runs draufgeht. Token-Kosten sind wenigstens sichtbar. Review-Müdigkeit findet man nicht auf dem Dashboard wieder. ## Wo der Mensch im Loop bleibt Wie viel Kontrolle nötig ist, hängt weniger von der gefühlten Intelligenz des Modells ab als von Prüfbarkeit, Umkehrbarkeit und Schadenspotenzial. Ein System darf eine reversible, maschinell gut prüfbare Routine eher autonom erledigen als eine Zahlung, Veröffentlichung oder Änderung an produktiven Daten. [Human-in-the-Loop](https://t01.li/glossar/#human-in-the-loop) ist dabei nur eine Variante. Der Mensch kann innerhalb eines Laufs eine sensible Aktion freigeben, einen autonomen Prozess von außen überwachen, erst das fertige Ergebnis genehmigen oder bei eng begrenzter Routinearbeit operativ gar nicht eingreifen. Innerhalb eines Systems können alle vier Formen gleichzeitig vorkommen. Das verdient aber einen eigenen Artikel. Für Loop Engineering genügt vorerst eine Faustregel: Je schlechter ein Ergebnis prüfbar, je schwerer eine Aktion umkehrbar und je höher der mögliche Schaden, desto früher muss der Mensch eingreifen. Eine Schlussfreigabe hilft nicht mehr, wenn der Agent die Mail bereits verschickt hat. ## Aus dem Buzzword bleibt ein brauchbares Muster Loop Engineering ist keine neue Basistechnologie. Ob der Begriff in zwei Jahren noch verwendet wird oder still in Agentenplattformen verschwindet, ist offen. Trigger, Zustand, Verifikation, Budgets und Eskalationen verschwinden dadurch allerdings nicht. Irgendjemand muss sie gestalten. Die erste empirische Bestandsaufnahme fand in einem Sample von 36.710 Software-Repositories 256 heuristisch passende Projekte und bestätigte in 217 davon autonome Agentenprozesse. Die Autoren betonen zugleich, dass systematische Evidenz für die behaupteten Produktivitätsgewinne fehlt. Sichtbare Konfigurationen lassen sich untersuchen; Laufzeitdaten, Kosten und Zustandsdateien bleiben oft außerhalb der Repositories. Auch der junge [LoopArena-Benchmark](https://arxiv.org/abs/2608.28281?ref=t01.li) bremst die großen Autonomiegeschichten. Er trennt den steuernden Controller von einem festen Coding-Worker. Bei vollständigen Aufgaben erreichte das beste getestete Controller-Modell eine Strict Success Rate von 24,69 %. Das ist kein allgemeiner Qualitätswert für Loop Engineering, zeigt aber, wie schwer zuverlässige Langzeitsteuerung weiterhin ist. Hotter Take dazu: Der Begriff ist jünger als viele seiner Bestandteile und wird gerade mit mehr Zukunftsmusik beladen, als die Daten überhaupt hergeben. Als Architekturmuster ist er trotzdem nützlich. Er zwingt dazu, nicht mehr nur über das Modell und seinen Prompt nachzudenken, sondern über den Prozess darum herum. Dort entscheidet sich, ob aus einem Agentenlauf produktive Arbeit oder nur automatisierter Beschäftigungslärm wird.