El problema
Una sesión de depuración de hace dos horas investigó un fallo en la aplicación y concluyó erróneamente que la causa residía en el módulo de autenticación. A la mañana siguiente, un desarrollador retoma esa sesión utilizando --resume para continuar el trabajo — y el agente adopta esa conclusión incorrecta como verdad absoluta porque ningún elemento del estado fue marcado como obsoleto. Toda la mañana se desperdicia desandando una premisa que debió ser descartada horas atrás.
Reanudar una sesión no es una acción neutra. Recupera todo el contexto acumulado, incluyendo observaciones de herramientas que perdieron vigencia y conclusiones que ya fueron refutadas. La decisión arquitectónica es: cuándo el historial acumulado sigue aportando valor y cuándo se convierte en peso muerto que debe sustituirse por un resumen estructurado explícito.
El concepto central
--resume <nombre-de-sesion> restaura una sesión previa con todo su historial intacto. Esto es ideal cuando el contexto acumulado sigue siendo plenamente válido — la sesión fue pausada, no invalidada, y reanudarla ahorra el trabajo de reconstruir lo establecido. Sin embargo, cuando alguna observación intermedia queda obsoleta (stale) — un archivo cambió, una hipótesis se refutó, una decisión se revirtió —, recargar ese historial reintroduce el error. En tales casos, la decisión correcta es iniciar una nueva sesión con un resumen estructurado explícito: un registro conciso de hechos confirmados, premisas descartadas con sus motivos y tareas pendientes. Esto ahorra tokens y, sobre todo, purga supuestos obsoletos.
fork_session aborda un reto arquitectónico distinto: explorar alternativas sin contaminar la línea principal de razonamiento. Si deben evaluarse dos enfoques competitivos — optimizar una consulta actual versus reescribir la capa de acceso a datos —, bifurcar la sesión permite que cada rama se ejecute en aislamiento sin que las conjeturas de una afecten a la otra. Sin bifurcación, la sesión principal se satura de callejones sin salida de ambos experimentos.
El tercer componente es cómo los errores estructurados y los resultados parciales atraviesan las fronteras entre sesiones o entre un coordinador y sus subagentes. Un subagente que falla a mitad de una tarea jamás debe terminar en silencio — debe devolver un payload estructurado de error (qué se intentó, dónde ocurrió el fallo y qué se confirmó hasta ese momento) para que el proceso receptor no repita la investigación a ciegas. Un resultado parcial aporta información procesable: "se confirmaron X e Y, pero no se alcanzó Z porque la herramienta W dio timeout". Un subagente que solo devuelve éxito o fallo binario obliga a rehacer todo el diagnóstico desde cero.
El antipatrón a evitar es tratar --resume como el estándar universal por mera comodidad. La comodidad no es un criterio arquitectónico — la validez del contexto sí lo es. Una sesión de hace dos semanas suele contener más peso muerto que señal útil; un resumen estructurado de treinta líneas sirve mucho mejor a la siguiente iteración que reanudar ciegamente un estado obsoleto.
Ponlo en práctica
En el laboratorio de esta lección implementarás un motor de ciclo de vida de sesiones en Python: a partir de la antigüedad de la sesión y banderas de invalidación, decidirá si reanudar una sesión existente o iniciar una nueva con resumen estructurado, complementado con un esquema de propagación de errores parciales entre subagentes.