Agentes Durables en 2026: Que Tu Agente de IA Sobreviva a Timeouts, Deploys y Humanos Lentos

1. El Problema: Un Agente Es un Proceso, Serverless Te Da un Request

Un runtime pensado para requests asume que el trabajo termina rápido. En Vercel con Fluid compute una función dura 300 segundos por defecto; Pro y Enterprise pueden subirla a 800 segundos, y un máximo extendido de 1.800 segundos sigue en beta. El trabajo de un agente ignora esos números: las llamadas al modelo fallan y piden reintentos, las herramientas son lentas y una aprobación humana puede tardar días. Y mientras el run espera, vas a deployar código nuevo.

La ejecución durable saca el ’dónde estoy’ de la memoria del proceso y lo mete en un log persistido. Seguís escribiendo una función async común, pero cada paso completado queda registrado; si el proceso muere, el run se reconstruye desde el log y sigue donde se había detenido. Las docs de Vercel dicen que sus runs sobreviven a deploys y crashes mediante replays determinísticos, la misma idea que Temporal e Inngest implementan a su manera.

2. Conceptos Mínimos Antes de Tocar Código

Seis ideas cubren todo el modelo. Los nombres cambian según el producto, la forma no.

3. Vercel Workflow vs Temporal vs Inngest: Qué Cambia de Verdad

Los tres te dan replay, reintentos, timers y esperas externas. Se diferencian en dónde corre tu código, qué tan estricto es el modelo de programación y cómo pagás. Los datos de abajo salen de las docs de cada proveedor al 2026-10-14; los límites y precios se mueven, así que revisalos de nuevo antes de presupuestar.

La misma espera de aprobación en tres dialectos

// 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: Un Agente con Aprobación Humana en Vercel Workflow

Elegí Vercel Workflow para el ejemplo porque su quickstart de Next.js es el más corto de los tres, corre en local sin servicios extra y un sitio Next.js en Vercel ya aloja los steps. Versiones verificadas en npm el 2026-10-14: workflow 5.2.2 (línea estable desde 5.0.0, el 2026-09-30), ai 7.0.140 y zod 4.6.7. El agente propone un reembolso con un LLM, espera a un humano y recién ahí llama a la herramienta de pagos, una sola vez.

Paso 1 — Instalá y envolvé la config de Next.js

Instalá los paquetes y envolvé tu config con withWorkflow. Es el único cambio de configuración obligatorio; las directivas hacen el resto.

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);

Paso 2 — El paso con LLM, el paso de herramienta, el hook y el workflow

Cinco piezas en un archivo. proposeRefund llama al modelo y devuelve un objeto tipado. requestReview le avisa al revisor. approvalHook es la espera tipada. issueRefund es el único paso que mueve plata, así que lleva una clave de idempotencia. refundAgent solo orquesta. El string del modelo pasa por Vercel AI Gateway, así que configurá sus credenciales (o pasá una instancia de proveedor) antes de la primera corrida.

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 };
}

Fijate en el orden: el hook se crea antes de avisar al revisor, así un sí rápido no llega cuando nadie escucha; y la espera compite contra un timer de dos días, así el silencio tiene un desenlace definido. El tope de 50.000 centavos vive en el código del workflow a propósito: el modelo propone, el código determinístico dispone.

Paso 3 — Iniciá el run y reanudalo desde route handlers

start() encola el run y vuelve enseguida. La ruta approve reanuda el hook por su token. Los tokens no son credenciales: el schema de Zod valida el payload, no a quien lo manda, así que autenticá al caller antes de llamar a resume().

TypeScript — dos 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 });
}

Paso 4 — Corrélo en local y leé la línea de tiempo

En local el SDK usa su Local World sin configuración. Iniciá un run, abrí el inspector y después aprobá. En Vercel los mismos runs aparecen en el dashboard, en Observability y luego Workflows. Una trampa de deploy que mencionan las docs: ’Enable access to System Environment Variables’ tiene que estar activo, o el deployment cae al Local World y falla por el filesystem de solo lectura.

Terminal — correr, inspeccionar, aprobar

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. Errores Comunes (el Código Durable Necesita Que Se Los Digan)

La ejecución durable te saca los timeouts de encima y agrega una clase nueva de bug: código que es correcto la primera vez e incorrecto la segunda. Estos cinco son los que rodean las docs de todos los proveedores.

Conclusión

Los agentes largos fallan por razones aburridas: un límite de tiempo, un reinicio, un reintento que repite un pago. La ejecución durable responde a las tres con un solo truco, registrar cada paso y hacer replay para reanudar, y los tres productos de acá lo empaquetan distinto: directivas en Vercel, un workflow determinístico más workers en Temporal, steps memoizados sobre HTTP en Inngest.

Elegí un flujo de agente que hoy cuidás con un cron y una columna de estado. Mové la llamada al modelo y el efecto secundario a steps, dale al que mueve plata una clave de idempotencia, reemplazá el polling por un hook o signal y competilo contra un timer. Esa migración debería borrar más código pegamento del que agrega, y es la base de cada agente con humano en el loop que construyas después.

Fuentes

• Vercel — Resumen de Workflows (event log, replay, Fluid compute, Queues)
• Vercel — Precios y límites de Workflow (events, datos escritos, límites de payload y run)
• Vercel — Límites de Functions (duración máxima con Fluid compute)
• Workflow SDK — Primeros pasos con Next.js (withWorkflow, start, inspector local)
• Workflow SDK — Errores y reintentos (retries, FatalError, RetryableError)
• Workflow SDK — Hooks (defineHook, resume, timeouts con sleep)
• Workflow SDK — Idempotencia (stepId como clave de idempotencia)
• Temporal — Signals en el SDK de TypeScript (defineSignal, setHandler, condition)
• Temporal — Retry policies (defaults de las activities)
• Temporal — Límites de tamaño de payload y mensaje gRPC
• Temporal Cloud — Precios (Actions, almacenamiento, planes)
• Inngest — Límites de uso (salida de steps, estado del run, duración del run)
• Inngest — Precios (ejecuciones y planes)
• Inngest — step.waitForEvent