Durable Execution for Agents: Temporal vs Inngest vs Restate

Why Agents Need Durable Execution (and Queues Don't Cut It)

A traditional background job is short, idempotent, and cheap to retry from scratch. An agent run is none of those things. It is long (seconds to days), stateful (the plan and accumulated context are the work), and built from steps that are individually expensive and often irreversible. Retrying an agent from the top is not a safety net, it is a way to double-charge a customer and re-corrupt a file.

Three properties of agents break the naive queue-plus-retry pattern:

Steps are probabilistic and non-repeatable. Every LLM call costs money and produces a different result each time. If your agent crashes after step 7, you do not want a retry to re-run steps 1 through 6, that is six more paid completions and six more tool invocations, and the rerun may take a different path entirely because the model is non-deterministic. Durable execution records each step's result once and replays it from the journal, so recovery is exact, not approximate.

Tool calls have side effects. Agents send emails, charge cards, open pull requests, and write database rows. A retry that re-runs a completed tool call sends the email twice. Durable execution combined with idempotent tools means a replayed step is a no-op on the external system.

Approval gates outlive the process. The moment your agent takes a consequential action, you want a human-in-the-loop approval gate in front of it. That gate might take five minutes or five days. No in-memory loop survives a deploy, a scale-down, or a crash across that window. Durable execution suspends the workflow at the gate with zero running compute and wakes it on the exact line when the approval signal arrives.

A job queue gives you at-least-once delivery and retries. It does not give you a journal, deterministic replay, suspendable multi-day waits, or exactly-once step semantics. Those are the durable execution primitives, and they are why this is its own category rather than a feature you add to BullMQ or SQS.

Temporal: The Mature Default With a Payload Trap

Temporal is the most battle-tested durable execution platform, descended from Uber's Cadence and run at scale across large engineering orgs. The model is workflow-as-code: you write a workflow function that orchestrates activities (your side-effecting steps), and Temporal guarantees exactly-once execution semantics for activities through its history-and-replay engine. In early 2026 Temporal shipped Nexus to GA (cross-namespace, cross-team service calls) and Multi-Region Replication to GA with a 99.99% SLA, which closes the last serious gaps for regulated, multi-region agent deployments.

For agents, Temporal's strengths are real. Multi-day and multi-week workflows are first-class. Signals and queries give you clean human-in-the-loop gates and live state inspection. The SDK exists for Go, Java, TypeScript, Python, and .NET, so you are not locked into one language. The operational tradeoff is weight: you run a Temporal server (or pay for Temporal Cloud) plus a worker fleet, and there is a genuine learning curve around determinism constraints and the activity-versus-workflow boundary.

Inngest: Fastest Path From App Code, Watch the Step Bill

Inngest takes the opposite stance on operational weight. There is no worker fleet to run and no separate server to operate in the self-managed sense, you write durable functions in your existing TypeScript (or Python/Go) application and Inngest's platform invokes them over HTTP in response to events. The ergonomics are the cleanest in the category for app developers: you wrap each durable boundary in step.run() with normal async/await, and Inngest memoizes the result so a re-run skips completed steps.

export const researchAgent = inngest.createFunction(
  { id: "research-agent" },
  { event: "agent/research.requested" },
  async ({ event, step }) => {
    const plan = await step.run("plan", () => llm.plan(event.data.task));

    const results = [];
    for (const subtask of plan.subtasks) {
      // each step.run result is journaled; a crash replays it, never re-calls
      const r = await step.run(`tool-${subtask.id}`, () => runTool(subtask));
      results.push(r);
    }

    // suspend with zero compute until a human approves
    await step.waitForEvent("approval", {
      event: "agent/approved",
      timeout: "3d",
      match: "data.runId",
    });

    return step.run("finalize", () => llm.synthesize(results));
  }
);

That waitForEvent is the human-in-the-loop gate: the function suspends for up to three days at zero running cost and wakes when the approval event lands. This is genuinely the fastest way to make an existing TypeScript agent durable.

Restate: Same Guarantees, Lighter Footprint, Exactly-Once Writes

Restate is the newest of the three and uses the same journal-and-replay model as Temporal, but ships as a single self-contained binary (the Restate server) with a notably lighter operational footprint. You write durable handlers in TypeScript, Java/Kotlin, Go, Python, or Rust, and Restate journals each step exactly like Temporal does. The pitch is "durable execution at the service boundary": Restate sits in front of your services and makes their handlers durable, resumable, and exactly-once without the heavier Temporal server plus worker topology.

The differentiator that matters most for agents is exactly-once semantics for writes without hand-rolling app-level idempotency keys. In Temporal and Inngest, the durable engine guarantees a step's result is recorded once and replayed, but it does not guarantee the underlying external write happened exactly once if a crash lands mid-call (after the side effect, before the journal write). That at-least-once edge is why you still add idempotency keys to write tools. Restate narrows this gap: its execution model gives handlers exactly-once invocation guarantees, so the amount of idempotency plumbing you write by hand drops. You should still design write tools to be safe under replay, but Restate does more of the work for you.

Restate's awakeables are its human-in-the-loop primitive (suspend, hand out a token, resume when the token is completed), and its lighter footprint makes it attractive when you do not want to operate a full Temporal cluster but you do want Temporal-grade guarantees.

Side-by-Side: The Decision Axes That Matter

The vendor pages push feature checklists. The actual decision is four axes: workflow maturity and duration, how you handle large LLM payloads, the cost model under realistic retry volume, and language fit.

A few patterns hold across the axes. Temporal earns its operational weight when workflows are long and regulated, the multi-region and SLA story is the reason large enterprises pick it, and the payload codec is mandatory homework rather than an edge case. Inngest wins on time-to-durability for TypeScript teams, but the step bill is the thing to model before you scale, not after. Restate is the sharpest pick when you want the journal-and-replay guarantee with the least operational surface and you value the exactly-once write semantics enough to adopt a younger platform.

Checkpointing, Resumption, and Idempotent Write Tools

The mechanics of "resume from a failed tool call without re-running side effects" come down to three disciplines that apply regardless of engine.

Wrap every side effect in a durable step. The LLM call, the tool invocation, the database write, the sleep, the wait-for-signal, each is a journaled boundary. Inside the step you do the work; the engine records the result. On replay, the recorded result returns and the body never runs again. The corollary is that anything outside a step must be deterministic, because it re-executes on every replay.

Make write tools idempotent. Because the engine's guarantee is at-least-once on the external system (the crash-mid-call window), a write tool can run twice. Pass a stable idempotency key derived from the workflow run ID and step ID, so the second call is a no-op: the payment processor sees a duplicate key and returns the original charge, the email sender deduplicates, the row insert is an upsert. Restate reduces how much of this you write by hand, but the principle is universal, design the tool so a replay is safe. This is the durable-layer twin of the tool-use correctness work you do at the agent layer.

Checkpoint state, not just steps. For agents that accumulate large working state (a plan, a scratchpad, retrieved context), keep the durable history lean by checkpointing big state to external storage and journaling the reference. This is the same claim-check pattern that keeps Temporal history under its cap, and it doubles as a clean recovery point: on resume, rehydrate state from the checkpoint rather than from a 40MB history blob.

Recommendation by Scenario

We close every durable execution scoping conversation with a concrete recommendation. They are imperfect, but they hold up most often:

Durability is what separates an agent demo from an agent in production. The model can be perfect and the agent will still feel unreliable if a worker restart wipes forty minutes of state and a retry re-runs every paid step. The broader question of when this reliability work pays off, and how to measure it, sits in our agent reliability versus accuracy guide and the wider AI Agents pillar. At Particula Tech we treat durable execution as a default for any agent that takes real-world actions, because the alternative is an agent that works in the demo and loses its mind the first time the process dies.

Pick the engine that matches your workflow duration, payload size, cost model, and language. Wrap every side effect in a durable step, make every write idempotent, and offload large payloads before history saturates. Then your agent survives the crash that was always coming.