Ejecución durable: agentes que sobreviven a que se caiga el servidor

Construir un sitio web para un cliente no es una operación de treinta segundos. Hay que investigar el negocio, redactar, generar imágenes, esperar aprobaciones, comprar un dominio, configurar DNS, publicar. Entre medio, el cliente se toma un fin de semana para contestar. El proceso completo puede durar días.

La primera versión de eso la escribimos como se escribe todo la primera vez: un proceso en memoria con un montón de estados. Funcionaba hasta que hacíamos un deploy. Entonces el proceso moría y con él el estado de todos los proyectos en curso.

El patrón que faltaba

Lo que necesitábamos tiene nombre propio: ejecución durable. Es una clase de motor que registra cada paso en un diario, de modo que el flujo puede retomar exactamente donde quedó, sin importar qué se cayó en el medio.

La idea central es que el estado del flujo deja de vivir en la memoria del proceso y pasa a ser un hecho persistido. Un flujo puede quedarse esperando una respuesta humana durante días o meses sin consumir nada, y cuando la respuesta llega, sigue. No hace falta escribir máquinas de estado a mano, ni tablas de "en qué paso está cada proyecto", ni tareas programadas que salen a revisar si algo cambió.

Migramos a esto y desapareció una categoría entera de bugs. No los arreglamos: dejaron de existir, porque el problema que los causaba ya no estaba.

Cómo lo usamos

Cada tipo de proyecto tiene su playbook: una secuencia de fases con sus tareas. Landing, sitio institucional, tienda online, campaña de Google, campaña de Meta. El motor es el mismo; lo que cambia es la definición.

Cada tarea del playbook puede resolverse de tres maneras, y esa flexibilidad resultó ser lo más valioso del diseño:

• La ejecuta un agente, cuando es una tarea acotada y verificable.
• La ejecuta una persona, cuando pide criterio o trato con el cliente.
• Queda en espera, cuando depende de algo externo: que el cliente apruebe, que se propague un DNS, que se acredite un pago.

Un mismo proyecto puede pasar de piloto automático a manos humanas y volver, sin que el flujo se entere. Eso es exactamente lo que permite vender un servicio por suscripción sin que la operación dependa de que alguien esté mirando.

Lo que no resuelve

Conviene ser honesto con los límites, porque el entusiasmo con estas herramientas es alto. La ejecución durable te garantiza que el flujo no se pierde. No te garantiza que el flujo esté bien.

Si tu playbook tiene una fase mal pensada, ahora vas a tener esa fase mal pensada, ejecutándose de forma perfectamente confiable, para siempre. El motor amplifica lo que le des: hace que lo bueno escale y que lo malo también.

Por eso el trabajo real no estuvo en la infraestructura, que es sólida y está resuelta hace rato. Estuvo en discutir, tarea por tarea, qué tiene que pasar para dar cada una por terminada. Esa discusión no la puede tener el motor, ni el agente. Esa la tenés que tener vos.