Vercel Workflow SDK comprime el estado de agentes con zstd: hasta 85% menos payload
Workflow SDK 5 beta empezó a comprimir con zstd los inputs y outputs persistidos de runs, hooks y steps. Para agentes durables, el cambio puede bajar almacenamiento y lecturas sin código nuevo, pero no elimina el problema de diseñar estados pequeños e idempotentes.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
Vercel anunció el 22 de junio de 2026 un cambio silencioso pero importante para los agentes que guardan estado durante horas: Workflow SDK 5 beta ahora comprime con zstd los inputs y outputs de runs, hooks y steps antes de persistirlos. La compresión se activa automáticamente cuando ayuda; los payloads pequeños permanecen sin comprimir.
El ejemplo de Vercel baja un workflow de 52 MB a 10 MB y describe ahorros de hasta 85% en JSON típico de conversaciones de IA. No es una promesa de que cada agente reducirá exactamente esa proporción, pero sí señala dónde se acumula un costo que a menudo nadie mide: historial, resultados de herramientas y estado intermedio que el runtime necesita guardar para reanudar una ejecución.
Por qué importa en un agente durable
Un workflow corto puede vivir en memoria y terminar antes de que alguien note el tamaño de sus datos. Un agente de investigación, soporte o coding suele ser distinto: espera una aprobación, duerme entre pasos, sobrevive a un deploy, reanuda después de un error y conserva suficiente contexto para continuar.
Cada una de esas capacidades necesita estado persistido. Si guardas el resultado completo de una búsqueda, el contenido de cada archivo, respuestas repetidas de una API y la conversación entera en cada paso, el volumen crece aunque el agente no esté haciendo trabajo útil. El almacenamiento, las lecturas y la serialización pasan a formar parte de la latencia de la tarea.
La compresión automática ataca ese costo sin obligarte a cambiar el código. También beneficia el caso que Vercel menciona de eve, su framework de agentes: el historial y el estado de las sesiones durables pueden ocupar menos espacio y moverse más rápido sin una migración de datos explícita.
Lo que sí cambia y lo que no
El cambio es de persistencia, no de arquitectura. zstd puede hacer más barato guardar un payload grande, pero no vuelve buena idea guardar todo. El agente seguirá pagando por:
- el tiempo de producir un resultado innecesario;
- el ancho de banda de llevar datos hasta el siguiente step;
- los tokens si el estado vuelve al contexto del modelo;
- la lógica de reintento cuando un efecto externo ya ocurrió.
En otras palabras: compresión ayuda al runtime; resumir y recortar estado ayuda al agente.
Mi primera revisión sería separar tres categorías. La entrada necesaria para reanudar debe permanecer. La evidencia que solo sirve para auditoría puede ir a almacenamiento externo con una referencia. El texto repetido o derivado debe recalcularse, resumirse o eliminarse. Esa división reduce dependencia del formato interno y hace más fácil cambiar de proveedor en el futuro.
Checklist para medir el beneficio real
Antes de actualizar workflow a una versión beta, registra durante un día típico:
- tamaño de inputs y outputs por step;
- porcentaje de payload que es historial repetido;
- tiempo de escritura y lectura del estado;
- costo de almacenamiento por sesión;
- cantidad de reintentos y reanudaciones;
- tamaño del contexto que finalmente recibe cada llamada al modelo.
Después compara una muestra equivalente con compresión. El indicador principal no debería ser solo megabytes almacenados. Mira p95 de reanudación, costo por sesión completa y si el agente conserva exactamente la información necesaria después de un reinicio.
Hay dos errores comunes. El primero es confundir compresión con cifrado: zstd reduce tamaño, pero no reemplaza controles de acceso, separación de tenants ni gestión de secretos. El segundo es activar la beta en producción sin revisar compatibilidad de serialización, versionado e idempotencia. Un step que envía un correo o modifica una base de datos debe poder repetirse de forma segura, con o sin compresión.
No hay SEO tooling conectado en esta corrida, así que no invento volumen. La demanda se infiere de las búsquedas probables Workflow SDK compression, zstd durable agents, Vercel workflow state y del problema recurrente de almacenar conversaciones largas y resultados de tools.
Si estás construyendo tu primer flujo con tools, reintentos y aprobación humana, el curso gratis cubre las bases que la compresión no puede resolver por ti. La lectura práctica de este cambio es: guarda menos, persiste mejor y mide la reanudación, no solo el tamaño del archivo.