Agenten-Retries: Warum ein Timeout keine fehlgeschlagene Aktion beweist

Wenn die Antwort ausbleibt, ist der Ergebniszustand offen

Ein Agent ruft ein Tool auf, das eine Ressource anlegt. Die Antwort bleibt aus, der Request läuft in einen Timeout. Ist die Aktion passiert oder nicht?

Diese Frage entscheidet, ob ein Harness automatisch wiederholen darf. Meine Antwort ist eng gefasst: Ein schreibender Tool-Aufruf darf nur dann automatisch wiederholt werden, wenn für genau diese Operation gesichert ist, dass sie sich ohne zusätzliche Seiteneffekte wiederholen lässt. Fehlt diese Zusage, muss der offene Ergebniszustand sichtbar werden.

Das Dilemma des Aufrufers

Eine Singleton-Workload verträgt höchstens eine EC2-Instanz zu jeder Zeit. Der Provisionierungsprozess ruft die RunInstances-API auf und bekommt, etwa wegen eines Netzwerk-Timeouts, keine Antwort — dieses Szenario beschreibt Malcolm Featonby in der AWS Builders’ Library. Damit ist offen, ob die Workload läuft. Ein einfacher Retry kann zu mehreren Workloads führen, mit entsprechend schweren Folgen.

Der Ausweg ohne Hilfe der API ist eine Reconciliation: nachsehen, ob die Workload läuft. Die Quelle nennt das „a lot of heavy lifting“ für einen Randfall, der relativ selten auftritt — und selbst danach bleibt Unsicherheit. Was, wenn die Ressource existiert, aber von einem anderen Provisionierungsprozess erzeugt wurde? In einfachen Fällen ist das egal. In komplexeren kann laut AWS gerade diese Herkunft entscheidend sein.

Für Agentensysteme steckt darin die Warnung. Ein Agent, der nach einem Timeout „nochmal probieren“ als Default wählt, steht vor demselben offenen Ergebniszustand. Und ein Agent, der stattdessen selbst nachsieht, baut sich genau das Heavy Lifting ins Harness, das die Quelle als teuren Sonderweg beschreibt.

Idempotenz ist ein Vertrag, keine Vermutung

Für automatische Retries reicht es nicht, dass zwei Aufrufe gleich aussehen. Entscheidend ist ihr beabsichtigter Effekt: Der zweite Aufruf darf keine zusätzliche Ressource, keine zweite Buchung und keine weitere Nachricht erzeugen.

Dieses Wissen kann das Harness nicht aus einem Timeout ableiten. Es braucht einen belastbaren Vertrag für die konkrete Operation oder einen Prüfpfad, der den tatsächlichen Zustand eindeutig ermittelt. Ohne eine dieser beiden Voraussetzungen bleibt nur die sichere Eskalation: Fehler anzeigen, Kontext erhalten und keine weitere schreibende Aktion auslösen.

Die Retry-Erlaubnis gehört deshalb an die Operation. Ein pauschaler Schalter wie „bei Netzwerkfehlern wiederholen“ ist für lesende Zugriffe oft praktisch, für schreibende Tools aber gefährlich.

Warum der Service Wiederholungen erkennen muss

Eine idempotente Operation lässt sich laut AWS Builders’ Library ohne zusätzliche Seiteneffekte erneut übertragen — eine Eigenschaft, die in verteilten Systemen sehr nützlich ist. Der Nutzen für den Client ist erheblich: Ein Vertrag, der Nicht-Validierungs-Fehler durch sichere Wiederholung auflösbar macht, spart große Teile des Fehlerbehandlungscodes. Der Preis dafür landet in der Service-Implementierung.

Dort liegt die eigentliche Herausforderung. In einem verteilten System mit vielen Clients und vielen gleichzeitigen Requests muss der Service erkennen, dass ein Request die Wiederholung eines früheren ist. Featonby diskutiert den naheliegenden Weg, ein synthetisches Token aus den Request-Parametern abzuleiten, etwa einen Hash — jeder Request desselben Aufrufers mit identischen Parametern gälte dann als Duplikat. Laut AWS trägt dieser Ansatz nicht in allen Fällen.

Hier liegt die Grenze, die ein Harness nicht selbst schließen kann: Ob ein zweiter Aufruf als Wiederholung oder als neues Vorhaben zählt, entscheidet die Gegenseite.

Was das für ein Agentenharness heißt

Die Retry-Automatik der AWS-SDKs zeigt, wofür ein solcher Vertrag gut ist. Einige AWS-SDK-Implementierungen wiederholen laut AWS Builders’ Library automatisch Requests, die an Netzwerk-IO-Problemen, serverseitigen Fehlern oder Rate-Limiting scheitern. Das reduziert die Zahl der Randfälle im Client und damit den undifferenzierten Boilerplate-Code in aufrufenden Services — allerdings nur, weil auf der Serverseite ein Idempotenzvertrag dahintersteht.

Dieselbe Verlagerung — Zuständigkeit außerhalb des Agenten statt Urteil im Modell — findet sich dort, wo Zuständigkeiten bewusst außerhalb des Agenten liegen. Und um zu sehen, wie oft ein Harness überhaupt wiederholt, brauchst du Ausführungsspuren; Agenten-Traces mit Bewertung sind dafür der naheliegende Ort.

Die Grenze für automatische Retries

Die Mindestregel ist schmal, aber belastbar: Automatische Wiederholung nur für schreibende Tool-Aufrufe, deren Semantik nachweislich idempotent ist. Diese Grenze liegt außerhalb des Agenten, weil die Gegenseite entscheidet, was als Duplikat gilt. Für das Harness heißt das: Fehlt dieses Wissen, wird der Fehler sichtbar gemacht statt weggeretryt. Ein Modell, das vorsichtig sein soll, ersetzt diesen Vertrag nicht.