Ein Lauf, der einen Nodeausfall überlebt
Durable Execution heißt: Der Fortschritt eines Agenten liegt nicht im Prozessspeicher, sondern in einem append-only Event Log. Fällt der ausführende Node aus, setzt der Lauf auf dem letzten Checkpoint auf — ohne bereits ausgeführte Seiteneffekte zu wiederholen.
Geeignet fürUnternehmen, deren Agenten Geld bewegen, Tickets schließen oder Daten schreiben
Durable Execution · Checkpoints · Idempotenz — ein Nodeausfall kostet keinen Lauf
Das Wichtigste auf einen Blick
- Geeignet für
- Unternehmen, deren Agenten Geld bewegen, Tickets schließen oder Daten schreiben — wo eine Doppelbuchung teuer wird
- Ausgangssituation
- Ein Nodeausfall mitten im Lauf kostet heute den ganzen Vorgang — oder erzeugt beim Neustart eine zweite Buchung
- Wir übernehmen
- Betrieb der Runtime mit Event Log, Checkpoints vor und nach jedem Tool-Call, Idempotenz-Keys und Budgetgrenzen je Lauf
- Bei Ihnen bleibt
- Ihre Daten und die Entscheidung, welche davon ein Modell sehen darf. Eigentum und Hoheit wechseln nicht.
- Vorhandene Systeme
- Welche Hardware und welche Schnittstellen sich weiterverwenden lassen, klären wir vor dem Angebot. Das Ergebnis steht schriftlich fest, bevor Sie beauftragen.
- Ihr Ergebnis
- Ein Ausfall kostet keinen Lauf. Die Wiederaufnahme setzt am letzten Checkpoint auf, Schreib-Calls laufen genau einmal
- Preisrahmen
- ab 690 € im Monat (Einstiegsklasse der Plattform)Business 1.490 €, Enterprise 3.900 € — Schritte, Tool-Calls und Tokens werden getrennt abgerechnet
- Reaktionszeit
- 99,95 % zugesicherte Verfügbarkeit der Plattform; Wiederanlaufziele werden je Umgebung vertraglich vereinbart
- Dauer
- Erst ein Lauf in der Sandbox, dann ein Pilot, dann der VertragEin einzelner Lauf darf bis zu 72 Stunden dauern, Wartezeit auf Freigaben eingeschlossen
- Erster Schritt
- In der Sandbox schalten wir während Ihres Laufs einen Node ab — Sie sehen im Trace, wo er wieder aufsetzt
Warum ein Agent kein normaler Request ist
Durable Execution
Ausführungsmodell, bei dem der Fortschritt eines langlaufenden Prozesses persistent außerhalb des ausführenden Prozesses gehalten wird, sodass die Ausführung nach einem Ausfall an der letzten bekannten Stelle fortgesetzt werden kann.
Checkpoint
Konsistenter, persistierter Zustand eines Laufs an einer definierten Grenze — in der Regel unmittelbar vor und nach jedem Tool-Call. Ein Checkpoint enthält Schrittzähler, Kontextreferenzen und die Ergebnisse abgeschlossener Aufrufe.
Idempotenz-Key
Eindeutiger, aus Lauf-ID und Schrittnummer abgeleiteter Schlüssel, der einem Tool-Call mitgegeben wird. Erhält das Zielsystem denselben Schlüssel zweimal, führt es die Aktion nur einmal aus und liefert beim zweiten Mal dasselbe Ergebnis zurück.
Was bei einem Ausfall tatsächlich passiert
checkpoint tool.call#3 letzter Checkpoint Node A · Prozess verloren
t + 38 s, mitten in tool.call#3
Node B · Wiederaufnahme
replay 7 events → Zustand rekonstruiert
Schritte, die Sie selbst schreiben
import { defineAgent, step } from "@hostspezial/agent-sdk";
export default defineAgent({
name: "refund-agent",
// Harte Obergrenze pro Lauf. Wird sie erreicht, endet der Lauf
// mit status=budget_exceeded — nicht mit einer Endlosschleife.
budget: { tokens: 200_000, eur: 0.50, wallClockMs: 120_000 },
async run(ctx, input) {
// Lesende Schritte sind frei wiederholbar.
const order = await step(ctx, "load-order", () =>
ctx.tools.postgres.query("SELECT * FROM orders WHERE id = $1", [input.orderId])
);
// Schreibende Schritte bekommen einen Idempotenz-Key aus
// Lauf-ID und Schrittnamen. Nach einem Absturz liefert das
// Zielsystem dasselbe Ergebnis statt einer zweiten Buchung.
const refund = await step(ctx, "issue-refund", {
idempotencyKey: `${ctx.runId}:issue-refund`,
retry: { attempts: 3, backoff: "exponential", maxDelayMs: 8_000 },
}, () => ctx.tools.stripe.refund({ orderId: order.id, amount: order.total }));
return { refundId: refund.id, status: "settled" };
},
});Fehlermodi und das Verhalten der Runtime
| Fehlermodus | Verhalten | Sichtbar als |
|---|---|---|
| Tool antwortet mit 5xx | Retry mit exponentiellem Backoff bis zur konfigurierten Obergrenze, danach Eskalation an den definierten Fehlerpfad. | tool.failed → tool.retried |
| Tool antwortet gar nicht | Timeout je Tool, Abbruch des Aufrufs, Checkpoint bleibt auf dem Stand davor. | tool.timeout |
| Node fällt zwischen zwei Schritten aus | Ein anderer Node übernimmt, spielt das Event Log ein und setzt am nächsten Schritt an. | run.resumed |
| Node fällt während eines Schreib-Calls aus | Wiederaufnahme wiederholt den Call mit demselben Idempotenz-Key. Das Zielsystem führt ihn nicht erneut aus. | run.resumed (dedup) |
| Modell liefert unbrauchbare Antwort | Schema-Validierung schlägt an, ein Reparaturversuch mit engerem Prompt, danach Abbruch. | plan.invalid |
| Budget aufgebraucht | Harter Stopp. Der Lauf endet mit budget_exceeded, der bisherige Zustand bleibt einsehbar. | run.budget_exceeded |
| Mensch antwortet nicht auf Freigabe | Lauf bleibt im Wartezustand, ohne Rechenkosten zu erzeugen, bis Freigabe oder Ablauffrist. | run.awaiting_approval |
Was das nicht löst
Ehrliche Grenzen
Exactly-once gilt nur, soweit das Zielsystem mitspielt. Ein Tool ohne Idempotenz-Unterstützung kann die Runtime nicht nachrüsten — sie kann den Aufruf nur als „bereits versucht“ markieren und die Entscheidung an Ihre Fehlerbehandlung geben. Und: Wiederaufnahme reproduziert den Zustand, nicht die Modellantwort. Wer bitgleiche Wiederholbarkeit braucht, arbeitet mit dem deterministischen Replay gegen aufgezeichnete Antworten.
Durable Execution im Detail
/01Was unterscheidet Durable Execution von einer Retry-Schleife?+
Eine Retry-Schleife wiederholt den gesamten Vorgang. Durable Execution wiederholt nur den fehlgeschlagenen Schritt und kennt den Zustand aller vorherigen. Der Unterschied wird bei Seiteneffekten entscheidend: Die Schleife bucht zweimal, die Runtime einmal.
/02Event-Sourcing oder Snapshotting?+
Beides. Jeder Schritt wird als Ereignis geschrieben; zusätzlich wird periodisch ein Snapshot abgelegt, damit die Wiederaufnahme nicht bei langen Läufen tausende Ereignisse einspielen muss. Die Begründung für diese Kombination steht im Architektur-Kapitel.
/03Wie lange darf ein Lauf dauern?+
Bis zu 72 Stunden am Stück — das deckt auch Wartezustände auf menschliche Freigaben ab. Längere Vorhaben wie eine Codebase-Migration werden als Kette geplanter Läufe modelliert, damit jeder Abschnitt einzeln bewertbar bleibt.
/04Kostet ein wartender Lauf Geld?+
Rechenzeit nicht. Ein Lauf im Wartezustand hält keinen Prozess offen, sondern nur einen Datensatz. Abgerechnet werden Schritte, Tool-Calls und Tokens — die Aufteilung steht auf der Preisseite.
/05Kann ich einen abgebrochenen Lauf manuell fortsetzen?+
Ja. Jeder Lauf lässt sich ab einem beliebigen Checkpoint fortsetzen — auch mit geändertem Modell, geänderter Policy oder korrigierten Eingaben. Der neue Zweig wird als eigener Lauf geführt, der ursprüngliche bleibt unverändert im Log.
/06Was passiert bei einem Rechenzentrums-Ausfall?+
Der Zustandsspeicher wird an den DR-Standort repliziert. Laufende Runs werden dort fortgesetzt, sobald die Kontrollebene übernimmt. Verfügbarkeits- und Wiederanlaufziele werden vertraglich je Umgebung vereinbart — Details auf der Trust-Seite.
Weiter in der Plattform
Agentic AI Infrastruktur Die Übersicht über alle fünf Schichten.
Orchestrierung Wie mehrere Agenten sich eine Aufgabe teilen — DA
Tool-Layer MCP-Server-Hosting, Registry und das Gateway vor jede
Observability Traces je Span, deterministisches Replay und Koste
Architektur-Deep-Dive Das Execution-Modell mit Idempotenz, Snaps
Testen Sie den Fehlerfall, nicht den Glücksfall
Einen Lauf ansehen.
Wie sich ein Lauf verhält, wenn mitten darin ein Knoten wegbricht, sieht man nicht in einer Präsentation. Wir zeigen es an einem Ihrer Vorgänge. Ausführlich beschrieben ist das unter Agentic AI.
Betrieb in deutschen Rechenzentren