Alle Notizen
6. Juni 202611 Min. Lesedauerdurable-executionai-agentstemporalrestateengineeringorchestration

Wähle die Durable Runtime, bevor dein zweiter Agent ausgeliefert wird

Wähle die Durable Runtime, bevor dein zweiter Agent ausgeliefert wird

Die meisten Produktions-Agents, die ich bei Firmen mit zwanzig bis zweihundert Leuten sehe, sind ein Python-Skript, das in einer Schleife ein LLM ruft, von cron getriggert, mit Ergebnissen in eine Datenbankzeile geschrieben. Ich habe genau diese Form selbst mehr als einmal ausgeliefert, und am Tag des Releases funktioniert sie. Beim nächsten Reboot mitten im Call, beim nächsten Mal, wenn zwei Instanzen gleichzeitig laufen, oder beim nächsten Tool-Call-Timeout, der die Arbeit lautlos verschluckt, merkst du, dass du ein verteiltes System betreibst, ohne dass du eines besitzt. Der Fix ist kein klügerer Prompt. Es ist die langweilige Runtime-Schicht unter dem Agent, die jeden Schritt journalt, beim Crash replayt und dir sagt, welcher Call die Arbeit verloren hat.

Kernaussagen

  • Die Auswahlentscheidung für Produktions-Agents ist die Durable Execution-Runtime, nicht das Modell, nicht das Framework, nicht der Prompt.
  • KMU-Teams treffen klassische Distributed-Systems-Failures in dem Moment, in dem eine zweite Instanz ausgeliefert wird: Partial Failure, Lost State, doppelte Side Effects, keine Retries.
  • Sechs Runtimes lösen dasselbe Problem mit demselben Journal-and-Replay-Muster, preislich von kostenlosem Postgres bis ~100 $ pro Monat managed.
  • Restate oder DBOS zuerst für Postgres-native Teams; Temporal Essentials für 100 $ pro Monat, wenn ein Managed-Vertrag billiger ist als Ops.
  • Die These verliert bei echten Single-Shot-Stateless-Calls und im reinen POC-Stadium, wo eine Cron-Schleife ehrlich genug ist.

In diesem Artikel

Was tatsächlich in deiner while-True-Schleife bricht

Der erste Agent in Produktion ist fast immer ein dünnes Skript. OpenRouter-SDK aufmachen, ein Modell rufen, Response parsen, Ergebnis an das nächste Tool reichen, eine Zeile in Postgres schreiben, schlafen, wiederholen. Es gibt kein Journal, in welchem Schritt der Agent war, als die EC2-Instanz um 03:00 recycelt wurde. Es gibt keinen Idempotency-Key auf der ausgehenden Mail, die der Agent zweimal verschickt hat. Es gibt kein Retry-Budget auf der Third-Party-API, die mitten im Tool-Call 502 zurückgab. Der Agent ist nicht kaputt. Die Runtime um den Agent herum existiert nicht.

Vor zwanzig Jahren hatten wir das Vokabular dafür schon. Partial Failure: Halber Workflow lief, halber nicht. Lost State: Das In-Memory-Dict, das „Schritt drei von sieben" hielt, ist weg. Exactly-once Side Effects: Haben wir den Kunden belastet oder nicht. Der Trick von Durable-Execution-Runtimes ist ein Journal. Jeder Schritt schreibt vor der Ausführung in ein dauerhaftes Log, und beim Crash replayt die Runtime das Log, um den Workflow in genau den Zustand zurückzubringen, in dem er war. Temporal, Restate, DBOS, Azure Durable Functions, AWS Step Functions und Lambda Durable Functions machen alle dasselbe. Andere Storage, andere APIs, andere Rechnungen, gleiches Muster.

💡 Das Modell ist hinter einem API-Call austauschbar. Die Runtime, in der dein Agent abstürzt, nicht.

Montagshandlung: Öffne die Codebase, aus der du Agents lieferst, und grep nach while True, time.sleep und Cron-Einträgen, die eine Python-Datei aufrufen. Jeder Treffer ist ein Kandidat-Workflow, der ein Durable Step sein sollte, keine Schleife.

Die Runtime-Schicht, auf die Microsoft und Anyscale gezeigt haben

Auf der Microsoft Build 2026 war die Session BRK227 ein Fireside zwischen Mark Russinovich (Azure CTO) und Ion Stoica (Anyscale-Mitgründer, Berkeley-Professor, die Person hinter Spark, Ray und vLLM). Sie haben fünfundvierzig Minuten an den meisten Zuhörern vorbei über KV-Caches und Bulk-Synchronous-Processing geredet. Der für KMU-Teams herausgreifbare Teil saß in der Mitte: Klassische verteilte Systeme wurden um menschliches Tempo und menschliche Zuverlässigkeit herum entworfen, und agentische Workloads brechen diese Annahmen, weil sie mit Maschinengeschwindigkeit laufen, nicht-deterministische Failure-Modes treffen und State über langlaufende Schritte brauchen. Ihre Antwort bei Azure ist die Foundry-Runtime: Hosted Agents, die Container-Crashes und Redeploys mit State-Persistenz über Turns hinweg überleben. Session-Abstract, die Foundry-Ankündigung und der Runtime-Detail-Post sind unten in den Ressourcen verlinkt.

Foundry ist nicht die einzige Antwort. Es ist eine Zeile in einer Tabelle mit sechs. Anyscale liefert seine eigene Runtime auf Ray. Temporal liefert Temporal Cloud. Restate liefert ein einzelnes Binary. DBOS liefert eine Python-Bibliothek auf dem Postgres, den du ohnehin betreibst. Der interessante Befund ist die Konvergenz: fünf Anbieter, ein Muster. Die interessante Entscheidung ist, welcher zu einem Unternehmen deiner Größe und deinem Stack passt.

Montagshandlung: Wenn du schon auf Azure bist und dein zweiter Agent zehn Wochen entfernt ist, setze Foundry Hosted Agents jetzt auf die Evaluationsliste, warte nicht auf GA. Wenn du nicht auf Azure bist, streich es und geh zur Vergleichstabelle unten.

Sechs Runtimes, ein Muster, sehr unterschiedliche Rechnungen

Streich das Marketing heraus, und diese Runtimes machen denselben Job. Was für ein zwanzig-bis-zweihundert-Personen-Team zählt: Preisuntergrenze, Storage, den du ohnehin betreibst, Sprachergonomie und wie laut die Ops-Rechnung wird.

| Runtime | Was du betreibst | KMU-Preisuntergrenze | Best Fit | |---|---|---|---| | Temporal Cloud Essentials | Nichts; managed | ~100 $ pro Monat, 1M Actions | Teams, die einen Managed-Vertrag und SLA wollen und bereit sind, Workflow- + Activity-Semantik zu lernen | | Restate | Ein selbst gehostetes Binary | Kostenlos OSS; Cloud Preview | Python- oder TypeScript-Teams, die HTTP-förmiges Durable RPC wollen, keine Workflow-DSL | | DBOS | Library auf deinem bestehenden Postgres | Kostenlos | Teams schon auf Postgres, die keinen zweiten Datastore wollen | | Azure Durable Functions | Azure Functions Consumption Plan | Erste 1M Execs kostenlos pro Monat | Teams schon auf Azure mit Sub-Sekunden-Schritten und burstiger Last | | AWS Lambda Durable Functions | Nur Lambda | Free Tier deckt das meiste | Teams, die Step-Functions-förmige Flows ohne Step-Functions-Preise wollen | | Foundry Hosted Agents | Nichts; managed | Azure-Abrechnung; GA Anfang Juli 2026 | Azure-native Teams, die Multi-Session-Agents mit State über Turns liefern |

Die Preise zählen. Temporal Cloud Essentials sind hundert Dollar pro Monat für eine Million Actions, ein Gigabyte aktiven Speicher, vierzig Gigabyte Retention und 99,9 Prozent SLA, laut Temporal pricing. Azure Durable Functions im Consumption Plan kosten zwanzig Cent pro Million Executions und enthalten die ersten Million pro Monat, laut Azure Functions pricing, mit dem tragenden Hinweis aus den Durable Functions billing docs, dass jeder Orchestrator-Replay als separate abrechenbare Invocation zählt. AWS Step Functions Standard berechnen fünfundzwanzig Dollar pro Million Transitions; Lambda Durable Functions, when you don't need Step Functions macht den contrarian Case, dass ein 8-State-Approval-Workflow mit zehntausend Runs pro Monat 2,00 $ in Step Functions versus 0,00 $ Wartezeit-Gebühren in Lambda Durable Functions kostet.

Die Ray-Seite zieht einen anderen Hebel. Der kanonische Skalierungs-Claim aus Ray: A Distributed Framework for Emerging AI Applications ist, dass Ray Millionen Tasks pro Sekunde bei Millisekunden-Latenz schedult. Diese Zahl ist real und tragend für Frontier-Training, aber sie ist nicht die Zahl, auf die ein KMU beim zweiten Agent optimieren sollte. Optimiere auf „der Workflow verliert nicht lautlos State, wenn der Container neu startet". Die Latte erfüllt jede der sechs.

So sieht derselbe Schritt in drei Runtimes aus. Lies es und beachte: Der Modell-Call ist identisch; nur der Runtime-Vertrag drumherum ändert sich:

# Temporal: ein Workflow + Activity, deterministischer Replay bei Crash
from temporalio import workflow, activity

@activity.defn
async def call_llm(prompt: str) -> str:
    return await openrouter.complete(prompt)

@workflow.defn
class ResearchAgent:
    @workflow.run
    async def run(self, topic: str) -> str:
        plan = await workflow.execute_activity(
            call_llm, f"plan research for {topic}",
            start_to_close_timeout=timedelta(minutes=2),
        )
        return await workflow.execute_activity(
            call_llm, f"execute: {plan}",
            start_to_close_timeout=timedelta(minutes=10),
        )

# DBOS: ein Python-Decorator über dem Postgres, den du ohnehin betreibst
from dbos import DBOS

@DBOS.step()
def call_llm(prompt: str) -> str:
    return openrouter.complete(prompt)

@DBOS.workflow()
def research_agent(topic: str) -> str:
    plan = call_llm(f"plan research for {topic}")
    return call_llm(f"execute: {plan}")

# Restate: ein Service über HTTP, Durable RPC, keine DSL
from restate import Workflow, WorkflowContext

agent = Workflow("ResearchAgent")

@agent.main()
async def run(ctx: WorkflowContext, topic: str) -> str:
    plan = await ctx.run("plan", lambda: openrouter.complete(f"plan: {topic}"))
    return await ctx.run("execute", lambda: openrouter.complete(f"execute: {plan}"))

Montagshandlung: Öffne die Runtime-Docs der einen, deren Storage du ohnehin betreibst. Wenn du Postgres in Produktion betreibst, ist das DBOS. Wenn du auf Azure läufst, ist das Durable Functions oder Foundry. Wenn du auf AWS läufst, ist das Lambda Durable Functions. Wenn du auf nacktem Python läufst und einen Managed-Vertrag willst, ist das Temporal Cloud Essentials. Lies neunzig Minuten, dann portiere einen existierenden cron-getriebenen Agent als Spike. Neunzig Minuten ist das gesamte Budget.

Ein 60-Personen-Logistiker entscheidet am Montag

Konkretes Beispiel. Ein 60-Personen-Logistiker in Hamburg liefert Frachtangebote. Der Ops Lead, Engineer von Haus aus, der sowohl das Datenteam als auch den IT-Dienstleister steuert, hat im April einen Agent gebaut, der Carrier-Raten scraped, das interne Postgres nach aktueller Kapazität abfragt, Claude über OpenRouter um ein Angebot bittet und den Kunden anschreibt. Er läuft alle fünfzehn Minuten aus einem Cron-Eintrag auf einem einzelnen VPS. Er funktioniert meistens. Dann Mai: Der VPS rebootet um 02:17 für einen Kernel-Patch, drei Angebote gehen verloren, zwei werden doppelt gemailt, weil der mid-Call abgebrochene Cron-Tick beim Wiederhochfahren von vorn neu lief. Der Ops Lead verbringt sechs Stunden mit Incident Response und schreibt ein Notion-Dokument mit dem Titel „wir brauchen Observability".

Was der Ops Lead tatsächlich braucht, ist Durable Execution. Die Montagsentscheidung ist eine erzwungene Wahl zwischen zwei kostenlosen Optionen und einer bezahlten. DBOS ist kostenlos, läuft als Python-Bibliothek auf dem bestehenden Postgres, in das der Carrier-Raten-Agent ohnehin schreibt, und wandelt die Cron-Schleife mit einem Decorator in einen Workflow um. Restate ist kostenlos, läuft als einzelnes selbst gehostetes Binary neben der Python-App und formt jeden Schritt als Durable RPC. Temporal Cloud Essentials kostet hundert Dollar pro Monat und tauscht Ops-Aufwand gegen ein SLA. Der Ops Lead wählt DBOS, weil das Postgres schon da ist und das Team ein Entwickler.

Das messbare Ergebnis, das der Ops Lead noch am selben Tag ins Notion-Dokument schreibt, als zu testende Hypothese: Prozentsatz der Agent-Runs, die end-to-end abschließen versus lautlos abbrechen. Mai-Baseline aus dem Incident-Review: ~94 Prozent (drei verloren, siebenundneunzig geliefert aus hundert Runs in der Woche). Ziel zwei Wochen nach DBOS-Landung, geschrieben als die Wette des Ops Leads, nicht als Industriebenchmark: ~99,9 Prozent, mit den fehlenden 0,1 Prozent als beabsichtigte Aborts, die die Runtime logged und surface. Bewegt sich die Zahl nicht, war die Wahl falsch, und die nächste zu probierende Runtime ist Restate. Ich würde dieselben Zahlen in dasselbe Notion-Dokument schreiben.

Montagshandlung: Schreib zuerst die Metrik auf. Wähl die Runtime zweitens. Die Metrik ist das Einzige, das dir sagt, welche Runtime du behältst.

Wo die These verliert

Dieses Argument hat einen weichen Bauch, und der gehört benannt. Die Regel „wähle eine Durable Runtime vor deinem zweiten Agent" verliert an zwei Stellen.

Erstens, echte Single-Shot-Stateless-Calls. Wenn der Agent eine One-Pass-Funktion ist, die Input nimmt, ein Modell ruft, Output zurückgibt und nirgendwo sonst schreibt, ist eine Cron-Schleife ehrlich genug. Die Runtime-Schicht fügt Ops-Kost hinzu (eine Sache mehr zu upgraden, eine Sache mehr zu monitoren), ohne Failure-Modes zu beseitigen, die zählen. Der ehrliche Schwellwert ist „in dem Moment, in dem ein Workflow zwei Schritte und einen Side Effect dazwischen hat", nicht „in dem Moment, in dem du einen Agent hast".

Zweitens, reines POC-Stadium. Wenn du noch in Woche eins der Frage steckst, ob der Agent es wert ist, gebaut zu werden, ist eine Runtime zuerst Premature Optimization. Der richtige Zug: Behalte die Schleife, liefere an einen Nutzer, lerne die echten Failure-Modes, dann wähl die Runtime, wenn der zweite Nutzer auftaucht. Die Kost eines verlorenen Wochenendes auf Restate ist höher als die Kost eines verlorenen Wochenendes auf einem Skript, das sich am Ende für das falsche Problem löst.

Die Regel greift in dem Moment wieder, in dem der Agent an einen zweiten gleichzeitigen Caller ausgeliefert wird, oder einen zweiten Schritt mit Side Effect dazwischen bekommt, oder auf einem Zeitplan länger als der Aufmerksamkeitsspanne des Entwicklers läuft. Das ist die Linie. Überschreite sie und die Rewrite-Kost wächst exponentiell; weigere dich, sie zu überschreiten, und der Rewrite ist die Rechnung, die du vermeiden wolltest.

Montagshandlung: Benenne die Schwelle für deinen eigenen Agent heute schriftlich. „Wir adoptieren eine Durable Runtime, wenn [Bedingung]." Eine geschriebene Schwelle macht aus der Runtime-Entscheidung statt eines Bauchgefühls einen Trigger.

Wie das zu Framework- und Observability-Entscheidungen passt

Ein früherer Beitrag hier, Copilot Studio Workflows ist das Rückgrat, das LLM-Agents brauchten, argumentierte, dass fünf Anbieter in ihren jeweiligen Produkten auf dasselbe Deterministic-Spine-Muster konvergierten. Dieser Beitrag ist die Schicht darunter. Der Spine-Beitrag sagt: „das Produkt, das du wählst, sollte ein deterministisches Rückgrat haben". Dieser Beitrag sagt: „die Runtime, die du wählst, ist das deterministische Rückgrat, und du wählst sie am Montag mit Preisschild und Storage-Backend, nicht zur Architektur-Review-Zeit".

Das andere Geschwister, auf das ich zeigen will, ist Observability überlebt deine Agent-Framework-Wahl, das argumentierte, die OpenTelemetry-GenAI-Semconv sei die Fünf-Jahres-Entscheidung unter der Sechs-Monats-Framework-Wahl. Die Runtime-Entscheidung hat dieselbe Form: Sie überlebt das Framework. Du wirst LangGraph gegen Microsoft Agent Framework tauschen, dann das gegen, was auf Build 2027 erscheint. Du wirst nicht das Postgres tauschen, in das deine Durable Workflows journaln, oder den Temporal-Namespace, gegen den deine Actions aufrollen. Wähl das Rückgrat, wähl das Observability-Schema, und behandle das Framework darüber als austauschbares Detail.

Montagshandlung: Öffne ein einseitiges Dokument mit dem Titel „irreversible Schichten". Schreib zwei Zeilen: die Durable Runtime, das Observability-Schema. Wähl bis Freitag eine Option pro Zeile. Alles darüber ist reversibel; behandle es so.

Notizen vergleichen

Wenn du in einer Firma mit zwanzig bis zweihundert Leuten sitzt und im nächsten Quartal einen zweiten Agent ausliefern wirst, würde ich gerne hören, welche Runtime du gewählt hast und wie das Storage-Backend aussieht. Besonders interessiert an DBOS-auf-bestehendem-Postgres-Geschichten, weil das der Pfad ist, den ich am häufigsten empfehle und für den am wenigsten veröffentlicht ist. Schreib mir, wenn du Notizen vergleichen willst, bevor du den Vertrag unterschreibst.

Ressourcen