02.11.2025 AI Engineering5 Minuten Lesezeit

Durable Execution für Agenten

Agenten, die Stunden oder Tage laufen, können ihren Zustand nicht im Prozessspeicher belassen. Wir definieren Durable Execution, vergleichen Event-Historien-Replay mit Checkpoint-Schnappschüssen und ordnen die Engine-Landschaft Ende 2025 von Temporal bis LangGraph 1.0 und Microsoft Agent Framework ein. Ebenso klar benennen wir, 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 — sei es durch ein Deployment, einen Out-of-Memory-Kill oder einen Knotenausfall —, ist jeder abgeschlossene Schritt verloren. Der Agent startet bei null, wiederholt jeden LLM-Aufruf und bezahlt jedes Token ein zweites Mal. Die Seiteneffekte bereits ausgeführter Werkzeuge bleiben in der Außenwelt dennoch bestehen.

Bei einer 30-Sekunden-Aufgabe ist dieser Neustart ein Ärgernis. Für einen Recherche-Agenten mit sechs Stunden Laufzeit oder einen Freigabeprozess über fünf Tage ist er disqualifizierend. Langlaufende Agenten sind verteilte Systeme und erben deren zentrale Anforderung: Der Ausführungszustand muss den Prozess überleben, der ihn erzeugt hat. Seit 2025 gibt es für diese Anforderung nicht nur einen Namen, sondern auch 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.

Praktisch bedeutet das: Die Wiederherstellung kostet keine zusätzlichen Tokens. Ein Workflow, der nach 40 von 50 Werkzeugaufrufen abbrach, setzt bei Aufruf 41 fort. Weder eine handgeschriebene Zustandsmaschine in Redis noch manueller Checkpoint-Code oder verteilte Neustartlogik sind nötig. Die Dauerhaftigkeit liegt in der Laufzeitumgebung statt in der Anwendung — und genau das 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.

Entscheidend ist die Bandbreite der Betriebsmodelle: externer Cluster, einzelnes Binary, In-Process-Bibliothek oder Framework-Schicht. Dauerhaftigkeit ist damit nicht mehr an eine bestimmte Infrastruktur gebunden. Teams können die passende Gewichtsklasse wählen, statt ihre Umgebung an die Engine anzupassen. Für kleine Teams genügt häufig eine Bibliothek; regulierte Umgebungen profitieren eher 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.

Auch die Qualität von Entscheidungen verbessert Dauerhaftigkeit nicht. Ein wiederaufgenommener Agent setzt den bisherigen Plan fort; ist dieser falsch, wird der Fehler lediglich zuverlässig persistiert. Ebenso wachsen Kontextfenster nicht dadurch, dass Zustand auf der Festplatte liegt — lange Historien müssen weiterhin zusammengefasst werden, bevor sie das Modell erreichen. Hinzu kommen Wartungskosten des Determinismus: Geänderten Workflow-Code auszurollen, während alte Ausführungen laufen, erfordert explizites Versionieren oder Patchen, und dieser Aufwand wird häufig unterschätzt.

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, weshalb Aufbewahrungsrichtlinien zum Bestandteil des Agentendesigns werden müssen statt zum nachträglichen Gedanken. Bei Blue IT Systems behandeln wir Dauerhaftigkeit daher als erste Architekturentscheidung für jeden Agenten, der eine einzelne Anfrage überdauert. Alles Weitere baut darauf auf.