Loop Engineering: Die Schleife entwerfen, die Ihren KI-Agenten promptet

Hören Sie auf, Ihrem Agenten Anweisungen einzeln zuzufüttern. Bauen Sie die Schleife, die das für Sie erledigt. Dieser Denkwechsel hat inzwischen einen Namen – Loop Engineering – und er verändert, womit Sie Ihre Stunden verbringen, wenn Sie mit KI-Agenten arbeiten.

Das Zwei-Uhr-nachts-Problem

Stellen Sie sich eine lange Nacht mit einem Coding-Agenten vor. Er schreibt einen Patch. Sie lassen die Tests laufen, drei schlagen fehl. Sie kopieren die rote Ausgabe in den Chat und tippen „Behebe das“. Der Agent versucht es erneut, und Sie kopieren wieder. In der fünften Runde dämmert es Ihnen: Jede Nachricht, die Sie schicken, ist mechanisch. Tests laufen lassen. Fehler lesen. Auf die wahrscheinliche Ursache zeigen. Neu versuchen. Aufhören, wenn alles grün ist.

Sie sind die fähigste Komponente in diesem System – und werden als Zwischenablage benutzt.

Tausende Ingenieure stießen um Mitte 2026 an dieselbe Wand, und die Idee, die daraus entstand, war unverblümt: Hören Sie auf, den Agenten zu prompten, und entwerfen Sie stattdessen die Schleife, die ihn promptet.

Von Prompts zu Schleifen

Loop Engineering ist die jüngste Sprosse einer Leiter, die die Branche seit Jahren hinaufsteigt. Jede Stufe umschließt die darunterliegende, statt sie zu ersetzen. Erst wurden die Worte optimiert, dann die Daten, dann die Umgebung. Jetzt steht der Zyklus selbst zur Gestaltung an.

• Prompt Engineering (etwa 2022 bis 2024) fragt, welche Worte man verwendet. Die Grenze ist offensichtlich: Keine Formulierung kann einem Modell eine Tatsache liefern, die es nie erhalten hat.
• Context Engineering (2025) fragt, welche Daten das Modell zur Inferenzzeit zu sehen bekommt.
• Harness Engineering (Anfang 2026) fragt, was das Modell umgibt: Tools, eine Sandbox, Validatoren.
• Loop Engineering (2026) fragt, welcher Zyklus laufen soll und wann er endet.

Ihre Rolle verschiebt sich mit. Sie beginnen als Operator, der Prompts tippt, werden zum Manager, der mehrere Agenten parallel beaufsichtigt, und landen als Systemdesigner. Dann legen Sie fest, was „gut“ und „fertig“ bedeuten, und lassen die Maschine diese Ziele verfolgen.

Eine Arbeitsdefinition: Loop Engineering heißt, die Schleife, in der ein Agent läuft, bewusst zu gestalten – einschließlich Auslöser, Ziel, Prüfungen, Gedächtnis und Abbruchregeln –, statt jede nächste Anweisung von Hand zu schreiben.

Jeder Agent läuft bereits in einer Schleife

Der Clou: Keinem Agenten fehlt eine Schleife. Fast alle haben eine, und nur wenige gestalten sie bewusst. Genau diese Lücke trennt einen Agenten, der die Arbeit leise erledigt, von einem, der über Nacht ein Budget verbrennt und dabei überzeugt ist, voranzukommen.

Der zugrunde liegende Zyklus ist das ReAct-Muster von 2022: nachdenken, durch einen Tool-Aufruf handeln, das Ergebnis beobachten, wiederholen bis fertig. Das ist nichts Neues. Neu ist 2026, dass dieser Zyklus als das Wichtigste gilt, was es zu konstruieren gibt – mit derselben Sorgfalt, die man einer API widmen würde. Wenn sich Coding-Agenten in der Qualität unterscheiden, liegt es selten am Basismodell. Meist liegt es am Schleifendesign.

Der Verifier ist der Engpass

Wenn nur ein Gedanke hängen bleibt, dann dieser: In jeder Schleife begrenzt der Verifier die Ergebnisse, nicht das Modell.

Eine Schleife ist schlicht ein Generator, der an einen Verifier angeschlossen ist. Der Generator, also das Modell, ist billig und wird nie müde, tausend Versuche kosten fast nichts. Der Verifier entscheidet, ob all diese Aktivität etwas Nützliches ergibt oder einen Haufen Schrott.

Dass sich Schleifen überhaupt lohnen, liegt an einer Asymmetrie, die manchmal Verifier's Law genannt wird: Bei vielen Aufgaben ist es viel leichter, eine Antwort zu prüfen, als sie zu erzeugen. Das ist die ganze Ökonomie. Erzeugen, prüfen, neu erzeugen – und Sie liegen trotzdem vorn, weil die Prüfung so wenig kostet.

Verifier gibt es in zwei Varianten, und die Wahl zwischen ihnen macht den Großteil des Handwerks aus:

• Deterministische Prüfungen führen die Tests aus, validieren das Schema oder bestätigen einen Score. Sie sind günstig, verlässlich und schwer zu täuschen, also bevorzugen Sie sie, wo immer es geht.
• LLM-as-Judge-Setups lassen ein zweites Modell die Ausgabe anhand einer Rubrik bewerten. Sie eignen sich für unscharfe Ziele, lassen sich aber austricksen, und Verzerrungen durch Position, Ausführlichkeit und Selbstbevorzugung sind gut dokumentiert.

Das Risiko übersieht man leicht. Ein schwacher Verifier scheitert nicht laut. Er produziert selbstbewusst Schrott, hunderte Male hintereinander. Deshalb ist das Schreiben des Verifiers das neue Prompt Engineering geworden.

Schleifen um Schleifen legen

Zum Handwerk wird das durch Verschachtelung. Denken Sie an vier konzentrische Schleifen, jede mit einem langsameren Takt. Die innere erledigt die Arbeit, und jeder äußere Ring macht das System zuverlässiger, autonomer und schließlich fähig, sich selbst zu verbessern.

1. Die Agenten-Schleife. Das Modell ruft Tools auf, bis die Aufgabe erledigt ist.
2. Die Verifikations-Schleife. Ein Bewerter misst die Ausgabe an einer Rubrik und gibt sie mit Feedback zurück, wenn sie nicht reicht.
3. Die ereignisgesteuerte Schleife. Webhooks, Cron-Jobs oder eingehende Nachrichten starten Läufe, sodass der Agent arbeitet, während Sie schlafen, und ein Mensch freigeben kann, bevor etwas ausgeliefert wird.
4. Die Hill-Climbing-Schleife. Ein separater Analyse-Agent liest Produktions-Traces und schreibt den Harness selbst um: Prompts, Tools und Rubrik. Das System verbessert das System.

Der übliche Rat lautet, nach außen zu den Schleifen drei und vier vorzudringen, wo sich Gewinne aufsummieren. Das ist richtig, mit einem Vorbehalt. Eine vierte Schleife um einen schwachen Verifier automatisiert nur selbstbewussten Schrott im großen Stil. Bauen Sie also nach außen, um mehr Reichweite zu bekommen, aber erst, wenn der innerste Verifier stark ist.

Schreiben Sie den Vertrag, nicht den Prompt

So sieht der Wechsel in der Praxis aus. Sie hören auf, Anweisungen zu schreiben, und schreiben stattdessen eine Definition von „fertig“ – eine Belohnungsfunktion plus Abbruchregel – und lassen die Schleife darauf hinarbeiten:

Goal: get the test suite passing.
Done when: all tests green - and no test was skipped or deleted to fake it.
Loop: run tests -> read failures -> fix the likely cause -> run again.
Stop when: done, or after 6 rounds (then summarize what's left).

Keine einzige Anweisung ging an das Modell – das ist Loop Engineering in seiner kleinsten Form.

Begrenzen Sie die Schleife, sonst begrenzt sie Ihr Budget

Eine Schleife vervielfacht Ihren Aufwand, und das gilt in beide Richtungen. Geben Sie jeder Schleife drei Ausgänge: Erfolg, wenn der Verifier besteht; Aufgabe, wenn ein Limit oder Budget erschöpft ist; Übergabe, wenn an einen Menschen eskaliert wird. Die oberste Regel: Der Harness, nie der Agent, muss garantieren, dass die Schleife endet.

Zu jedem typischen Fehler gibt es eine passende Leitplanke:

• Endloses Kreisen fängt man mit einer harten Obergrenze für Iterationen und der Erkennung von Läufen ohne Fortschritt ab.
• Ausufernde Kosten fängt man mit Budgetprüfungen vor jedem Aufruf und günstiger Vorsortierung vor teurer Arbeit ab.
• Ein halluziniertes „fertig“ fängt man mit einem separaten, deterministischen Verifier ab. Lassen Sie einen Agenten nie seine eigene Arbeit bewerten.
• Reward Hacking fängt man mit gehärteten Kriterien und einer menschlichen Freigabe für sensible Aktionen ab.

Bevor eine Schleife jemals unbeaufsichtigt läuft, testen Sie den Verifier mit Fällen, von denen Sie wissen, dass sie gut sind, und solchen, von denen Sie wissen, dass sie schlecht sind. Prüfen Sie, dass er schlechte Ausgaben ablehnt – nicht nur, dass er gute akzeptiert. Ein Verifier, den niemand getestet hat, ist nur eine Meinung.

Behalten Sie die Hände am Steuer

Automatisierung heißt nicht, aus dem Prozess auszusteigen. Setzen Sie einen menschlichen Kontrollpunkt dort, wo es zählt: bei der Freigabe riskanter Tool-Aufrufe, der Bewertung kritischer Ergebnisse und der Abnahme, bevor eine Änderung am Harness live geht. Es gibt auch leisere Kosten. Wenn eine Schleife einen Fix ausliefert, haben Sie etwas ausgeliefert, das Sie vielleicht nicht ganz verstehen. Diese Lücke wird Verständnisschuld genannt, und sie könnte sich als nächste Form technischer Schulden erweisen.

Die Haltung passt in einen Satz: Bauen Sie die Schleife, aber bauen Sie sie wie jemand, der vorhat, der Ingenieur zu bleiben, und nicht bloß die Person, die auf Start drückt.

Zwei Uhr nachts, noch einmal

Es ist wieder zwei Uhr nachts, und diesmal schlafen Sie. Stunden zuvor hat ein Webhook ausgelöst. Am Morgen wartet ein Entwurf eines Pull Requests. Die Schleife hat vor dem Merge angehalten, weil sie diese Entscheidung nicht allein treffen darf, und eine saubere Zusammenfassung hinterlassen, was sich geändert hat und warum.

Sie sind nicht mehr die Zwischenablage. Sie sind die Person, die die Maschinerie entworfen hat, und jedes Teil geht auf eine Entscheidung von Ihnen zurück: das Ziel, den Verifier, die Grenzen und die Stellen, an denen sie innehalten und fragen muss.

Das ist Loop Engineering. Bauen Sie eine Schleife – und bauen Sie sie so, dass Sie der Ingenieur bleiben.