Jedes Team, das ein agentisches System ausliefert, stellt irgendwann dieselbe Frage, meist im dritten Monat: „Brauchen wir Temporal / Inngest / Restate, oder können wir einfach Retries hinzufügen?"
Die Antwort lautet fast immer: „Sie brauchen den durable Orchestrator, aber aus einem Grund, der nicht 'Retries' ist."
Was Retries tatsächlich lösen
Retries sind das richtige Werkzeug, wenn ein transienter Fehler vom gleichen Prozess beobachtet wird, der den Aufruf abgesetzt hat. Netzwerk-Glitch, Rate-Limit-Antwort, ein wackliger Downstream — der Caller hat das fehlgeschlagene Ergebnis in der Hand, weiß, was er versucht hat, und kann es einfach erneut versuchen.
Dafür brauchen Sie: eine Retry-Policy mit exponentiellem Backoff, ein Max-Attempts-Cap und Idempotenz beim Empfänger. Das ist eine Library, kein System. p-retry, tenacity, tokio-retry — wählen Sie eines und machen Sie weiter.
Was Durable Execution tatsächlich löst
Durable Execution ist das richtige Werkzeug, wenn der Prozess selbst zwischen Schritten sterben kann. Crash, Deploy, k8s evictet den Pod, ein 30-minütiger LLM-Call, der Ihr Request-Timeout überschreitet — die Frage ist nicht „können wir es erneut versuchen", sondern „wo waren wir, als die Lichter ausgingen, und wie nehmen wir die Arbeit wieder auf, ohne die Teile zu wiederholen, die bereits erfolgreich waren?"
Das ist ein fundamental anderes Problem. Es braucht:
- Persistenter Step-State — ein Log darüber, welche Schritte abgeschlossen wurden, mit ihren Ergebnissen.
- Replaybare History — wenn der Prozess fortsetzt, läuft er durch das Log, überspringt abgeschlossene Schritte und fährt vom ersten unfertigen fort.
- Deterministische Step-Grenzen — Code so strukturiert, dass der Orchestrator Schritte über Replays hinweg eindeutig identifizieren kann.
Sie können das von Grund auf schreiben. Leute tun das. Es sind sechs Monate Debugging von Race Conditions, bevor Sie merken, dass Sie eine schlechtere Version von Temporal gebaut haben.
Die eigentliche Entscheidung
Wenn Ihr agentisches System hat:
- Tool-Calls, die einzeln mehr als ein paar Sekunden dauern,
- Workflows mit mehr als ~3 sequenziellen Schritten,
- einen Handoff oder Human-in-the-Loop irgendwo in der Mitte,
- SLAs, die keinen Deploy-Restart tolerieren können, der zu einem für den Nutzer sichtbaren Fehler führt,
…brauchen Sie einen durable Orchestrator. Nicht „Sie könnten einen für Nice-to-haves wollen." Sie brauchen einen, und ihn später hinzuzufügen wird viel teurer, als damit anzufangen.
Wenn Ihr System kurz, synchron und zustandslos ist (ein Prompt, eine Response, fertig in 5 Sekunden), sind Retries in Ordnung. Über-engineeren Sie nicht.
Was wir ausliefern
In der Praxis ist unser Default Temporal oder Restate (je nach Sprach-Stack), mit Workflow-Code so strukturiert, dass jeder LLM-Call, jede Tool-Invocation und jede Freigabe ein separater Schritt ist. Die Kosten: etwas Lernkurve und eine Runtime, die zu betreiben ist. Der Vorteil: „Was passiert, wenn dieser Prozess mitten im Workflow crasht" hört auf, eine Frage zu sein, die wir bei jedem neuen Feature beantworten müssen — der Orchestrator beantwortet sie einmal.
Retries lösen „dieser Aufruf ist fehlgeschlagen." Durable Execution löst „dieser Workflow muss Ausfälle des Dings überleben, das ihn ausführt." Sie sind keine Alternativen — die meisten Produktionssysteme brauchen beides, und es ist das zweite, das die Leute unterschätzen.