KI-Agenten: So steuert der Agent Loop Ablauf und Abbruch

Das Modell schlägt den nächsten Schritt vor. Die Software entscheidet, ob dieser Schritt zulässig ist, protokolliert das Ergebnis und prüft, ob ein weiterer Modellaufruf erlaubt ist. Diese Aufgabenteilung bildet die Grundlage für den ersten eigenen Agenten ebenso wie für die Fehlersuche bei einem Lauf, der einfach nicht enden wollte.

Das hier beschriebene Verhalten der Frameworks wurde am 24. Oktober 2026 anhand der jeweils aktuellen Herstellerdokumentation geprüft. Der Vergleich ordnet ein, was die einzelnen Frameworks zählen und an welcher Stelle ihre Steuerungsmechanismen greifen. Die Beispiele mit Support-Tickets und die vorgeschlagenen Regeln dienen der Veranschaulichung; sie sind keine gemessenen Ergebnisse aus dem Produktivbetrieb.

Wie funktioniert der Agent Loop bei KI-Agenten?

Der grundlegende Ablauf lautet Modellaufruf → Tool-Aufruf → Beobachtung → Wiederholung. Ein Ausstieg ist immer dann vorgesehen, wenn weitere Arbeit unnötig oder nicht erlaubt ist.

Das lässt sich mit einem Disponenten vergleichen, der einen Techniker koordiniert: Der Disponent bestimmt den nächsten Auftrag, der Techniker führt ihn aus, und sein Arbeitsbericht liefert die Grundlage für die nächste Entscheidung. Ein Auftrag zur Maschinenprüfung ist noch keine Prüfung. Und eine beruhigende Nachricht belegt noch keine gelungene Reparatur.

In der Software übernimmt ein großes Sprachmodell, kurz LLM, die Rolle des Disponenten. Der Techniker ist ein Tool: eine Funktion, die eine Datenbank abfragt, Dokumente durchsucht, einen Befehl ausführt oder einen Datensatz ändert. Die Laufzeitumgebung besteht aus dem Code, der beide verbindet.

Bei einer beispielhaften Aufgabe zum Entwerfen einer Ticketantwort könnte das Protokoll so aussehen: Der erste Modellaufruf fordert das Ticket an, der zweite die passende Richtlinie, der dritte liefert einen Entwurf auf Grundlage beider Quellen. Das sind 3 Modellaufrufe und 2 Tool-Ausführungen innerhalb einer einzigen Anfrage an die Anwendung. Muss der Versand freigegeben werden, kann die Entwurfsarbeit bereits abgeschlossen sein, während die Freigabe noch aussteht.

Aufgabenzustand und Gesprächsprotokoll sollten getrennt bleiben. Aus dem Zustand muss hervorgehen, welches Ticket bearbeitet wird, welche Richtlinie als Grundlage akzeptiert wurde, ob ein Entwurf vorliegt und ob der Versand erlaubt ist. Das Protokoll erklärt, wie dieser Stand zustande kam. Muss das Modell all das immer wieder aus einem wachsenden Gespräch erschließen, wird die Überwachung der Aufgabe schwieriger.

Was bringt ein Agent mit Ausführungsschleife?

Ein solcher Agent kann seine nächste Aktion anhand des neuesten Ergebnisses auswählen. Bei einem festen Workflow steht die Reihenfolge bereits fest: Ticket abrufen, Richtlinie abrufen, Entwurf erstellen. Die adaptive Schleife ist sinnvoll, wenn erst das Ergebnis einer Aktion zeigt, welcher nächste Schritt nützlich ist. Fehlt diese Ungewissheit, genügt die feste Abfolge.

Wie passt der ReAct Agent in diesen Ablauf?

Der ReAct Agent Loop verbindet Schlussfolgern und Handeln: Das Modell nutzt Beobachtungen als Grundlage für die nächsten Aktionen. Das ursprüngliche ReAct-Projekt beschreibt, wie sich Überlegungen und Aktionen in einer Umgebung abwechseln. Für die Überwachung einer Anwendung sollten angeforderte Aktionen, Beobachtungen und Ergebnisse erfasst werden. Ein ausformulierter Fortschrittsbericht ersetzt keine Ausführungsbestätigung.

Welche drei Abbruchbedingungen braucht ein Agent im Produktivbetrieb?

Es braucht drei bewusst vorgesehene Ausgänge: Aufgabe abgeschlossen, Limits ausgeschöpft und menschliche Entscheidung erforderlich. Das sind Kategorien für den Systementwurf, keine Behauptung, jedes SDK stelle dieselben drei Schalter bereit. Auch Abstürze, Stornierungen und nicht behebbare Fehler müssen ausdrücklich behandelt werden.

Beenden, sobald die Aufgabe erledigt ist

Noch vor dem ersten Modellaufruf muss feststehen, was als Abschluss gilt. Bei einem Schreibassistenten kann das ein gültiger Entwurf mit den relevanten Quellenverweisen sein. Bei einem Assistenten, der selbst Aktionen ausführt, kann zusätzlich ein Beleg für eine abgeschlossene Schreiboperation erforderlich sein.

„Das Modell fordert keine weiteren Tools an“ und „die gewünschte Aufgabe wurde erfolgreich erledigt“ sind zwei unterschiedliche Aussagen. Die erste ist ein Signal der Laufzeitumgebung. Die zweite braucht aufgabenspezifische Belege. Ein Modell kann auch aufhören, weil es nicht weiterkommt. Die Anwendung sollte den Vorgang dann als blockiert oder unvollständig erfassen, statt ihn als Erfolg auszugeben.

Eine gescheiterte Validierung sollte die Schleife nicht automatisch wieder in Gang setzen. Auch ein Korrekturversuch muss auf die Limits desselben Auftrags angerechnet werden. Andernfalls kann die Validierung selbst zur Ursache endloser Wiederholungen werden.

Bei einem erreichten Limit stoppen

Für Schritte, Ressourcenverbrauch und verstrichene Zeit sind voneinander unabhängige Limits nötig. Eine Schrittgrenze begrenzt die Wiederholung. Ein Token- oder Kostenbudget begrenzt den Verbrauch. Eine Frist verhindert, dass ein langsames Modell oder Tool den Auftrag unbegrenzt offenhält. Keines dieser Limits ersetzt die anderen.

Limits müssen geprüft werden, bevor neue Arbeit zugelassen wird; nach Abschluss wird der tatsächliche Verbrauch erfasst. Ein Zähler für abgeschlossene Aufrufe kann nicht verhindern, dass eine bereits laufende Anfrage weiter Ressourcen verbraucht. Verspricht die Anwendung eine harte Obergrenze, muss sie vor dem Start Kapazität für den nächsten Vorgang reservieren und gleichzeitig laufende Arbeit berücksichtigen.

Limits gehören um die gesamte fachliche Aufgabe, nicht nur um einen einzelnen SDK-Aufruf. Ein erneuter Versuch, die Fortsetzung nach einer Freigabe oder ein untergeordneter Agent darf nicht unbemerkt ein neues Kontingent erhalten. Ist zusätzliche Arbeit gerechtfertigt, muss die Anwendung das Kontingent ausdrücklich erweitern.

Human in the Loop: vor der Aktion auf Freigabe warten

Ein KI-Agent mit menschlicher Freigabe muss vor dem genehmigungspflichtigen Vorgang pausieren. Dazu werden die vorgeschlagene Aktion, ihr Ziel und die relevanten Argumente angezeigt. Der ausstehende Aufruf und der aktuelle Aufgabenzustand werden gespeichert; danach wartet das System auf eine ausdrückliche Entscheidung.

Beim Ticketassistenten gilt die Freigabe für genau die vorgesehene Antwort an genau den vorgesehenen Empfänger. Die Zustimmung zu einem Entwurf darf keine pauschale Erlaubnis für spätere Nachrichten werden. Ändert das Modell nach der Freigabe den Empfänger oder den Inhalt, muss die Aktion erneut bewertet werden.

Eine Pause wird als awaiting_approval erfasst, nicht als completed. Eine Ablehnung muss zu einer festgelegten Alternative oder zum Stopp führen. Sie darf keine Serie von Versuchen auslösen, denselben Vorgang über ein anderes Tool doch noch auszuführen. Der Leitfaden zu Human in the Loop behandelt Freigabewarteschlangen und Eskalation.

Ein einfacher Agent Loop als Pseudocode

Die Schleife bleibt übersichtlich, wenn jeder Vorgang von Regelprüfungen eingerahmt wird. Das folgende Beispiel ist Pseudocode, kein ausführbarer SDK-Code. Die Grenze von 8 Modellaufrufen ist eine beispielhafte Entscheidung der Anwendung. Welche Limits passen, ergibt sich aus der Aufgabe und den beobachteten Ausführungsprotokollen.

state = new_job(task, max_model_calls=8, budget, deadline)

while true:
    if limit_reached(state):
        return stop("limit", partial_result=state)

    reserve_capacity_or_stop(state, next_model_call)
    response = call_model_with_deadline(state)
    record_model_call_usage_and_response(state, response)

    if response.is_final and not response.tool_calls:
        return validate_and_finish_or_stop_incomplete(response, state)

    if not response.tool_calls:
        return stop("no_action", partial_result=state)

    for index, call in enumerate(response.tool_calls):
        decision = validate_and_authorize(call, state)
        if decision == "denied":
            return stop("denied", partial_result=state)
        if decision == "needs_human":
            return pause_and_save(state, response.tool_calls[index:])

        reserve_capacity_or_stop(state, call)
        observation = execute_with_timeout_and_retry_cap(call)
        record_tool_usage(state, observation)
        append_matching_tool_result(state, call, bounded(observation))

    if no_progress(state):
        return stop("stalled", partial_result=state)

Hinter den Namen der Hilfsfunktionen stehen wichtige Anforderungen. Reservierungen müssen bereits laufende Arbeit berücksichtigen. Wiederholungen von Tool-Aufrufen brauchen Grenzen. Bei einer Zeitüberschreitung mit ungewissem Ergebnis einer Schreiboperation muss das System stoppen oder den tatsächlichen Zustand klären, bevor es einen neuen Versuch startet. Ein fataler Modell- oder Tool-Fehler beendet den Lauf mit einem protokollierten Fehler, statt in die nächste Iteration überzugehen.

Beim Speichern einer Pause müssen die verbleibenden Tool-Aufrufe, bereits abgeschlossene Ergebnisse und das verbrauchte Kontingent mitgesichert werden. Die Fortsetzung greift diese gespeicherte Arbeit auf und prüft Berechtigungen sowie Limits erneut. Wer die gesamte Aufgabe von vorn startet, kann bereits ausgeführte Änderungen wiederholen.

Entscheidend ist die Position der Prüfungen: Die Freigabe erfolgt vor der Tool-Ausführung, die Verbrauchserfassung nach Abschluss der Arbeit. Eine neue Iteration darf nicht allein deshalb beginnen, weil das Modell sie angefordert hat.

Wie die Frameworks den Agent Loop steuern

OpenAI Agents SDK, Claude Agent SDK, Vercel AI SDK und LangGraph kapseln die Schleife unterschiedlich. Vor dem Vergleich von Optionsnamen steht deshalb die Frage: Was wird gezählt, und an welcher Stelle greift ein Stopp?

Diese Bezeichnungen stammen aus der jeweiligen Dokumentation zum OpenAI-Loop, zum Claude-Loop, zum Vercel-Loop und zur LangGraph Graph API. Die Quellen zum jeweiligen Freigabeverhalten sind in den folgenden Abschnitten verlinkt.

OpenAI Agents SDK: Der Runner steuert die Fortsetzung

Im OpenAI Agents SDK ruft der Runner das Modell auf, führt angeforderte Tools aus, ergänzt deren Ergebnisse und setzt den Lauf fort. Bei einer Übergabe wechselt der aktive Agent; der Lauf geht weiter. Als reguläres Ende dokumentiert ist eine Ausgabe des erwarteten Typs ohne Tool-Aufrufe. Wird max_turns überschritten, löst das SDK MaxTurnsExceeded aus, sofern dies nicht abgefangen wird. OpenAI-Dokumentation zur Agentenausführung.

Für einen Ticketassistenten bietet das einen klaren Ansatzpunkt, um die Zahl der Modellaufrufe zu begrenzen. Die Grenze dieses Mechanismus liegt im Unterschied zwischen einem beendeten Lauf und einer abgeschlossenen fachlichen Aktion: Das erwartete Ausgabeformat muss festgelegt und die für die Aufgabe nötigen Belege müssen geprüft werden.

Für Freigaben können Python-Tools needs_approval deklarieren. Ausstehende Aufrufe erscheinen dann in interruptions. Der RunState wird gespeichert, die Freigabe oder Ablehnung angewendet und der Lauf anschließend fortgesetzt. Ein pausierter Lauf ist keine neue Nutzeranfrage. OpenAI-Dokumentation zu Human in the Loop.

Claude Agent Loop: Durchläufe und Kosten begrenzen

Das Claude Agent SDK enthält die Schleife, auf der Claude Code aufbaut, einschließlich der Tools für Dateien und Befehle. Die Option maxTurns zählt Durchläufe mit Tool-Nutzung; maxBudgetUsd legt einen Schwellenwert für die geschätzten Kosten fest. Ohne gesetzte Werte sind beide unbegrenzt. In Python heißen die Optionen max_turns und max_budget_usd. Dokumentation zum Claude Agent Loop.

Der Ergebnisuntertyp muss ausgewertet werden: success, error_max_turns und error_max_budget_usd stehen für unterschiedliche Ausgänge. Im Single-Shot-Modus folgt auf ein Fehlerergebnis eine Exception. Deshalb müssen sowohl das Ergebnis als auch der Fehlerpfad behandelt werden. Ergebnisbehandlung bei Claude.

Ebenso sorgfältig müssen die Berechtigungen behandelt werden. allowedTools genehmigt die aufgeführten Tools automatisch. Wird ein Tool nicht aufgeführt, ist es dadurch nicht entfernt. Im Standardmodus für Berechtigungen landen Aufrufe bei canUseTool, wenn sie eine Freigabe benötigen und keine Erlaubnisregel auf sie zutrifft. Bevor das SDK unbeaufsichtigt Schreiboperationen ausführt, muss die gesamte Berechtigungsrichtlinie geprüft werden. Berechtigungen bei Claude.

Bei der Verbrauchserfassung über untergeordnete Agenten hinweg unterscheidet Claude zwischen usage für die Hauptschleife und modelUsage beziehungsweise model_usage in Python für den gesamten Agentenbaum. Für die Untersuchung des Gesamtverbrauchs einer Aufgabe muss die passende Summe herangezogen werden. Claude-Dokumentation zu Kosten und Verbrauch.

Den Einstieg in die Implementierung bietet der Leitfaden zum Claude Agent SDK auf dieser Website.

Vercel AI SDK: stopWhen entscheidet über den nächsten Schritt

Im Vercel AI SDK steuert stopWhen die Fortsetzung. Die aktuelle Dokumentation verwendet isStepCount für eine Schrittgrenze und erlaubt mehrere Bedingungen; sobald eine davon zutrifft, stoppt der Lauf. ToolLoopAgent ist standardmäßig auf 20 Schritte eingestellt, generateText und streamText dagegen auf eine Generierung. Welcher Einstiegspunkt verwendet wird, macht also einen Unterschied. Schleifensteuerung bei Vercel, Dokumentation zu Tool-Aufrufen.

Ein Schritt umfasst eine Generierung und die zugehörigen lokalen Tool-Ausführungen. Entscheidend ist: stopWhen wird ausgewertet, wenn der letzte Schritt Tool-Ergebnisse enthält. Bereits ausgeführte Tool-Aktionen, aus denen diese Ergebnisse stammen, lassen sich damit nicht rückgängig machen. Der Mechanismus steuert also die Fortsetzung; er erteilt keine Freigabe vor einer Aktion. Mehrstufige Aufrufe bei Vercel.

Für eine ausdrückliche Nutzerfreigabe ist der dokumentierte Mechanismus toolApproval vorgesehen. Die ältere Tool-Eigenschaft needsApproval ist in der aktuellen Dokumentation als veraltet gekennzeichnet. Tool-Freigaben bei Vercel.

Zur Kontextverwaltung wird vor jedem Schritt prepareStep ausgeführt. Darüber lassen sich Nachrichten oder Einstellungen ändern. An dieser Stelle kann gezielt der relevante Zustand übergeben werden, statt immer wieder sämtliche Rohergebnisse mitzuschleppen. Vercel prepareStep.

LangGraph und der Agent Loop in LangChain

LangGraph ist eine Laufzeitumgebung für Graphen. Knoten führen Arbeit aus; Kanten verbinden sie und bestimmen, was als Nächstes läuft. Bei einem graphbasierten Agent Loop in LangChain müssen sowohl der Rückweg zum Modell als auch der Weg zu END ausdrücklich definiert werden. In Python begrenzt recursion_limit die Super-Steps des Graphen. Parallel ausgeführte Knoten teilen sich dabei einen Super-Step. Tool-Aufrufe werden damit nicht gezählt. LangGraph Graph API.

recursion_limit gehört auf die oberste Ebene der Aufrufkonfiguration, nicht in configurable. Wird die Grenze erreicht, löst das GraphRecursionError aus. Ein bewusst vorgesehener Abschlussweg sollte normalerweise vor diesem Notausgang zum Ziel führen. Rekursionslimit in LangGraph.

Für eine menschliche Prüfung pausiert interrupt() den Graphen. Dafür werden ein Checkpointer und eine stabile thread_id verwendet; die Fortsetzung erfolgt mit Command(resume=...). Die entscheidende Einschränkung: Beim Fortsetzen beginnt der unterbrochene Knoten wieder von vorn. Code vor der Unterbrechung kann erneut ausgeführt werden. Aktionen mit Außenwirkung gehören deshalb hinter die Freigabe oder müssen idempotent sein: Eine wiederholte Ausführung darf keine zusätzliche Wirkung haben. Unterbrechungen in LangGraph.

Diese explizite Graphstruktur eignet sich, wenn Verzweigungen und ein nach Pausen fortsetzbarer Zustand zentral für die Aufgabe sind. Für einen ersten rein lesenden Assistenten mit einem einfachen Tool-Zyklus genügt zunächst die kleinste Laufzeitumgebung, die die Anforderungen erfüllt.

Warum kommt ein Agent auf 40 Schritte?

Bevor die Grenze erhöht wird, sollte geklärt werden, was sich zwischen den Schritten verändert hat. Ein langer Lauf kann sinnvolle Arbeit leisten, wiederholt scheitern oder nach einem Neustart vergessen haben, was bereits erledigt wurde. An der Zahl allein lässt sich das nicht erkennen.

Endlosschleifen: Wiederholung ohne neue Erkenntnisse

Ein Ticketagent sucht nach einer Richtlinie, erhält keine Treffer und wiederholt dieselbe Suche. Die nächste Beobachtung liefert nichts Neues. Damit kann auch die nächste Entscheidung wieder zur gleichen Aktion führen.

Protokolliert werden sollten der normalisierte Tool-Name samt Argumenten, ein Fingerabdruck des Ergebnisses und ein Merkmal für den Aufgabenfortschritt. Wiederholungen ohne Zustandsänderung sollten eine Prüfung auf Stillstand auslösen. Auch legitime Statusabfragen können sich wiederholen. Für solche Abfragen braucht es deshalb eigene begrenzende Regeln, statt jedes Duplikat als Fehler zu werten.

Vor einem neuen Versuch muss sich etwas ändern: ein Suchbegriff, eine fehlende Kennung, eine verfügbare Datenquelle oder der Umfang der Aufgabe. Lässt sich nichts sinnvoll ändern, sollte die offene Anforderung zurückgemeldet oder Hilfe angefordert werden. „Noch einmal versuchen“ ist für sich genommen keine Strategie zur Fehlerbehebung.

Tool-Fehler: behebbaren Fehler und ungewissen Ausgang unterscheiden

Ein fehlerhaftes Argument, eine verweigerte Berechtigung und ein vorübergehender Dienstausfall erfordern unterschiedliche Reaktionen. Das Modell braucht eine knappe Fehlermeldung, aus der es einen nächsten Schritt ableiten kann. Wiederholungsversuche bei behebbaren Fehlern müssen begrenzt sein. Bei Fehlern, die sich mit den Berechtigungen des Auftrags nicht beheben lassen, muss der Lauf sofort stoppen.

Schwieriger ist eine Zeitüberschreitung beim Schreiben: Die Operation kann erfolgreich gewesen sein, obwohl die Antwort nie ankam. Bevor eine Kundennachricht erneut versendet oder ein weiterer Datensatz angelegt wird, muss der Vorgangsstatus abgefragt oder ein Idempotenzschlüssel verwendet werden. Das ist eine stabile Kennung, an der der Dienst erkennt, dass derselbe beabsichtigte Vorgang gemeint ist.

Erfolgreich erledigte Arbeit muss bei der Fehlerbehebung erhalten bleiben. Wurde das Ticket bereits gelesen, aber die Richtlinie ließ sich nicht abrufen, verursacht ein kompletter Neustart zusätzliche Arbeit und kann bereits eingetretene Änderungen wiederholen.

Wachsender Kontext: Entscheidungen mitführen, Rohdaten begrenzen

Jede Beobachtung konkurriert beim nächsten Modellaufruf mit den Aufgabenanweisungen und bisherigen Belegen um Aufmerksamkeit. Eine umfangreiche Tool-Antwort kann technisch gültig sein und trotzdem die nächste Entscheidung erschweren.

Tool-Ausgaben sollten begrenzt, große Artefakte außerhalb des Prompts gespeichert und kompakte Ergebnisse mit abrufbaren Referenzen zurückgegeben werden. Akzeptierte Vorgaben, Freigaben und bestätigte Aktionen gehören in einen dauerhaft gespeicherten Anwendungszustand. Eine Zusammenfassung darf diese Einträge beschreiben, aber nicht ihre einzige verbleibende Kopie sein.

Das Claude SDK dokumentiert eine automatische Verdichtung nahe der Kontextgrenze und weist darauf hin, dass frühe Anweisungen in der Zusammenfassung verloren gehen können. Gerade deshalb muss kritischer Zustand gezielt erhalten bleiben. Kontextverdichtung bei Claude. Der Erklärartikel zu Context Rot erläutert, warum ein Inhalt zwar ins Kontextfenster passen kann, ohne später zuverlässig nutzbar zu sein.

Das Ausführungsprotokoll muss die Fragen des Betriebs beantworten

Für jeden Auftrag werden die Kennung, die Zahl der Modellaufrufe, die Tool-Versuche, der Verbrauch, die verstrichene Zeit, ausstehende Freigaben und der Stoppgrund erfasst. Für jeden Vorgang wird protokolliert, was angefordert wurde, was abgeschlossen ist und ob sich dadurch der Aufgabenzustand geändert hat.

Modellanfragen, Tool-Ausführungen und Schritte der Laufzeitumgebung brauchen getrennte Zähler. Eine Anzeige von „40 Schritten“ ohne Einheit erklärt den Lauf nicht. Arbeit untergeordneter Agenten und Wiederholungsversuche müssen in die Verbrauchserfassung der übergeordneten Aufgabe einfließen. Der Leitfaden zur Orchestrierung von KI-Agenten erklärt die Zuständigkeiten, wenn Arbeit zwischen Agenten wechselt.

Was wird beim Agent Loop überschätzt?

Mehr Iterationen belegen keinen größeren Fortschritt. Eine Schleife schafft wiederholte Gelegenheiten, Rückmeldungen zu nutzen. Ob die Wiederholung hilft, hängt von der Qualität dieser Rückmeldungen und einer klaren Definition des Erfolgs ab.

Ein Modell, das „fertig“ sagt, hat seinen Teil des Austauschs beendet. Eine Schrittgrenze belegt, dass der Lauf begrenzt war. Beides beweist weder, dass eine Support-Antwort richtig ist, noch, dass eine gewünschte Änderung tatsächlich vorgenommen wurde.

Auch ein Framework nimmt der Anwendung nicht die Aufgabe ab, Berechtigungen, dauerhafte Speicherung und Fehlerbehebung festzulegen. Das Framework liefert die Mechanismen zur Ausführung. Die Anwendung bestimmt, was Erfolg bedeutet und welche Aktionen erlaubt sind.

Die Testschleife eines Agenten ist eine eigene Aufgabe

Eine Testschleife bewertet das Verhalten eines Agenten anhand von Testfällen und Abnahmekriterien. Sie kann die Ausführungsschleife mit einer Prüfinstanz umgeben, die das Ergebnis akzeptiert oder Rückmeldungen für einen weiteren Versuch liefert. LangChains Erklärung zum Loop Engineering unterscheidet zwischen Ausführung, Überprüfung und ereignisgesteuerter Arbeit.

Auch die Prüfinstanz braucht Grenzen. Wird immer wieder ein weiteres Modell gefragt, ob eine Antwort gut ist, kann das das Kontingent aufbrauchen, ohne eindeutige Belege zu liefern. Wo möglich, sind konkrete Prüfungen vorzuziehen: Sind Pflichtfelder vorhanden, stimmen zitierte Datensätze überein, liegt eine Schreibbestätigung vor oder besteht ein erwarteter Test?

Was Entwicklung und Betrieb als Nächstes tun sollten

Für den ersten eigenen Agenten: Mit einer eng umrissenen, rein lesenden Aufgabe, eindeutigen Abschlusskriterien und begrenzten Operationen beginnen. Schreibzugriffe kommen hinzu, sobald die vorgeschlagene Aktion angezeigt, die Berechtigung durchgesetzt und ein uneindeutiges Ergebnis aufgeklärt werden kann. Steht die Reihenfolge schon fest, reicht möglicherweise ein fester Workflow.

Bei der Untersuchung eines teuren Laufs: Wiederholte Aufrufe, Ketten von Wiederholungsversuchen und wachsende Beobachtungen prüfen, bevor das Modell gewechselt oder ein Limit erhöht wird. Entscheidend ist, welcher Schritt nützliche Erkenntnisse geliefert und welcher Zähler den Auftrag tatsächlich gestoppt hat.

Für Teams mit einem zuverlässigen festen Workflow: Den bestehenden Ablauf beibehalten, bis die adaptive Tool-Auswahl ein konkretes Problem löst. Eine Schleife bringt Nutzen, wenn Zwischenergebnisse die nächste Aktion bestimmen. Wiederholung allein ist kein Grund für einen Umbau.

Der konkrete nächste Schritt für Montag: Eine repräsentative Aufgabe auswählen und ihren regulären Abschluss, den Stopp am Limit, die Freigabepause, eine verweigerte Aktion und einen Tool-Fehler durchspielen. Jeder Pfad muss einen klaren Status hinterlassen. Bei einer Fortsetzung müssen sowohl die bereits erledigte Arbeit als auch das verbleibende Kontingent erhalten bleiben.

Häufige Fragen zum Agent Loop

Praktische Leitfäden zur Entwicklung und zum Betrieb von KI-Systemen gibt es im Newsletter.