Loop Engineering: die Fähigkeit, die Prompt Engineering leise abgelöst hat

Was ist Loop Engineering also genau?

Beginnen wir mit dem, was konstruiert wird. Ein KI-Agent, auf sein Wesentliches reduziert, ist "ein LLM in einer while-Schleife mit Tools." Er nimmt einen Input auf, das Modell überlegt, was zu tun ist, ruft ein Tool auf, schaut sich das Ergebnis an, und geht wieder von vorne los, bis die Aufgabe erledigt ist oder ein Limit erreicht wird. Das ist der KI-Agent-Loop, und genau dieses eine Merkmal unterscheidet einen Agenten von einem Chatbot: Ein Chatbot antwortet in einem einzigen Durchgang, ein Agent bleibt über viele Schritte hinweg dran und passt sich an.

Loop Engineering ist die Disziplin, diesen Loop zuverlässig zu machen. Wie Simon Willison es formulierte, als er der Praxis ihren Namen gab:

"Meine bevorzugte Definition eines LLM-Agenten ist etwas, das Tools in einem Loop ausführt, um ein Ziel zu erreichen. Die Kunst, sie gut einzusetzen, besteht darin, die Tools und den Loop, den sie nutzen, sorgfältig zu gestalten."

Simon Willison, Designing agentic loops (September 2025)

Am klarsten zeigt sich, wo das hinpasst, wenn man betrachtet, wie sich die Disziplin in Schichten entwickelt hat. Prompt Engineering kam zuerst: eine gute Anweisung schreiben. Dann Context Engineering: die gesamte Menge an Tokens kuratieren, die das Modell bei jedem Turn sieht, nicht nur den Prompt. Loop Engineering sitzt über beidem, es gestaltet das Laufzeitsystem rund um das Modell.

Anthropic beschreibt die mittlere Schicht als "die natürliche Weiterentwicklung von Prompt Engineering", und dieselbe Logik trägt eine Stufe weiter:

"Ein Agent, der in einem Loop läuft, erzeugt immer mehr Daten, die für den nächsten Inferenz-Turn relevant sein könnten, und diese Informationen müssen zyklisch verfeinert werden."

Anthropic, Effective context engineering for AI agents

Die Beziehung ist also nicht konkurrierend, sondern verschachtelt. Prompt Engineering optimiert einen einzelnen Aufruf. Context Engineering optimiert den Zustand, den das Modell bei jedem Turn sieht. Loop Engineering optimiert die Maschinerie, die entscheidet, ob der Agent überhaupt jemals einen guten Zustand erreicht. Wer unseren Erklärartikel zu Prompt Engineering gelesen hat, ist hier eine Etage weiter oben.

Warum der Loop zum Hebel wurde, nicht der Prompt

Den größten Teil von 2023 und 2024 war die klügste Sache, die man tun konnte, mit dem Modell reden zu lernen. Das funktionierte, weil Modelle in einem Schritt antworteten. In dem Moment, in dem sie anfingen, in Loops zu laufen, Tools aufzurufen und über viele Schritte hinweg zu handeln, hörte der Prompt auf, der Engpass zu sein. Das, was einen Agenten heute am ehesten zum Scheitern bringt, ist keine schlecht formulierte Anweisung, sondern ein Loop ohne Aus-Schalter, ohne Speicherstrategie oder ohne Möglichkeit, seine eigene Arbeit zu überprüfen.

Solomon Hykes, der Gründer von Docker, hat die Gefahr in einem Satz eingefangen, den mittlerweile das ganze Feld zitiert:

"Ein KI-Agent ist ein LLM, das seine Umgebung in einem Loop zerlegt."

Solomon Hykes, via Simon Willison (AI Engineer World's Fair, Juni 2025)

Das ist die Neuausrichtung. Ein leistungsfähigeres Modell in einem schlecht konstruierten Loop ist gefährlicher, nicht weniger, weil es seine schlechten Ideen kompetenter ausführt. Die Praktiker-Community hat das schnell begriffen. Auf Hacker News ist einer der am höchsten bewerteten Beiträge zum Thema schlicht mit "The canonical agent architecture: a while loop with tools" betitelt, und ein weiterer beliebter Thread über die unvernünftige Effektivität eines LLM-Agent-Loops ist voller Leute, die überrascht sind, wie gut ein einfacher Loop performt, sobald das Gerüst darum stimmt.

LangChain hat das auf eine saubere Formel gebracht: Agent = Model + Harness.

"Harness Engineering bedeutet, Systeme rund um Modelle zu bauen, um aus ihnen Arbeitsmaschinen zu machen. Das Modell enthält die Intelligenz, und das Harness macht diese Intelligenz nutzbar."

LangChain, The anatomy of an agent harness

Ob man es nun Loop Engineering, Harness Engineering oder Agentic Coding nennt (die Begriffe pendeln sich noch ein), die Idee ist dieselbe: Wenn du nicht das Modell bist, bist du der Loop, und im Loop steckt jetzt das Engineering.

Die fünf Stellschrauben eines gut konstruierten Loops

Betrachtet man die Leute, die dieses Feld definieren, Willison, Anthropic, LangChain, Thoughtworks, zerfällt der Loop jedes Mal in dieselbe Handvoll Stellschrauben. Das sind die Regler, an denen man tatsächlich dreht.

1. Tools (die Agent-Computer-Schnittstelle). Was der Agent tatsächlich tun kann. Anthropic hat bei seiner SWE-Bench-Arbeit mehr Zeit in die Optimierung der Tools als in den Prompt gesteckt und den Begriff ACI (Agent-Computer-Interface) geprägt, das Pendant des Agenten zu einer UI. Willison bevorzugt einfache Shell-Befehle für Coding-Agenten, weil "Coding-Agenten wirklich gut darin sind, Shell-Befehle auszuführen."
2. Abbruchbedingungen. Wann der Loop aufhören darf, bei Erfolg, bei einer maximalen Iterationsgrenze, bei einem Budgetlimit, oder wenn er erkennt, dass er keine Fortschritte macht. Ein Loop ohne Abbruchlogik erklärt sich entweder verfrüht zum Sieger oder hört nie auf. Anthropic: "Es ist auch üblich, Abbruchbedingungen einzubauen (etwa eine maximale Anzahl an Iterationen), um die Kontrolle zu behalten."
3. Kontextmanagement. Was über Turns hinweg erhalten bleibt. Die Techniken dafür sind Kompaktierung (zusammenfassen und nahe am Fenster-Limit neu starten), Notizführung (eine NOTES.md, die der Agent außerhalb seines Kontexts pflegt), und Sub-Agenten, die jeweils zig-tausende Tokens verbrauchen, aber eine knappe 1.000- bis 2.000-Token-Zusammenfassung zurückgeben. Der Grund, warum das wichtig ist: Der Recall verschlechtert sich, je mehr Tokens sich ansammeln, also muss man aktiv kuratieren (siehe unsere Notiz zur Größe des Kontextfensters).
4. Verifikation. Wie der Loop beweist, dass er die Sache wirklich erledigt hat. Das ist die am häufigsten wiederholte Stellschraube. Willison sagt, der Wert eines Coding-Agenten werde "durch eine gute, sauber durchlaufende Test-Suite massiv verstärkt." Anthropics Harness für lang laufende Agenten nutzt eine JSON-Feature-Liste mit über 200 End-to-End-Features, jedes zunächst mit passes: false markiert, sodass der Agent ein Feature nicht als erledigt markieren kann, ohne es zu beweisen.
5. Leitplanken. Was den Loop davon abhält, Schaden anzurichten. Sandboxes, eng begrenzte Zugangsdaten und Budgets. Willison hat Claude Code eine eigene Fly.io-Organisation mit einem 5-Dollar-Budget gegeben, damit ein außer Kontrolle geratener Loop kein echtes Geld ausgeben konnte.

Wenn ein Agent sich falsch verhält, liegt der Fix fast immer bei einer dieser fünf Stellschrauben, nicht bei einem umformulierten Prompt. Hier ist die Kurzdiagnose, zu der ich greife:

Loop Engineering, aber für den Kundensupport

Hier kommt der Teil, den die meisten Coding-fokussierten Berichte übersehen. Die klarste real existierende Version des Jobs eines Loop Engineers besteht nicht darin, eine Coding-CLI zu bauen, sondern darin, einen KI-Agenten auf einer echten Support-Warteschlange laufen zu lassen, und das sage ich als jemand, der solche Agenten beruflich baut.

Ein Support-Ticket ist ein nahezu perfekter Loop. Der Agent nimmt die eingehende Nachricht wahr, überlegt sich die Absicht, ruft ab, was er braucht (Bestellhistorie, Docs, Kontostand), führt eine Aktion aus (eine Rückerstattung, ein Reset, ein Ticket-Update), verifiziert das Ergebnis und löst dann entweder oder übergibt an einen Menschen. Anthropic hebt Support als "eine natürliche Passform für offenere Agenten" hervor, gerade weil die Arbeit sowohl Konversation als auch Aktion braucht, mit einem Erfolg, der sich "klar durch nutzerdefinierte Lösungen messen lässt."

Und jede der fünf Stellschrauben entspricht einer Support-Entscheidung, die Käufern wichtiger ist, als ihnen bewusst ist. Wir haben die letzten dreieinhalb Jahre damit verbracht, KI-Agenten auf echten Support-Warteschlangen einzusetzen, und das, was darüber entscheidet, ob ein Rollout funktioniert, ist nie die Cleverness des Prompts. Es ist der Loop. Die schärfste Version davon, die ich gehört habe, kam von einer CX-Leiterin einer DTC-Nahrungsergänzungsmittel-Marke auf Gorgias und Shopify, mit rund 7.000 Tickets pro Monat, die uns in einem Call sagte:

"Die KI wird nie 100% der Fragen beantworten können... Ich brauche eine KI, die nur die Tickets bearbeitet, bei denen sie sich sicher ist, und bei allen anderen die Finger davon lässt."

Das ist eine Loop-Engineering-Anforderung in Alltagssprache. "Bearbeite nur, wobei du dir sicher bist" ist eine Kombination aus Abbruchbedingung und Leitplanke, und genau das war das eine Feature, das ihre Kaufentscheidung bestimmte. Ein Bot, der versucht, alles zu beantworten, sieht in einer Demo beeindruckend aus und untergräbt in der Produktion leise das Vertrauen. Das ist dasselbe Fehlermuster hinter den meisten KI-Chatbot-Problemen: kein Konfidenz-Gate, also antwortet er, wenn er es nicht sollte. Es ist auch die Trennlinie zwischen einem echten Agenten und einem regelbasierten Chatbot, der dieses Urteilsvermögen überhaupt nicht hat.

Die Verifikations-Stellschraube hat ein exaktes Support-Pendant. Beim Coden verifiziert man mit einer Test-Suite. Im Support verifiziert man, indem man den Agenten gegen die eigenen vergangenen Tickets simuliert, bevor er je einen Kunden berührt, beobachtet, was er gesagt hätte, wo die Abdeckung dünn ist, und was er falsch macht. Das ist das Support-Pendant zu Anthropics "200 Features, alle passes: false"-Disziplin, und deshalb haben wir Simulation in eesels Helpdesk-Agent eingebaut, statt Teams live herausfinden zu lassen.

Die Zahlen untermauern, warum das Engineering wichtig ist. In einem Benchmark-Report von 2026 setzt Notch klassische Chatbots bei 10 bis 25% Lösungsquote an und agentische Plattformen (die, die sich "direkt mit CRM-, Abrechnungs- und Schadenssystemen verbinden und ausführen") bei 70 bis 85% End-to-End-Lösungsquote. Die Lücke liegt nicht an der Modellqualität, jede Stufe kann dieselben Frontier-Modelle nutzen. Die Lücke liegt darin, ob jemand den Loop drumherum konstruiert hat. Der schärfste Satz des Reports ist ein Kauftipp: Die ehrliche Frage an einen Anbieter ist "nicht, wie hoch seine Lösungsquote ist, sondern was er als gelöst zählt."

Man kann diesen Loop auch in normaler Sprache statt in Code abstimmen, und genau das macht Loop Engineering für ein Support-Team zugänglich, nicht nur für Entwickler.

Den Loop selbst bauen, oder einen fertigen nutzen

Sobald man Support-Automatisierung als Loop Engineering betrachtet, wird die Build-versus-Buy-Frage klarer. Du kannst den Loop selbst auf der rohen Claude- oder OpenAI-API aufbauen, viele technische Teams tun das, und die Claude-Code-Best-Practices-Artikel sind ein wirklich guter Ort, um die Disziplin zu lernen. Aber das Harness ist der schwierige Teil, und es ist der Teil, den man dauerhaft warten muss. Anthropics eigene Arbeit an lang laufenden Agenten umfasste eine Verifikationsliste mit über 200 Features, Sub-Agent-Orchestrierung und Kompaktierungslogik, und das nur, um einen Coding-Agenten auf Kurs zu halten. Ein produktiver Support-Loop kommt zusätzlich mit Konfidenz-Routing, mehrsprachiger Verarbeitung, ticket-typ-spezifischen Regeln und sauberer menschlicher Übergabe.

Ein Engineering-Lead bei einem Kryptohardware-Unternehmen mit einer Wissensdatenbank aus über 300 Artikeln fasste die Rechnung zusammen, nachdem er sich fürs Kaufen entschieden hatte:

"Wir hätten versuchen können, unsere eigene LLM-Anwendung zu schreiben, aber wir wollten unsere Zeit nicht darin investieren. Wir wollten etwas, das wir nicht warten müssen."

Karel, Engineering-Lead bei GENERAL BYTES (eesel-Kunde)

Das ist der eigentliche Trade-off. Der Loop ist jetzt das Produkt, also lautet die Frage, ob man derjenige sein will, der ihn konstruiert und wartet, oder ob man lieber einen Loop kauft, der für den Support-Fall bereits konstruiert ist. Wer Letzteres prüfen möchte, findet in unserem Überblick zur besten KI-Helpdesk-Software, unserem Feld an KI-Agenten-Beispielen und unserer Auswahl der besten KI-Agenten eine gute Landkarte, wer diese Konstruktionsarbeit geleistet hat und wie gut.

eesel ausprobieren

eesel AI ist, in der Rahmung dieses ganzen Beitrags, ein Loop, der für den Support bereits konstruiert ist. Du bindest es in deinen Helpdesk ein (Zendesk, Freshdesk, Gorgias, Help Scout und über 100 weitere), und es lernt vom ersten Tag an aus deinen vergangenen Tickets und Docs. Die fünf Stellschrauben sind für den Support-Fall bereits fertig gebaut: Simulation gegen deine historischen Tickets ist der Verifikationsschritt, konfidenzbasiertes Routing ist die Abbruchbedingung, und begrenzte Aktionen plus Ticket-Typ-Ausschlüsse sind die Leitplanken, alles konfigurierbar in normaler Sprache statt in Code.

Deshalb hat ein Team wie Gridwise mit eesel im ersten Monat 73% der Tier-1-Anfragen gelöst, wobei der Loop zunächst beaufsichtigt lief und sich Autonomie erarbeitete, sobald die Simulation ihn als sicher erwiesen hatte. Du bekommst den konstruierten Loop und die Verifikation, um ihm zu vertrauen, ohne einen eigenen aufzubauen und zu warten. Du kannst kostenlos starten und ihn gegen deine eigene Tickethistorie simulieren, bevor ihn ein einziger Kunde zu Gesicht bekommt.