Workflow SDK ya corre nativo en Nitro v3: menos fricción para agentes durables en apps Nuxt
Vercel anunció el 13 de junio de 2026 que Workflow SDK tiene integración beta nativa con Nitro v3. Para builders, el detalle útil es que los steps corren dentro del runtime de la app y pueden usar APIs server-side como useStorage.
Por Marco Lee · Reportar un error
Vercel anunció el 13 de junio de 2026 que Workflow SDK ya corre de forma nativa en Nitro v3 en beta. A primera vista parece una nota de framework, pero para builders de agentes hay una señal más interesante: las tareas durables empiezan a vivir más cerca del runtime real de la aplicación, no como un paquete separado que obliga a duplicar contexto.
El cambio concreto es que los steps corren dentro del mismo bundle de Nitro y pueden usar APIs del lado servidor como useStorage() dentro de funciones marcadas con "use step".

Qué cambia frente a un worker separado
Un agente práctico rara vez es una sola llamada al modelo. Necesita esperar, reintentar, persistir estado, consultar tools, recibir eventos externos y continuar sin depender de que una request HTTP siga viva. Por eso Vercel ha empujado Workflow SDK como capa de ejecución durable.
La integración con Nitro baja una fricción concreta para equipos Nuxt/Nitro:
- no separa tanto el código de app y el código de workflow;
- permite usar primitivas server-side del runtime;
- expone UI de inspección y debug en desarrollo;
- y evita tratar cada step como un microservicio lateral.
Eso puede importar mucho si estás construyendo un agente que sincroniza datos, prepara reportes, procesa webhooks o coordina llamadas a modelos con pasos humanos intermedios.
La pregunta correcta no es "¿uso Vercel?"
La pregunta mejor es: ¿mi agente necesita sobrevivir a pausas, retries y eventos externos sin inventar mi propio scheduler?
Si la respuesta es no, una función normal basta. Si la respuesta es sí, empiezan a aparecer requisitos menos glamorosos: idempotencia, observabilidad, estado persistente, límites de tiempo, errores repetibles y forma de inspeccionar qué paso falló.
Workflow SDK intenta ordenar esa zona. Nitro v3 lo vuelve más natural para equipos que ya viven en ese ecosistema.

Dónde lo probaría primero
Lo probaría en workflows estrechos, no en "agente general":
- ingestión de leads o tickets con enriquecimiento por modelo;
- generación de resúmenes programados con revisión humana;
- sincronización de CRM, docs o base de conocimiento;
- evaluación batch de prompts o tools;
- procesamiento de webhooks que pueden llegar fuera de orden.
El riesgo es convertir cualquier tarea simple en arquitectura durable. Eso agrega coste mental. Si no necesitas pausa, retry o estado entre pasos, probablemente estás metiendo más plataforma de la necesaria.
Lecturas relacionadas
Sigue explorando Deploy y otras piezas para builders.

Workers Cache llega a Cloudflare: menos CPU para agentes, si separas bien respuestas cacheables

AWS quiere sacar los coding agents de tu laptop: AgentCore Runtime pone cada sesión en una microVM

vercel deploy --dry da a los agentes un preflight real antes de subir código
