02.11.2025 AI Engineering 5 Minuten Lesezeit

Durable Execution für Agenten

Agenten mit Laufzeiten von Stunden oder Tagen dürfen ihren Zustand nicht im Prozessspeicher halten. Wir definieren Durable Execution, vergleichen Event-Historien-Replay mit Checkpoint-Schnappschüssen, ordnen die Engine-Landschaft Ende 2025 von Temporal bis LangGraph 1.0 und Microsoft Agent Framework ein und benennen offen, was Dauerhaftigkeit nicht löst: Seiteneffekte, Entscheidungsqualität und Kontextwachstum.

Agenten sterben mit dem Prozess

Ein Agent ist eine Schleife: Ein Modell plant, ruft Werkzeuge auf, bewertet Ergebnisse und plant erneut. In den meisten Frameworks lebt diese Schleife im Prozessspeicher. Stirbt der Prozess — durch ein Deployment, einen Out-of-Memory-Kill, einen Knotenausfall — ist jeder abgeschlossene Schritt verloren. Der Agent startet bei null, wiederholt jeden LLM-Aufruf und bezahlt jedes Token ein zweites Mal. Bereits ausgeführte Werkzeugeffekte bleiben in der Außenwelt trotzdem bestehen.

Bei einer 30-Sekunden-Aufgabe ist das ein Ärgernis. Bei einem Recherche-Agenten mit sechs Stunden Laufzeit oder einem Freigabeprozess über fünf Tage ist es disqualifizierend. Langlaufende Agenten sind verteilte Systeme und erben deren zentrale Anforderung: Der Ausführungszustand muss den Prozess überleben, der ihn erzeugt hat. Diese Anforderung hat einen Namen und seit 2025 ausgereiftes Werkzeug.

Eine Aufgabe kommt an — der Agent plant den nächsten Schritt. 1/4

Was Durable Execution tatsächlich bedeutet

Durable Execution ist ein Programmiermodell. Die Laufzeitumgebung protokolliert das Ergebnis jedes Schritts mit Seiteneffekten — LLM-Aufruf, Werkzeugausführung, HTTP-Request — in einem persistenten Log. Der Orchestrierungscode um diese Schritte muss deterministisch sein. Nach einem Absturz führt die Laufzeit den Code erneut aus; protokollierte Schritte liefern ihre gespeicherten Ergebnisse zurück, statt erneut zu laufen, und das Programm erreicht den exakten Fehlerpunkt mit identischem lokalem Zustand. Temporal nennt das Replay. Der Effekt ist absturzsichere Ausführung.

Die praktische Konsequenz: Die Wiederherstellung kostet keine Tokens. Ein Workflow, der nach 40 von 50 Werkzeugaufrufen abbrach, setzt bei Aufruf 41 fort. Keine handgeschriebene Zustandsmaschine in Redis, kein manueller Checkpoint-Code, keine Neustartlogik quer durch die Agentenschleife. Die Dauerhaftigkeit liegt in der Laufzeitumgebung, nicht in der Anwendung. Genau diese Eigenschaft macht tagelange Läufe wirtschaftlich tragfähig.

Zwei Wege zur Wiederaufnahme

Engines in der Temporal-Tradition persistieren eine Event-Historie. Temporal speichert pro Workflow eine Historie in Cassandra, MySQL oder PostgreSQL und spielt deterministischen Workflow-Code dagegen ab; nicht-deterministische Arbeit — jeder Modell- und Werkzeugaufruf — läuft in Activities, deren Ergebnisse genau einmal aufgezeichnet werden. Restate 1.2 (Februar 2025) verdichtet dieselbe Idee in ein einzelnes Binary mit eigenem verteiltem Log. DBOS Transact wählt den Bibliotheksweg: Sie annotieren Funktionen im eigenen Prozess und speichern den Ausführungszustand in der Postgres-Datenbank, die Sie ohnehin betreiben.

LangGraph macht stattdessen Zustandsschnappschüsse. Nach jedem Graphknoten schreibt ein Checkpointer die Kanalwerte in ein In-Memory-, SQLite- oder Postgres-Backend; die Wiederaufnahme lädt den letzten Checkpoint und fährt am nächsten Knoten fort. Es gibt kein Replay — und keine Aufzeichnung dessen, was innerhalb eines Knotens geschah. Beide Modelle liefern dieselbe Garantie. Sie unterscheiden sich in Granularität, Speicherwachstum und im Umgang mit Codeänderungen bei laufenden Ausführungen.

Die Engine-Landschaft Ende 2025

2025 hat sich das Werkzeugangebot konsolidiert. LangGraph 1.0 erschien am 22. Oktober 2025 — das erste stabile Major-Release eines durablen Agenten-Frameworks, nach Produktionseinsatz bei Uber, LinkedIn und Klarna. Temporals Integration mit dem OpenAI Agents SDK ging am 30. Juli 2025 in die Public Preview. Das Microsoft Agent Framework, die Zusammenführung von Semantic Kernel und AutoGen, erreichte am 1. Oktober 2025 die Public Preview mit Checkpointing und Pause/Resume in seinen Graph-Workflows.

Die Bandbreite ist entscheidend. Ein externer Cluster, ein einzelnes Binary, eine In-Process-Bibliothek, eine Framework-Schicht: Dauerhaftigkeit ist nicht mehr an ein Betriebsmodell gebunden. Teams wählen die Gewichtsklasse, die zu ihrer Infrastruktur passt, statt die Infrastruktur an die Engine anzupassen. Kleinen Teams genügt oft eine Bibliothek; regulierte Umgebungen profitieren vom auditierbaren Event-Log eines externen Clusters.

Engine	Modell	Zustandsspeicher	Status am 2. Nov 2025
Temporal	Event-Historien-Replay über externen Cluster	Cassandra, MySQL, PostgreSQL	GA; OpenAI-Agents-SDK-Integration in Public Preview
Restate	Event-Log in einem einzelnen Binary	Eingebettetes RocksDB plus Object-Store-Snapshots	1.2 seit 18. Feb 2025
DBOS Transact	In-Process-Bibliothek mit Dekoratoren	Beliebige Postgres-kompatible Datenbank	TypeScript 2.0 seit 29. Jan 2025
LangGraph	Zustands-Checkpointing auf Knotenebene	In-Memory-, SQLite-, Postgres-Checkpointer	1.0 stabil seit 22. Okt 2025
Microsoft Agent Framework	Graph-Workflows mit Checkpoints	Austauschbarer Checkpoint-Speicher	Public Preview seit 1. Okt 2025

Tagelanges Warten als Feature

Dauerhaftigkeit verändert, worauf ein Agent warten darf. Ein durabler Workflow kann eine Woche auf eine menschliche Freigabe blockieren: Der Code liest sich wie ein synchrones Await, doch während des Wartens läuft kein Prozess und belegt kein Speicher. Timer, Wiederholungen mit stundenlangem Backoff und Human-in-the-Loop-Unterbrechungen werden gewöhnlicher Kontrollfluss statt externer Cron-Jobs und Message-Queues.

Das ist der Mechanismus hinter mehrtägigen Agentenprozessen: entwerfen, auf Review warten, überarbeiten, ausführen. LangGraph 1.0 bietet ihn als Interrupts auf Basis von Checkpoints an; Temporal als durable Timer und Signale. In beiden Systemen kostet das Warten Speicherplatz, nicht Rechenzeit — und es übersteht jedes Deployment dazwischen. Auf der Rechnung ist das der Unterschied zwischen einem laufenden Container und einer Zeile in einer Datenbank.

Was Durable Execution nicht leistet

Replay stellt Ergebnisse wieder her; es macht Effekte nicht rückgängig. Schritte laufen mindestens einmal: Stürzt ein Prozess ab, nachdem ein Werkzeug lief, aber bevor sein Ergebnis aufgezeichnet wurde, läuft der Schritt erneut. Werkzeuge mit Seiteneffekten — E-Mails senden, Karten belasten, Tickets anlegen — brauchen weiterhin Idempotenzschlüssel. Die Engine garantiert die Orchestrierung, nicht die Semantik des Orchestrierten.

Dauerhaftigkeit verbessert auch keine Entscheidungen. Ein wiederaufgenommener Agent setzt seinen bisherigen Plan fort; ein falscher Plan bleibt dauerhaft persistiert falsch. Kontextfenster wachsen nicht, weil Zustand auf der Festplatte liegt — lange Historien brauchen weiterhin Zusammenfassung, bevor sie das Modell erreichen. Und Determinismus hat Wartungskosten: Geänderten Workflow-Code auszurollen, während alte Ausführungen laufen, erfordert explizites Versionieren oder Patchen — ein Aufwand, den die meisten Teams unterschätzen.

Schließlich sind Checkpoint- und Historienspeicher eine Vertrauensgrenze. Serialisierter Agentenzustand enthält Prompts, Werkzeugausgaben und gelegentlich Zugangsdaten im Transit. Wer in diesen Speicher schreiben kann, bestimmt, was ein wiederaufgenommener Agent glaubt, bereits getan zu haben. Verschlüsseln Sie den Speicher und beschränken Sie Schreibzugriffe entsprechend.

Ausblick vom November 2025

Wir erwarten, dass Dauerhaftigkeit zur Standardeigenschaft von Agenten-Laufzeiten wird, statt ein Zusatz zu bleiben. Die Signale von 2025 zeigen in eine Richtung: Ein Checkpointing-Framework erreichte 1.0, ein Durable-Execution-Anbieter liefert Erstanbieter-Integrationen für Agenten-SDKs, und Microsoft baute Checkpoints von Beginn an in sein vereinheitlichtes Framework ein. Binnen eines Jahres dürfte eine Agentenschleife ohne Persistenz so befremdlich wirken wie ein Webservice ohne Logs.

Zwei Fragen bleiben offen. Erstens die Konvergenz: Event-Historien-Engines und Checkpoint-Frameworks werden sich vermutlich in der Mitte treffen — Historien mit Snapshot-Kompaktierung, Checkpoints mit Aufzeichnungen auf Schrittebene. Zweitens die Kosten: Durable LLM-Transkripte sind umfangreich, und Aufbewahrungsrichtlinien werden Teil des Agentendesigns statt nachträglicher Gedanke. Bei Blue IT Systems behandeln wir Dauerhaftigkeit inzwischen als erste Architekturentscheidung für jeden Agenten, der eine einzelne Anfrage überdauert. Alles Weitere baut darauf auf.