Die meisten Mittelständler, die einen ersten KI-Agenten bauen lassen, sehen zuerst die Demo: eine Aufgabe wird formuliert, der Agent plant, ruft Tools auf, liefert ein Ergebnis. Funktioniert im Test zuverlässig, weil der Test kurz ist und nichts schiefgeht. Der Praxistest kommt erst, wenn derselbe Agent produktiv 800 Rechnungen verarbeitet, ein Deployment mitten in seinem Lauf passiert oder ein Tool fünf Sekunden zu spät antwortet. Genau an dieser Stelle trennt sich die Prototyp-Architektur von der Produktions-Architektur — und das Thema heißt Durable Execution.
Ehrlich: Ein Agenten-Lauf ist kein HTTP-Request. Ein Request dauert Millisekunden und ist bei einem Fehler folgenlos wiederholbar. Ein Agenten-Lauf dauert Sekunden bis Tage, ruft fremde Systeme mit echten Seiteneffekten auf und darf bei einem Ausfall nicht einfach "nochmal von vorn" versuchen.
Warum Prototyp und Produktion unterschiedliche Spiele sind
Ein typischer Prototyp hält den gesamten Laufzustand in einer Programmiersprachen-Variablen: die bisherigen Schritte, die Zwischenergebnisse, den Plan. Das ist die einfachste Implementierung und für eine Demo völlig ausreichend. Das Problem beginnt, sobald dieser Prozess neu gestartet werden muss — durch ein Deployment, einen Absturz, ein Autoscaling-Event oder einfach, weil der zugrunde liegende Server gewartet wird. Der komplette Zustand ist weg, weil er nie irgendwo anders existiert hat als im Arbeitsspeicher dieses einen Prozesses.
In der Praxis fällt das erst auf, wenn der Agent nicht mehr Spielzeug ist, sondern etwas bucht: eine Erstattung, eine Bestellung, einen Statuswechsel in einem Ticketsystem. Ein naiver Neustart wiederholt dann nicht nur die Denkarbeit, sondern auch die bereits ausgeführten Aktionen. Die Rechnung wird zweimal angelegt. Die Mail geht zweimal raus. Die Gutschrift wird zweimal gebucht. Das ist der Moment, in dem aus einem netten Automatisierungs-Feature ein Vorfall im Buchhaltungs- oder Support-Team wird — und in dem Teams anfangen, nach belastbarer Agent-Runtime-Architektur statt nach der schnellsten Bibliothek zu suchen.
Event-Sourcing: der Laufzustand lebt außerhalb des Prozesses
Die Grundidee von Durable Execution ist unspektakulär und stammt aus einem deutlich älteren Software-Prinzip: Event Sourcing. Statt den aktuellen Zustand als Variable zu halten, wird jeder Schritt eines Laufs als unveränderliches Ereignis in ein Append-only-Log geschrieben — run.started, plan.created, tool.call, tool.ok, checkpoint und so weiter. Der aktuelle Zustand ist zu jedem Zeitpunkt nichts anderes als das Ergebnis, das entsteht, wenn man alle bisherigen Ereignisse der Reihe nach abspielt.
{"event":"run.started","runId":"run_8f21","ts":"2026-07-26T09:12:03Z"}
{"event":"plan.created","step":1,"tool":null}
{"event":"tool.call","step":2,"tool":"invoice.parse","idempotencyKey":"run_8f21:2"}
{"event":"tool.ok","step":2,"result":{"amount":428.90,"vendor":"..."}}
{"event":"checkpoint","step":2,"stateHash":"c93a..."}
{"event":"tool.call","step":3,"tool":"erp.postRefund","idempotencyKey":"run_8f21:3"}Ausschnitt aus einem Event Log (vereinfacht)
Dieser Aufbau hat einen entscheidenden Vorteil gegenüber einem einfachen Snapshot des Zustands: Er ist prüfbar. Man kann nachträglich rekonstruieren, welcher Schritt wann mit welchem Ergebnis ausgeführt wurde — nicht nur, wie der Endzustand aussah. Das ist auch der Grund, warum das Execution-Modell für Agenten-Runtimes fast immer beides kombiniert, Event Log und periodische Snapshots: Das Log liefert die Nachvollziehbarkeit, der Snapshot verhindert, dass ein sehr langer Lauf bei der Wiederaufnahme tausende Ereignisse einzeln einspielen muss. Details zu dieser Kombination beschreibt das Execution-Kapitel der Architektur-Dokumentation.
Checkpoints an jeder Tool-Grenze
Ein Checkpoint ist ein konsistenter, persistierter Zwischenstand — in der Regel unmittelbar vor und nach jedem Tool-Aufruf. Diese Granularität ist bewusst gewählt: Die Tool-Grenze ist genau die Stelle, an der ein Agenten-Lauf die kontrollierte, vorhersehbare Welt des Sprachmodells verlässt und in ein Fremdsystem hineinwirkt. Ein Checkpoint an dieser Stelle enthält den Schrittzähler, Referenzen auf den bisherigen Kontext und die Ergebnisse aller abgeschlossenen Aufrufe.
In der Praxis bedeutet das: Ein Lauf mit 40 Tool-Calls hat nicht einen einzigen Wiederanlaufpunkt am Ende, sondern 40 mögliche Wiederanlaufpunkte. Fällt der Prozess während Tool-Call Nummer 27 aus, verliert man höchstens den Zustand innerhalb dieses einen Calls — nicht die 26 davor. Ohne diese Granularität würde jeder Ausfall den kompletten Lauf zurück auf null werfen, unabhängig davon, wie weit er schon war.
Idempotenz-Keys: warum die Erstattung nicht zweimal gebucht wird
Checkpoints allein lösen das Zustandsproblem, aber nicht das Seiteneffekt-Problem. Selbst mit einem Checkpoint kurz vor dem Tool-Call kann es passieren, dass der Aufruf beim Zielsystem bereits angekommen und ausgeführt wurde, die Antwort aber nie zurückkam, bevor der Prozess starb. Aus Sicht der Runtime ist unklar, ob der Call durchgeführt wurde oder nicht — genau hier kommen Idempotenz-Keys ins Spiel.
Jeder schreibende Tool-Call bekommt einen eindeutigen Schlüssel, der sich deterministisch aus Lauf-ID und Schrittnummer ableiten lässt, zum Beispiel run_8f21:issue-refund. Dieser Schlüssel wird mit jedem Aufruf an das Zielsystem mitgegeben. Unterstützt das Zielsystem Idempotenz — wie es Zahlungsdienstleister, viele ERP-Schnittstellen und moderne MCP-Tool-Server tun — erkennt es beim zweiten Aufruf mit demselben Schlüssel, dass die Aktion bereits ausgeführt wurde, und liefert das ursprüngliche Ergebnis zurück, statt die Buchung zu wiederholen.
Konkretes Beispiel: Ein Erstattungs-Agent prüft eine Reklamation und löst eine Rückzahlung über die Zahlungs-API aus. Der ausführende Node stirbt exakt in dem Moment, in dem die Antwort der API unterwegs ist. Ohne Idempotenz-Key würde die Wiederaufnahme den Aufruf erneut absetzen — Ergebnis: zwei Erstattungen für dieselbe Reklamation. Mit Idempotenz-Key erkennt die Zahlungs-API den bereits bekannten Schlüssel, bucht kein zweites Mal und gibt die ursprüngliche Transaktions-ID zurück.
Wichtig für die eigene Erwartungshaltung: Idempotenz ist keine Eigenschaft, die eine Runtime einem Fremdsystem aufzwingen kann. Sie funktioniert nur, wenn das Zielsystem selbst mitspielt. Wo das nicht der Fall ist, kann die Runtime einen Aufruf höchstens als "bereits versucht" markieren und die Entscheidung an eine definierte Fehlerbehandlung übergeben — ein Punkt, der eng mit sauber vergebenen Rechten über Agent Identity statt Admin-Zugängen zusammenhängt, damit ein Agent überhaupt nur Aktionen ausführen kann, die sich im Zweifel sauber zurückverfolgen lassen.
Wiederaufnahme statt Neustart: Recovery unter 5 Sekunden
Fällt der ausführende Node aus, übernimmt ein anderer Node den Lauf. Er lädt die bisherigen Ereignisse aus dem Event Log — im Regelfall seit dem letzten Snapshot nur eine überschaubare Anzahl —, rekonstruiert daraus den Zustand und setzt exakt am nächsten offenen Schritt an. Der Zielwert für diese Wiederaufnahme liegt bei unter 5 Sekunden ab Verlust des Node, nachzulesen mit der zugrunde liegenden Methodik auf der Runtime-Seite der Agentic-AI-Infrastruktur.
Diese Zahl ist kein Selbstzweck. Sie entscheidet darüber, ob ein Deployment, ein Autoscaling-Ereignis oder ein einzelner Hardwarefehler im laufenden Betrieb überhaupt auffällt — oder ob er als Fußnote im Trace verschwindet. Nachvollziehbar wird das erst durch Observability: Jede Wiederaufnahme erzeugt ein eigenes Ereignis (run.resumed), das sich im Trace des Laufs genauso wiederfindet wie jeder reguläre Tool-Call. Wie diese Traces aufgebaut sind und was sich daraus für Kosten- und Fehleranalysen ableiten lässt, beschreibt die Seite zur Observability-Schicht — Thema auch des vierten Artikels dieser Serie, Observability für KI-Agenten.
Lange Läufe: von Minuten bis zu Tagen
Ein Agenten-Lauf, der eine Codebase migriert, mehrere hundert Dateien durchgeht oder auf eine menschliche Freigabe wartet, kann Minuten, Stunden oder — inklusive Wartezeit auf Freigaben — bis zu 72 Stunden dauern. Für einen klassischen Serverprozess wäre das eine ungewöhnliche Laufzeit; für Durable Execution ist es der Normalfall, für den die Architektur gebaut ist.
Entscheidend dabei: Ein Lauf, der auf eine menschliche Entscheidung wartet, hält keinen Prozess offen und erzeugt in dieser Zeit keine Rechenkosten — er existiert nur als Datensatz im Event Log, bis die Freigabe eintrifft oder eine Frist abläuft. Das macht sehr lange Läufe praktisch günstig, solange die Wartezeit selbst passiv ist. Ein gutes Beispiel für diese Kategorie ist der Anwendungsfall Codebase-Migration, bei dem ein Lauf über hunderte Dateien mit mehreren Freigabepunkten dazwischen realistisch über mehrere Arbeitstage verteilt ist, ohne dass dafür durchgehend Rechenzeit anfällt.
Retry-Semantik und die exactly-once-Illusion
In der Marketing-Sprache vieler Anbieter taucht "exactly-once" als Versprechen auf. Technisch betrachtet ist reines Exactly-once über ein Netzwerk hinweg — bekannt als Konsequenz aus dem Problem der zwei Generäle — nicht beweisbar erreichbar: Man kann nie mit letzter Sicherheit wissen, ob eine Nachricht beim Empfänger angekommen ist, ohne selbst wieder eine Bestätigung zu benötigen, die verloren gehen kann. Was Durable-Execution-Runtimes tatsächlich liefern, ist präziser: at-least-once-Ausführung auf Infrastrukturebene, kombiniert mit Idempotenz auf Anwendungsebene. Das Ergebnis fühlt sich für den Anwender wie exactly-once an, ist technisch aber "effectively-once" — der Aufruf kann mehrfach versucht werden, sein Effekt tritt aber nur einmal ein.
Diese Unterscheidung ist keine Haarspalterei, sondern bestimmt, wie eine Retry-Policy konfiguriert werden muss. Jeder Schritt bekommt eine eigene Politik: Anzahl der Versuche, Backoff-Strategie, maximale Wartezeit zwischen Versuchen. Lesende Schritte — eine Datenbankabfrage, ein Lookup — sind gefahrlos beliebig oft wiederholbar. Schreibende Schritte brauchen zusätzlich den Idempotenz-Key, sonst wird aus der Fehlertoleranz ein Datenproblem. Diese Unterscheidung explizit zu treffen ist Teil dessen, was eine Runtime von einer bloßen Retry-Bibliothek unterscheidet, und hängt eng mit der Orchestrierung mehrerer Agenten zusammen, sobald ein Schritt nicht mehr isoliert, sondern Teil eines größeren Ablaufs ist.
Drei Bauweisen im Vergleich
Für den Laufzustand eines Agenten gibt es im Kern drei Bauweisen, die sich in der Praxis begegnen. Keine ist grundsätzlich falsch — sie passen nur zu unterschiedlichen Situationen.
| Kriterium | Naiver In-Memory-Loop | Durable-Execution-Runtime | Klassische Workflow-Engine |
|---|---|---|---|
| Zustandshaltung | Im Prozessspeicher, verloren bei Absturz | Event Log außerhalb des Prozesses, jeder Schritt persistiert | Zustandsmaschine in der Datenbank |
| Recovery nach Ausfall | Kompletter Neustart | < 5 s ab letztem Checkpoint (Zielwert) | Minuten, oft manuell angestoßen |
| Idempotenz bei Seiteneffekten | Nicht vorgesehen, Entwickler prüft selbst | Idempotenz-Key automatisch je Schritt | Meist auf Aktivitätsebene, nicht auf LLM-Tool-Calls zugeschnitten |
| Passt zu nichtdeterministischen LLM-Antworten | Schlecht — Retry dupliziert Denkarbeit und Effekte | Gut — jeder Tool-Call einzeln retry-fähig | Mäßig — für deterministische Prozesse entworfen |
| Betriebsaufwand | Niedrig für den Prototyp, hoch im Störfall | Mittel, aber vorhersehbar | Hoch — eigenes Engine-Hosting und Ops-Team |
| Typischer Einsatz | Demo, Proof of Concept | Produktive Agenten mit echten Seiteneffekten | Etablierte Geschäftsprozesse ohne LLM-Kern |
Die mittlere Spalte folgt der Bauweise, die sich unter dem Namen Durable Execution in den letzten Jahren als eigenes Muster etabliert hat — unabhängig vom konkreten Anbieter: Schritte als Code, Persistenz und Retry als Eigenschaft der Runtime, nicht der Anwendung. Wer diese drei Bauweisen näher gegenüberstellen will, insbesondere die Frage, ob ein eigenes Team eine solche Runtime selbst bauen sollte, findet die ausführliche Abwägung unter Eigenbau vs. Managed Agent Platform — auch Thema des siebten Artikels dieser Serie.
Praxisbeispiel: Deployment mitten in einem 40-Minuten-Lauf
Ein Rechenbeispiel macht den Unterschied greifbar. Angenommen, ein Agent verarbeitet im Rahmen einer Codebase-Migration 800 Dateien — er analysiert jede Datei, wendet ein Codemod-Muster an und committet das Ergebnis. Der komplette Lauf dauert im Schnitt 40 Minuten, also rund 3 Sekunden pro Datei (Annahme, Rechenbeispiel). Mitten im Lauf, nach 27 Minuten und 540 von 800 Dateien, wird die Runtime selbst neu deployt — ein ganz normaler Rolling-Restart, kein Fehler.
Ohne Checkpointing: der naive In-Memory-Loop
Der Prozess, der den Lauf hält, stirbt mit dem Deployment. Der gesamte Fortschritt existierte ausschließlich in seinem Speicher und ist weg. Der nächste Versuch beginnt bei Datei 1 — die 27 Minuten Rechenzeit und Modellkosten für die ersten 540 Dateien sind verloren. Schwerer wiegt das zweite Problem: Es gibt keinen Zustand, der sagt, welche der 540 Dateien bereits committet wurden. Ohne zusätzliche manuelle Prüfung landen einige der bereits vorgenommenen Commits ein zweites Mal im Repository, mit denselben Änderungen auf einem inzwischen veränderten Stand — Aufräumarbeit, die in der Praxis leicht eine weitere Stunde kostet.
Mit Checkpointing: die Durable-Execution-Runtime
Das Deployment löst ein kontrolliertes Draining aus: laufende Tool-Calls werden entweder sauber beendet oder auf den letzten Checkpoint zurückgesetzt, bevor der Node abgeschaltet wird. Der neue Node lädt das Event Log — 540 kompakte Checkpoint-Einträge — rekonstruiert den Zustand in weniger als 5 Sekunden und setzt bei Datei 541 fort. Die verbleibenden 260 Dateien benötigen bei gleichem Tempo rund 13 Minuten. Gesamtlaufzeit: 27 Minuten plus wenige Sekunden Recovery plus 13 Minuten — praktisch identisch mit den ursprünglich veranschlagten 40 Minuten, ohne doppelte Commits und ohne manuelle Nacharbeit.
Rechenbeispiel im Überblick: Ohne Checkpointing verliert das Beispiel realistisch 27 Minuten Rechenzeit plus rund 60 Minuten Aufräumarbeit für doppelte Commits (Annahme). Mit Checkpointing bleibt es bei den veranschlagten rund 40 Minuten Gesamtlaufzeit und unter 5 Sekunden Recovery-Zeit. Der Unterschied entsteht nicht durch schnellere Hardware, sondern dadurch, dass die 540 bereits erledigten Schritte gar nicht erst zur Diskussion stehen.
Ein ähnlicher Ablauf mit realen Freigabepunkten und Kostengrößen findet sich im Anwendungsfall Codebase-Migration; wie sich der Aufwand je erfolgreich abgeschlossener Datei in konkrete Kosten übersetzt, behandelt der sechste Artikel dieser Serie, Kosten je erfolgreichem Task.
Wann Durable Execution Overkill ist
Nicht jeder Agent braucht diesen Aufbau. Ehrlich gesagt: Für viele kurze, seiteneffektfreie Aufgaben ist Durable Execution reiner Overhead. Eine einzelne Klassifikationsanfrage, ein Zusammenfassungs-Call, eine reine Leseoperation ohne Buchung — all das läuft in Millisekunden bis wenigen Sekunden durch, verändert nichts in einem Fremdsystem und hat im Fehlerfall keinen Zustand zu verlieren, der über den einen Request hinausgeht. Ein einfacher Retry auf Anwendungsebene reicht hier völlig aus.
Auch bei Läufen mit sehr geringem Volumen und niedrigem Risiko lohnt sich der Aufbau von Event Log und Checkpoint-Infrastruktur selten — der Betriebsaufwand für die Runtime steht dann in keinem Verhältnis zu dem, was im Zweifel schiefgehen könnte. In der Praxis ziehen die meisten Mittelständler die Grenze an der Frage: Löst dieser Agent Aktionen mit echten Seiteneffekten aus, und würde ein doppelter Effekt Geld, Vertrauen oder Compliance-Aufwand kosten? Ist die Antwort Nein, ist ein einfacherer Aufbau die richtige Entscheidung — und ein Wechsel auf eine Durable-Execution-Runtime lässt sich später nachholen, wenn aus dem Prototyp ein produktiver Prozess wird.
Häufige Fragen
Was ist Durable Execution bei KI-Agenten?
Ein Ausführungsmodell, bei dem der Fortschritt eines Agenten-Laufs außerhalb des ausführenden Prozesses in einem Event Log persistiert wird. Stürzt der Prozess oder der Node ab, wird der Lauf am letzten Checkpoint fortgesetzt statt komplett neu gestartet — bereits ausgeführte Seiteneffekte werden dabei nicht wiederholt.
Warum reicht eine einfache Retry-Schleife nicht aus?
Eine Retry-Schleife wiederholt bei einem Fehler den gesamten Lauf von vorn. Das ist unproblematisch, solange keine Seiteneffekte passiert sind. Sobald ein Agent aber schon eine Erstattung gebucht, eine Mail verschickt oder ein Ticket geschlossen hat, führt ein kompletter Neustart diese Aktionen ein zweites Mal aus. Durable Execution wiederholt nur den fehlgeschlagenen Schritt, nicht den ganzen Lauf.
Wie schnell setzt ein Agenten-Lauf nach einem Ausfall wieder auf?
Der Zielwert liegt bei unter 5 Sekunden ab dem Verlust des ausführenden Node. Ein neuer Node lädt die bisherigen Ereignisse aus dem Event Log, rekonstruiert daraus den Zustand und setzt am nächsten offenen Schritt fort.
Was passiert, wenn der Absturz mitten in einer Buchung passiert?
Jeder schreibende Tool-Call bekommt einen Idempotenz-Key aus Lauf-ID und Schrittnummer. Erhält das Zielsystem denselben Schlüssel ein zweites Mal, führt es die Aktion nicht erneut aus, sondern liefert das ursprüngliche Ergebnis zurück. Die Erstattung wird so genau einmal gebucht, unabhängig davon, wie oft der Schritt wiederholt wird.
Wie lange darf ein Agenten-Lauf dauern?
Bis zu 72 Stunden am Stück, inklusive Wartezuständen auf menschliche Freigaben. Ein Lauf im Wartezustand hält keinen Prozess offen und verursacht keine Rechenkosten. Vorhaben, die länger dauern, werden als Kette geplanter Läufe modelliert.
Ist Durable Execution dasselbe wie eine klassische Workflow-Engine?
Verwandt, aber nicht identisch. Klassische Workflow-Engines modellieren meist deterministische Geschäftsprozesse mit grobkörnigen Aktivitäten. Durable-Execution-Runtimes für Agenten sind auf feingranulare, nichtdeterministische LLM-Tool-Calls zugeschnitten — jeder einzelne Tool-Call ist ein eigener, idempotenter, retry-fähiger Schritt.
Wann ist Durable Execution Overkill?
Bei kurzen, seiteneffektfreien Läufen — etwa einer reinen Textklassifikation oder einer einzelnen Suchanfrage, die in Millisekunden bis wenigen Sekunden durchläuft und nichts in einem Fremdsystem verändert. Hier steht der Aufwand für Event Log und Checkpointing in keinem Verhältnis zum Risiko, das er absichert.
Was hat Durable Execution mit DSGVO und EU AI Act zu tun?
Das Event Log ist gleichzeitig ein lückenloses Protokoll jeder Entscheidung und jedes Tool-Calls. Für Nachweispflichten nach EU AI Act und für Auskunfts- und Löschprozesse nach DSGVO ist genau diese Nachvollziehbarkeit relevant — nicht als Nebeneffekt, sondern als eingebaute Eigenschaft der Architektur.
Wer diese Architektur nicht selbst betreiben möchte: Unsere Agentic-AI-Infrastruktur bildet Durable Execution als eine von fünf Schichten ab — einen Überblick über alle fünf gibt die interaktive Systemkarte. Für Unternehmen, die den kompletten Betrieb inklusive Modell-Hosting aus einer Hand wollen, ist KI Full-Stack Providing der passende Einstieg; wer bereits eine eigene GPU-Infrastruktur betreibt oder aus regulatorischen Gründen On-Premise bleiben muss, findet die Variante dazu unter KI On-Premise. Beide Wege lassen sich mit den Managed-KI-Services kombinieren, deren Betriebsklassen sich mit den Preisstufen der Agentic-AI-Infrastruktur decken.