Durable execution
What is durable execution?
An AI agent that calls five tools, or an order that charges a card and then waits three days for a carrier, will fail halfway at some point, and somebody ends up repairing the state by hand. Durable execution is a way of running long processes like these so they survive the machine they started on. The engine records every step, and after a crash or a deploy it replays that history and carries on where it stopped.
TechFabric is a Temporal partner. Our senior engineers build agent runs, approvals and long-running API operations as durable workflows on Temporal, inside your own systems, with the workflow history as the audit trail. We run our own products the same way.
It's how an AI agent gets from a demo to production without a person babysitting every run. With durable execution your team stops writing the retry tables and clean-up jobs that patch over failure, and that code is where most of the bugs in a long-running system live.
The problem it removes
Take an order that charges a card, reserves stock, books a carrier and emails a confirmation. Four steps, three of which can fail, one of which can take three days. Written normally, that becomes four handlers, a status column, a retry table, a nightly job that finds stuck rows, and a runbook for the operations team. Most of that code exists to describe what should happen when something goes wrong halfway.
Under durable execution it is one function that reads top to bottom, with the waits written as waits. The engine holds the position. A crash three days in resumes at the carrier step with the card still charged exactly once.
| What fails | Written by hand | Durable execution |
|---|---|---|
| Worker crashes mid-order | Status column says in-progress forever; a human repairs it | Replays to the last completed step and continues |
| Payment API times out | Retry loop, and a risk of charging twice | Step retried under a policy; the charge stays exactly once |
| Deploy lands mid-flight | In-flight work is lost or half-applied | Runs continue; versioning decides which code they use |
| Waiting three days on a carrier | Cron job scans for stuck rows | The workflow simply waits, holding its place |
| Someone asks what happened on order 4471 | Grep the logs, if they are still retained | Query the run history: every step, input and retry |
The part the tutorials skip
Replay puts real rules on your code
Because recovery works by replaying history, workflow code has to produce the same result every time it runs. That rules out reading the clock, generating a random number or a UUID, and calling out to a network directly from workflow code. Each of those has to move into a recorded step, or the replay diverges from the history and the run fails in a way that reads as a mystery the first time you see it.
This is the single most common way a first durable workflow goes wrong, and it is a design constraint rather than a bug. It is worth knowing before you choose the approach, because it shapes how the code is written from the first line.
Clients running this in production
Each of these is a process that takes days, touches several systems, and must never half-complete.
Athlinks
More than 400 million athlete records stitched across disparate sources on a multi-tiered serverless architecture, with granular control, automated retries and real-time visibility across the pipeline.
Vehicle repossession risk
A long-running, legally sensitive process rebuilt on Temporal so every step is recoverable and the full history of what happened is there afterwards, which is the part the lawyers care about.
Auto Approve
An automated approval engine that doubled the monthly loans processed and replaced more than four manual workflows. Twice the volume, and no new agents hired to carry it.
Fabric
Our own agent runtime. A session that thinks for hours, calls six tools and waits on a person runs as a Temporal workflow, with every nondeterministic call in an activity so a replay reaches the same decisions rather than asking the model again.
Canvass
Our own production application, running on Cloudflare with PostgreSQL and durable Temporal workflows. We are on the pager for this one, which changes how it was designed.
Where we use it
APIs and durable systems
The service, and how an engagement usually starts
AI workflow automation
Long-running processes with model calls inside them
Agentic AI development
Agents that park for approval and survive a restart
Durable execution with Temporal
Our Temporal capability in full
Auto Approve
Twice the loans, no new agents
Durable RAG with Temporal
Working code, not an illustration
FAQ
Durable execution: common questions
What is durable execution?
A way of running a long process so that it survives the machine it started on. The engine records every step and its result, and if the worker crashes, redeploys or loses the network, the process is rebuilt by replaying that history and continues from where it stopped.
The practical effect is that a workflow can run for days across restarts without anybody writing state-machine and retry code by hand.
How is durable execution different from a queue or a cron job?
A queue moves messages and leaves the sequencing to you. Durable execution holds the sequence itself, including the waits, so "charge the card, then wait up to three days for the carrier, then either confirm or refund" is one readable function rather than four handlers and a state column.
If a step fails, the engine retries that step rather than replaying the side effects around it.
What are the main durable execution frameworks?
Temporal is the most widely deployed, and it is the one we build on and partner with. Others in the category include Restate, Inngest, DBOS, Azure Durable Functions and AWS Step Functions.
They differ mainly in whether you write ordinary code or a state definition, whether they are hosted or self-run, and how they handle versioning a workflow that is already in flight.
When is durable execution not worth it?
For anything short and idempotent, it is overhead you will feel. A request that finishes in a second and can simply be retried does not need replay, a worker fleet, or the discipline that comes with them.
The line is roughly: does a partial failure here leave the business in a state somebody has to repair by hand? If not, use a queue.
What is the hardest part in practice?
Versioning. A workflow that runs for three days will have code deployed underneath it mid-flight, and changing the order of steps changes the history that replay depends on. Every framework has a mechanism for this, and every team learns it the second time rather than the first. Budget for it before the first long-running workflow ships, not after.
Does durable execution help with AI agents?
It is close to a requirement once an agent does more than one thing. Model calls fail far more often than database calls, agent runs are long, and a half-completed sequence of tool calls is exactly the state nobody wants to unpick. Approvals become natural too: the run parks waiting for a person and survives a restart while it waits.