Durable Agents in 2026: Keep Your AI Agent Alive Through Timeouts, Deploys and Slow Humans

1. The Problem: An Agent Is a Process, Serverless Gives You a Request

A request-shaped runtime assumes work finishes quickly. On Vercel with Fluid compute a function defaults to 300 seconds; Pro and Enterprise can raise it to 800 seconds, and a 1,800-second extended maximum is still in beta. Agent work ignores those numbers: model calls fail and need retries, tools are slow, and a human approval can take days. And while the run waits, you will deploy new code.

Durable execution moves ’where am I’ out of process memory and into a persisted log. You still write an ordinary async function, but every completed step is recorded; if the process dies, the run is rebuilt from the log and continues where it stopped. Vercel’s docs say its runs survive deployments and crashes through deterministic replays, the same idea Temporal and Inngest implement in their own ways.

2. Minimum Concepts Before Touching Code

Six ideas cover the whole model. The names change per product, the shape does not.

3. Vercel Workflow vs Temporal vs Inngest: What Actually Differs

All three give you replay, retries, timers and external waits. They differ in where your code runs, how strict the programming model is and how you pay. The facts below come from each vendor’s docs on 2026-10-14; limits and prices move, so re-check them before you budget.

The same approval wait in three dialects

// Vercel Workflow - hook + timer race
const hook = approvalHook.create({ token: "refund:" + orderId });
const approval = hook.then((p) => p);
const decision = await Promise.race([approval, sleep("2 days").then(() => "timeout" as const)]);
// resume: await approvalHook.resume("refund:" + orderId, { approved: true });

// Temporal - signal + condition with timeout
export const approve = defineSignal<[{ approved: boolean }]>("approve");
let decision: { approved: boolean } | undefined;
setHandler(approve, (d) => { decision = d; });
const arrived = await condition(() => decision !== undefined, "2 days"); // false on timeout
// client: await handle.signal(approve, { approved: true });

// Inngest - wait for an event
const review = await step.waitForEvent("wait-for-approval", {
  event: "refund/approved",
  timeout: "2d",
  match: "data.orderId",
}); // null when the timeout expires

4. Tutorial: An Approval-Gated Agent on Vercel Workflow

I picked Vercel Workflow for the worked example because its Next.js quickstart is the shortest of the three, it runs locally with no extra service, and a Next.js site on Vercel already hosts the steps. Versions checked on npm on 2026-10-14: workflow 5.2.2 (stable line since 5.0.0 on 2026-09-30), ai 7.0.140 and zod 4.6.7. The agent proposes a refund with an LLM, waits for a human, then calls a payment tool exactly once.

Step 1 — Install and wrap the Next.js config

Install the packages and wrap your config with withWorkflow. That is the one required config change; the directives do the rest.

Terminal + next.config.ts

npm i workflow ai zod

// next.config.ts
import type { NextConfig } from "next";
import { withWorkflow } from "workflow/next";

const nextConfig: NextConfig = {};

export default withWorkflow(nextConfig);

Step 2 — The LLM step, the tool step, the hook and the workflow

Five pieces in one file. proposeRefund calls the model and returns a typed object. requestReview pings the reviewer. approvalHook is the typed wait. issueRefund is the only step that moves money, so it carries an idempotency key. refundAgent only orchestrates. The model string routes through Vercel AI Gateway, so configure its credentials (or pass a provider instance) before the first run.

TypeScript — workflows/refund-agent.ts

// workflows/refund-agent.ts
import { defineHook, sleep, getStepMetadata, FatalError } from "workflow";
import { generateText, Output } from "ai";
import { z } from "zod";

type Ticket = { orderId: string; message: string };
type Plan = { amountCents: number; reason: string };

// The human decision, validated before the run resumes
export const approvalHook = defineHook({
  schema: z.object({ approved: z.boolean(), comment: z.string().optional() }),
});

// LLM step: proposes, never executes
async function proposeRefund(ticket: Ticket): Promise<Plan> {
  "use step";
  const { output } = await generateText({
    model: "anthropic/claude-sonnet-5.5", // any AI Gateway "provider/model" string
    instructions: "You triage refund requests. Propose a refund amount in cents.",
    prompt: ticket.message,
    output: Output.object({
      schema: z.object({ amountCents: z.number(), reason: z.string() }),
    }),
  });
  return output;
}

// Notification step: a retry may ping twice - fine for a ping, not for money
async function requestReview(ticket: Ticket, plan: Plan) {
  "use step";
  await fetch(process.env.REVIEW_WEBHOOK_URL!, { // the secret stays inside the step
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({
      text: "Refund " + plan.amountCents + " cents for order " + ticket.orderId + ": " + plan.reason,
    }),
  });
}

// Tool step: the only place money moves
async function issueRefund(orderId: string, amountCents: number) {
  "use step";
  const { stepId } = getStepMetadata();
  const res = await fetch("https://payments.example.com/v1/refunds", { // placeholder provider
    method: "POST",
    headers: {
      authorization: "Bearer " + process.env.PAYMENTS_API_KEY,
      "content-type": "application/json",
      "idempotency-key": "refund:" + stepId, // stable across retries of this step
    },
    body: JSON.stringify({ orderId, amountCents }),
  });
  if (res.status === 429 || res.status >= 500) throw new Error("Payments API " + res.status); // retried
  if (!res.ok) throw new FatalError("Refund rejected: " + res.status); // not retried
  return (await res.json()) as { refundId: string };
}

// The workflow: deterministic orchestration only
export async function refundAgent(ticket: Ticket) {
  "use workflow";

  const plan = await proposeRefund(ticket);
  if (plan.amountCents > 50_000) return { status: "needs-manager", plan };

  const hook = approvalHook.create({ token: "refund:" + ticket.orderId }); // BEFORE notifying
  await requestReview(ticket, plan);

  const approval = hook.then((payload) => payload);
  const decision = await Promise.race([
    approval,
    sleep("2 days").then(() => "timeout" as const),
  ]);

  if (decision === "timeout" || !decision.approved) {
    return { status: "closed", plan, decision };
  }

  const receipt = await issueRefund(ticket.orderId, plan.amountCents);
  return { status: "refunded", receipt };
}

Notice the order: the hook is created before the reviewer is notified, so a fast yes cannot arrive before anyone is listening; and the wait is raced against a two-day timer, so silence has a defined outcome. The 50,000-cent guard lives in workflow code on purpose: the model proposes, deterministic code disposes.

Step 3 — Start the run and resume it from route handlers

start() enqueues the run and returns immediately. The approve route resumes the hook by its token. Tokens are not credentials: the Zod schema validates the payload, not the sender, so authenticate the caller before calling resume().

TypeScript — two route handlers

// app/api/refund/route.ts - start a run
import { start } from "workflow/api";
import { refundAgent } from "@/workflows/refund-agent";

export async function POST(req: Request) {
  const ticket = await req.json();
  const run = await start(refundAgent, [ticket]);
  return Response.json({ runId: run.runId });
}

// app/api/refund/approve/route.ts - resume it
import { approvalHook } from "@/workflows/refund-agent";
import { getReviewer } from "@/lib/auth"; // your own auth, not part of the SDK

export async function POST(req: Request) {
  const reviewer = await getReviewer(req);
  if (!reviewer?.canApproveRefunds) return new Response("Forbidden", { status: 403 });

  const { orderId, approved, comment } = await req.json();
  await approvalHook.resume("refund:" + orderId, { approved, comment });
  return Response.json({ ok: true });
}

Step 4 — Run it locally and read the timeline

Locally the SDK uses its Local World with zero configuration. Start a run, open the inspector, then approve. On Vercel the same runs appear in the dashboard under Observability, then Workflows. One deployment gotcha from the docs: ’Enable access to System Environment Variables’ must be on, or the deployment falls back to the Local World and fails on the read-only filesystem.

Terminal — run, inspect, approve

npm run dev

# start a run
curl -X POST --json '{"orderId":"A-1042","message":"Charged twice, please refund the duplicate."}' http://localhost:3000/api/refund

# watch it: web UI or terminal
npx workflow web
npx workflow inspect runs

# the reviewer says yes (your auth must let this through)
curl -X POST --json '{"orderId":"A-1042","approved":true}' http://localhost:3000/api/refund/approve

5. Common Mistakes (Durable Code Needs Them Spelled Out)

Durable execution removes timeouts from your life and adds a new class of bug: code that is correct the first time and wrong the second. These five are the ones every vendor’s docs circle around.

Conclusion

Long-running agents fail for boring reasons: a time limit, a restart, a retry that repeats a payment. Durable execution answers all three with one trick, record every step and replay to resume, and the three products here package it differently: directives on Vercel, a deterministic workflow plus workers on Temporal, memoized steps over HTTP on Inngest.

Pick one agent flow you currently babysit with a cron job and a status column. Move the model call and the side effect into steps, give the money-moving one an idempotency key, replace the polling with a hook or signal and race it against a timer. That migration should delete more glue code than it adds, and it is the foundation for every human-in-the-loop agent you build next.

Sources

• Vercel — Workflows overview (event log, replay, Fluid compute, Queues)
• Vercel — Workflow pricing and limits (events, data written, payload and run limits)
• Vercel — Functions limits (max duration with Fluid compute)
• Workflow SDK — Next.js getting started (withWorkflow, start, local inspector)
• Workflow SDK — Errors & retrying (retries, FatalError, RetryableError)
• Workflow SDK — Hooks (defineHook, resume, timeouts with sleep)
• Workflow SDK — Idempotency (stepId as idempotency key)
• Temporal — Signals in the TypeScript SDK (defineSignal, setHandler, condition)
• Temporal — Retry policies (activity defaults)
• Temporal — Payload and gRPC message size limits
• Temporal Cloud — Pricing (Actions, storage, plans)
• Inngest — Usage limits (step output, run state, run length)
• Inngest — Pricing (executions and plans)
• Inngest — step.waitForEvent