Compound Failure Rates in Multi-Step-Agents sind brutal — das haben wir bereits geklärt. Ein Sieben-Schritte-Workflow bei 95% Zuverlässigkeit pro Schritt landet bei rund 70% End-to-End. Drei von zehn Durchläufen fliegen dir um die Ohren. Aber hier kommt der Teil, den niemand fixt: Wenn Schritt vier einen HTTP 500 wirft — was passiert mit den drei Schritten, die bereits gelaufen sind? Die Slack-Nachricht ist raus, die Datenbankzeile geschrieben, das Jira-Ticket angelegt. Dein Agent weiß nicht, welche Schritte abgeschlossen sind. Er hat keinen Checkpoint — keine gespeicherte Position zum Wiederaufsetzen. Und er hat keine Compensation Logic — kein automatisches "Rückgängig" für halb erledigte Arbeit.

Die Fehlerrate zu sehen ist Schritt eins. Den Fehler zu überleben ist Schritt zwei. Niemand liefert Schritt zwei.

Recovery-Theater

Alle drei großen Agent Runtimes haben im April Recovery-Features gelauncht. Keines davon löst tatsächlich Recovery.

Anthropics Managed Agents (8. April) nutzen ein Append-only Event Log — ein einmal beschriebenes Tagebuch von allem, was der Agent getan hat. Crash? Neustart, Tagebuch lesen, weitermachen. Ihr Engineering-Team: "Nothing in the harness needs to survive a crash." Klingt robust. Aber es gibt keine Dead-Letter-Queue für fehlgeschlagene Tasks, keine Exactly-once-Garantie, dass jede Aktion genau einmal ausgeführt wird, und keinen Weg, abgeschlossene Seiteneffekte zurückzurollen.

OpenAIs Agents SDK Update (15. April) brachte Snapshotting und Rehydration — Speichern und Wiederherstellen des Agent-Zustands über Container-Neustarts hinweg. Aber es persistiert Message History, nicht Execution State. Das Modell erinnert sich, was es gesagt hat; es trackt nicht, was es getan hat.

Googles ADK (angekündigt auf der Cloud Next, 22. April) liefert SequentialAgent, ParallelAgent, LoopAgent plus eine ResumabilityConfig. Das Kleingedruckte: Der Aufrufer muss Unterbrechungen erkennen und manuell neu starten. Kein automatisches Recovery.

Drei verschiedene Ansätze für Durability. Alle drei modellieren Ausführung als Inferenz-Schleifen — "denke → rufe Tool auf → beobachte → wiederhole." Keiner modelliert es als durable State Machine — ein System, das exakt weiß, in welchem Zustand es sich befindet und welche Übergänge gültig sind. Wie ein Getränkeautomat, der sich auch nach einem Stromausfall daran erinnert, dass du schon deinen Euro eingeworfen hast.

Die Lösungen, die es längst gibt (außerhalb von KI)

Workflow Engines haben Durable Execution vor einem Jahrzehnt gelöst. Die KI-Branche hat sie nur noch nicht adoptiert.

Temporal verpackt jeden Schritt in eine wiederholbare, replaybare Activity. Crash mitten im Workflow? Temporal spielt ab der letzten abgeschlossenen Activity zurück — nicht von vorne. So sieht ein Temporal-gekapselter Agent-Step aus:

@activity.defn
async def file_jira_ticket(ctx: AgentContext) -> TicketResult:
    """Temporal retries this automatically on failure.
    If the agent crashes mid-workflow, it replays
    from the last completed activity — not from scratch."""
    return await ctx.tools.jira.create_issue(
        summary=ctx.draft.title,
        idempotency_key=ctx.run_id  # prevents duplicate tickets
    )

Dieser idempotency_key — eine eindeutige ID, die sicherstellt, dass derselbe Request nicht zweimal ausgeführt wird — ist der gesamte Unterschied zwischen "production-grade" und "beeindruckende Demo".

Cloudflares Project Think (15. April) ging einen komplett anderen Weg: Pro-Agent-SQLite-Datenbanken, step.do()-Checkpoints und kostenlose Hibernation. Jeder Agent ist eine durable, isolierte Entität mit eigenem persistenten State — kein Job in einem zentralen Orchestrator. Für Teams, die bereits auf Cloudflare Workers setzen, ist das wohl der sauberste Pfad — keine externe Workflow Engine, kein Message Broker, einfach Durable Objects mit eingebautem Checkpointing.

Restate liegt dazwischen: leichtgewichtiger als Temporal, strukturierter als rohe Durable Objects. Es bietet Exactly-once-Garantien mit einem journalbasierten Replay-Mechanismus und hat direkte Integrationspatterns mit Google ADK veröffentlicht.

Die unbequeme Mitte

Hier ist das Problem, das niemand aussprechen will: Die Lücke geht in beide Richtungen.

Workflow Engines sprechen kein LLM. Sie verstehen keine Token Budgets — wie viel Text eine KI pro Aufruf verarbeiten kann. Sie können kein Model Fallback Routing — den Wechsel zu einem günstigeren Modell, wenn das teure an Rate Limits stößt. Sie kennen kein Prompt Versioning, kein Context Window Management, keine Tool-Call Schema Evolution. Agents auf Temporal aufzuschrauben bedeutet, eine Übersetzungsschicht zwischen "Workflow Step" und "Inference Call" zu schreiben — und die bei jeder API-Änderung deines Model Providers zu pflegen.

Agent-Plattformen verstehen keine Durability. Sie behandeln Tool Calls als flüchtige Seiteneffekte von Inferenz, nicht als State Transitions, die transaktionale Garantien brauchen. Ein LLM, das ein Tool aufruft, ist philosophisch etwas völlig anderes als ein Workflow-Step, der eine Funktion aufruft: Das LLM könnte beschließen, das Tool nochmal aufzurufen, ein anderes Tool zu nehmen oder ein Tool zu halluzinieren, das gar nicht existiert. Workflow Engines setzen deterministische Step-Definitionen voraus. LLMs sind per Definition nicht-deterministisch.

Keine Seite hat Unrecht. Sie lösen verschiedene Hälften desselben Problems.

Was das für dich bedeutet

Wenn dein Agent über mehr als drei Schritte hinweg externen State verändert — E-Mails verschickt, Datenbanken beschreibt, Third-Party-APIs aufruft — brauchst du bereits Workflow-Engine-Garantien. Deine Agent-Plattform liefert sie nicht. Du hast drei Optionen:

  1. Temporal/Restate selbst anschrauben. Echte Integrationskomplexität, aber kampferprobte Durability. Lohnt sich, wenn du Agents in Produktion mit echten SLAs betreibst.
  2. Cloudflare-nativ gehen. Wenn du schon auf Workers sitzt, gibt dir Project Think durable Agents ohne den Orchestrierungs-Overhead. Kompromiss: Plattform-Lock-in.
  3. Die Fehlerrate akzeptieren und manuelle Reconciliation-Tools bauen. Ehrlich gesagt, für interne Tools mit geduldigen Nutzern kann das rational sein. Nenn es nur nicht "production-ready".

Die Konvergenz ist unvermeidlich. Der erste Anbieter, der Durable-State-Machine-Execution als Standard-Agent-Primitiv liefert — nicht als Nachgedanke, nicht als Third-Party-Integration — besitzt die Production Reliability Layer über allen drei Runtimes. Temporal weiß das; ihre OpenAI Agents SDK Integration ist ein Landgrab. Cloudflare weiß das; Project Think ist darauf ausgelegt, Agents zum Plattform-Feature zu machen.

Deine Sieben-Schritte-Demo funktioniert weiterhin wunderbar. Sie in Produktion zu bringen bedeutet immer noch, sich zu entscheiden, mit welchem Failure Mode du leben kannst.