Dora NodaThree days ago, Temporal raised USD 550 million at a USD 12.55 billion valuation — seven months after raising USD 300 million at USD 5 billion. In between those two rounds, on March 23, its integration with OpenAI's Agents SDK went generally available. That sequence is the whole story: investors just priced "your AI agent survives a crash mid-task" as a twelve-billion-dollar requirement, and the tooling to deliver it is already GA.
The bet is specifically about agents that do things, not agents that chat. A deploy-from-chat agent — "ship the hotfix branch to staging, verify it, then promote to production" — is a multi-step workflow with side effects, long waits, and a human approval gate. Run that as fire-and-forget tool calls and a single pod restart turns it into a mess. This post shows exactly what breaks, how durable execution fixes it, and what adopting it costs: managed cloud, self-hosted open source, or a lighter engine.
The news ledger: three numbers that moved in 2026
First, the receipts. On February 17, Temporal announced a USD 300 million Series D at a USD 5 billion valuation, led by Andreessen Horowitz with Lightspeed, Sapphire, and Sequoia participating — doubling the USD 2.5 billion mark from an October secondary. OpenAI's VP of app infrastructure, Venkat Venkataramani, put the thesis in one sentence in that announcement: "As AI systems become more complex and long-running, durability is as important as performance."
Second, on March 23 the OpenAI Agents SDK integration went GA for Temporal's Python SDK: the agent loop runs as a workflow, tool calls run as activities, and an activity_as_tool helper generates OpenAI-compatible tool schemas straight from activity signatures.
Third, on September 14, Temporal raised USD 550 million at USD 12.55 billion, led by Lightspeed, disclosing an annualized revenue run rate above USD 250 million (tripled year over year), a team doubled to 570, and named customers including Anysphere (Cursor) and Lovable. Temporal Cloud has processed 9.1 trillion lifetime action executions, 1.86 trillion of them for AI-native companies. Gartner, meanwhile, warned in August that agentic AI workflow costs will rise more than fivefold through 2028 — the "Inference Paradox" of cheaper tokens but vastly more of them.
Durability is no longer the niche infrastructure concern. It is the line item.
The core scenario: what a crash does to "ship the hotfix"
Here is the concrete thing the title promises. A developer tells a deploy agent in chat: "Deploy the hotfix branch to staging, run smoke checks, and if they pass, promote to production — ask me before the prod step." The agent plans five steps:
- Trigger the staging deploy, get a deploy ID.
- Wait for the service to report healthy (minutes, maybe tens of minutes).
- Run the smoke suite against staging and record results.
- Ask the human to approve the production promotion (hours, maybe overnight).
- Promote to production — or roll staging back if anything failed.
Now kill the agent's pod in the middle of step 3. Here is what happens under each execution model:
| Step state at crash | Fire-and-forget tool calls | Durable execution |
|---|---|---|
| Deploy ID from step 1 | Gone with process memory; the replacement must list deploys and guess which one is "mine" | In the event history; replay hands it back without re-triggering |
| Health-wait from step 2 | Restarts from zero, or worse, the new session doesn't know a wait was in progress | The wait is a durable timer; it simply continues |
| Partial smoke results, step 3 | Lost; the suite re-runs end to end (or partially, with no record of what passed) | Completed activities replay their recorded results; only unfinished work re-runs |
| LLM reasoning so far | Re-derived from scratch — every planning token burned again | Replayed from history at zero token cost |
| Pending prod approval, step 4 | No record an approval was ever requested; the human gets asked twice or never | A signal the workflow is durably blocked on; asking twice is impossible |
| Rollback decision | Made blind: "did staging actually go green?" is now a guess | Made from recorded step-3 results |
The fire-and-forget column has one failure mode that should scare anyone running production: the replacement session, unsure whether step 1 completed, can trigger the deploy again. Unless every tool in the chain is perfectly idempotent — and "trigger_deploy" rarely is — recovery and double-deploy become indistinguishable. Durable execution removes the ambiguity structurally: completed activities are never re-executed, their results replayed from history instead.
Note what this scenario assumes: a typical mid-size deploy with a human gate, not a hyperscale edge case. Long waits, an approval, and a non-idempotent trigger are the normal shape of deploy-from-chat, which is why the fix belongs in the execution layer rather than in per-agent heroics.
How durable execution delivers the right-hand column
Temporal's model is event sourcing applied to program execution. Every workflow run appends events — activity scheduled, activity completed, timer fired, signal received — to a history, and all workflow state can be recreated at any time by replaying that history. Three consequences do all the work in the scenario above:
Workflows decide, activities act. Workflow code must be deterministic; every side effect (LLM calls, MCP tool invocations, file I/O) runs inside an activity. When a worker crashes and a replacement replays the workflow, each completed activity returns its recorded result instead of re-running. That is the entire mechanism behind "resumes at the exact step it died on." In agent terms, the mapping the GA integration makes official is: the agent loop is a workflow, each model call and tool call is an activity.
Signals and timers make waiting free. A workflow blocked on a human approval or a twenty-minute health check consumes no worker resources while it waits — it is history plus a wake condition, resumable days later. Compare the fire-and-forget version, where "wait" means a process staying alive (and billable, and crashable) for the whole window. Human-in-the-loop deploy gates stop being the thing that breaks your agent runtime's cost model.
Retries, heartbeats, and versioning handle the rest. Activities retry transient failures with exponential backoff instead of failing the whole run; long activities heartbeat so a stalled tool call is detected rather than silently hung. And worker versioning means the agent code itself can be redeployed mid-run without stranding in-flight deploys — the scenario's fix doesn't require freezing the deployer.
The March GA integration matters because it collapses the adoption gap: activity_as_tool turns existing Temporal activities into agent tools with generated schemas, and the OpenAIAgentsPlugin wires the durability in without restructuring the agent. Teams already running OpenAI's Agents SDK get the right-hand column by promoting their tool layer, not by rewriting their agent.
The adoption decision: cloud, self-hosted, lighter, or hand-rolled
Knowing the mechanism, the question is what it costs to run. Four options, honestly compared:
| Option | What you operate | Ops weight | Best for |
|---|---|---|---|
| Temporal Cloud | Nothing; action-metered managed service | Near zero | Teams that want durability this sprint and can meter it |
| Self-hosted Temporal OSS | Server cluster + Postgres/MySQL/Cassandra; Elasticsearch optional (SQL visibility since v1.20) | Real: upgrades, history growth, retention tuning | Fleets that already run stateful infra and want data-plane control |
| Lighter engines (DBOS, Restate, Inngest) | DBOS: your existing Postgres, zero new infra; Restate: lightweight sidecar; Inngest: TS-first, serverless | Low | Narrower needs: one language, HTTP-native services, TS background jobs |
| In-house state machine | Your own checkpoint table + resume logic | Deceptively high over time | Short, idempotent, gateless sequences — and only those |
Be concrete about the self-hosted middle row, since this blog's readers run their own machines. A production Temporal cluster is the server processes plus a persistence store (Postgres 12+ is the common pick), with advanced visibility available on SQL databases since v1.20 — Elasticsearch is no longer the forced dependency it once was. Docker Compose covers small setups; Helm covers Kubernetes.
The ongoing costs are the ones distributed systems always charge: version upgrades across the cluster, event-history growth and retention policy, and enough Postgres competence to keep the workflow store healthy. Teams routinely underestimate the human cost here — the infrastructure bill is the smaller half of self-hosted TCO.
The threshold rule for the bottom row is the most useful deliverable in this section. Hand-rolled checkpointing stays sufficient while all four of these hold: steps complete in seconds (no long waits), every tool is idempotent (double-execution is harmless), no human gate interrupts the flow, and one language runtime runs everything. The deploy-from-chat scenario violates the first three simultaneously — minutes-long health waits, a non-idempotent deploy trigger, an overnight approval. The moment your agent workflow has a wait, a gate, or a side effect you can't safely repeat, you've outgrown the state machine and should price the engines above instead of building the fifth one.
What this means for a self-hosted PaaS
If you run a git-push platform and are adding an agent story — an MCP server with deploy, logs, and rollback tools — Temporal's arc is your roadmap input twice over. First, your tools are someone's future activities: scope them explicitly, annotate destructiveness, and make them as idempotent as you can, because durable agents calling them will still benefit when the platform cooperates. Second, the agent runtime sitting on top of those tools needs resume semantics from day one; bolting durability onto a fleet of fire-and-forget chat sessions after the first 3 a.m. double-deploy is the expensive order of operations.
The market just told you what that runtime is worth: USD 5 billion in February, USD 12.55 billion in September, with Cursor and Lovable already running on it. Durable execution won the "is this required for production agents" debate. The remaining question is only which row of the table you pick — and for a deploy-from-chat workflow with waits, gates, and real side effects, "none of the above" stopped being an option sometime around March 23.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
