Vincent saca el estado de las tareas de agentes fuera de la pestaña del terminal

El proyecto Vincent propone mover la propiedad de las tareas de agentes desde la pestaña del terminal hasta un demonio en segundo plano. La TUI, la CLI y la API pasan a ser clientes de ese estado: cerrar cualquiera de ellos no altera nada de lo que hay detrás. La idea de fondo es sencilla y algo incómoda: el terminal es un buen sitio para arrancar un proceso y un mal sitio para guardar la verdad sobre ese proceso.

La pestaña como plano de control accidental

Cuando una tarea de agente vive dentro de una pestaña, esa pestaña acaba haciendo de plano de control sin que nadie lo haya decidido. Cerrarla puede detener el trabajo. Perder el scrollback borra la explicación útil de lo que pasó. Y volver al proyecto obliga a reconstruir qué se ejecutó, qué rama se tocó y si aquello estaba esperando, había terminado o llevaba un rato atascado en silencio. Cuanto más larga es la tarea, más frágil se vuelve ese arreglo.

Vincent traslada el estado al demonio: estado de tareas, ejecución de flujos, procesos de agentes, planificación, base de datos y worktrees de git. Varios clientes pueden inspeccionar el mismo demonio sin convertirse en escritores que compiten entre sí, y el planificador admite tareas por prioridad y límites de concurrencia aunque no haya ningún panel abierto mirando.

Qué pasa cuando algo se interrumpe

La durabilidad es la parte que cambia cómo se trata una caída. Vincent persiste una transición de estado antes de actuar sobre ella. Si el demonio se detiene a mitad de un paso, la recuperación al reiniciar registra el intento interrumpido, verifica cualquier proceso huérfano antes de pararlo y vuelve a ejecutar el paso sin consumir un reintento por fallo. El sistema no finge que un proceso sobrevive a un reinicio de la máquina: hace explícita la interrupción y se recupera desde un estado conocido.

Instalar el demonio como servicio de usuario extiende el mismo modelo entre sesiones. Es el sistema operativo el que arranca el plano de control, y el terminal vuelve a ser lo que debería ser: una ventana opcional sobre el trabajo.

Conviene precisar qué hay publicado hasta ahora. El material que acompaña al proyecto es un documento de diseño, con la explicación arquitectónica y poco más: no hay versión numerada, ni licencia anunciada, ni referencias a un repositorio, ni cifras de rendimiento medidas por un tercero. Tampoco se enseña una demo del demonio en funcionamiento, así que lo que se puede evaluar hoy es el planteamiento, no el software.

Aun así, el planteamiento toca un problema real para quien ya tiene agentes en producción. La codificación con agentes se parece cada vez menos a una conversación y cada vez más a una carga de trabajo: tareas que esperan cuotas, puertas de validación, reintentos, ramas hijas y comprobaciones externas. Atar la vida de esas tareas a la vida de la interfaz que las lanzó es una decisión de arquitectura, y no precisamente buena. El terminal puede mostrar el trabajo. Otra cosa es que deba ser su dueño.