# 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 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. 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. These are not optimizations. They are the baseline behavior. 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. Event-driven triggers are a first class concept. The local development story is good. Inngest has a local dev server that mirrors production behavior, so you can iterate on workflows without deploying. The dashboard shows you every run, every step, every input, every output. When something goes wrong, you can see exactly what happened and often just click to replay from a failed step. ### Where it falls short The hosted pricing can get expensive for high-volume workflows. 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 took a different path. It is open source, self-hostable from day one, and focuses on making background jobs and workflows accessible with a minimum of ceremony. ### What it does well The setup is the fastest of the three tools. The self-hosting story is first class. The dashboard is genuinely nice. The SDK handles common AI patterns well. ### Where it falls short The platform is younger than Inngest. The managed cloud pricing is competitive but still finding its positioning. ### 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. ### Where it falls short It only works on Vercel. It is newer than the alternatives. ### 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. ## 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. **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. Inngest is mature and event-driven. Trigger.dev is open source and fast to adopt. Vercel Workflow is native to Vercel and uses Fluid Compute to keep costs down on long-running AI workloads. All three are production-ready and solve the core problem of multi-step, long-running, stateful AI work. Pick a tool. Migrate your AI workflows. Get your weekends back.