Vous lancez trois jobs d’un coup : l’un exécute la suite de tests, l’autre tire des dépendances, le troisième génère des assets en arrière-plan. Vous partez en réunion. À votre retour, l’écran n’est qu’un mur de « job finished » — et chacun a déclenché son propre tour de modèle, alors que tout ce que vous vouliez, c’était « ils ont tous fini, continue ».

Le problème n’a jamais été les notifications elles-mêmes ; c’était que chaque notification comptait comme le début d’une conversation distincte. Un changement récent resserre cela : les tâches de fond déjà prêtes sont désormais fusionnées en un seul tour de notification sur les surfaces interactives.

Le nouveau comportement : les tâches terminées déjà prêtes forment un seul tour

La règle est courte. Les surfaces de conversation fusionnent les fins de processus de fond consécutives, déjà prêtes pour une conversation, en un unique tour de notification. Les échecs restent dans le lot aux côtés des sorties réussies — les mauvaises nouvelles ne sont pas mises de côté. Et une tâche isolée conserve son texte d’origine plutôt que d’être enveloppée dans une enveloppe de lot.

Une précision, car la méprise est facile : il ne s’agit pas d’un regroupement différé. Le système ne retient pas un processus terminé tôt pour permettre à d’autres de le rejoindre. Il combine uniquement ce qui est déjà prêt à cet instant, et il ne promet explicitement pas de combiner des jobs qui se terminent à des moments différents. Vous ne verrez donc pas un test terminé depuis longtemps rester sur une notification au lieu de réveiller l’agent.

Ce qui n’est pas fusionné

Le regroupement couvre les événements de fin de processus en arrière-plan. Deux choses en sont délibérément exclues :

• Les résultats de watch (abonnements aux changements de sortie) et les résultats de délégation asynchrone restent des notifications séparées, livrées dans leur ordre d’origine.
• Le gateway de messagerie — le bot qui vous répond sur Telegram, Slack et compagnie — garde son propre regroupement à fenêtre courte, indexé par route. Ce changement ne remplace pas ce mécanisme et ne modifie pas les envois des adaptateurs.

L’usage scripté n’est pas affecté non plus : les consommateurs non interactifs comme une requête API, un client ACP ou un appel CLI ponctuel ne gagnent aucune nouvelle boucle de notification autonome.

Les processus consommés ne notifient plus

C’est la partie la plus pratique du changement, et la plus facile à manquer.

L’identité du processus reste disponible jusqu’à la distribution. Donc si vous avez déjà pris explicitement le résultat d’un processus de fond — en lisant son log via process_manage, en attendant qu’il se termine, ou en le tuant — le CLI n’ajoutera pas d’avis de fin par la suite, même si ce processus a quitté le registre et se trouve dans la file d’entrée. Un lot entièrement consommé ne démarre aucun tour.

Autrement dit : aller regarder le résultat vous-même revient à dire à Hermes « je suis déjà au courant pour celui-là ».

Qui s’occupe de quoi

Le même comportement vit dans différents modules selon la surface. Connaître l’organisation fait gagner du temps quand quelque chose semble anormal :

Surface	Module	Ce qu’il fait
CLI classique	hermes_cli/cli_process_notifications.py	Prend en charge le drain en idle et après tour, la propriété sensible à la compression et le déballage final de l’entrée
TUI et Desktop	tui_gateway/session_notifications.py	Regroupe l’instantané prêt du poller après vérification de la propriété ; chaque processus émet toujours son propre statut UI ; les sessions occupées remettent en file des événements structurés plutôt que des chaînes de lot rendues
TUI après tour	tui_gateway/prompt_turn.py	Même chemin de routage et de rendu ; les clients de chat du desktop et du dashboard partagent ce backend

Le moteur de rendu partagé est ProcessNotificationBatch dans tools/process_registry_notifications.py. Deux contraintes de conception méritent d’être retenues :

1. Ni le lot ni son statut de livraison ne sont persistés dans le system prompt. Le bruit n’entre jamais dans le contexte du modèle — ce qui est exactement la moitié de l’histoire qui économise des tokens.
2. Les événements adressés ont besoin d’un propriétaire prouvable. Une autre session active ne peut pas les adopter. La livraison des délégations continue via son propre registre durable claim/complete : une fois par délégation plutôt qu’une fois par lot de processus.

Vérifier par vous-même

Il existe une sonde dans le dépôt que vous pouvez exécuter localement :

python3 evals/completion_backlog_probe.py /path/to/repo /tmp/out.json

Elle démarre de vrais enfants shell dans des répertoires temporaires, lit leurs vrais événements de fin et pilote le CLI de production, le poller de la TUI et les routes de notification après tour (un puits de tour HTTP en loopback tient lieu de soumission réelle d’un prompt). Elle enregistre de vraies distributions mais n’exerce pas l’inférence du modèle.

Attention à ce qu’elle mesure : l’admission des tours à la frontière des notifications, pas les économies de tokens. Les deux sont liés mais distincts — moins de lots signifie moins de tours et un contexte plus court, mais la sonde ne calculera pas les caractères que vous avez économisés.

La version courte

L’intérêt ici n’est pas une fonctionnalité clinquante ; c’est du bruit qui atterrit sous une forme prévisible. Les tâches déjà prêtes forment un seul tour, les échecs restent, les résultats consommés ne reviennent pas, les watch et les subagents gardent leur propre ordre, et les lots n’atteignent jamais le system prompt. Si vous lancez habituellement plusieurs jobs de fond d’affilée, la différence après la mise à jour est simple : un seul résumé vous attend, et vous poursuivez.

Le travail de fond commence généralement par des jobs planifiés — voir la référence hermes cron. Si le planificateur lui-même se comporte mal, cron doctor est la lecture la plus proche. Et pour comprendre comment les subagents sont contrôlés et livrés en temps réel, voir l’orchestration live des subagents.