Long-running AI agent workflows fail differently than simple background jobs: LLM calls are slow and expensive, outputs are non-deterministic, side effects like sending emails or charging cards can't be safely repeated, and some steps wait on humans for days. Durable execution solves this by checkpointing completed steps so failures resume from the last successful point rather than restarting entirely. Inngest is used as a case study, contrasted with BullMQ (queue-first, more operational control) and Temporal (workflow-first, more complex). Key building blocks covered include checkpointing via step.run(), waiting via step.sleep() and step.waitForEvent(), retry policies, idempotency for side effects, flow control (concurrency, throttling, rate limiting, debouncing, priority), and observability through tracing and replay. Developers still must handle idempotent side effects, step boundary design, retry policies, and cross-system data consistency themselves.
Table of contents
What Is an AI AgentWhy AI Agents Need Durable ExecutionWhy Traditional Job Queues Are NOT EnoughWhat Durable Execution Actually MeansHow to Build Durable Execution YourselfWhat Inngest IsBullMQ vs Temporal vs InngestUnder the Hood: How Inngest Executes a FunctionHow Inngest Handles FailuresOther Pieces That Matter in ProductionWhat You Still Have to HandlePutting It All Together: A Durable Research AgentClosing ThoughtsQuestions this post answers
How does Inngest avoid re-running completed steps when an AI agent workflow fails partway through?
Inngest uses step.run() to wrap each unit of work and persist its result once it completes. On a rerun, the SDK hashes each step's ID, checks for a saved result, and returns it instead of re-executing the code, so only steps without a saved result actually run again after a failure. Developers designing recoverable agent pipelines can weigh durable execution tradeoffs alongside broader backend content on daily.dev.
What is the difference between a retry and a checkpoint in a durable workflow system?
A retry reruns a failed task from scratch, while a checkpoint remembers which tasks already completed successfully. With only retries, a research agent that fails during drafting would repeat its earlier retrieval and extraction steps too; with checkpointing, those completed steps are reused and only the failed step runs again, saving time and LLM token costs. Teams comparing retry-only queues against checkpointed workflow engines can track these architecture patterns on daily.dev.
How do BullMQ, Temporal, and Inngest differ for building durable AI agent workflows?
BullMQ is queue-first, giving fine-grained control over workers, retries, and rate limiting but requiring a team to build checkpointing and resumability manually. Temporal is workflow-first, well suited to very complex interdependent workflow graphs but with more operational complexity. Inngest is application-code-first, adding durable execution around existing code via step.run() with less low-level control than BullMQ. Engineers deciding between BullMQ, Temporal, and Inngest can follow ongoing comparisons of workflow tools on daily.dev.
1.1K Impressions1 Comment