Agent-Tool-Timeouts: Wiederherstellungspläne, die Wiederholungen verhindern

Ein Timeout ist eine Beobachtung des Clients, kein Urteil über die Arbeit. Der Aufrufer hat aufgehört zu warten. Mehr weiß er nicht. Wenn ein Agent diese Beobachtung in «fehlgeschlagen» umwandelt und einen zustandsändernden Aufruf wiederholt, kann daraus eine zweite Zahlung, eine zweite Bereitstellung, ein zweites Support-Ticket oder ein entfernter Befehl entstehen, der zweimal auf einer ohnehin belasteten Maschine läuft.

Agent-Tool-Timeouts brauchen einen Wiederherstellungsplan, weil Agents schneller handeln als die Menschen, die sie überwachen, und Tool-Ausgaben oft als unumstößliche Wahrheit behandeln. Eine fehlende Antwort ist keine solche Wahrheit. Der Wiederherstellungsweg muss entscheiden, ob er wiederholt, wartet, nach Belegen fragt oder stoppt und eine menschliche Entscheidung verlangt. Lege diesen Weg fest, bevor du einem Agenten erlaubst, folgenreiche Aufrufe auszuführen.

Ein Timeout lässt drei plausible Abläufe offen

Nach einem Client-Timeout gehört die Anfrage zu einem von drei groben Abläufen: Der Dienst hat sie nie erhalten, der Dienst hat sie erhalten und ist noch nicht fertig, oder der Dienst ist fertig geworden, aber die Antwort hat den Client nie erreicht. Netzwerkfehler können auftreten, bevor eine Verbindung geöffnet wird, während der Request-Body übertragen wird, während der Dienst arbeitet oder während die Antwort zurückkommt. Derselbe Ausnahmetyp kann alle vier Fälle abdecken.

Dieser Unterschied bestimmt die nächste Aktion. Wenn eine DNS-Abfrage scheitert, bevor eine Verbindung entsteht, kann eine Wiederholung sinnvoll sein. Wenn der Dienst eine Anfrage zum Löschen einer Ressource akzeptiert und die Antwort verschwindet, kann eine Wiederholung den destruktiven Vorgang erneut ausführen. Wenn der Dienst einen asynchronen Job einreiht, kann eine zweite Übermittlung einen konkurrierenden Job erzeugen, während der erste noch läuft.

HTTP bietet kein magisches Bit, das dem Client verrät, welcher Ablauf eingetreten ist. RFC 9110 beschreibt Request-Methoden und die Bedeutung von Antworten, einschließlich des Unterschieds zwischen sicheren und idempotenten Methoden. Es verspricht nicht, dass ein Client die Ausführung auf dem Server aus einer verlorenen Antwort ableiten kann. Diese Grenze ist physikalisch bedingt, keine fehlende SDK-Option.

Teams vermischen oft zwei getrennte Fragen:

• Kann diese Anfrage erneut gesendet werden, ohne den beabsichtigten Endzustand zu verändern?
• Hat der ursprüngliche Versuch den Dienst tatsächlich erreicht und beeinflusst?

Idempotenz beantwortet die erste Frage. Ein Abgleich beantwortet die zweite. Ein System braucht beides. Ein idempotentes PUT kann gefahrlos wiederholt werden, trotzdem weißt du nach einem Timeout nicht, ob die dadurch ausgelöste nachgelagerte Arbeit abgeschlossen ist. Eine Statusabfrage kann den Ausgang klären, schützt aber nicht vor doppelter Arbeit, wenn der Dienst zwei nicht unterscheidbare Erstellungsanfragen akzeptiert.

Agents brauchen diese Unterscheidung in ihren Tool-Verträgen. Ein einfacher Textfehler wie request timed out lädt zur Improvisation ein. Ein strukturiertes Ergebnis mit outcome: unknown teilt dem Agenten mit, dass er den Wiederholungszweig verlassen und in den Belegzweig wechseln muss.

Den Anfrageweg abbilden, bevor du eine Wiederholung auswählst

Ein brauchbarer Wiederherstellungsplan benennt die Grenzen, an denen Belege entstehen können. Beginne beim Agent-Prozess und gehe dann über Tool-Wrapper, Verbindungspool, Gateway oder Proxy, falls vorhanden, Service-Eingang, Anwendung, dauerhaften Speicher und jeden Worker, der asynchrone Arbeit übernimmt. Ein Timeout an einer Grenze sagt nichts Zuverlässiges über die nächste Grenze aus.

Nimm einen Aufruf zum Erstellen einer Bereitstellung. Der Agent sendet eine Anfrage über ein Tool. Der Client schreibt den vollständigen Request-Body, der Server speichert einen Bereitstellungsdatensatz, dann bricht die Verbindung ab, bevor die Antwort den Client erreicht. Das Tool gibt ein Timeout aus. Der Agent wiederholt den Aufruf mit einer neuen Anfrage. Der Server hat nun zwei Bereitstellungsdatensätze, die aus ihrer jeweiligen Sicht beide gültig sind.

Ändere nun ein Detail: Der Client läuft beim Hochladen des Bodys in ein Timeout, und der Server weist den unvollständigen Body zurück, bevor Anwendungscode ausgeführt wird. Dasselbe Tool kann weiterhin timeout zurückgeben. In diesem Fall kann eine Wiederholung genau eine Bereitstellung erzeugen. Der Aufrufer kann diese Fälle allein anhand des Timeouts nicht unterscheiden.

Notiere, welche Belege jede Komponente liefern kann. Bei einer typischen HTTP-Aktion gehören dazu:

• Client-Zeitstempel, ausgewähltes Ziel, Digest des Request-Bodys und eine vom Aufrufer erzeugte Vorgangs-ID.
• Service-Access-Logs, aus denen hervorgeht, ob der Eingang die Anfrage akzeptiert hat.
• Ein Anwendungsdatensatz, der die Vorgangs-ID zusammen mit einem gespeicherten Ergebnis enthält.
• Worker- oder Queue-Datensätze für Aktionen, die nach der synchronen Anfrage weiterlaufen.
• Ein Lese-Endpunkt, der den aktuellen Zustand oder den Status des Vorgangs zurückgibt.

Netzwerk-Logs dürfen nicht deine einzige Quelle der Wahrheit sein. Ein Load-Balancer-Log kann zeigen, dass Bytes angekommen sind, aber nicht beweisen, dass die Datenbanktransaktion gespeichert wurde. Ein Datenbankdatensatz kann einen Commit belegen, aber möglicherweise nicht, dass ein externer Anbieter eine spätere Nebenwirkung erhalten hat. Der maßgebliche Datensatz muss zu der Aktion passen, die du nachweisen willst.

Beim Versand einer E-Mail ist die vom Anbieter vergebene Kennung der akzeptierten Nachricht ein stärkerer Beleg als ein Anwendungslog mit «Versand wird vorbereitet». Bei einer Datenbankmigration ist eine Migrationstabelle oder ein Transaktionsdatensatz aussagekräftiger als ein Shell-Prozess-Exitcode, den der Aufrufer nie erhalten hat. Beim Erstellen einer Cloud-Ressource ist eine Operations-URL oder ein Ressourcen-Tag mit einer vom Aufrufer erzeugten ID besser als eine wiederholte Erstellungsanfrage.

Idempotenz muss zum Vorgang gehören, nicht zum Versuch

Ein Wiederholungsschema funktioniert nur, wenn jeder Versuch derselben beabsichtigten Aktion dieselbe dauerhafte Kennung trägt. Erzeuge die Kennung vor dem ersten Netzwerkaufruf. Speichere sie zusammen mit der Aktionsbeschreibung. Verwende sie nach einem Neustart des Prozesses, einem Neustart des Tools oder einer Übergabe an einen menschlichen Operator weiter.

Erzeuge keine neue UUID innerhalb einer Wiederholungsschleife. Dieser Ansatz sieht in einer Codeprüfung sorgfältig aus und vereitelt den gesamten Zweck. Der Server sieht jede Wiederholung als neue Anfrage, genau so entstehen doppelte Vorgänge.

Eine Anfrage kann je nach API einen Idempotenzwert in einem Header oder in einem Body-Feld enthalten. Das Transportdetail ist weniger wichtig als die Serverregel. Der Server muss diesen Wert atomar mit dem Vorgang und seinem Ergebnis verknüpfen. Treffen zwei identische Anfragen gleichzeitig ein, muss der Server sie serialisieren oder eine von ihnen das Ergebnis der anderen beobachten lassen. Ein Cache, der abläuft, bevor verzögerte Wiederholungen abgeschlossen sind, bietet keinen zuverlässigen Schutz vor Duplikaten.

Eine praktische HTTP-Anfrage könnte so aussehen:

POST /deployments HTTP/1.1
Content-Type: application/json
Idempotency-Key: op_7d5d4d8e4e5a
X-Correlation-ID: run_42_task_9

{"repository":"api","revision":"a1b2c3d4","environment":"staging"}

Der Server sollte den Idempotenzwert zusammen mit einem Fingerabdruck der relevanten Anfragefelder und der resultierenden Bereitstellungs- oder Vorgangs-ID speichern. Wenn derselbe Wert mit einer anderen Revision oder Umgebung eintrifft, muss er abgewiesen werden. Das erste Ergebnis für eine andere Nutzlast zurückzugeben, würde stillschweigend die falsche Absicht ausführen.

Bei einem asynchronen Vorgang sollte der Server sofort nach Annahme der Arbeit eine dauerhafte Vorgangsreferenz zurückgeben:

{
  "operation_id": "dep_1842",
  "state": "accepted",
  "status_url": "/operations/dep_1842"
}

Nach einem Timeout fragt der Agent nach op_7d5d4d8e4e5a oder dep_1842, bevor er eine weitere Übermittlung in Betracht zieht. Unterstützt die API weder einen Idempotenzwert noch eine Suche nach einer externen Referenz, muss die Schreiboperation bewusst als mehrdeutig eingestuft werden. Für eine wegwerfbare Testressource kann das akzeptabel sein. Für eine autonome Aktion, die Kosten verursacht oder den Produktionszustand ändert, ist es eine schlechte Lösung.

Nenne eine Methode nicht allein deshalb sicher, weil sie POST mit einer Retry-Bibliothek verwendet. Namen von HTTP-Methoden sind Hinweise auf die beabsichtigte Semantik, aber kein Schutz vor einer Serverimplementierung, die Arbeit dupliziert. Lies die Dokumentation der konkreten API und teste das Verhalten bei Duplikaten anschließend selbst.

Agents brauchen einen ausdrücklichen Zustand für unbekannte Ausgänge

Ein Agent sollte von einem Tool, das die Außenwelt verändern kann, nicht nur success oder error erhalten. Er braucht ein drittes Ergebnis: unknown. Dieser Zustand verhindert das gefährlichste Verhalten eines Modells: ein unvollständiges Protokoll als Erlaubnis zu behandeln, eine leicht veränderte Version desselben Befehls zu versuchen.

Verwende einen Ergebniskontrakt, der die fehlgeschlagene Phase festhält und zugleich zugibt, dass diese Phase möglicherweise unsicher ist. Zum Beispiel:

{
  "outcome": "unknown",
  "operation_id": "op_7d5d4d8e4e5a",
  "correlation_id": "run_42_task_9",
  "transport_observation": "response deadline exceeded after request write",
  "retry_allowed": false,
  "reconcile": {
    "method": "GET",
    "path": "/operations/by-id/op_7d5d4d8e4e5a"
  }
}

Das Feld retry_allowed muss aus der Tool- oder Aktionsdefinition stammen, nicht aus einer Vermutung des Agents über englische Verben. Ein Agent kann nicht sicher ableiten, dass create_release harmlos ist, nur weil das Ziel eine Staging-Umgebung ist. Eine Staging-Bereitstellung kann trotzdem Benachrichtigungen senden, ein gemeinsames Kontingent verbrauchen oder einen Release-Kanal verändern.

Lass den Agenten eine begrenzte Wiederherstellungsfolge einhalten:

1. Behalte die beabsichtigte Aktion, Vorgangs-ID, Ziel und Timeout-Beobachtung im Laufdatensatz.
2. Frage die maßgebliche Statusquelle mit derselben Vorgangs-ID oder einer vom Dienst ausgegebenen Referenz ab.
3. Fahre nur bei einem bestätigten Endergebnis fort. Wiederhole die Aktion nur, wenn die Aktionsdefinition dies erlaubt und die Statusquelle keinen angenommenen Vorgang zeigt.
4. Stoppe und lege die Belege vor, wenn der Dienst den Ausgang innerhalb der Wiederherstellungsfrist der Aktion nicht feststellen kann.

Die Abbruchbedingung ist wichtig. Ein Agent, der endlos abfragt, bindet Aufmerksamkeit und kann eine Aufgabe lange nach ihrem eigentlichen Zweck am Leben halten. Ein Agent, der fünf Varianten einer Schreibanfrage ausprobiert, kann anderen ein Aufräumprojekt hinterlassen. Gib jedem Vorgang eine Wiederherstellungsfrist, die getrennt von der Anfragefrist gilt.

Eine menschliche Genehmigung beseitigt einen unbekannten Ausgang nicht von selbst. Eine Genehmigung beantwortet die Frage «Darf dieser Aufrufer diese Aktion versuchen?». Sie beantwortet nicht die Frage «War der vorherige Versuch erfolgreich?». Halte Autorisierungsbelege und Ausführungsbelege sowohl in der Oberfläche als auch in den Logs getrennt.

Lese-Timeouts brauchen eine andere Behandlung als Schreib-Timeouts

Ein Timeout bei einem Lesevorgang birgt meist ein geringeres Duplikatrisiko, kann aber trotzdem zu falschen Agent-Entscheidungen führen. Ein Agent kann beim Auflisten von Ressourcen in ein Timeout laufen, an anderer Stelle eine unvollständige oder veraltete zwischengespeicherte Antwort erhalten und daraus schließen, dass eine Ressource nicht existiert. Dann versucht er eine Erstellung, die mit der Realität kollidiert.

Ordne Lesevorgänge nach der Entscheidung ein, die sie unterstützen. Eine harmlose Aktualisierung eines Dashboards kann mit begrenztem Backoff wiederholt werden. Ein Lesevorgang, der über eine Schreibaktion entscheidet, braucht eine ausdrückliche Konsistenzregel. Bietet der Dienst ein ETag, eine Versions- oder Generationsnummer oder einen Status-Endpunkt für Read-after-Write, solltest du ihn verwenden. Gibt es nur Eventual Consistency, müssen Wartezeit und Abbruchbedingung für den Agenten sichtbar sein.

Vermeide eine allgemeingültige Anzahl von Wiederholungen. Eine kurze Metadatenabfrage verträgt vielleicht zwei schnelle Wiederholungen. Eine Berichtsanfrage, die ein Data Warehouse belastet, braucht möglicherweise eine lange Frist und keine unmittelbare Wiederholung. Ein Aufruf mit 429 Too Many Requests oder einem ausdrücklichen Wiederholungswert des Dienstes muss anders behandelt werden als ein Socket-Timeout. Jeden Fehler als vorübergehendes Netzwerkproblem zu behandeln, verwandelt einen Teilausfall in vermeidbare Last.

Backoff schützt Dienste, löst aber keine Mehrdeutigkeit. Es verteilt doppelte Anfragen über einen größeren Zeitraum. Kombiniere Backoff bei jedem wichtigen Schreibvorgang mit einem Idempotenzwert oder einer Statusabfrage.

Verwende bedingte Schreibvorgänge, wenn die API sie unterstützt. Eine If-Match-Anfrage mit einem bekannten ETag kann verhindern, dass ein Agent eine Ressource überschreibt, die sich seit seinem Lesevorgang geändert hat. Eine Erstellung mit einer vom Client gewählten Ressourcen-ID kann dafür sorgen, dass Wiederholungen auf dasselbe Objekt hinauslaufen. Diese Mechanismen schützen Zustandsübergänge, ersetzen aber keinen Nachweis darüber, ob Nebenwirkungen außerhalb dieser Ressource stattgefunden haben.

SSH verbirgt die entfernte Ausführung hinter einem einzigen unterbrochenen Datenstrom

Bei der Wiederherstellung nach einem SSH-Timeout ist noch mehr Vorsicht nötig als bei HTTP. Eine verlorene SSH-Sitzung kann auftreten, nachdem der entfernte Host einen Befehl gestartet hat, während die Ausgabe übertragen wird, nachdem der Befehl beendet wurde oder während ein Kindprozess nach der Trennung seines Elternprozesses weiterläuft. Eine lokale Shell-Meldung kann nicht sagen, welcher Fall eingetreten ist.

Das gefährliche Muster ist ein langer zusammengesetzter Befehl:

ssh deploy@host 'download-release && migrate-db && restart-service'

Wenn die Verbindung nach migrate-db abbricht, kann eine Wiederholung des vollständigen Befehls die Migration zweimal ausführen oder einen Dienst neu starten, dessen neue Version noch nicht vollständig heruntergeladen wurde. Das Terminalprotokoll hat mehrere Zustandsübergänge zu einem undurchsichtigen Ergebnis zusammengefasst.

Teile die entfernte Arbeit in Vorgänge mit dauerhaften, prüfbaren Markierungen auf. Eine Bereitstellung kann vor dem Start eine Release-ID speichern, Migrationsversionen in der Datenbank festhalten und die aktive Revision über einen lokalen Statusbefehl ausgeben. Ein Wiederherstellungstool verbindet sich erneut und fragt diese Markierungen ab, bevor es irgendetwas anderes tut.

Zum Beispiel kann ein Agent einen entfernten Statusbefehl verwenden, dessen Ausgabe für Maschinen und nicht für Menschen gedacht ist:

ssh deploy@host '/usr/local/bin/release-status --json'

{
  "release_id": "rel_202",
  "phase": "migrated",
  "active_revision": "9f24c1",
  "migration_version": "20250308_02"
}

Die Wiederherstellungsaktion hat nun eine Grundlage für die Entscheidung. Wenn phase den Wert migrated hat, dürfen die Migrationen nicht erneut ausgeführt werden. Meldet der Host keine release_id, darf der Agent den Vorgang nur starten, wenn der entfernte Befehl garantiert, dass das Fehlen bedeutet, dass zuvor keine Ausführung stattgefunden hat. Kann SSH keine Verbindung herstellen, bleibt das korrekte Ergebnis unbekannt. Ersetze es nicht durch eine hoffnungsvolle Wiederholung, wenn die Aktion einen Produktionshost verändert.

Verwende entfernte Sperren mit Bedacht. Eine Sperre kann parallele Läufe verhindern, aber eine veraltete Sperre nach einem Hostausfall kann die Wiederherstellung blockieren. Speichere die Vorgangs-ID und eine Ablaufregel im Sperrdatensatz und ermögliche eine Prüfung, ohne die Sperre blind zu löschen. Ein Aufräumbefehl, der jede alte Sperre entfernt, ist ebenfalls eine zustandsändernde Aktion und braucht eigene Belege.

Sallyport kann SSH-Zugangsdaten aus einem Agent-Prozess heraushalten, während der integrierte Helfer sp-ssh die Verbindung herstellt. Die Trennung der Zugangsdaten macht eine abgebrochene Sitzung aber nicht sicher wiederholbar. Der entfernte Befehl braucht weiterhin eine Vorgangs-ID, dauerhafte Markierungen und einen Weg zum Abgleich.

Audit-Aufzeichnungen helfen bei der Untersuchung, beweisen aber keinen Abschluss

Ein Aktionslog sollte genügend Details bewahren, um Absicht und Wiederherstellung zu rekonstruieren, ohne Geheimnisse zu speichern. Protokolliere die aufrufende Sitzung, den Zeitpunkt, die Zielidentität, die Vorgangs-ID, den Anfrage-Digest oder das Befehlsmuster, das Autorisierungsereignis, das Transportergebnis und den abschließenden Abgleich. Speichere keine Bearer-Tokens, privaten Schlüssel oder unveränderten Request-Bodies, die Zugangsdaten oder personenbezogene Daten enthalten können.

Trenne eine versuchte Aktion von einer abgeschlossenen Aktion. Eine Logzeile wie POST /deployments timeout ist ein Versuchsdaten- satz. Eine spätere Abfrage, die einen Vorgang im Zustand succeeded zurückgibt, ist ein Abschlussbeleg. Bewahre beides auf. Wenn du den ersten Datensatz durch einen abschließenden Erfolg ersetzt, löschst du den nützlichsten Teil des Vorfalls: den Zeitraum, in dem der Aufrufer den Ausgang nicht kannte.

Manipulationsnachweise sind wichtig, wenn ein Agent-Lauf später zu einem Streitfall führt. Du musst beantworten können, welcher Prozess den Aufruf ausgelöst hat, wozu er berechtigt war, ob er ein Ergebnis erhalten hat und wie das Team den Endzustand festgestellt hat. Eine veränderbare Aktivitätstabelle ist leicht durchsuchbar, aber als Beleg schwach, wenn ein kompromittierter Prozess die Historie umschreiben kann.

Sallyport zeichnet Agent-Sitzungen und einzelne Aufrufe in einem schreibgeschützten, verschlüsselten und hashverketteten Audit-Log auf. Mit sp audit verify lässt sich die Kette offline über dem Chiffretext prüfen. Dieser Datensatz kann die Gateway-Aktion und die Historie des Aufrufers zeigen. Maßgeblich dafür, ob die beabsichtigte Arbeit abgeschlossen wurde, bleibt jedoch der entfernte Dienst oder Host.

Verwechsle ein Gateway-Audit-Ereignis nicht mit einer Anwendungstransaktion. Wenn das Gateway eine ausgehende Anfrage protokolliert hat, kann sie trotzdem fehlgeschlagen sein, bevor der Dienst sie gespeichert hat. Wenn der Dienst sie gespeichert hat, hat das Gateway die Antwort möglicherweise nie gesehen. Untersuchungen funktionieren, wenn die Datensätze beider Seiten dieselbe Vorgangs- oder Korrelations-ID verwenden.

Mehrdeutigkeit gezielt testen, bevor ein Ausfall es für dich tut

Ein Timeout-Plan, der noch nie eine verlorene Antwort erlebt hat, ist eine Annahme. Teste genau den Fehlerfall, bei dem der Dienst den Vorgang abschließt, der Client aber das Ergebnis verliert. Diesen Fall lassen viele Teams aus, weil gewöhnliche Happy-Path-Test-Doubles ihn nicht darstellen können.

Baue einen Test-Endpunkt oder eine Proxy-Fixture, die eine Anfrage annimmt, ihren dauerhaften Datensatz speichert und dann die Antwort verzögert oder verwirft. Sende dieselbe Vorgangs-ID zweimal. Prüfe, dass der Dienst einen logischen Vorgang zurückgibt, dass der Agent nach dem Timeout den Status abfragt und dass die Audit-Spur beide Versuche sowie das Abgleichsergebnis bewahrt.

Teste danach den umgekehrten Fall: Unterbreche die Anfrage, bevor der Dienst sie annimmt. Stelle sicher, dass die Wiederherstellung nur dann wiederholen kann, wenn sie keinen Vorgangsdatensatz findet. Beide Tests können beim Client dieselbe Ausnahme erzeugen. Der Tool-Vertrag muss zu unterschiedlichen Aktionen führen, weil sich die Belege des Dienstes unterscheiden.

Übe auch diese Fälle:

• Der Dienst nimmt den Vorgang an, aber sein Worker bleibt über die Wiederherstellungsfrist des Agents hinaus ausstehend.
• Zwei Agent-Prozesse übermitteln nahezu gleichzeitig dieselbe Vorgangs-ID.
• Der Status-Endpunkt ist nicht verfügbar, während der primäre Schreib-Endpunkt funktioniert.
• Ein SSH-Befehl startet einen Kindprozess, dann endet die Verbindung vor der letzten Ausgabe.
• Ein Mensch setzt einen pausierten Lauf fort, nachdem ein anderer Operator die Aktion bereits abgeglichen hat.

Der letzte Fall deckt ein Problem auf, das im echten Betrieb häufig auftritt: Der Wiederherstellungszustand muss außerhalb des Gesprächsgedächtnisses des Agents liegen. Speichere die Vorgangs-ID und die aktuelle Erkenntnis in einem dauerhaften Laufdatensatz. Ein neu gestarteter Agent sollte diesen Datensatz lesen und mit dem Abgleich fortfahren, statt eine neue Aktion zu erfinden, weil er das frühere Protokoll nicht sehen kann.

Richte Alarme für unbekannte Ausgänge ein, deren Wiederherstellungsfristen überschritten sind. Alarmiere nicht bei jedem ersten Timeout, wenn gewöhnliche Wiederholungen sichere Lesevorgänge auflösen. Alarmiere, wenn bei einer folgenreichen Schreibaktion ein bestätigter Endzustand fehlt, wenn doppelte Vorgangs-IDs unterschiedliche Nutzdaten tragen oder wenn entfernte Markierungen dem erwarteten Ablauf widersprechen. In diesen Fällen braucht es einen Menschen, bevor der Agent weitermacht.

Ein Wiederherstellungsplan sollte eine Verweigerung selbstverständlich machen

Das stärkste Verhalten nach einem Timeout ist oft eine Verweigerung: «Ich kann nicht bestätigen, ob die Bereitstellungsanfrage abgeschlossen wurde, deshalb sende ich keine weitere.». Das ist kein Tool-Fehler. Es ist die richtige Reaktion auf fehlende Belege bei einer irreversiblen oder teuren Aktion.

Mach diese Reaktion nützlich. Zeige die Vorgangs-ID, das Ziel, den zuletzt bestätigten Zustand, die Zeitstempel und die genaue Statusabfrage oder entfernte Prüfung, die den Fall klären würde. Gibt es keine maßgebliche Abfragemöglichkeit, sag das ausdrücklich und übergib die Entscheidung an jemanden, der die Folgen eines Duplikats versteht.

Teams sträuben sich dagegen, weil eine Wiederholung produktiv wirkt und eine Pause langsam. Nach genügend doppelten Schreibvorgängen und halbfertigen Bereitstellungen wird der Unterschied deutlich. Eine Minute für den Abgleich ist günstiger, als später festzustellen, dass zwei Systeme jeweils glauben, die eine Aktion ausgeführt zu haben, die dein Agent ausführen sollte.

Beginne mit Schreibvorgängen, die Geldbewegungen, externe Nachrichten, Releases, Zugriffsänderungen und das Löschen von Daten auslösen. Verlange für jeden davon drei Antworten vom API-Verantwortlichen: Welche Kennung bindet Wiederholungen an einen Vorgang? Wo kann ein Aufrufer das Ergebnis abfragen? Welcher Beleg bleibt, wenn die Verbindung abbricht? Fehlt eine Antwort, muss das Tool unknown zurückgeben und eine bewusste menschliche Entscheidung verlangen, statt dem Agenten das Raten beizubringen.