Temporal im Test: Agenten, die Abstürze überstehen und auf Menschen warten

Temporal ist eine quelloffene Plattform für dauerhafte Ausführung. Du schreibst den Agenten als normalen Code, und die Plattform protokolliert jeden Schritt. So übersteht ein Lauf Abstürze, Deployments und Tage des Wartens. Mein Urteil vorweg: Es passt zu Agentenläufen, die Minuten bis Tage dauern, mehrere Systeme berühren und für einen Schritt einen Menschen brauchen. Für eine Chat-Antwort, die in zwei Sekunden fertig ist, ist es übertrieben.

Es konkurriert mit zwei einfacheren Dingen, die die meisten Teams schon betreiben: einem Graph-Checkpointer wie dem von LangGraph und einer Job-Queue mit Zustandstabelle. Beides ist die richtige Wahl, bis ein Prozess mitten in einem zwölfschrittigen Lauf stirbt und der Lauf dort weitermachen muss, wo er aufgehört hat. Lass Temporal weg, wenn niemand den Workflow-Code oder, beim Selbsthosting, den Cluster verantworten will.

Was es ist

• Ein Befehl zum Ausprobieren. temporal server start-dev startet Service und Web-Oberfläche auf dem Laptop, ohne externe Abhängigkeiten.
• Zwei Wege zum Betrieb. Du hostest den Server selbst oder nutzt Temporal Cloud, deren Regionen unter anderem AWS Frankfurt und Irland umfassen. Der Server ist MIT-lizenziert.
• Normaler Code. Workflows und Activities sind einfache Funktionen in Go, Java, Python, TypeScript, .NET, Ruby oder PHP, je nach SDK.

Wie es funktioniert

Ein Workflow entscheidet, was als Nächstes passiert. Eine Activity erledigt die Arbeit: Sie ruft ein Modell auf, spricht eine API an oder schreibt eine Datei. Temporal speichert jede Entscheidung und jedes Activity-Ergebnis in der Ereignishistorie des Workflows. Nach einem Absturz spielt ein Worker den Workflow-Code gegen diese Historie ab, überspringt die fertigen Activities und macht beim ersten offenen Schritt weiter. Ein Agent passt sauber auf diese Aufteilung: Schleife, Tool-Auswahl und Übergaben liegen im Workflow, und jeder Modell- oder Tool-Aufruf ist eine Activity.

Replay ist die Grenze. Der Workflow-Code muss bei jedem Replay dieselben Aufrufe in derselben Reihenfolge machen. Darum bricht das Replay, wenn darin eine API aufgerufen, die Uhr gelesen oder eine Zufallszahl gezogen wird. Solche Arbeit gehört in Activities, oder du nutzt in Python workflow.now() und workflow.random(). Eine Änderung an einem Workflow mit laufenden Ausführungen braucht Versionierung. Typ oder ID einer Activity zu ändern ist nicht sicher, Eingaben und Timeouts dürfen sich aber ändern.

Erste Schritte

Der schnellste Einstieg ist die Integration mit dem OpenAI Agents SDK, die als Paket temporalio-openai-agents erscheint. Du schreibst den Agenten mit dem normalen SDK innerhalb eines Workflows und hängst dann OpenAIAgentsPlugin an den Client und an den Worker. Jeder Modellaufruf wird zu einer Activity, wird also dauerhaft wiederholt und beim Replay nicht erneut ausgeführt.

from datetime import timedelta
from agents import Agent, Runner
from temporalio import workflow
from temporalio.client import Client
from temporalio.openai_agents import ModelActivityParameters, OpenAIAgentsPlugin


@workflow.defn
class HelloWorldAgent:
    @workflow.run
    async def run(self, prompt: str) -> str:
        agent = Agent(name='Assistant', instructions='You only respond in haikus.')
        result = await Runner.run(agent, input=prompt)
        return result.final_output


# worker.py: the plugin sets the timeout for each model activity
client = await Client.connect(
    'localhost:7233',
    plugins=[
        OpenAIAgentsPlugin(
            model_params=ModelActivityParameters(
                start_to_close_timeout=timedelta(seconds=30)
            )
        ),
    ],
)

# starter.py: the same plugin, so payloads are converted the same way
client = await Client.connect('localhost:7233', plugins=[OpenAIAgentsPlugin()])
result = await client.execute_workflow(
    HelloWorldAgent.run,
    'Tell me about recursion in programming.',
    id='my-workflow-id',
    task_queue='openai-agents-basic-task-queue',
)

ModelActivityParameters legt fest, wie Modell-Activities geplant werden. Der Parameter start_to_close_timeout ist standardmäßig 60 Sekunden. Für Tools führt activity_as_tool() I/O als Activity aus, während ein einfaches @function_tool im Workflow läuft und deterministisch sein muss. Integrationen gibt es auch für Google ADK, Pydantic AI, Mastra und das Vercel AI SDK. Die LangGraph-Integration ist als Public Preview verfügbar.

Retries und Timeouts

Retries sind der Punkt, an dem sich dauerhafte Ausführung bezahlt macht, und dort, wo die Standardwerte beißen. Eine fehlgeschlagene Activity wird mit exponentiellem Backoff wiederholt, beginnend bei einer Sekunde und begrenzt auf 100 Sekunden zwischen den Versuchen, ohne Limit für die Zahl der Versuche. Eine Zahlungsbuchung will genau das. Eine Anfrage, die nie gelingen kann, etwa das Abrufen einer Bestellung, die es nicht gibt, sollte gar nicht wiederholt werden. Drei Einstellungen bestimmen das Verhalten:

• Start-to-close begrenzt einen Versuch. Es hat keinen eigenen Standardwert, und Temporal empfiehlt dringend, es zu setzen.
• Schedule-to-close begrenzt die ganze Activity inklusive Retries und damit, wie lange ein Modellschritt insgesamt laufen darf.
• Retry-Policy legt die Zahl der Versuche und die Fehlertypen fest, die nie wiederholt werden dürfen.

import httpx
from datetime import timedelta
from temporalio import activity
from temporalio.common import RetryPolicy
from temporalio.exceptions import ApplicationError
from temporalio.openai_agents import ModelActivityParameters

model_params = ModelActivityParameters(
    start_to_close_timeout=timedelta(seconds=60),
    schedule_to_close_timeout=timedelta(minutes=5),
    retry_policy=RetryPolicy(maximum_attempts=5),
)


@activity.defn
async def lookup_order(order_id: str) -> dict:
    async with httpx.AsyncClient() as client:
        response = await client.get(f'https://shop.example.com/api/orders/{order_id}')
    if response.status_code == 404:
        # Retrying cannot make a missing order appear.
        raise ApplicationError('Order not found', type='OrderNotFound', non_retryable=True)
    response.raise_for_status()
    return response.json()

Activity-Code muss außerdem idempotent sein, denn Temporal rechnet damit, dass Activities nach einem Fehler erneut laufen. Ein Tool, das eine E-Mail verschickt, braucht einen Idempotency-Key, den das empfangende System respektiert.

Menschliche Freigabe mit Signalen

Hier hört Temporal auf, nur eine Retry-Bibliothek zu sein. Ein Signal ist eine asynchrone Nachricht an einen laufenden Workflow. Das Human-in-the-loop-Beispiel von Temporal speichert die Entscheidung in einem Signal-Handler und wartet mit workflow.wait_condition darauf. Während des Wartens liegt der Zustand in der Ereignishistorie, und Timer überstehen Neustarts. Der Standard-Timeout des Beispiels beträgt fünf Minuten, was für einen Test passt. Für eine Freigabe-Queue würde ich Tage nehmen.

import asyncio
from datetime import timedelta
from typing import Optional
from temporalio import workflow


@workflow.defn
class ApprovalWorkflow:
    def __init__(self) -> None:
        self.decision: Optional[str] = None

    @workflow.signal
    async def approval_decision(self, decision: str) -> None:
        self.decision = decision

    @workflow.run
    async def run(self, request: str) -> str:
        # propose_action and execute_action are activities defined elsewhere
        proposal = await workflow.execute_activity(
            propose_action, request, start_to_close_timeout=timedelta(seconds=60)
        )
        try:
            await workflow.wait_condition(
                lambda: self.decision is not None,
                timeout=timedelta(days=3),
            )
        except asyncio.TimeoutError:
            return 'no decision within three days'
        if self.decision != 'approve':
            return 'rejected'
        return await workflow.execute_activity(
            execute_action, proposal, start_to_close_timeout=timedelta(seconds=60)
        )

Eine Query liest den Zustand, ohne ihn zu ändern. Ein Update ist eine Anfrage, auf die der Aufrufer wartet, und ein Validator kann sie ablehnen, bevor sie in die Historie geschrieben wird. Eine abgelehnte Anfrage zählt trotzdem als Action. Lange Sitzungen stoßen auf harte Grenzen: Eine Ausführung endet ab 51.200 Ereignissen, 2.000 Updates oder 10.000 Signalen. Darum brauchen Chat-artige Workflows Continue-As-New. workflow.info().is_continue_as_new_suggested() meldet, wann der Server es vorschlägt. Wo Freigabe-Gates hingehören, ist eine Designfrage, die ich in Human in the Loop für KI-Agenten behandle.

Kosten und Betrieb

Selbst gehostet fällt keine Lizenzgebühr an. Temporal Cloud wird nach Verbrauch bezahlt, ohne Mindestumsatz, und neue Konten erhalten $150 Guthaben für 90 Tage. Die Tabelle zeigt die Listenpreise Stand Oktober 2026.

Nutzungsregeln bewegen die Rechnung mehr als der Richtpreis. Actions zählen jeden Activity-Start und jeden Retry sowie jedes Signal, jeden Timer, jedes Update, jede Query und jeden Workflow-Start. Mein Rechenbeispiel umfasst 18 Actions, also kosten 100.000 solcher Läufe etwa $90 an Actions, vor Storage und Support. Ein GB aktiver Storage, einen Monat lang gehalten, kostet etwa $31, und ein GB Retained Storage etwa 78 Cent. Ist Fairness aktiv, steigen die Actions jeder Stunde um 10 Prozent.

Business lohnt sich wegen Support, SCIM und Commit-Rabatten mehr als wegen der Actions. Die Mindestgebühr von $500 enthält 2,5 Millionen Actions, und das reicht für mehr als 130.000 Läufe wie mein Beispiel.

Wohin die Daten gehen. Ein Namespace wird in einer Region angelegt. Die Regionsliste umfasst AWS Frankfurt (eu-central-1), Irland (eu-west-1) und London (eu-west-2), dazu GCP Frankfurt (europe-west3). Nutzlasten lassen sich auf deinen Workern mit dem Data Converter verschlüsseln, bevor sie den Worker verlassen. Ein Codec Server erlaubt deinem Team, Historien in der Web-Oberfläche zu lesen, ohne Schlüssel herauszugeben. Aufbewahrte Historien bleiben in Cloud bis zu 90 Tage erhalten, längere Aufbewahrung heißt also Export. Für die weiteren Fragen siehe DSGVO und LLM-Datenresidenz.

Der Auftragsverarbeitungsvertrag. Der Vertrag von Temporal, gültig ab 10. Oktober 2024, enthält Standardvertragsklauseln und ein UK-Addendum. Die Subprocessor-Liste nennt AWS für die Infrastruktur, Google Cloud für Namespaces in GCP-Regionen sowie Datastax, Auth0, Elastic und WorkOS für bestimmte Dienste. Gegen einen neuen Subprocessor kannst du innerhalb von 15 Tagen nach Veröffentlichung widersprechen. Backups werden 30 Tage aufbewahrt, und Kundendaten werden bei Beendigung gelöscht. Temporal erklärt, nach SOC 2 Typ 2 zertifiziert sowie mit DSGVO und HIPAA konform zu sein. Betrachte das als Ausgangspunkt deiner Prüfung, nicht als Rechtsberatung.

Selbsthosting. Das verlagert diese Fragen auf deinen eigenen Hoster, und du trägst Datenbank, Suchspeicher, Backups und Upgrades. Der Server besteht aus vier Services, die unabhängig skalieren: Frontend, History, Matching und Worker. Elasticsearch oder OpenSearch wird empfohlen, sobald du mehr als ein paar Ausführungen betreibst, und das Docker-Compose-Beispiel betreibt PostgreSQL mit Elasticsearch. Temporal empfiehlt, jeweils eine Minor-Version nach der anderen einzuspielen, und Releases können alle zwei Wochen erscheinen. Die Shard-Anzahl wird beim Build festgelegt, und RBAC oder Audit-Logs gibt es nicht ab Werk. Die Checkliste des Herstellers nennt Personal einen erheblichen Kostenfaktor. Hardware habe ich nicht bepreist, weil sie von Shard-Anzahl und Last abhängt.

Wo es hakt

• Determinismus ist eine Gewohnheit. Code zu ändern, während Ausführungen laufen, kann das Replay brechen, und Versionierung lässt alte Codepfade zurück, die du pflegen musst.
• Harte Grenzen der Historie. Ausführungen enden ab 51.200 Ereignissen, 2.000 Updates oder 10.000 Signalen, daher brauchen lange Sitzungen Continue-As-New von Anfang an.
• Retries sind ein Budget. Der unbegrenzte Standard passt zu Infrastruktur und schlecht zu Modellaufrufen.
• Teile sind noch Preview. Die OpenTelemetry- und LangGraph-Integrationen sind Public Preview, Sandbox-Unterstützung ist Pre-Release und Streaming ist experimentell.
• Nicht alles ist dauerhaft. MCP-Server laufen außerhalb des Workflows, und jeder MCP-Aufruf läuft als Activity. LocalShellTool, ComputerTool und SQLiteSession werden nicht unterstützt.

Fazit

Temporal ist der richtige Standard für langlaufende Agenten, die mehrere Systeme berühren und auf Menschen warten, vorausgesetzt, jemand verantwortet den Workflow-Code und, beim Selbsthosting, den Cluster. Als Standard für einen einzelnen Modellaufruf hinter einer HTTP-Anfrage ist es der falsche.

1. Nimm es, wenn ein Lauf Stunden oder Tage dauert und ein Neustart keine Zahlung, keine E-Mail und keinen Modellaufruf wiederholen darf.
2. Nimm es, wenn ein Mensch Schritte freigibt, die erst Tage später kommen, und das Warten Neustarts überstehen muss.
3. Lass es weg, wenn der Agent in Sekunden antwortet. Ein Timeout und ein Retry um den Modellaufruf reichen dann.
4. Betreibe es selbst nur, wenn jemand den Cluster durch häufige Upgrades bringt. Sonst nimm Temporal Cloud.

Drei Alternativen decken die meisten Fälle ab, in denen Temporal übertrieben ist:

• LangGraph-Checkpoints LangGraph wenn der Agent ein Python-Graph ist, der Zustand klein bleibt und PostgreSQL ohnehin da ist. Seine Interrupts pausieren einen Graphen für die menschliche Freigabe.
• Eine Job-Queue mit Zustandstabelle wenn die Pipeline eine feste Folge idempotenter Schritte ist. Retries und Timer baust du selbst, das ist bei fünf Schritten in Ordnung und bei fünfzig mühsam.
• Das OpenAI Agents SDK allein OpenAI Agents SDK wenn jeder Lauf kurz ist, in einem Prozess bleibt und nie einen Neustart überstehen muss.

Quellen

• Temporal Cloud: Preise
• Temporal Cloud: Preisdokumentation
• OpenAI-Agents-SDK-Integration für Python
• Workflow-Definition und Determinismus
• Retry-Policies
• Activity-Timeouts
• Referenz der Cloud-Actions
• Grenzen der Event History
• Nachrichtenübermittlung in Python: Signale, Queries und Updates
• Beispiel für KI-Agenten mit menschlicher Freigabe
• Sicherheitsmodell der Cloud
• Cloud-Service-Regionen
• Auftragsverarbeitungsvertrag
• Anleitung zum Selbsthosting
• Checkliste für den Produktivbetrieb (selbst gehostet)
• Visibility-Speicher beim Selbsthosting
• Architektur des Temporal Servers
• Lizenzdatei des Temporal Servers
• Übersicht der Temporal-Integrationen
• LangGraph-Integration mit Temporal
• LangGraph-Persistenz
• LangGraph-Interrupts
• Anleitung zum Selbsthosting und Entwicklungsserver
• Python-SDK-Referenz: workflow.wait_condition
• Python-SDK-Referenz: ApplicationError