# Durable AI Workflows in 2026: Why Your Next AI Feature Needs Orchestration I shipped an AI feature last fall that took an input document, called a large language model to extract structured data, called a second model to validate it, posted the results to a webhook, and then emailed the user. The whole thing took between 40 seconds and 3 minutes depending on the document size. It worked perfectly in testing. It worked for the first hundred users in production. Then a network hiccup took out the LLM provider for 90 seconds during a busy afternoon, and I discovered the hard way that I had built a very expensive way to lose data. My serverless function timed out. The retry was another full run from scratch, which hit the LLM a second time for tokens I had already paid for. Users saw errors. Some of them got two emails. A few of them got neither because the second run failed at a different step and the retry count hit zero. I spent the next weekend rewriting the whole thing on top of a durable workflow engine. The problem was not that I had bad code. The problem was that I was using request-response infrastructure to run a multi-step, long-running, stateful process. That is not what serverless functions are for, and pretending it is leads to exactly the kind of failure I walked into. This post is the guide I wish I had before I shipped that feature. It covers what durable workflows are, why AI features need them more than almost any other category of work, and how to choose between Inngest, Trigger.dev, and Vercel Workflow in 2026. ## What Breaks When AI Meets Serverless The default pattern for shipping a feature in 2026 looks something like: a Next.js or similar framework, an API route that handles a request, some business logic, maybe a database call, and a response. This pattern is fast, cheap, and covers 90 percent of what most web apps do. It also breaks in predictable ways when AI gets involved. **Timeouts.** LLM calls are slow. A single Claude or GPT call is typically a few seconds. A chain of them can take minutes. Vercel raised the default function timeout to 300 seconds in 2025, which helps, but a multi-step agent can easily exceed that. If your function times out mid-run, you lose the work in progress and any external side effects you already triggered. **Retries.** When an LLM provider has an outage or rate limits you, you need to retry. Naive retries cause duplicate emails, duplicate database writes, and duplicate bills. Smart retries require keeping track of which steps have already succeeded so you can resume from where you left off instead of starting over. **Cost.** Every retry on an LLM call costs real money. A workflow that reruns from scratch on every failure can 2x or 3x your AI costs during a bad day with a provider. For features where each run is cheap this is tolerable. For agentic workflows that use 50,000 tokens per run, it is a budget problem. **Observability.** When a multi-step AI workflow fails, you need to know which step failed, with what input, and with what output from the previous steps. Tracing this in a standard logging setup is painful. You end up grepping logs across multiple function invocations, trying to correlate request IDs that may not even exist on retries. **Concurrency.** If a user kicks off ten AI workflows at once, you want to throttle them so you do not blow up your rate limits with your LLM provider. Standard serverless functions have no built-in way to do this without building your own queue. These are not edge cases. They are the default failure modes for any AI feature that does more than a single one-shot completion. ## What Durable Workflows Actually Are The term “durable workflow” sounds like enterprise jargon, but the idea is simple. A durable workflow is a function where each step is checkpointed. When a step succeeds, the result is persisted. If the workflow fails partway through, the engine resumes from the last successful step instead of starting over. The function can take minutes, hours, or days to complete. It can pause to wait for external events. It can sleep for a week and then resume. All of this is handled by the engine, not by you. The programming model looks almost identical to normal async code. You write a function with steps. Each step is a regular async operation. The engine wraps each step to persist its result and provide the persisted result on replay if the step has already run. The magic is that failures become survivable. A network blip in step 3 of a 5 step workflow does not lose the work from steps 1 and 2. A provider outage does not double bill you. A deploy in the middle of a running workflow does not drop it on the floor. This is the model Temporal popularized in the enterprise. What changed in 2026 is that the pattern finally got accessible to indie developers and small teams, with tools that work natively with Next.js, serverless functions, and modern TypeScript stacks. ## Inngest: The Mature Choice Inngest has been in the durable workflow space longer than most of the current competitors. It is a hosted service with a TypeScript SDK that defines workflows as functions with steps, using a familiar async pattern. ### What it does well The developer experience is polished. Defining a workflow looks like writing a regular async function with a few wrapper calls. You call `step.run` for operations that should be checkpointed, `step.sleep` for delays, and `step.waitForEvent` for waiting on external triggers. Event-driven triggers are a first class concept. Instead of calling a workflow directly, you emit an event, and Inngest decides which workflows should run based on event matching rules. The local development story is good. Inngest has a local dev server that mirrors production behavior, so you can iterate on workflows without deploying. Concurrency and rate limiting are built in. You can limit a workflow to process at most 5 runs concurrently per user, or throttle invocations to 10 per second per integration. ### Where it falls short The hosted pricing can get expensive for high-volume workflows. Inngest charges based on step executions and concurrency. Self-hosting is possible but more involved than the managed service suggests. ### When to pick it Inngest is the right choice if you are building an event-driven system, care about first class concurrency controls, and want a polished managed service. ## Trigger.dev: The Open Source Friendly Pick Trigger.dev is open source, self-hostable, and focuses on making background jobs and workflows accessible with a minimum of ceremony. Version 3 added durable execution and significantly improved the developer experience. ### What it does well The setup is fast. You install the SDK, define a task with a simple decorator pattern, and it is ready to run. The self-hosting story is first class. The open source version of Trigger.dev runs as a Docker container and has feature parity with the managed cloud product. The dashboard is genuinely nice. You get a live view of running tasks, a history of past runs, the ability to replay from any step, and the tooling for debugging failed runs is polished. The SDK handles common AI patterns well. There is built in support for streaming responses, long running inference calls, and checkpointing expensive LLM outputs. ### Where it falls short The platform is younger than Inngest. Some advanced features are either newer or still in development. The managed cloud pricing is competitive. ### When to pick it Trigger.dev is the right choice if you value open source, want the fastest possible setup, need to self host, or want a tool that was designed with AI workloads in mind from the start. ## Vercel Workflow: The Native Vercel Pick Vercel Workflow is Vercel’s answer to the durable workflow problem. It runs on Fluid Compute, integrates with the rest of the Vercel platform, and requires no separate infrastructure if you are already deploying on Vercel. ### What it does well The integration with the Vercel platform is seamless. The programming model is clean. Cost efficiency is genuinely different. The observability tie-in is strong. Workflow runs show up in the Vercel dashboard alongside your deployments, logs, and other platform metrics. ### Where it falls short It only works on Vercel. It is newer than the alternatives and the ecosystem of patterns, examples, and integrations is smaller. ### When to pick it Vercel Workflow is the right choice if you are already on Vercel and want the tightest possible integration with your existing stack. ## The Decision Framework After running all three on real projects for the last few months, here is the framework I use to decide which one to reach for. **Are you on Vercel and shipping Next.js?** Start with Vercel Workflow. **Do you need to self host?** Trigger.dev is the pick. **Is your workflow fundamentally event-driven?** Inngest is the pick. **Are you optimizing for the fastest possible setup?** Trigger.dev is the pick. **Do you care about long term track record and maturity?** Inngest is the pick. For most of my current projects, I end up running Vercel Workflow for the AI features that live inside a Vercel-hosted app, and Trigger.dev for anything that needs to run off platform or where I want to control my own infrastructure. ## Practical Patterns for AI Workflows A few patterns I have learned the hard way that apply regardless of which tool you pick. **Checkpoint LLM calls aggressively.** Every LLM call should be its own checkpointed step. **Store the raw LLM output, not just the parsed version.** When an LLM call succeeds but the parsing fails, you want to be able to fix the parser and replay without rerunning the LLM. **Use the workflow engine’s native rate limiting.** Do not build your own throttling layer on top of a workflow engine. **Design steps for idempotency.** Even with durable workflows, steps can retry. **Keep step inputs small.** Every step’s inputs get persisted. Pass references to stored data rather than the data itself when possible. **Log the prompts and the responses.** For debugging AI workflows, the prompt-response pair is the source of truth. ## The Honest Bottom Line If you are shipping an AI feature that does more than a single one-shot completion, you need a durable workflow engine. The wrong answer is to keep running AI workflows on plain serverless functions and hope that your users never hit a provider outage. I ended up migrating the feature that ate my weekend to a durable workflow in a single afternoon.