A2A et après : les agents préparent leur propre réseau local

A2A permet déjà à deux Hermes sur des machines différentes de se « téléphoner ». Et maintenant ? Dans la liste de souhaits de la communauté se cache un plan bien plus ambitieux.

Ce qu’on sait déjà faire : retour sur « le téléphone »

A2A v1.0 est sorti. En résumé, il permet à des Hermes sur des machines différentes d’échanger leurs cartes de visite (Agent Card), de communiquer avec un langage standardisé (JSON-RPC), de suivre l’avancement en temps réel (flux SSE), et de garder en mémoire le contexte des conversations à plusieurs tours. Côté sécurité, le minimum est bien fait : chaque pair a son jeton d’authentification, et toutes les opérations sont journalisées. Autrement dit, chaque Hermes a désormais son « téléphone professionnel » — il peut appeler, envoyer des SMS, laisser des messages vocaux, mais uniquement en tête-à-tête.

Direction n°1 : le réseau local des agents (coordination multi-nœuds)

L’idée la plus populaire dans la communauté, c’est de transformer le « téléphone » en « réseau local ». Vous avez un poste macOS à la maison, un PC Windows, un serveur Linux, peut-être même un laptop et un téléphone, chacun avec son Hermes. Aujourd’hui, ils travaillent chacun de leur côté. Demain, on aimerait qu’ils forment un « réseau local d’agents » via un overlay réseau privé. C’est comme tous vos appareils connectés sur le même Wi-Fi : vous dites un mot, et l’enceinte du salon, la lampe de la chambre et le four de la cuisine réagissent ensemble. Pour Hermes, ça veut dire qu’une tâche peut circuler automatiquement entre plusieurs machines : les infos collectées sur le laptop sont synchronisées vers le poste de travail pour un traitement approfondi, puis le résultat est poussé vers votre téléphone pour validation.

Direction n°2 : la hiérarchie entre agents (le chef et ses subordonnés)

Aujourd’hui, les Hermes sont tous « au même niveau » : celui qui initie la conversation mène la danse. La communauté veut une relation hiérarchique : un Hermes leader peut déléguer une tâche à un Hermes subordonné sur une autre machine, et le leader peut voir en temps réel où en est la tâche — attention, « voir », pas « intervenir ». C’est comme un patron qui confie un dossier à son employé : vous voulez connaître l’avancement, sans surveiller chaque clic. Cette « observabilité passive » est essentielle : elle préserve l’autonomie du subordonné tout en rassurant le chef.

Direction n°3 : la collaboration multi-sessions (de l’îlot à la salle de réunion)

Imaginons que vous ouvrez trois sessions sur la même machine — une pour la recherche, une pour l’implémentation, une pour la relecture. Ce sont trois îlots isolés. Les infos clés trouvées par la session de recherche, vous devez les copier-coller manuellement vers la session d’implémentation : fragile et source d’erreurs. La proposition, c’est que ces sessions puissent s’envoyer des « messages » et partager le contexte nécessaire. Imaginez : au lieu de trois box individuelles, une salle de réunion où trois collègues peuvent se passer des notes et échanger en continu, tout en gardant leurs notes personnelles privées.

Direction n°4 : le talkie-walkie local (messages inter-sessions)

Cette proposition est plus ciblée : plusieurs sessions Hermes interactives sur la même machine devraient disposer d’un mécanisme de messagerie locale de « première classe ». Pas besoin de passer par un protocole réseau — comme un talkie-walkie au bureau : on appuie, on parle. La session de recherche a trouvé une info importante, elle « appelle » directement la session d’implémentation : « Hé, fais gaffe à l’API dans le troisième paragraphe. » Fini le copier-coller, fini les solutions fragiles du type tmux send-keys. C’est le complément de la direction n°3 : l’une gère l’inter-machine, l’autre la machine locale.

Direction n°5 : politique d’approbation à distance (portail de sécurité)

A2A permet déjà à un pair distant d’envoyer des tâches dans votre session live. Utile, mais risqué — et si on vous demande de modifier un fichier ? La communauté veut une politique de « pairs de confiance scopés » : vous pouvez désigner un Hermes précis sur une machine précise comme « de confiance » — ses tâches peuvent avoir des effets de bord locaux. Tous les autres, en lecture seule. C’est comme un badge d’entreprise : certains ont accès à la salle des comptes, d’autres seulement à la salle de réunion. C’est un maillon essentiel pour une délégation sécurisée.

Direction n°6 : notification visible de fin de tâche

Aujourd’hui, quand une tâche A2A se termine, le résultat est écrit dans les logs ou renvoyé via une réponse JSON-RPC. Mais si vous ne surveillez pas les logs ? La communauté souhaite qu’une notification s’affiche dans le canal Hermes que vous utilisez au quotidien — comme une notification push sur votre téléphone : « La tâche que tu as déléguée sur cette machine est terminée, voici le résultat. » Ça ne vous interrompt pas, mais ça vous tient informé.

Qu’est-ce qui est déjà partiellement en place ?

Bonne nouvelle : le concept de « worker borné » proposé par la communauté est déjà partiellement implémenté — un lanceur externe configurable qui limite le périmètre d’exécution des tâches distantes. C’est une première fondation pour l’« approbation à distance ». Par ailleurs, des détails comme le timeout de 330 secondes, les résultats tardifs et l’isolation du contexte sont déjà en place. Mais attention : la coordination multi-nœuds, la hiérarchie et le talkie-walkie local restent pour l’instant des vœux pieux dans des issues ouvertes.

Et pour vous, ça change quoi ?

Si vous êtes un utilisateur lambda, ces directions signifient qu’à l’avenir, Hermes ne sera plus une collection d’« agents solitaires », mais une véritable « équipe » capable de collaborer. Vous n’avez pas à vous soucier de la façon dont ils communiquent entre eux — vous savez juste que les Hermes sur tous vos appareils à la maison s’entraideront comme une famille, et que rien de ce qui mérite votre attention ne vous échappera.

Un dernier mot : tout cela, ce sont des issues ouvertes proposées par la communauté. Le dossier .plans officiel a été supprimé (août 2026), donc rien ne garantit que tout sera implémenté. Mais au moins, la feuille de route est dessinée — les agents préparent leur réseau local, et cette fois, ils comptent bien y connecter aussi la « maison ».