Jeden Morgen dasselbe Ritual: Rechner an, Terminal öffnen, dem Coding-Agenten eintippen, er möge nachsehen, welche Pull Requests seit gestern liegen geblieben sind. Die Antwort ist meist nützlich, der Auftrag ändert sich nie, und trotzdem muss ein Mensch ihn jedes Mal von Hand auslösen. Genau an dieser Stelle setzt die Idee an, die im KI-Umfeld unter dem Schlagwort „Loop“ diskutiert wird.

Ein Loop ist kein neues Paradigma, sondern eine alte Technik mit neuem Ziel: Statt dass ein Mensch den Prompt abschickt, tut es ein Auslöser, also eine Uhrzeit, ein Ereignis oder ein noch nicht erreichtes Ziel. Claude Code von Anthropic und Codex von OpenAI bieten dafür inzwischen eigene Funktionen. Wer sie sinnvoll nutzen will, sollte das Prinzip verstehen, denn die eigentliche Arbeit steckt nicht im Klick auf „Zeitplan anlegen“, sondern im Auftrag, im Abbruchkriterium und in der Frage, wer die Ergebnisse kontrolliert.

Was ein Loop bei KI-Agenten ist

Die meisten Menschen kennen genau eine Art, mit einem KI-Agenten zu arbeiten: die Nachricht. Sie tippen eine Frage, warten auf die Antwort und schreiben die nächste Nachricht. Das ist ein vom Menschen gesteuertes Wechselgespräch, und für viele Aufgaben bleibt es die richtige Form, weil Sie jederzeit eingreifen, nachfragen und korrigieren können.

Bei einem Loop fällt diese menschliche Hand weg. Der Prompt, also die Arbeitsanweisung an das Sprachmodell, wird vorab formuliert und dann vom System selbst immer wieder ausgelöst. Im Kern ist das automatisiertes Prompten. Neu daran ist nur, wer am Ende der Kette steht: Früher startete ein Zeitplan ein starres Skript, das genau eine Sache tat. Heute startet er einen Agenten, der Dateien liest, Werkzeuge aufruft, Code ändert und selbst entscheidet, welcher Schritt als Nächstes sinnvoll ist.

Daraus folgt der wichtigste Unterschied zum klassischen Skript. Ein Skript tut auch beim hundertsten Lauf exakt dasselbe. Ein Agent kann bei gleichem Prompt unterschiedliche Wege gehen. Das macht ihn flexibler, aber auch schwerer vorhersehbar. Ein Loop ist deshalb immer auch eine Frage des Vertrauens und der Aufsicht.

Vier Auslöser: Takt, Zeitplan, Ereignis und Ziel

Drei der vier gängigen Auslöser sind so alt wie die Systemadministration selbst. Der vierte ist erst mit den Agenten wirklich praktikabel geworden.

Heartbeat: der regelmäßige Takt

Ein Heartbeat, auf Deutsch Herzschlag, löst in festen Abständen aus, etwa alle fünf Minuten oder jede Stunde. Bei jedem Schlag prüft der Agent, ob es etwas zu tun gibt. Angenommen, ein Supportteam möchte neue Tickets schnell vorsortieren: Ein stündlicher Herzschlag lässt den Agenten die neuen Einträge lesen, nach Dringlichkeit einordnen und eine Notiz anlegen. Gibt es nichts Neues, endet der Lauf sofort.

Cron: der feste Termin

Cron ist der klassische Zeitplaner unter Unix und Linux. Im Unterschied zum gleichmäßigen Takt nennt er konkrete Termine: „werktags um 7 Uhr“ oder „jeden Freitag um 16 Uhr“. Für Agenten eignen sich solche Termine für Berichte und Aufräumarbeiten, etwa eine Wochenübersicht über offene Änderungen vor dem Teammeeting.

Hook: die Reaktion auf ein Ereignis

Ein Hook, wörtlich Haken, klinkt sich in ein Ereignis ein. Das kann ein internes Ereignis sein, etwa der Start einer Sitzung oder das Ende einer Antwort des Agenten, oder ein externes, etwa ein neuer Pull Request oder eine eingehende Nachricht, die per Webhook eine Aktion anstößt. Claude Code kennt Hooks für Ereignisse im Lebenszyklus einer Sitzung, mit denen sich etwa nach jeder Dateiänderung automatisch ein Formatierer oder ein Test starten lässt.

Goal-Loop: Arbeiten bis zum Ziel

Der vierte Typ hat keine Uhr, sondern ein Ergebnis im Blick. Der Agent bekommt einen überprüfbaren Zielzustand und arbeitet so lange, bis dieser erreicht ist oder bis eine vorher festgelegte Grenze greift. Ein typisches Beispiel lautet: „Überarbeite das Modul, bis alle Tests grün sind und der Linter keine Fehler meldet.“ Entscheidend ist das Wort „überprüfbar“. Tests, ein erfolgreicher Build oder ein Linter liefern eindeutige Signale. „Bis der Code schön ist“ liefert keines.

Die bekannteste Spielart dieses Musters ist die sogenannte Ralph-Wiggum-Technik, bei der ein Agent denselben Auftrag in einer Endlosschleife immer wieder bekommt, bis die Aufgabe erledigt ist. Was dahintersteckt und wann sie sich eignet, erklärt der Beitrag Die Ralph-Wiggum-Technik für KI-Coding-Agenten. Hier geht es um das allgemeine Prinzip wiederkehrender Aufträge und die Werkzeuge dafür.

Wofür sich wiederkehrende Aufträge eignen

Ein hilfreiches Bild für den Entwurf eines Loops ist die Einarbeitung einer neuen Kollegin. Einer Assistenz würde man etwa sagen: „Gehen Sie jeden Freitag meinen Kalender durch, notieren Sie abgesagte Termine und schicken Sie mir eine kurze Zusammenfassung.“ Das ist ein wiederkehrender Auftrag mit klarer Aufgabe, festem Termin und erkennbarem Ergebnis, also genau das, was ein Loop braucht.

Einem Entwicklerteam gegenüber könnte der Auftrag lauten: „Prüfen Sie jeden Morgen, welche Änderungen seit mehr als einem Tag ohne Review liegen, und melden Sie sie im Teamkanal.“ Auch das ist ein Loop. Und wer anordnet, jede neue Änderung so lange nachzubessern, bis sie die Qualitätsprüfungen besteht, beschreibt einen Goal-Loop.

Gut geeignet sind Aufgaben mit drei Eigenschaften:

• Sie wiederholen sich täglich, wöchentlich oder bei jedem bestimmten Ereignis.
• Sie sind klar umrissen, sodass sich der Auftrag ohne Rückfragen verstehen lässt.
• Ihr Ergebnis ist prüfbar, durch einen Test, eine Liste, einen Bericht, den ein Mensch in wenigen Minuten durchsieht.

Schlecht geeignet sind dagegen Aufgaben, die laufend Abwägungen verlangen: Architekturentscheidungen, Gespräche mit Kunden, alles mit rechtlicher Tragweite. Hier hilft der Agent besser im Dialog als in der unbeaufsichtigten Schleife.

Was ein Loop technisch braucht

Damit Agenten unbeaufsichtigt arbeiten können, ohne sich gegenseitig oder dem Team in die Quere zu kommen, braucht es einige Bausteine. Die Begriffe unterscheiden sich je nach Werkzeug, das Prinzip ist überall ähnlich.

Eigene Arbeitsbereiche über Git-Worktrees

Ein Git-Worktree ist eine zusätzliche Arbeitskopie desselben Repositorys mit eigenem Branch. Man kann sie sich als abgetrennten Schreibtisch vorstellen: Der Agent arbeitet dort, ohne die Dateien zu verändern, an denen ein Mensch oder ein anderer Agent gerade sitzt. Laufen mehrere Loops parallel, ist diese Trennung Pflicht, sonst überschreiben sie sich gegenseitig.

Skills, Plugins und Connectoren

Skills sind beschriebene Arbeitsabläufe, die der Agent bei Bedarf lädt, etwa „So erstellen wir einen Release-Bericht“. Sie sorgen dafür, dass wiederkehrende Aufgaben immer auf dieselbe Weise erledigt werden. Plugins bündeln solche Skills mit weiteren Erweiterungen. Connectoren, oft über das Model Context Protocol (MCP) angebunden, geben dem Agenten Zugriff auf externe Systeme wie GitHub, den Kalender oder den Teamchat. Jeder Connector ist zugleich eine Berechtigung, die man bewusst vergeben sollte.

Subagenten für Teilaufgaben

Subagenten sind Helfer, an die der Hauptagent Teilaufgaben abgibt, besonders gern das Überprüfen von Ergebnissen. Ein Agent, der Code schreibt, und ein zweiter, der ihn mit frischem Blick prüft, finden zusammen mehr Fehler als einer allein. Jeder Subagent verbraucht allerdings eigene Rechenzeit.

Statusverfolgung und Abbruchkriterium

Ein Loop braucht ein Gedächtnis über die Läufe hinweg: eine Aufgabenliste, eine Fortschrittsdatei oder die Historie im Repository. Sonst beginnt er jedes Mal von vorn. Mindestens ebenso wichtig ist das Abbruchkriterium, also die Antwort auf die Frage, wann der Agent aufhört. Das kann das erreichte Ziel sein, eine Höchstzahl an Durchläufen oder ein Zeitlimit. Ein Loop ohne solche Grenze ist kein Werkzeug, sondern ein Kostenrisiko.

Geplante Aufgaben in Claude Code: der tägliche PR-Wächter

In Claude Code heißen fest eingerichtete, wiederkehrende Aufträge laut Anthropic inzwischen „geplante Aufgaben“ (Scheduled tasks), früher „Routinen“ (Routines). Der alte Name taucht in Oberfläche und Befehlen weiter auf, dieser Beitrag bleibt beim kürzeren Begriff Routine. Die Funktion ist als Research Preview gekennzeichnet. Eine Routine besteht aus einem Prompt, einem oder mehreren Repositorys und den benötigten Connectoren. Sie läuft nicht auf dem eigenen Rechner, sondern standardmäßig in der Cloud-Umgebung von Anthropic. Der Laptop darf also zugeklappt sein, während die Routine arbeitet.

Drei Auslöser für eine Routine

Laut Dokumentation kann eine Routine auf drei Wegen starten: nach Zeitplan, etwa stündlich, täglich oder wöchentlich; über einen API-Aufruf, für den jede Routine einen eigenen Endpunkt mit Zugangstoken erhält; oder als Reaktion auf Ereignisse aus GitHub, etwa einen neu geöffneten Pull Request. Die Auslöser lassen sich kombinieren.

Daneben gibt es in Claude Code den Befehl /loop, der einen Prompt innerhalb einer laufenden Sitzung in einem festen oder von Claude selbst gewählten Abstand wiederholt. Der Unterschied ist wichtig: Diese Schleife lebt nur, solange die Sitzung auf dem eigenen Rechner offen ist. Für einen Auftrag, der jeden Morgen zuverlässig laufen soll, ist die Routine das passende Mittel.

Ein Beispiel: offene Änderungen, die niemand mehr beachtet

Angenommen, ein Team liefert viel aus, und immer wieder bleiben Pull Requests tagelang liegen, weil niemand sie im Blick hat. Statt jeden Morgen selbst nachzusehen, übernimmt das eine Routine. Anlegen lässt sie sich im Browser in der Weboberfläche von Claude Code, in der Desktop-App oder im Terminal mit dem Befehl /schedule.

Weil die Routine ohne Rückfragen läuft, muss der Prompt in sich geschlossen sein. Er beschreibt, was zu tun ist, woran Erfolg zu erkennen ist und was der Agent ausdrücklich nicht tun darf:

Prüfe alle offenen Pull Requests im Repository, die seit mehr als
24 Stunden auf ein Review warten.
Für jeden dieser Pull Requests:
- Fasse in zwei Sätzen zusammen, was er ändert.
- Prüfe, ob die CI-Prüfungen grün sind. Wenn nicht, nenne den
  fehlgeschlagenen Schritt.
- Ändere keinen Code und führe nichts zusammen.
Schicke die Übersicht in den Kanal #entwicklung.
Gibt es keine solchen Pull Requests, schicke nichts.

Dieser Auftrag ist bewusst nur lesend. Die Routine erstellt einen Bericht, die Entscheidung bleibt beim Team. Erst wenn sich das über einige Wochen bewährt hat, ist es vertretbar, ihr auch kleinere Korrekturen zu erlauben, etwa das Aktualisieren eines Branches.

Kontingente und Grenzen

Routinen verbrauchen laut Anthropic dasselbe Nutzungskontingent wie gewöhnliche Sitzungen. Zusätzlich gelten stündliche Obergrenzen für die Zahl der Läufe, nach Herstellerangaben etwa 100 geplante Läufe pro Stunde und Konto; ein Tageslimit je Tarif nennt die Dokumentation nicht. Ist das Nutzungskontingent aufgebraucht, laufen Routinen nur weiter, wenn die kostenpflichtige Zusatznutzung freigeschaltet ist. Solche Grenzen ändern sich bei neuen Funktionen häufig, ein Blick in die aktuelle Dokumentation lohnt sich vor der Planung. Jeder Lauf bleibt als eigene Sitzung nachvollziehbar, Routinen lassen sich pausieren, bearbeiten und löschen.

Weitere Funktionen von Claude Code, die für solche Abläufe nützlich sind, etwa Hooks und Subagenten, stellt der Beitrag Claude Code richtig nutzen vor.

Geplante Aufgaben in Codex: wöchentliche Skill-Pflege

Codex von OpenAI ist seit Juli 2026 Teil der ChatGPT-Desktop-App. Die wiederkehrenden Aufträge hießen dort zunächst „Automatisierungen“ (Automations), die Dokumentation nennt sie inzwischen „geplante Aufgaben“ (Scheduled tasks). Sie laufen im Hintergrund: Statt zu warten, bis jemand nach dem Stand fragt, kehrt Codex zur festgelegten Zeit zurück, erledigt die Arbeit und legt das Ergebnis zur Durchsicht vor. Verwaltet werden sie in der Desktop-App oder im Web, nicht in der Codex-CLI.

Zwei Arten von Automatisierungen

Codex unterscheidet zwei Formen. Geplante Aufgaben in einem Chat hängen an einem bestehenden Gespräch und holen Codex wie ein Herzschlag immer wieder in dieselbe Unterhaltung zurück, samt bisherigem Kontext. Eigenständige geplante Aufgaben starten dagegen bei jedem Lauf einen neuen Chat. Sie eignen sich, wenn die Läufe voneinander unabhängig sind und die Ergebnisse getrennt erscheinen sollen.

Erst im Gespräch erproben, dann automatisieren

Die Dokumentation gibt einen Rat, der für Einsteiger der wichtigste sein dürfte: Den Prompt zuerst von Hand in einem normalen Gespräch ausprobieren und so lange verfeinern, bis Vorgehen und Ergebnis stimmen. Erst dann wird daraus eine Automatisierung. Wer diesen Schritt überspringt, automatisiert womöglich einen Auftrag, der schon beim ersten Lauf ins Leere geht, und merkt es erst Tage später.

Ein Beispiel: Skills pflegen, die im Alltag haken

Angenommen, ein Team arbeitet mit einer Reihe von Skills für Codex, etwa für Release-Notizen oder Datenbankmigrationen. Einige davon funktionieren nicht zuverlässig, aber niemand findet Zeit, sie zu verbessern. Eine eigenständige Automatisierung kann einmal pro Woche die Sitzungen der vergangenen Tage durchsehen. Gab es beim Einsatz eines Skills wiederholt Probleme, schlägt sie eine Verbesserung vor. Tauchte eine Aufgabe häufig auf, für die es noch keinen Skill gibt, entwirft sie einen. Der Prompt sollte festhalten, dass neue Skills nur mit guter Begründung entstehen und jede Änderung gemeldet wird. Der wöchentliche Takt sorgt dafür, dass genug Material für eine sinnvolle Auswertung zusammenkommt.

Interessant wird das, weil Skills nach Angaben von OpenAI selbst wieder Automatisierungen anlegen oder ändern können. So entsteht ein verschachteltes System, in dem ein Loop weitere Arbeit anstößt, etwa einen Subagenten, der einen neuen Skill gegen den Hauptbranch erprobt. Das ist technisch reizvoll, macht die Abläufe aber auch schwerer zu überblicken. Für den Anfang empfiehlt es sich, solche Vorschläge nur als Bericht ausgeben zu lassen und selbst zu entscheiden, was übernommen wird.

Sandbox, Arbeitsbereiche und Triage

Zwei Hinweise aus der Dokumentation verdienen Aufmerksamkeit. Erstens laufen Automatisierungen unbeaufsichtigt mit den Standardeinstellungen der Sandbox, also des abgeschotteten Bereichs, in dem Codex Befehle ausführen darf. Steht sie auf „nur lesen“, scheitern alle Schritte, die Dateien ändern oder auf das Netz zugreifen. Wer der Automatisierung mehr erlaubt, sollte das bewusst und so eng wie möglich tun. Zweitens können häufige Läufe mit eigenen Arbeitsbereichen mit der Zeit viele Worktrees ansammeln, die man regelmäßig aufräumen sollte. Die Ergebnisse landen gesammelt in der Ansicht „Scheduled“, die als Posteingang dient, sodass sie sich nacheinander durchsehen lassen.

Kosten, Abbruchkriterien und Aufsicht

So bequem Loops sind, sie haben zwei typische Schwachstellen, und beide hängen zusammen.

Unklare Ziele kosten Geld

Ein Agent, der in einer Schleife arbeitet, Subagenten startet und so lange nachbessert, bis ein Ziel erreicht ist, verbraucht stetig Rechenzeit. Ist das Erfolgskriterium schwammig, arbeitet er weiter, ohne voranzukommen. Bei Abonnements äußert sich das in aufgebrauchten Kontingenten, bei Abrechnung über eine API direkt in der Rechnung. Hilfreich sind deshalb harte Grenzen: eine Höchstzahl an Durchläufen, ein Zeitlimit und ein Budget, dessen Überschreiten den Loop beendet.

Prompts für Loops verdienen mehr Sorgfalt

Im Gespräch fällt ein missverständlicher Prompt sofort auf, weil Sie die Antwort lesen. In der Schleife fällt er unter Umständen erst nach Dutzenden Läufen auf. Ein Loop-Prompt sollte deshalb beschreiben, was zu tun ist, woran Erfolg messbar wird, was verboten ist und wann der Agent aufhören oder eine Frage an einen Menschen stellen soll. Wie solche Aufträge präzise werden, zeigt der Beitrag KI-Agenten richtig anleiten. Ein praktischer Kniff: Lassen Sie den Agenten im Gespräch einen Entwurf für das Abbruchkriterium formulieren und schärfen Sie ihn dann selbst nach.

Rechte klein halten, Ergebnisse prüfen

Unbeaufsichtigte Agenten sollten nur die Rechte haben, die der Auftrag erfordert. Ein Berichts-Loop braucht Lesezugriff, keinen Schreibzugriff auf den Hauptbranch. Änderungen gehören in eigene Branches und durchlaufen dasselbe Review wie menschliche Beiträge. Wer Connectoren zu E-Mail, Chat oder Kundendaten einbindet, sollte zusätzlich klären, welche Daten in die Cloud des Anbieters gelangen. Bei personenbezogenen Daten ist das auch eine Frage des Datenschutzes nach DSGVO.

Was das für Ihr Team bedeutet

Loops sind keine Zauberei, sondern eine naheliegende Erweiterung dessen, was Teams ohnehin tun: Wiederkehrende Aufgaben werden automatisiert, nur dass jetzt ein Agent statt eines Skripts arbeitet. Der Nutzen ist dort am größten, wo Aufgaben regelmäßig anfallen, klar beschrieben werden können und ein prüfbares Ergebnis haben. Tägliche Übersichten, das Vorsortieren von Tickets oder das Nachbessern bis zum grünen Test sind gute Kandidaten.

Überschätzt wird dagegen die Vorstellung, man könne ganze Arbeitsbereiche in sich selbst organisierende Agententeams auslagern. Je verschachtelter die Loops, desto schwerer lassen sich Kosten und Fehler nachvollziehen. Unsere Empfehlung: Beginnen Sie mit einem einzigen, nur lesenden Loop, etwa einem morgendlichen Bericht, beobachten Sie die ersten Wochen genau und erweitern Sie Rechte und Umfang erst dann, wenn die Ergebnisse verlässlich sind.

Wer prüfen möchte, welche Abläufe im eigenen Unternehmen sich für solche Agenten eignen, findet Unterstützung bei unserer Prozessoptimierung und Automatisierung. Für Entwicklerteams, die KI-Werkzeuge in ihre tägliche Arbeit einbinden wollen, bieten wir Beratung und Seminare zum Thema KI in der Webentwicklung an.

Häufige Fragen zu KI-Agenten-Loops

Braucht man Programmierkenntnisse für den ersten Loop?

Für einfache Fälle nicht. Eine Routine oder Automatisierung wird in normaler Sprache beschrieben, Zeitplan und Repository wählt man in der Oberfläche aus. Hilfreich ist aber, die Ergebnisse beurteilen zu können. Sobald ein Loop Code ändert, sollte jemand im Team den Code auch prüfen können.

Worin unterscheidet sich ein zeitgesteuerter Loop von einem Goal-Loop?

Ein zeitgesteuerter Loop startet zu einem Termin und endet, wenn sein Durchlauf abgeschlossen ist. Ein Goal-Loop endet erst, wenn ein bestimmtes, überprüfbares Ergebnis erreicht ist, etwa wenn alle Tests bestehen, oder wenn eine vorher gesetzte Grenze greift. Der erste richtet sich nach dem Kalender, der zweite nach dem Resultat. Goal-Loops sind deshalb die anspruchsvollere und potenziell teurere Variante.

Wie lässt sich verhindern, dass ein Loop unnötig Ressourcen verbraucht?

Mit einem messbaren Erfolgskriterium, harten Grenzen für Durchläufe und Laufzeit sowie einem engen Auftrag. Beobachten Sie die ersten Läufe aufmerksam und prüfen Sie den Verbrauch, bevor Sie den Takt erhöhen oder dem Agenten mehr Freiheiten geben.

Laufen Routinen und Automatisierungen auf dem eigenen Rechner?

Routinen in Claude Code laufen nach Angaben von Anthropic in dessen Cloud-Umgebung und brauchen keinen eingeschalteten Rechner. Bei Codex hängt es davon ab, wo die Automatisierung eingerichtet ist und in welcher Umgebung sie arbeitet. Schleifen innerhalb einer Sitzung, etwa mit /loop in Claude Code, enden dagegen, sobald die Sitzung geschlossen wird.