Temporal
Type: full-code · Vendor: Temporal Technologies · Language: Go, Java, Python, TypeScript, .NET, PHP, Ruby · License: MIT · Status: active · Status in practice: mature · First released: 2019-10-16
Open-source durable-execution platform whose Workflows survive crashes, restarts, and infrastructure outages by replaying an event-sourced history; increasingly adopted as the substrate for long-running AI agents.
Description. Temporal is a durable-execution platform originating as a fork of Uber's Cadence and built by Temporal Technologies. The server (Go) coordinates workflows and activities; SDKs in Go, Java, Python, TypeScript, .NET, PHP, and Ruby let developers write Workflow Definitions (deterministic functions) that invoke Activities (idempotent side-effecting functions). The Temporal Service persists every command and event in a per-workflow Event History; when a Worker crashes or restarts, Temporal replays the history to reconstruct in-memory state and continues from the last unfinished step. Signals, Queries, Updates, Schedules, Retry Policies, and the Saga compensation pattern are first-class primitives. Agent frameworks adopt Temporal to make agent loops crash-proof.
Agent loop shape. Workflow-as-code with deterministic replay. The agent loop is written as a Workflow Definition; each model call, tool call, or side effect runs as an Activity with built-in retries and timeouts. The Workflow's Event History is the source of truth: on Worker restart Temporal replays history step by step to rebuild the in-memory state, then resumes execution. Signals drive asynchronous inputs (user messages, approvals); Updates handle synchronous request/response; Queries inspect state without changing it; Schedules trigger periodic runs; Saga lists of compensating Activities roll back on failure.
Primary use cases
- durable workflows for long-running, fault-tolerant business processes
- AI-agent backbones with crash-proof tool loops
- saga / compensation across distributed services
- scheduled and signal-driven recurring jobs
Key concepts
- Workflow → durable-workflow-snapshot (docs) — Deterministic code defining a sequence of steps; the Event History is replayed to reconstruct state.
- Activity → tool-use (docs) — Normal function executing a single well-defined action; auto-retried, can be non-deterministic, should be idempotent.
- Signal / Query / Update → event-driven-agent (docs) — Asynchronous writes, read-only inspections, and synchronous tracked writes against a running Workflow.
- Retry Policy → fallback-chain (docs) — Declarative retry settings on Activities and Workflows; Activities retry by default.
- Saga / Compensation → compensating-action (docs) — Maintain a list of compensating Activities, executed in reverse on failure.
- Schedule → scheduled-agent — Periodic / cron triggers for Workflow Executions.
Patterns this full-code implements —
- ★★Agent Resumption
Workflows pick up exactly where they left off; the engine replays Event History to reconstruct state.
- ★★Compensating Action
Saga pattern documented as a list of compensating Activities executed in reverse order on failure.
- ★★Event-Driven Agent
Signals (async writes), Updates (sync tracked writes), and Queries (reads) drive running Workflows.
- ★★Fallback Chain
Activities retry by default per a declarative Retry Policy; failures fall through retry intervals before surfacing.
- ★★Scheduled Agent
Temporal Schedules are a first-class primitive for periodic / cron-driven Workflow Executions.
- ★★Session Isolation
Each Workflow Execution has exclusive access to its local state; executions are uniquely identified and run concurrently and independently, communicating only via Signals and Activities.
- ★★Tool Use
Activities are the tool-use primitive: idempotent functions that call out to models, APIs, databases, MCP servers, etc.
- ★Durable Workflow Snapshot
Event-sourced Workflow with deterministic replay is the headline feature.
- ★★Replan on Failure
Temporal provides the substrate for replanning: ApplicationError with non_retryable=True bypasses retries and surfaces failure to the Workflow, which can then catch ActivityError and choose a new bra…
- ★★Step Budget
Activity timeouts (Schedule-To-Close, Start-To-Close, Schedule-To-Start, Heartbeat) and retry-policy max attempts function as per-step budgets; the engine does not surface a global step-count budget…
Neighbourhood
Click any neighbour to follow the lineage. Scroll to zoom, drag to pan.
Alternatives & relatives
Listed as alternative by (3)
References
“Build applications that never lose state, even when everything else fails.”
Temporal documentation
temporalio/temporal
“Temporal is a durable execution platform that enables developers to build scalable applications without sacrificing productivity or reliability.”
“Develop agents that survive real-world chaos, reliable MCP & orchestrate training pipelines.”
Provenance
- Last analyzed:
- Last updated:
- Verification status: verified