Qué aporta durable-harness
La idea central del paquete es separar la lógica del agente de la memoria de la sesión. En lugar de confiar en un proceso vivo en memoria, `durable-harness` guarda un registro persistente de los pasos de cada turno: primero anota la intención de una llamada, luego su resultado cuando termina y, con esa información, reconstruye el estado si el proceso cae. Vercel lo presenta como una forma de mantener sesiones de Pi, OpenCode, Claude Code y Codex vivas a través de caídas, *timeouts* y *redeploys*.
Ese enfoque importa porque los *harnesses* de código suelen diseñarse como procesos locales de larga duración. Cuando se mueven a la nube, el problema no es solo ejecutar el modelo, sino conservar con precisión qué se ejecutó, qué quedó a medias y qué no llegó a arrancar. La propuesta de Vercel intenta cubrir precisamente ese hueco con un registro duradero que sirve de fuente de verdad para retomar la sesión.
Cómo funciona la reanudación
Según la documentación asociada, cada turno del agente se apoya en una cola y en un log persistente. Si la función muere a mitad de una tarea, la cola reasigna el turno a una nueva función, que lee el historial y continúa desde el último estado conocido. Ese diseño permite distinguir entre llamadas completadas, llamadas que estaban en curso y llamadas que nunca llegaron a ejecutarse.
Vercel indica además que las llamadas ya terminadas no deben repetirse, de modo que los tokens consumidos no se vuelven a cobrar. Para ciertas herramientas con efectos secundarios, el paquete contempla modos distintos de repetición: unas pueden volver a ejecutarse sin riesgo, mientras que otras no deberían lanzarse dos veces, como ocurre con una devolución o una acción irreversible. El modelo recibe entonces la advertencia de que esa llamada pudo haberse producido, aunque el sistema no la repita.
Dónde puede ejecutarse
El paquete no obliga a usar una única infraestructura. Vercel describe varios destinos: su propia plataforma, un entorno local y una configuración autogestionada con Postgres. En ese último caso, el material disponible menciona Node.js 22 o superior y una versión de Postgres a partir de 5.0.4 para el *World* correspondiente. También indica que el cambio de entorno se gestiona mediante variables como `WORKFLOW_TARGET_WORLD` y `WORKFLOW_POSTGRES_URL`.
En la práctica, eso significa que el mismo agente puede moverse entre despliegue en Vercel, ejecución local o una instalación propia sin reescribir su lógica central, siempre que se ajuste al entorno de durabilidad elegido. La compañía lo vende como una forma de separar el cómputo de la persistencia, un planteamiento que encaja con la tendencia a mover agentes a infraestructuras más controladas y auditables.
Qué queda confirmado y qué no
Lo confirmado, de momento, es que `durable-harness` existe, es abierto, usa una capa de registro persistente y está orientado a retomar sesiones de agentes de programación tras interrupciones. También está documentado que Vercel lo presenta como compatible con varios *harnesses* y con distintos entornos de ejecución.
Lo que no aparece en la información disponible son pruebas comparativas independientes, métricas de latencia o rendimiento y una evaluación externa de cuánta fiabilidad real añade frente a otras arquitecturas de ejecución duradera. Tampoco hay, en lo aportado, una validación independiente de que todas las promesas de reanudación funcionen igual de bien en los distintos agentes citados. La propia publicación lo sitúa además en una versión 0.0.x, es decir, todavía experimental.
Para equipos que trabajan con agentes de código, la novedad práctica no está en el modelo de lenguaje, sino en la capa que evita perder trabajo cuando algo falla. Si el enfoque de Vercel se consolida, la conversación dejará de girar solo en torno a qué modelo escribe mejor y pasará también por quién conserva mejor el estado de una sesión larga, un detalle que decide si un agente puede usarse de forma fiable en producción.
