How to Build Agents

Deployment & Scaling

Top 5 Durable Workflow Engines for Long-Running Agent Runs

A long-running agent run is more than a model call that takes a while. It may need to pause for approval, wait for an event, retry after a failure, or recover without repeating completed work.

The workflow engine you choose determines how that progress is recorded—and what runtime your team takes on.

This guide compares Temporal, Restate, Inngest, Trigger.dev, and Hatchet for those practical needs. I’d focus on three questions: how each handles recovery, whether its waits and run limits fit your tasks, and how much separate infrastructure or workflow-specific code you’re willing to adopt.

There’s no universal winner here. The right fit depends on whether your priority is very long execution, interactive signals, retriable steps, flexible task code, or checkpoint-based recovery.

Use the quick picks to narrow the field, then confirm the documented limits and operating model against your own deployment before committing.

Digital illustration of cyberpunk cats in neon-lit urban scenes, engaged in AI-agent tasks such as coding, debugging, or analyzing data streams. The style features glowing outlines, high contrast, and a vibrant acid-color palette. No brand logos, no invented software screenshots, no legible text.: Top 5 Durable Workflow Engines for Long-Running Agent Runs

Quick picks

Temporal is a strong candidate when runs must recover across failures and may last a long time; its trade-off is adopting a Temporal Service and worker processes, plus replay-aware workflow design.

Restate suits interactive workflows that use durable promises and signals, with journaled agent decisions available for recovery. Its service-registration and runtime model are part of the adoption decision.

Inngest fits runs composed of retriable steps and event- or time-based waits. Check its Cloud plan duration limits and step timeout against your workload and hosting environment.

Trigger.dev is worth a look for TypeScript tasks that need extended waits or external approval, with managed compute or self-hosting available. The cited documentation does not establish an overall maximum workflow lifetime or every plan’s waitpoint limits.

Hatchet offers checkpoint-based recovery, waits, and child-task composition. If self-hosting, account for operating its control plane and infrastructure dependencies.

Product shortlist

1. Temporal

Temporal: A calico cat kneels on a metallic safety mat, each paw resting on a small steel shelf holding three ink bottles, a brass compass, and a folded newspaper. The cat's whiskers cast faint cyan dust motes across the mat. It opens its mouth, revealing a tiny red pen clipped to its jawline, and carefully draws one black line across an open ledger with its tongue. The ledger pages show stepped vertical bars in different heights. The action is steady, deliberate, and anatomically plausible..Temporal
Temporal — AI editorial illustration, not a product photo or screenshot.

Temporal is a strong fit when an agent run must survive failures and may continue for a long time. I’d consider it for workflows that pause between steps, call external services, or need to resume without repeating completed work.

Its durable execution model is powerful, but it also asks you to adopt a separate workflow service and worker processes.

What I like

  • Workflow executions can run from seconds to years, which accommodates agent tasks with unpredictable pauses or long waits.
  • Temporal records workflow event history and replays it after a failure, helping the run recover its progress.
  • External operations such as API calls and LLM invocations can be placed in Activities, whose recorded results are reused during replay.

Limitations

  • You need a Temporal Service and worker processes; you can self-host the service or use Temporal Cloud.
  • Workflow code must make replay-consistent decisions, so developers need to understand which logic belongs in the workflow and which external effects belong in Activities.

My take

The main appeal is recovery across crashes and infrastructure problems without treating every restart as a new agent run. That can matter when repeating an LLM call or other external operation would be costly or produce a different result.

The trade-off is adopting Temporal’s runtime and designing workflow code around replay. I’d choose it when durable recovery is a core requirement and the team is comfortable operating or using a separate workflow service; for simpler tasks, that infrastructure and implementation model may be more than the run needs.

Best for

Teams building long-running agent workflows that need to recover across failures and preserve completed external work. It is less compelling if you want to avoid a separate workflow runtime or cannot accommodate replay-aware workflow design.

Sources: What is Temporal?; Temporal Workflow.

2. Restate

Restate: A fat tabia cat lies flat on a concrete rooftop at golden hour, one paw raised and scratching a niche in old brickwork. From the niche hangs a frayed leather lasso weighted at both ends by polished copper toggles. The cat tucks its chin toward the lasso and pulls gently, dragging it taut against a stone ledge. A faint shimmer of magenta light traces the line as the loop slides along the wall..Restate
Restate — AI editorial illustration, not a product photo or screenshot.

Restate is worth considering when an agent run needs to pause, receive signals, and recover without replaying every completed decision. I like that its workflow model is designed for interactive processes, while its journal can preserve agent routing decisions, calls, and results across a failure.

What I like

  • Durable promises, signals, and lifecycle management give you building blocks for multi-step agent runs that need to wait for input or continue later.
  • The documented recovery pattern resumes from the last journaled progress point, so completed routing decisions do not need to be repeated after a crash.
  • You can deploy agents as separate Restate services, which can suit systems where agent components need independent deployment.

Limitations

  • Restate adds a runtime and service-registration model to your architecture, even though the application services themselves can run on serverless, container, or dedicated-server infrastructure.
  • The documentation describes workflow-ID behavior, not exactly-once effects in arbitrary external systems; external side effects still need careful handling.

My take

The main appeal is the combination of workflow IDs, durable promises, and signals. That makes Restate a natural fit for agent tasks that wait on events or user input, and then continue through multiple steps.

Best for

Consider Restate if you want durable, interactive agent workflows and are comfortable adopting its runtime and registering services. It may be less suitable if you want to avoid adding a separate workflow layer.

Sources: Services; Multi-Agent Orchestration.

3. Inngest

Inngest: A calico cat perches on a marble altar-stone inside a foggy conservatory. Above it sits an ornate hourglass filled with glowing lime glass beads turning counterclockwise, held by iron brackets. Each bead has a small hole drilled through it, and a thin gold wire connects them in sequence to a wooden crank handle at the base. The cat grips the crank with its paw and slowly rotates it, lifting individual beads off the sand into tiny cups arranged in a circle beneath..Inngest
Inngest — AI editorial illustration, not a product photo or screenshot.

Inngest is a good fit for agent runs built from steps that may fail independently, pause for an event, or wait out a delay. It saves completed step results and resumes from the failed step after a retry or wait, so later failures need not mean repeating earlier work.

Its documentation also describes durable agents where the model selects the next step.

What I like

  • Saved step results help preserve completed work when a later step fails.
  • Event and time-based waits let a run pause without keeping compute busy.
  • The documented durable-agent pattern accommodates model-directed next steps.

Limitations

  • Inngest Cloud’s documented total run limit varies by plan: 30 days on Free, 90 on Pro, and 366 on Business; Enterprise limits are custom.
  • A step can run for up to two hours, but a shorter hosting-provider timeout may apply.

My take

I like Inngest for agent workflows with clear, independently retriable steps and pauses for events such as human approval. That model makes recovery easier to reason about than restarting an entire run.

Best for

Choose Inngest when your agent needs durable steps and event- or time-based waits, and its plan and hosting limits fit your run. Check the limits for long uninterrupted steps before choosing it.

Sources: Durable Execution; Usage Limits | Runs, Events & Retention.

4. Trigger.dev

Trigger.dev: An orange tabia cat sits upright on top of a thin reinforced steel beam spanning two concrete pillars. Its tail curls around its body like a seatbelt. It holds a spherical brass orifice–and–discharge mechanism between both paws: a hollow sphere on a pivoting arm with a small rubber stopper at one end and a plodon at the other. The cat tightens the arm, expelling a bright cyan stream through the sphere that arcs down to a receiving tray on the pillars below..Trigger.dev
Trigger.dev — AI editorial illustration, not a product photo or screenshot.

Trigger.dev is a strong fit when an agent run needs to outlive a request, wait for a person or external system, and then continue without making you express every operation as a workflow step. Its task-oriented model can use regular TypeScript, with checkpoint-resume snapshots for recovery.

I like the choice between Trigger.dev-managed compute and self-hosting, though teams should verify the applicable wait and lifetime limits before designing around extended pauses.

What I like

  • Tasks have no platform-imposed timeout stated, and you can set a maxDuration or disable it; wait time does not count toward that duration.
  • Waitpoints let a run pause for human approval, a third-party callback, or a user decision, then resume when the token is completed.
  • Managed compute avoids hosting task workers yourself, while self-hosting remains an option.

Limitations

  • The available documentation does not establish an overall maximum workflow lifetime or every plan's waitpoint limits, so confirm these details for your intended deployment.
  • Self-hosting is available, but choosing it means taking responsibility for the infrastructure that runs the tasks.

My take

I’d consider Trigger.dev for agent runs that need long waits or external approval, especially if you want to keep task logic in regular TypeScript rather than structure every operation as a step. Checkpoint-resume snapshots and waitpoints address different needs: recovery around task execution and resuming after an external event.

Best for

Best for teams building TypeScript agent tasks that may run beyond request limits or pause for approval and callbacks. It is also worth considering if you want managed compute but need the option to self-host.

Sources: Trigger.dev vs Inngest; Waitpoints.

5. Hatchet

Hatchet: A black-and-white tuxedocat rests its haunches on stacked wooden crestones forming a pyramid. In front of it, a weathered green folding rule snaps open in an L-shape; both of its arms display parallel scratched lines running in opposite directions like tick marks on a surveyor's table. The cat extends one front leg and taps the free end of one arm, then the other, adjusting the visual height of each scale until they align. Then the cat draws a thin chalk line along one ruled edge from left to right, resuming where the marks already ended..Hatchet
Hatchet — AI editorial illustration, not a product photo or screenshot.

Hatchet is worth considering when an agent run needs to pause, wait for an event, or recover after a worker failure. Its durable tasks record checkpoints in an event log, allowing a task to replay from its last completed checkpoint rather than repeat earlier completed steps.

I like that this model maps naturally to human-in-the-loop workflows and tasks composed dynamically at runtime, though it does mean adopting a distinct workflow control plane.

What I like

  • Checkpoint-based recovery can help a long-running task resume after a worker crash without rerunning steps that already reached a checkpoint.
  • Durable tasks can wait for events or timed sleeps, which is useful when an agent must pause for external input before continuing.
  • Child-task composition supports workflows that need to create and coordinate additional tasks as they run.

Limitations

  • Recovery depends on using Hatchet's documented durable-task operations correctly; the checkpoint model is not automatic for arbitrary code.
  • Self-hosting adds infrastructure to operate: the control plane includes an API server, orchestration engine, PostgreSQL database, and dashboard, with RabbitMQ optional.

My take

Hatchet's strongest fit is an agent workflow where pauses, human input, or worker failures are normal design cases. Its checkpoint and task-composition model offers a practical way to structure those runs, rather than treating them as one uninterrupted process.

The trade-off is runtime adoption. Teams choosing self-hosting must account for the separate control plane; Hatchet documents Lite for development, testing, or low-throughput production, and Docker Compose or Kubernetes Helm for production.

I would compare that operational commitment with the value of controlling the workflow infrastructure before choosing it.

Best for

Choose Hatchet if your agent workflows need checkpoint-based recovery, waits, or dynamically composed child tasks. It is a better fit for teams willing to adopt and, if self-hosting, operate a separate workflow control plane.

Sources: Durable Execution; Self-Hosting the Hatchet Control Plane.

How to choose

Choose based on how a run can fail or pause: identify whether it needs to wait for people or events, recover from worker crashes, or retry smaller steps. Then check how the engine records progress and what runtime or infrastructure your team must adopt.

Common Mistakes to Avoid

Don’t assume “long-running” means unlimited: check plan, step, and hosting limits. Also avoid treating workflow recovery as a guarantee that arbitrary external side effects happen exactly once.

Frequently Asked Questions

Can an agent wait without keeping a worker busy? Inngest documents event and time-based waits that do not hold compute while paused.

Final Verdict — Which One Would I Choose?

I’d favor the model that matches your failure and pause patterns, not a universal winner. Choose a runtime your team can operate, and verify its limits against your longest expected run.

Sources: What is Temporal?; Temporal Workflow; Services; Multi-Agent Orchestration; Durable Execution; Usage Limits | Runs, Events & Retention; Trigger.dev vs Inngest; Waitpoints; Durable Execution; Self-Hosting the Hatchet Control Plane.

Which option fits?

I’d choose by tracing one representative agent run from start to finish. Mark where it can wait, which completed steps must not be repeated, what happens after a worker or infrastructure failure, and whether external approval or callbacks are involved.

Then compare that flow with each engine’s recovery model and runtime requirements. Temporal is a fit when replay-based recovery and very long execution justify its separate service and worker model; Inngest is appealing when work breaks naturally into retriable steps and waits.

Consider Restate for interactive, journaled processes, Trigger.dev for TypeScript tasks with extended pauses, and Hatchet when checkpoint recovery and task composition match the workflow.

Before choosing, verify current plan and hosting limits—especially for the longest uninterrupted step and total run—and decide who will operate any separate runtime or control plane. I’d test the failure and resume paths with a representative task before building the full agent system around one engine.