Agent infrastructure
Agents in production
Durable execution for AI agents explained: what Temporal-style workflows solve for long-running agents, where the abstractions leak, and what they don't fix.
Agents that run for minutes are easy. Agents that run for hours, span a dozen tool calls, resume after a crash, and end up in a state your finance team can audit — those are hard. The question isn't whether your model can reason through the plan. It's whether the runtime beneath it can survive the plan.
Durable execution is the pattern most teams reach for when they hit that wall. Borrowed from workflow engines like Temporal, Restate, and AWS Step Functions, it promises exactly-once semantics, replayable history, and workflows that outlive the processes running them. That promise maps unevenly onto agents. Some of it fits cleanly. Some of it fights the way models actually work.
This piece walks through what durable execution actually gives you, where it lands well for agents, where the abstractions leak, and how to think about the trade-offs before you commit a codebase to a workflow engine you'll be married to.
A durable execution engine treats a workflow as a deterministic function whose every step is persisted. If the process crashes halfway through, another process picks up the workflow from the last recorded step and replays history to reconstruct state. Side effects — API calls, database writes, tool invocations — are wrapped as activities and executed at most once (or at least once, with idempotency required) against the outside world.
The pattern comes from Cadence and its successor Temporal, with variations in Restate, Inngest, AWS Step Functions, and DBOS. The mechanics differ. The core contract is the same: the workflow is code, the engine handles persistence, retries, timers, and recovery.
For long-running agent workflows, three properties matter most:
Some agent workloads look almost exactly like the workflows durable engines were built for. Long-horizon business processes: onboard a customer, close a deal, run a payroll cycle. The agent decides what to do next; the workflow persists what's been done. When the agent chooses to call a tool, that call becomes an activity. When it waits for a human review, that's a signal. When the process crashes, everything resumes.
Four concrete patterns where the fit is strong:
Multi-step business workflows with tool calls. An agent that processes an insurance claim across five internal systems, waits for adjuster approval, then writes back to the policy record. Every tool call is an activity. Every wait is a timer. If the worker restarts, no step repeats and no step is lost.
Scheduled and recurring agents. An agent that runs nightly reconciliation across a set of customer accounts. Durable execution gives you cron-like scheduling, per-tenant workflow isolation, and a clean audit log of what ran, when, and what it touched.
Human-in-the-loop pauses. The agent proposes an action, the workflow signals a human reviewer, and execution suspends until a response arrives. Without durable execution, you're building this on Redis, cron jobs, and hope. With it, the pattern is a two-line signal handler.
Compensating actions on failure. When step 7 fails, the workflow needs to reverse steps 3, 4, and 5. Saga patterns are native to durable engines. Agents that touch multiple systems benefit directly — and this is where the AI agent error handling story gets much shorter to write.
Agent workflow reliability, in the sense of "the workflow finishes what it started or explicitly rolls back," is a real win here. That's not something you get from an orchestrator loop and a try/except.
Durable execution engines were designed for deterministic business logic. Agents are the opposite of that. A model call is non-deterministic by construction — same prompt, different completion, different tool choice, different plan. That collides with the replay model in ways worth understanding before you commit.
The engine replays workflow code to rebuild state. If your workflow contains a model call, the engine needs to either (a) treat the model call as an activity whose result is recorded and replayed from history, or (b) accept that replay will produce a different plan than the original run.
Every serious framework picks (a). Temporal's OpenAI Agents SDK integration and its AI SDK integrations treat each LLM call as an activity. LangGraph's checkpointing does the same. This works — but it means the "reasoning" of your agent is frozen the moment it's persisted. Replay doesn't re-think. It re-plays a script.
That's mostly what you want. It also means you can't just drop a model call inside workflow code and expect the engine to figure it out. Every model interaction has to be structured as an activity with a stable input, a recorded output, and idempotent semantics on retry.
Activities in durable engines run at least once. If the worker dies after the API call succeeded but before the result was recorded, the workflow retries and the call happens again. For read operations, fine. For "send the invoice" or "charge the card," not fine.
The standard answer is API idempotency keys. The workflow generates a stable key, the tool endpoint honours it, duplicate calls collapse. This works when you control the API. When your agent is calling third-party SaaS APIs whose idempotency support ranges from excellent to non-existent, it doesn't. You end up wrapping every non-idempotent tool in a coordination layer that dedupes on your side — which is real engineering, not a checkbox.
Durable engines persist every event. For a workflow with 20 tool calls and 20 model responses, that's manageable. For an agent that plans 400 steps, revises its plan halfway through, and carries a growing context window of tool results — history size becomes a load-bearing constraint.
Temporal caps individual workflow histories at 51,200 events or 50 MB, whichever comes first, and starts warning at 10,240 events or 10 MB. For agent workflows carrying large tool-call payloads, the 50 MB size cap is often the binding constraint long before event count is. Long-running agents blow past these limits without careful context window management at the workflow level, not just the model level. Child workflows and continue-as-new patterns are the workaround. They also add complexity that the marketing pages don't mention.
The three most common choices for durable AI workflows have different trade-offs. A rough map:
Temporal is the incumbent — most mature, most examples, biggest community, and now with dedicated agent tooling. Restate is younger and optimised for lower per-step latency, which matters when your agent makes many small tool calls in sequence. Step Functions is the path of least resistance inside AWS but its state machine model resists the dynamic planning most agents actually do.
Beyond those three, Inngest, DBOS, and LangGraph's persistence layer all offer partial versions of the same guarantees. LangGraph in particular is worth naming because it comes from the agent world rather than the workflow world — it starts from graphs and adds durability, rather than starting from workflows and adding agent primitives. Which side you start from shapes what feels natural.
Whichever engine you pick, the same architectural question sits underneath: durability doesn't fix the tools your agent is calling. If those tools are flaky, missing capabilities, or authenticated as a service account instead of the real user, durable execution just gives you a more reliable way to reach the wrong surface.
It's easy to read the marketing and conclude that durable execution is the missing layer for production agents. It's a missing layer. It isn't the missing layer.
Four things it doesn't touch:
Tool coverage. If your agent needs to read a report your API doesn't expose, no amount of workflow durability creates the endpoint. The gap between what a product's UI can do and what its API can do is the structural problem behind most stalled agent projects, and it sits below the workflow layer entirely.
Tool call authorisation. Durable engines run activities under whatever identity the worker holds. If that's a service account, every tool call in your workflow executes as that service account — losing the per-user permissions, data visibility, and audit trail that real security reviews demand. See agent identity vs user identity for why this boundary matters.
Tool description quality. The model still has to pick the right tool. If descriptions are ambiguous or the tool surface is bloated, the workflow will durably execute the wrong plan. Fast.
Third-party API drift. When a SaaS vendor renames a field, durable execution replays the failure. It doesn't fix the connector. That's a connector maintenance problem, not a runtime problem.
The honest framing: durable execution is a real answer to a real class of reliability problems — crashes, waits, retries, compensating actions across long-running plans. It's not a substitute for the tools layer beneath it, and treating it as one is how teams end up with beautifully durable workflows that still can't reach their own product.
A rough decision rule: reach for durable execution when your agent workflows have at least two of these properties.
If your agent is a chat loop with tool calls that completes in under a minute, durable execution is overkill. A well-designed stateful runtime with checkpointing handles that case with less operational surface.
If your agent is running a multi-day process across five systems with human approvals in the middle, durable execution is close to non-negotiable. The question stops being "do we need it" and becomes "which engine, and how do we structure activities so replay actually works."
Most real production deployments sit between the two. That's where the decision gets interesting — and where the answer usually isn't a single tool, but a stack: an orchestrator for the plan, a durable engine for the long-running parts of the plan, and a tools layer beneath both that can actually reach the product the plan wants to act on.
Durable execution engines have been evolving toward agents for two years now. The interesting question isn't which one wins. It's what happens to the boundary between orchestration, durability, and tool execution as each layer matures.
Today, teams stitch these together by hand. Tomorrow, the seams will move. Some workflow engines will absorb more agent primitives — Temporal already has. Some agent frameworks will absorb more durability — LangGraph already has. And the tools layer beneath both will stop being the improvised part of the stack and start being the deliberate one.
The teams building production agents right now are the ones deciding where those seams land. Durable execution is a genuine part of that answer. It just isn't the whole answer, and pretending otherwise is how you end up with a reliable workflow that still can't do the job.
Stay up to date on the ever changing agentic landscape.
GET STARTED
Start with a 30-minute discovery call
contactus@pontil.com
