Agentenbetrieb und Nachweise /
Der Agent läuft weiter. Beim Mailversand kann der Abschluss unklar bleiben.
Ein Agent hat einen Antwortentwurf fertig, ruft das Versandwerkzeug auf und verliert seine Laufzeit, bevor ein Ergebnis zurückkommt. Hat der Maildienst die Nachricht schon angenommen? Der gespeicherte Gesprächsverlauf kann diese Frage offenlassen. Genau an dieser Stelle lohnt sich ein Blick in die Replayregeln von PiHarness.
PiHarness setzt dauerhafte Agentenarbeit fort und behandelt unterbrochene Werkzeuge nach ihrer Replayklasse. Ein unbekannter Versandabschluss braucht zusätzlich einen belastbaren Providerbeleg.
Eine neue Integration mit ausdrücklich vorläufiger API
Cloudflare hat am 2026-10-02 die Integration des Pi Durable Harness in sein Agents SDK angekündigt. Die Klasse PiHarness verbindet den Agentenablauf mit dem Lebenszyklus eines Durable Objects. Cloudflare beschreibt damit lange laufende Arbeit, deren Zustand Neustarts oder Unterbrechungen überstehen soll. Gleichzeitig kennzeichnet die Dokumentation PiHarness als Beta und Pi Durable als experimentelles Paket; die Schnittstelle dürfte sich noch ändern. Die beiden Pi-Pakete sind optionale Peer-Abhängigkeiten des SDK. Ein Entwickler muss sie für diesen Ablauf hinzufügen, erhält sie also nicht als Voraussetzung jedes bestehenden Agents-Projekts.
Die Wiederholung hängt am einzelnen Werkzeug
In der Dokumentation zu Extensions steht die konkrete Entscheidung: Bei replay: safe führt Pi einen unterbrochenen Aufruf nach dem Neustart erneut aus. Bei replay: unsafe, dem Standard, wiederholt Pi den Aufruf nicht automatisch. Das Modell bekommt stattdessen ein interrupted-Ergebnis und entscheidet über die nächsten Schritte. Cloudflare nennt Lesen und Suche als mögliche sichere Fälle, das Senden einer Mail ausdrücklich als unsicheren. Die Einordnung verlangt Kenntnis des Werkzeugs: Selbst ein Leseaufruf kann veränderliche Daten liefern, und ein als sicher deklarierter Aufruf braucht eine Ausführung, deren Wiederholung keinen unerwünschten Seiteneffekt erzeugt.
Ein gespeicherter Aufruf ist noch keine Versandbestätigung
Die README von Pi Durable ergänzt, dass die Absicht eines Werkzeugaufrufs vor execute dauerhaft gespeichert wird. Das hilft, einen begonnenen Vorgang nach einer Unterbrechung wiederzufinden. Zwischen der Annahme durch einen externen Maildienst und dem lokal gespeicherten Abschluss kann trotzdem eine Lücke entstehen. Unsafe hält die automatische Wiederholung dieses unterbrochenen Aufrufs an. Die anschließende Modellentscheidung könnte jedoch einen neuen Aufruf anstoßen. Für die Aussage, eine Nachricht gehe garantiert genau einmal hinaus, reicht die dokumentierte Replayklasse deshalb nicht aus.
Drei Zustände, die ein Versandablauf unterscheiden muss
Der Fall lässt sich ohne echte Mail auf Papier zerlegen. Vor dem Versand liegt nur der freigegebene Entwurf vor. Nach bestätigter Annahme durch den Maildienst muss die Wiederaufnahme diesen Abschluss berücksichtigen. Dazwischen steht der unklare Fall: Der Aufruf begann, aber der Lauf hat keinen belastbaren Abschlussbeleg. Eine neue Sendung kann hier eine Dublette erzeugen. Der Betreiber braucht eine Regel, die zunächst nach einem passenden Providerbeleg sucht oder den Vorgang zur Entscheidung anhält. Ein stabiler Auftragsschlüssel verhindert die zweite Annahme nur, wenn der Versanddienst oder die eigene Versandschicht ihn dafür tatsächlich auswertet. Diese Zustandsprüfung ist eine vorgeschlagene Vorbereitung, kein eigener Absturztest.
Was sich heute aus den Quellen beurteilen lässt
Die Integration liefert einen nachvollziehbaren Ansatz für wiederaufnehmbare Agenten. Cloudflares Replaybeschreibung und die README von Pi Durable passen an der entscheidenden Stelle zusammen: Sichere Aufrufe können erneut laufen, andere erreichen das Modell als unterbrochenes Ergebnis. Die Repositories cloudflare/agents und earendil-works/pi stehen unter MIT. Diese Lizenz erlaubt die Nutzung des Codes, bezahlt aber weder Cloudflare-Betrieb noch Modellaufrufe. Unsere Prüfung umfasst die Originaldokumente und die Lizenzen am 2026-10-05, ohne Installation oder Softwareversuch. Ein Team, das Mailversand darauf aufbaut, muss für den unterbrochenen Aufruf weiterhin festhalten können, ob die Nachricht beim Provider angekommen ist.
QUELLEN UND STAND / GEPRÜFT 2026-10-05
MATHIAS HEINKE