Avez-vous remarqué que lorsque vous demandez à Hermes quelque chose de vraiment complexe — « refactoriser ce module et ajouter des tests » — il tient une liste de tâches dans la session, en cochant les éléments au fur et à mesure, et se souvient encore où il en était même après une compression de contexte ? Cette liste avait un plafond dur : elle était plate. Chaque tâche était alignée dans une seule colonne, et l’ordre valait priorité. Exprimer « d’abord fais A, puis dans A il y a les étapes 1, 2, 3 » demandait une prose maladroite, était plus difficile à lire pour l’agent, et plus difficile à parcourir pour vous. La PR #97921 (fusionnée le 29 août) supprime ce plafond : les éléments todo peuvent désormais s’imbriquer — les sous-tâches se rattachent à un parent via un champ parent optionnel, et chaque surface rend l’arborescence avec indentation.

Ce qu’est l’outil todo

D’abord, le contexte. todo est un outil intégré de Hermes : l’agent l’utilise automatiquement pour construire une liste de suivi pour les tâches complexes (la doc officielle des outils suggère 3 étapes ou plus) ou lorsque vous lui confiez plusieurs choses à la fois. Sa conception est volontairement sobre :

• Un seul outil todo — passez un paramètre todos pour écrire, omettez-le pour lire la liste courante ;
• Chaque appel renvoie la liste complète à jour, pour que l’agent sache toujours où il en est ;
• Quatre statuts seulement : pending, in_progress, completed, cancelled ;
• Après une compression de contexte, la liste est réinjectée avec un en-tête stable (« Votre liste de tâches active a été préservée à travers la compression de contexte »), pour que les longues tâches ne perdent pas la mémoire.

L’agent gère la liste lui-même — vous n’avez aucune commande à retenir. Demandez-lui simplement de « faire un plan d’abord » ou de « décomposer ceci en liste de tâches » dans votre prompt, et il prend le relais.

À quoi ressemblent les sous-tâches

Le changement tient en une chose : chaque élément todo gagne un champ parent optionnel pointant vers l’id d’un autre élément.

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)

L’effet : chaque surface — le texte de la CLI, le panneau de tâches de l’app de bureau, l’adaptateur ACP — rend les sous-arborescences avec indentation. La référence officielle de l’outil le dit simplement : le champ parent optionnel d’un élément pointe vers l’id d’un autre élément, ce qui en fait une sous-tâche, et les surfaces rendent l’arbre en indentation.

L’implémentation protège aussi contre l’agent qui s’emmêle les pinceaux :

• Les auto-références sont ignorées — un parent qui pointe vers lui-même est écarté ;
• Les références pendantes et cycliques sont assainies — un parent qui n’existe pas, ou une boucle A→B→A, est nettoyé après écriture ;
• Un parent terminé reste visible tant qu’un descendant est actif — après la réinjection suivant la compression, un parent dont les enfants sont encore en cours n’est pas masqué ;
• La réorganisation saute les listes imbriquées — déplacer une position plate déchirerait une sous-tâche d’avec ses sœurs, l’arbre reste donc intact ;
• L’adaptateur ACP indente jusqu’à 4 niveaux maximum — pour que l’arbre ne devienne jamais illisible.

Le contrôle des coûts mérite aussi d’être signalé : toute la fonctionnalité ajoute une propriété de chaîne et une phrase de comportement au schéma d’outil mis en cache — environ 45 tokens. Pas de nouvel outil, pas de nouveaux paramètres en dehors de parent, pas de modification du prompt système.

Comment l’utiliser : le langage naturel suffit

Vous ne touchez jamais au JSON — todo est l’outil de l’agent, et vous n’avez qu’à exprimer l’intention « je veux des niveaux » :

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

L’agent fait le reste et produit une liste imbriquée avec des liens parent ; vous pouvez demander « où en sommes-nous ? » à tout moment et il lit la liste pour vous le dire. Pour les structures qui tournent naturellement en parallèle — comme une « phase de recherche » avec « comparer l’option A » et « comparer l’option B » suspendues dessous — l’imbrication se lit bien plus clairement qu’une liste plate.

Quand c’est le plus utile

• Tâches en plusieurs étapes : releases, migrations, refactorisations — naturellement hiérarchiques (« grande phase → petites étapes »), et l’imbrication rend la progression visible d’un coup d’œil.
• Longues sessions : après la compression, l’arbre se réinjecte intact, l’agent ne confond donc jamais sous-tâches et parents.
• Surfaces multiples : le panneau de tâches de l’app de bureau rend un véritable arbre, et les messages gateway montrent aussi la structure indentée.

Ce changement a atterri le 29 août (PR #97921) et est pour l’instant sur main uniquement — aucune étiquette de release ne le contient encore (v0.20.6 a été taguée le 27 août). Pour l’essayer maintenant, hermes update vers le code le plus récent.

Résumé

Passer d’une liste plate à un arbre de tâches imbriquable, c’est un petit champ, mais cela améliore réellement l’expérience des longues tâches : la structure est juste, le suivi de progression de l’agent et votre propre lecture en sortent tous deux facilités — le tout pour 45 tokens. La prochaine fois que vous confiez quelque chose de complexe à Hermes, dites-lui de « décomposer la tâche en une liste avec des sous-tâches » et observez la différence.

Pour d’autres mécanismes de longues tâches (limites de tours, budgets d’exécution, interruption sans arrêt), voir notre guide des tours illimités et notre guide d’optimisation des tokens de contexte.