¿Has notado que cuando le pides a Hermes algo de verdad complejo — «refactoriza este módulo y añade tests» — mantiene una lista de tareas (todo) en la sesión, marcando los elementos a medida que avanza, y sigue recordando dónde estaba incluso después de la compresión de contexto? Esa lista tenía un techo duro: era plana. Cada tarea se sentaba en una sola columna, y el orden significaba prioridad. Expresar «primero haz A, y dentro de A hay pasos 1, 2, 3» exigía prosa torpe, era más difícil de leer para el agente y más difícil de escanear para ti. El PR #97921 (fusionado el 29 de agosto) elimina ese techo: los elementos del todo ya pueden anidarse — las subtareas cuelgan de un padre mediante un campo parent opcional, y todas las superficies renderizan el árbol con sangría.

Qué es la herramienta todo

Primero, el contexto. todo es una herramienta integrada de Hermes: el agente la usa automáticamente para construir una lista de seguimiento en tareas complejas (los docs oficiales de la tool sugieren 3+ pasos) o cuando le das varias cosas a la vez. Su diseño es deliberadamente contenido:

• Una única tool todo — pasa un parámetro todos para escribir; omítelo para leer la lista actual;
• Cada llamada devuelve la lista completa actual, así el agente siempre sabe dónde está;
• Solo cuatro estados: pending, in_progress, completed, cancelled;
• Tras la compresión de contexto, la lista se reinyecta con un encabezado estable («Your active task list was preserved across context compression»), de modo que las tareas largas no pierden memoria.

El agente mantiene la lista por sí solo — no necesitas recordar ningún comando. Solo pídele «haz un plan primero» o «desglosa esto en una lista de tareas» en tu prompt y él se encarga del resto.

Cómo se ven las subtareas

El cambio es una sola cosa: cada elemento del todo gana un campo parent opcional que apunta al id de otro elemento.

1. Refactor parser module         (id: t1)
   ├─ Split parse_line function   (id: t2, parent: t1)
   └─ Add unit tests              (id: t3, parent: t1)
2. Update docs                    (id: t4)

El efecto: todas las superficies — el texto de la CLI, el panel de tareas de la app de escritorio, el adaptador ACP — renderizan los subárboles con sangría. La referencia oficial de la tool lo dice sin rodeos: el campo parent opcional de un elemento apunta al id de otro elemento, convirtiéndolo en subtarea, y las superficies renderizan el árbol indentado.

La implementación también se defiende de que el agente se enrede:

• Las autorreferencias se descartan — un parent que se apunta a sí mismo se ignora;
• Las referencias colgantes y cíclicas se sanean — un parent que no existe, o un bucle A→B→A, se limpia después de escribir;
• Un padre completado sigue visible mientras haya algún descendiente activo — tras la reinyección post-compresión, un padre cuyos hijos siguen en curso no se oculta;
• El reordenamiento se salta las listas anidadas — mover una posición plana arrancaría una subtarea de sus hermanas, así que el árbol permanece intacto;
• El adaptador ACP sangra hasta un máximo de 4 niveles — para que el árbol nunca se vuelva ilegible.

El control de costes también merece la pena destacarlo: toda la función añade una propiedad de string y una frase de comportamiento al schema de la tool en caché — unos 45 tokens. Sin tool nueva, sin parámetros nuevos aparte de parent, sin cambios en el system prompt.

Cómo usarlo: basta con lenguaje natural

Nunca tocas JSON — todo es la herramienta del agente, y solo necesitas expresar la intención de «quiero capas»:

"Break this release down into a task list: code freeze first, then tests, build, and packaging as subtasks under it"

El agente hace el resto y produce una lista anidada con enlaces parent; puedes preguntar «¿dónde estamos?» en cualquier momento y él lee la lista para decírtelo. Para estructuras que corren naturalmente en paralelo — como una «fase de investigación» con «comparar la opción A» y «comparar la opción B» colgando debajo — el anidamiento se lee mucho más claro que una lista plana.

Cuándo resulta más útil

• Tareas por etapas: releases, migraciones, refactors — naturalmente jerárquicas («fase grande → pasos pequeños»), y el anidamiento hace visible el progreso de un vistazo.
• Sesiones largas: tras la compresión, el árbol se reinyecta intacto, así el agente nunca confunde subtareas con padres.
• Múltiples superficies: el panel de tareas de la app de escritorio renderiza un árbol de verdad, y los mensajes del gateway muestran también la estructura con sangría.

Este cambio aterrizó el 29 de agosto (PR #97921) y hoy solo está en main — ningún release tag lo incluye todavía (v0.20.6 se etiquetó el 27 de agosto). Para probarlo ahora, hermes update al código más reciente.

Resumen

Pasar de una lista plana a un árbol de tareas anidable es un solo campo pequeño, pero mejora de verdad la experiencia de las tareas largas: la estructura está bien, el seguimiento del progreso por parte del agente y tu lectura se vuelven más fáciles — todo por 45 tokens. La próxima vez que le des algo complejo a Hermes, dile «desglosa la tarea en una lista con subtareas» y observa la diferencia.

Para más mecánicas de tareas largas (límites de turnos, presupuestos de ejecución, interrumpir sin detener), consulta nuestra guía de turnos ilimitados y la guía de optimización de tokens de contexto.