Temporal is a durable execution platform: you write workflows as ordinary code (Python, Go, TypeScript, Java, .NET), and the Temporal Service persists the full running state at every step — so when something fails, the workflow resumes exactly where it left off. No lost progress, no orphaned processes, no manual recovery. Failure-prone calls — APIs, LLM invocations, tools — are wrapped as Activities with automatic retries. It matters now because the agent reliability problem (an LLM call dies mid-loop, a tool times out, a human approval takes three days) is exactly the problem this lineage has been solving since Cadence in 2017. The engineering is real; the honest read is the operational weight.
Most orchestration tools make you describe a process in YAML, a DAG, or a diagram. Temporal's bet is that a process is best described as the code you'd naturally write — loops, conditionals, try/catch — with the platform making that code durable. Every state transition is recorded as an event history; if the worker running your workflow dies, another worker replays the history and continues from the exact step where execution stopped. A workflow can sleep for thirty days waiting for a human approval and consume no resources doing it.
The pedigree is unusually deep and worth naming: Temporal's founders built AWS SQS and Simple Workflow (SWF), worked on Azure Durable Functions, and created Cadence at Uber — the project Temporal forked from in 2019 and which still runs Uber-scale workloads. This is a third-generation take on a problem the same people have owned since the mid-2000s.
The Temporal server and SDKs are MIT-licensed and genuinely self-hostable — the core is open source in the full sense. The commercial layer is Temporal Cloud, the managed service, which is proprietary and USD-billed. That's the same honest split as LangGraph/LangSmith: the durable-execution engine is free; at production scale most teams end up paying for either the Cloud or the ops team that replaces it.
Two primitives carry the model. A Workflow is the durable orchestration logic; an Activity is any failure-prone call the workflow makes. The split is the whole design — and it comes with one hard rule.
Workflow code must be deterministic, because recovery works by replaying the event history — the same inputs must take the same path. Anything non-deterministic (network calls, random numbers, clock reads, LLM invocations) lives in Activities, which are recorded once and never re-executed on replay. Activities get automatic retries with backoff, timeouts, and heartbeats; Signals and Updates let the outside world (a webhook, a human approval, another system) reach into a running workflow. Your code runs on your workers; the Temporal Service only schedules and records.
# Python — the shape of a durable agent step @workflow.defn class ApprovalFlow: @workflow.run async def run(self, req: Request) -> str: # failure-prone call -> Activity with automatic retries draft = await workflow.execute_activity( call_llm, req, start_to_close_timeout=timedelta(minutes=2), retry_policy=RetryPolicy(maximum_attempts=5), ) # durable wait — human approval can take three days; costs nothing await workflow.wait_condition(lambda: self.approved) return await workflow.execute_activity(publish, draft, ...)
A self-hosted deployment is three moving parts: the Temporal Service (the cluster), a persistence layer (PostgreSQL, MySQL, or Cassandra — plus optionally Elasticsearch for visibility), and your worker fleet. That is a real infrastructure commitment with upgrades, capacity, and on-call attached — not a container you forget about. It's the central trade in the decision section below.
Temporal's 2026 positioning is squarely "build AI apps and agents on an open foundation." The mechanism claim is sound — an agent loop is a long-running workflow full of failure-prone calls — but the pieces are at very different maturities, and the labels matter.
| Piece | What it is | Maturity (as stated by Temporal, Jul 2026) |
|---|---|---|
| OpenAI Agents SDK integration | Durable agent loops on the Python SDK — each model/tool call an Activity. | GA since March 2026 |
| Vercel AI SDK integration | Same pattern for the TypeScript world. | Shipped; check current status |
| Google ADK integration | Durable execution under ADK agents. | Public preview |
| Serverless Workers | Workers without managing worker infrastructure (incl. Lambda). | Pre-release |
| Standalone Activities | Activities as first-class jobs outside a workflow — durable job processing without the queue plumbing. | Announced at Replay 2026 |
| Workflow Streams | Durable token streaming — LLM output through a workflow to a UI, with replay guarantees. | Announced at Replay 2026 |
The honest framing: the durable core is nine years proven via the Cadence lineage; the AI-specific surface is one GA integration plus a set of previews and announcements. Build on the core with confidence; treat the Replay 2026 pieces as roadmap you verify before you depend on it. And note what this leaf deliberately doesn't cite as evidence: the customer logos and testimonial quotes on temporal.io are vendor marketing — the checkable facts are the MIT repo, the docs, and the integration release notes.
Two positioning notes before the table. The BPM-suite comparison — Temporal vs Camunda for business-process work — lives on the Process orchestration leaf; this leaf is the engine-under-agents lens. And the closest genuine alternative for a Cloudflare-native stack has its own leaf: Cloudflare Workflows, which describes itself as Temporal-like semantics without running Temporal.
| Concern | Temporal | Cloudflare Workflows | DIY (queues + cron + state table) |
|---|---|---|---|
| Durability model | Event-history replay; exact resume | Durable Objects; step-based resume | Whatever you build |
| Infrastructure | Service + persistence + workers (or Cloud) | Zero — runs on the edge | Yours, forever |
| Language reach | Python, Go, TS, Java, .NET, more | JS/TS on Workers | Any |
| Maturity | Cadence lineage since 2017; battle-proven at scale | GA 2025 — young, moving fast | As mature as your team makes it |
| Long human-in-the-loop waits | Native — sleep for a month, free | Supported, within platform limits | The part everyone gets wrong |
| Best fit | Must-not-fail, long-running, polyglot, complex compensation | Cloudflare-native stacks with moderate workflow needs | Simple, short, tolerable-loss jobs |
Interruption survival is a local feature, not a nicety. In an environment where load-shedding and connectivity drops are planning assumptions, a workflow engine that resumes exactly — rather than restarts or loses state — changes what you can safely automate. A multi-hour ERP integration run or document pipeline that survives a power event mid-flight is the difference between automation you trust and automation you babysit.
The natural local workloads are human-in-the-loop and integration-shaped. Recruitment pipelines with days-long candidate and approval stages; ERP flows where a dropped step means a broken invoice; onboarding and compliance processes that wait on people. These are precisely the long-wait, must-not-fail shapes durable execution exists for — and where the "sleep for a month, free" property earns its keep.
Residency and the FX line. Self-hosted Temporal runs wherever you put it — an in-country VPC or on-prem rack — so the POPIA residency answer is yours to make, and the workflow state (which will contain personal information) stays home. The trade is the usual one: Temporal Cloud is USD-billed; self-hosting swaps the FX line for an ops commitment. For most SA teams the honest sequence is: prototype against a local docker-compose stack, and make the Cloud-vs-self-host call only when a real workload proves the platform.
The repo, the docs, and the dated integration announcements — maturity labels move, so check current status before depending on the preview-stage pieces. Last reviewed 2026-07-30.