Vercel anunció la integración con la OpenAI Agents API: ahora podés desplegar agentes de larga duración donde OpenAI administra el loop y el estado de sesión, mientras Vercel hostea la aplicación y conecta cada sesión a Vercel Sandbox para ejecución de código y acceso a archivos. La reconexión al Sandbox va por webhooks firmados de OpenAI y Vercel Queues, y la arquitectura es scale-to-zero, sin worker prendido todo el tiempo. La documentación de la Agents API llegó el mismo día al tope de Hacker News, así que el interés no es marginal.
Por qué importa
La señal no es "salió otra API de agentes". La señal es qué pieza dejó de ser tuya. Durante el último año y medio, cualquiera que armó un agente en serio escribió tres cosas a mano: el loop de razonamiento y llamada a herramientas, la persistencia del estado entre turnos, y un worker vivo esperando que el modelo termine de pensar. Esa tercera pieza es la que rompe el modelo serverless: un agente que tarda ocho minutos no entra en una función efímera.
Lo que hace esta integración es partir la responsabilidad por la mitad. OpenAI se queda con el loop y el estado. Vercel se queda con el hosting y el entorno de ejecución aislado. Y el pegamento entre ambos —el pedazo que todos veníamos improvisando con colas caseras y polling— pasa a ser infraestructura provista: webhooks firmados más Queues.
Escribir ese pegamento bien es más difícil de lo que parece. Reconectar una sesión a su sandbox después de que la función murió, garantizar que el webhook no se procese dos veces, mantener el workspace con los archivos que el agente generó en el turno anterior: es trabajo de sistemas distribuidos disfrazado de feature de producto. Que te lo den resuelto cambia el cálculo de si el agente vale la pena.
Qué cambia en la práctica
El cambio concreto es la desaparición del worker siempre encendido. Comparemos las dos formas de sostener un agente de larga duración:
| Aspecto | Worker propio | Agents API + Sandbox |
|---|---|---|
| Loop del agente | Tuyo, lo escribís y lo mantenés | Gestionado por OpenAI |
| Estado de sesión | Base o cache propia | Gestionado por OpenAI |
| Proceso en reposo | Siempre prendido | Scale-to-zero |
| Ejecución de código | Contenedor que administrás | Sandbox aislado por sesión |
| Archivos entre turnos | Volumen o storage propio | Workspace persistente |
| Portabilidad | Alta | Atada a ambos proveedores |
El flujo queda así:
┌──────────┐ instrucción ┌───────────────┐
│ App en │ ──────────────► │ Agents API │
│ Vercel │ │ loop + estado │
└────┬─────┘ └───────┬───────┘
│ │ webhook
│ │ firmado
│ ┌──────────────┐ │
└───────►│Vercel Queues │◄──────┘
└──────┬───────┘
│ crea / reconecta
▼
┌─────────────────┐
│ Vercel Sandbox │
│ workspace │
│ persistente │
└─────────────────┘Para quien trabaja con esto todos los días, lo que se simplifica es el código de infraestructura, no el de producto. Seguís definiendo tus herramientas, seguís decidiendo qué puede tocar el agente, seguís escribiendo el prompt. Lo que ya no escribís es el reintento de reconexión al sandbox ni la máquina de estados de la sesión.
El costo también se mueve de lugar. Un worker encendido se paga por tiempo, exista o no tráfico. Scale-to-zero se paga por uso. Para un producto con carga irregular —que es casi todo agente de uso interno— eso es una diferencia real. Pero ojo: el material de Vercel no publica precios ni benchmarks de latencia de arranque, así que la comparación económica concreta hay que medirla en tu caso, no asumirla.
Cuándo NO usarlo
Primero lo obvio y lo más caro: esto te acopla a dos proveedores simultáneamente para una sola funcionalidad. No es solamente OpenAI: es OpenAI para el loop más Vercel para el runtime, con webhooks firmados entre ambos como contrato. Migrar de modelo deja de ser cambiar un cliente HTTP y pasa a ser rediseñar la arquitectura de sesiones. Si tu producto necesita poder cambiar de proveedor de modelo —por precio, por regulación, por un cliente que exige otro vendor— este camino te lo encarece mucho.
Segundo: si el estado de sesión de tu agente contiene datos sensibles, ahora vive en infraestructura de OpenAI. Eso es una decisión de compliance, no de arquitectura, y la toma tu equipo legal antes que vos. No hay detalle en el anuncio sobre retención ni residencia de ese estado, así que si tu dominio es salud, finanzas o sector público, esa es la primera pregunta que tenés que hacer, no la última.
Tercero: si tu "agente" en realidad es una cadena de dos o tres llamadas determinísticas, no necesitás nada de esto. Un endpoint con lógica explícita es más barato, más rápido de depurar y más fácil de testear que un loop que decide por su cuenta. La tentación de llamar agente a un workflow es fuerte porque el término vende; resistila. El loop gestionado tiene sentido cuando el número de pasos es genuinamente impredecible.
Cuarto, y esto vale para todo el ecosistema: hay una asimetría entre lo que se anuncia y lo que se puede auditar. El mismo ciclo de noticias trajo el reporte de OpenAI sobre Navier-Stokes, donde la cobertura menciona números enormes de agentes en paralelo y el proceso quedó en discusión pública. No es un argumento contra la Agents API —son cosas distintas—, pero sí un recordatorio de que la capa de orquestación que no controlás es también la capa que no podés inspeccionar cuando algo sale mal. Depurar un loop ajeno es más difícil que depurar el tuyo.
Y algo menor pero práctico: el sandbox aislado por sesión con workspace persistente es cómodo hasta que necesitás que dos sesiones compartan estado, o que un proceso externo lea esos archivos. Ahí el aislamiento que te vendieron como feature se convierte en la pared con la que chocás.
Qué haría yo hoy
Lo probaría en algo interno y desechable: un agente que corra tareas de mantenimiento sobre un repo, o que procese archivos que ya son nuestros. Ahí el acoplamiento no duele porque el costo de tirar todo y empezar de nuevo es bajo, y aprendés cómo se comporta la reconexión de sesiones bajo carga real.
Para producción con clientes, esperaría. No porque la integración esté mal hecha —el diseño con webhooks firmados y Queues es sensato—, sino porque todavía no hay datos públicos de costo, latencia de arranque ni comportamiento bajo falla. Y también porque el mismo día se anunció GPT-Live-1 para voz full-duplex: el ritmo de cambio de esta superficie de API es tan alto que atar arquitectura hoy es apostar a que el contrato no se mueva mañana.
Mi regla sigue siendo la misma: adoptá infraestructura gestionada cuando el problema que resuelve ya te lastimó de verdad. Si nunca escribiste el reintento de reconexión de un sandbox, no sabés todavía cuánto vale que te lo den hecho.