Una modificación de un planificador podría dejar este registro al hacer el traspaso:
Objetivo: dejar de recibir tareas nuevas y permitir que terminen las importaciones en curso.
Artefacto: parche central guardado; falta conectar la entrada de línea de comandos.
Conflicto: el parche actual cancela tareas en curso y las pruebas verifican ese comportamiento anterior.
Siguiente paso: corregir la semántica de pausa y continuar la integración.
Ejecutor: ninguno.
Aunque no haya un agente ejecutándose, el trabajo mantiene un estado explícito. Quien lo retoma puede descubrir, incluso antes de leer toda la conversación, el defecto principal: el núcleo contradice el objetivo; conectarlo ahora expondría al usuario el comportamiento incorrecto.
Es un ejemplo didáctico del diseño Work propuesto por Flowness en el commit público c9d6abe. Esa versión todavía clasifica la continuidad completa entre agentes como diseño; el ejemplo no es una ejecución completada. Diseño y estado de evidencia
La dirección debe conducir a los fundamentos
Work ofrece una entrada estable para consultar trabajo persistente. Pero un identificador permite encontrarlo, no garantiza que al abrirlo aparezcan hechos actuales.
Flowness diseña Work como una proyección de registros subyacentes. El código permanece en el repositorio, las pruebas apuntan a versiones concretas y los juicios y cambios quedan en eventos; la vista reúne esos hechos. Si cambia el parche, debe indicar qué versión probaron los tests, en lugar de mostrar simplemente «aprobado» en verde.
La vista también tiene posición temporal. as_of_seq indica hasta qué evento se ha agregado información. Si llega hasta el 147 y el responsable cambia la pausa en el 148, el sistema puede reconocer que falta la decisión nueva. Diseño de WorkView
Esto puede sostener mejor la siguiente acción que un resumen de traspaso. El resumen explica cómo se pensaba entonces; la vista actual también debe reconocer qué interpretaciones cambiaron después.
Al interrumpirse el ejecutor, primero se comprueba qué quedó: si realmente terminó la ejecución, si se confirmó el parche, qué archivos siguen en el espacio temporal y qué resultados se verificaron. La recuperación depende del estado real, no de la estimación del agente anterior de que «casi termina».
Después se prepara el contexto de la acción siguiente. Flowness lo llama Context Capsule: desde un corte factual explícito selecciona objetivo, versiones, restricciones vigentes, artefactos y problemas abiertos. En el ejemplo, resolver el conflicto de pausa va primero; proporcionar toda la conversación podría ocultar los materiales decisivos. Verificación del estado y compilación de contexto
El nuevo agente inicia su ejecución sobre el mismo Work. Tras comprobarlos, sus resultados fundamentan la consulta siguiente.
Si cambia la premisa, cambia la lectura de lo completado
La pausa pudo interpretarse inicialmente como «detener todas las tareas». Después el responsable confirmó que las importaciones en curso debían terminar. El cambio afecta a más que la descripción de la tarea.
Las pruebas antiguas pasaron, pero verificaban cancelación. Código central, aserciones y ayuda de comandos pueden depender de esa misma premisa. El formato de logs, si es ajeno a la pausa, quizá no necesite rehacerse.
Para distinguirlo hacen falta dos dependencias: el orden de ejecución entre tareas y la versión de interpretación sobre la que se construyó cada artefacto. La primera dice que la integración sigue a las pruebas; la segunda revela que las pruebas usan requisitos caducados.
Flowness llama Finding a una observación que cambia el trabajo posterior. Reflow localiza las premisas y dependencias afectadas y organiza la continuación. Aquí basta escribir: «El núcleo cancela importaciones en curso y contradice el requisito actual». El plan vuelve al comportamiento central, verifica que las tareas en curso terminan y después conecta el comando. Relación de diseño entre Finding y Reflow
Se conservan los artefactos; cambia lo que permiten afirmar. Las pruebas antiguas explican la historia, pero no respaldan que se cumplan los requisitos nuevos.
El ahorro de rehacer solo una parte depende de registrar bien las relaciones. Las ausentes exigen investigación; si el alcance es incierto, ampliar la validación puede ser más barato que clasificar con detalle. Hay que probar el diseño en modificaciones reales: cuántos caminos equivocados evita y cuánto trabajo de registro añade.
La ejecución persistente ya tiene herramientas maduras. Temporal restaura estados de flujo mediante el historial de eventos y recibe Signal, Update y otras entradas; LangGraph conserva estados del grafo y datos entre hilos mediante puntos de control y almacenamiento persistente. Flujos de Temporal, mensajería, persistencia de LangGraph
Work se centra en interpretar lo guardado: versión del objetivo, juicios sustituidos, artefactos afectados y materiales que necesita ahora el relevo. Puede construirse sobre motores existentes. Si incidencias, repositorio y flujo ya conservan esas relaciones, otra base paralela solo añade sincronización.
La dirección sigue siendo útil después de «terminar»
Corregir el núcleo no elimina todo el trabajo posterior. Flowness distingue cuatro estados, asociados a continuaciones diferentes:
| Estado | Significado en el ejemplo |
|---|---|
| Construido (built) | Existe un artefacto comprobable de la función de pausa. |
| Integrado (integrated) | La entrada de comandos y la ruta real de llamada están conectadas. |
| Activado en uso real (activated) | El uso natural del entorno de destino invoca efectivamente la capacidad. |
| Aceptado (accepted) | La persona responsable confirma que el resultado satisface la necesidad. |
La activación real excluye pruebas, demostraciones, ensayos y el mero despliegue. La aceptación también debe señalar qué versión del resultado se reconoce. Definiciones de activación y aceptación
La espera se vuelve concreta. La función puede estar integrada sin haber encontrado una necesidad real de pausa, o haberse usado sin aceptación todavía. No hace falta mantener un agente ejecutándose: basta conservar el evento esperado, la persona responsable y las condiciones de revisión.
Cuando se cumplen, se abre el mismo Work, se comprueba la versión y se inicia la siguiente acción. La especificación pública de demostración de traspaso prepara precisamente esa prueba: si otro ejecutor puede continuar tras una interrupción a partir del estado persistente, sin la memoria temporal del agente anterior. Especificación de la demostración
Para quien mantiene el sistema, esa dirección debe responder algo práctico: si vuelvo hoy al planificador, ¿dónde empiezo? Responderlo de forma continuada permite atravesar el final de conversaciones, los relevos y los cambios de requisitos.