Temporal raised $300 million at a $5 billion valuation this year, led by a16z, explicitly framed around agents moving into production. That's not a vanity round. It's a market signal that the hard part of shipping agents was never the prompt.
Meanwhile AWS, Cloudflare, and Vercel have all shipped or expanded durable execution primitives in the last year. When three platforms with very different customer bases converge on the same pattern in the same window, that's not a trend piece, that's a category forming. The pattern is durable execution: a programming model that guarantees your code finishes despite crashes, restarts, and network failures. It existed before agents. Agents are why everyone suddenly needs it.
Why retry logic stops working once an LLM is in the loop
Traditional backend systems fail in predictable ways. A request times out, you retry it. A worker crashes, you requeue the job. The failure modes are finite and well understood, and a decade of retry-with-backoff patterns handles almost all of them.
Agents break that model in three specific ways. First, orchestration itself has more steps and more branches than a typical job, often a dozen or more LLM calls, tool invocations, and conditional branches chained together, any one of which can fail independently. Second, the LLM's behavior is probabilistic, so the same input can produce a different plan on retry, which means naive replay isn't safe: you can't just rerun the whole function from the top and expect the same tool calls to happen in the same order. Third, agents increasingly wait on humans. A support agent escalates to a manager. An onboarding agent waits three days for HR to approve a laptop request. That's not a retry scenario, that's a multi-day pause with no guarantee the process is even running on the same machine when it resumes.
Stack those three together and you get a failure surface that a try/catch block and a queue consumer were never designed to cover.
The failure mode that should scare you: duplicated side effects
Here's the one that actually costs money. An agent calls a payment API. The process crashes right after the call succeeds but before it records that success. Standard retry logic sees no confirmation, assumes failure, and retries. The payment goes through twice. A crash during the retry itself, or a slow response that looks like a timeout, and it goes through a third time.
Retries, crashes, and agent loops quietly turn one payment into three.
This isn't hypothetical, it's the default outcome of wiring an LLM tool call directly to a side-effecting API without an execution layer that tracks what has already happened. The fix isn't a smarter retry policy. The fix is exactly-once execution for any tool call that moves money, sends an email, or writes to an external system that doesn't have its own idempotency guarantees. That means every money-moving or state-mutating tool call needs an idempotency key generated once and reused across retries, so the downstream system (or the execution engine itself) can recognize
placeholder
How durable execution engines actually recover state
The mechanism is simpler than the marketing makes it sound. Every durable execution engine records each step of a workflow as it runs, essentially an append-only event log: this tool was called with these arguments, it returned this result, this branch was taken. When a crash happens, the engine doesn't guess. It replays that event log from the beginning, but instead of actually re-executing side effects, it feeds the recorded results back in until it reaches the point where execution stopped. Then it resumes as if nothing happened.
That's the whole trick. It's the same idea as event sourcing applied to workflow orchestration instead of application state. The differences between the major platforms come down to how they implement that log and how much of the surrounding infrastructure they own:
- Temporal runs a dedicated server (or managed cloud) that owns the event history and worker coordination, with SDKs in most major languages and strong guarantees for very long-running, complex workflows.
- Inngest leans into a simpler developer experience, function-as-workflow with steps defined inline, aimed at teams who want durable execution without standing up separate infrastructure.
- Restate positions itself as a lighter-weight, self-hostable runtime with a focus on low-latency request/response workflows alongside long-running ones.
- Cloudflare Workflows builds the same checkpoint-and-resume model directly into Workers, so state persists at the edge without a separate orchestration service.
- Vercel's durable execution primitives target the same problem for teams already deployed on their platform, aiming for zero-infrastructure durability for background and long-running tasks.
None of these are competing on whether durable execution works. They're competing on where the workflow state lives, how much infrastructure you have to run yourself, and how tightly it integrates with the rest of your stack.
Human-in-the-loop is not an edge case anymore
Google's Agent Development Kit ships a reference example worth studying closely: a new-hire onboarding coordinator agent that has to request equipment, wait for a manager's approval, and then trigger IT provisioning, a process that can span days. The agent persists its state across restarts, pauses for the approval, and resumes when a webhook fires.
The detail that matters operationally is what happens during the wait. The container running the agent can scale to zero for the entire idle period. There's no process sitting around polling a database for three days burning compute. When the webhook arrives, a container spins up, the session is hydrated from durable storage, and the agent resumes its reasoning chain exactly where it left off, with full context of what it had already decided before pausing.
This generalizes far beyond onboarding bots. Any agent workflow with an approval gate, a vendor callback, a cross-team handoff, or a wait-for-external-event step needs this pattern. Without it, teams end up building ad hoc versions with cron jobs, polling loops, and manually serialized state blobs stuffed into a database column, which works until someone changes the schema of the state blob and every in-flight workflow silently breaks.
When you don't need any of this
Durable execution is not free. It adds a dependency, a mental model shift for engineers used to writing straight-line functions, and in some cases real latency overhead from checkpointing every step. Teams reach for it too early almost as often as they reach for it too late.
A simple job queue with a retry policy is still the right answer if your agent workflow is short-lived, has no side effects that need idempotency, and doesn't pause for anything external. A single-turn RAG query, a classification task, a one-shot summarization job: none of these need a durable execution engine. They need a queue, a timeout, and maybe a dead-letter topic for manual review.
The signal that you've crossed into needing durable execution is specific: your workflow has more than two or three sequential steps where a partial failure leaves the system in an inconsistent state, or it can pause for something outside your control (a human, another system, a scheduled delay) for more than a few seconds, or any of its steps have side effects that are expensive or dangerous to duplicate. If none of those are true, adding Temporal or Inngest to your stack is just extra operational surface area for a problem you don't have yet.
Picking a tool without overthinking it
For teams already committed to a cloud, the path of least resistance usually wins. If you're deep in AWS, Step Functions or Temporal on AWS covers most needs without adding a new vendor relationship. If you're on Cloudflare Workers already, Workflows is the same mental model with none of the deployment overhead. Vercel-native teams get a comparable story for background tasks without leaving the platform.
For teams building agent infrastructure as a first-class product, not just a feature bolted onto an existing app, Temporal's maturity and multi-language SDK support make it the default choice, and the funding round is a reasonable proxy for how much engineering investment will keep flowing into it. Inngest and Restate are worth a serious look if the operational simplicity of not running a separate server outweighs Temporal's broader ecosystem.
What actually matters is not which vendor logo ends up in your stack. It's recognizing that once an agent workflow has multiple steps, side effects, and any possibility of pausing on a human or an external system, you are building a distributed system whether you meant to or not. Durable execution is just the honest name for the infrastructure that distributed system needs. Treating it as a prompting problem instead of a systems problem is how one payment quietly becomes three.