Les systèmes multi-agents permettent aujourd’hui de répartir une mission complexe entre plusieurs modèles : un agent peut travailler sur une API, un autre sur une interface, un troisième sur les tests, pendant qu’un orchestrateur coordonne l’ensemble.
Mais même lorsque ces agents travaillent en parallèle, leur principal moyen de communication reste généralement le même que celui que nous utilisons avec un chatbot : le texte.
Un agent découvre quelque chose, le transforme en message, ce message est transmis à un autre agent, qui doit ensuite le lire et le réinterpréter dans son propre contexte.
Avec Formic-Link, nous explorons une approche différente.
Formic-Link est une architecture de communication conçue pour permettre à plusieurs agents Formic travaillant sur une même mission de s’échanger directement des représentations latentes issues de leur calcul interne, tout en conservant leurs modèles, leurs contextes et leurs caches indépendants.
L’objectif n’est pas de créer un cerveau collectif unique.
L’objectif est de permettre à plusieurs exécuteurs spécialisés de mieux coordonner leur travail, partager plus rapidement les informations importantes et adapter leur propre exécution à ce que découvrent les autres agents.
Le problème : plusieurs agents ne sont pas automatiquement une équipe
Imaginons trois agents travaillant simultanément sur le même projet logiciel.
L’agent A modifie une interface backend. L’agent B travaille sur le code qui utilise cette interface. L’agent C prépare les tests.
Au départ, leurs tâches peuvent être parfaitement réparties.
Mais pendant son travail, A peut découvrir qu’un ancien cas doit rester compatible. B peut découvrir qu’une dépendance a changé. C peut détecter qu’une hypothèse commune est incorrecte.
À ce moment-là, la qualité du système dépend moins de la capacité individuelle de chaque modèle que de la vitesse à laquelle cette nouvelle information se propage aux autres agents.
Dans un système classique, chaque découverte doit être transformée en message textuel, transmise, puis relue et interprétée avant que l’agent destinataire puisse adapter son travail.
Formic-Link cherche à raccourcir cette boucle.
Une communication directement reliée au modèle
L’idée centrale de Formic-Link est de ne plus faire du texte l’unique canal de communication entre les agents.
Lorsqu’un agent dispose d’une information potentiellement utile à un autre, Formic-Link peut produire une petite représentation numérique apprise — un message latent.
Le destinataire n’a alors pas nécessairement besoin de reconstruire cette information à partir d’une explication en langage naturel. Le message peut être directement consulté par certains modules intégrés à son réseau neuronal.
Cela ne signifie évidemment pas que deux GPU communiquent « sans transport ». Les tenseurs doivent toujours être déplacés entre processus ou machines.
La différence se situe à l’interface avec le modèle : l’information peut arriver sous forme neuronale plutôt que sous la forme obligatoire d’un nouveau dialogue textuel.
Comment fonctionne Formic-Link techniquement ?
L’architecture repose principalement sur cinq composants : un émetteur, un routeur, une boîte de réception latente, des lecteurs neuronaux et un runtime de communication.
1. L’émetteur : extraire une information de l’état interne
Chaque agent Formic effectue normalement ses calculs à travers les différentes couches de son modèle.
Pendant cette exécution, le réseau construit des représentations internes de ce qu’il vient de lire et de ce qu’il est en train de faire.
Formic-Link ajoute un petit émetteur neuronal capable de lire une partie de ces activations déjà calculées.
Il ne cherche pas à exporter « toute la pensée » du modèle. Son rôle est plutôt de compresser certaines informations potentiellement utiles en une représentation beaucoup plus petite.
Par exemple, un agent pourrait venir de comprendre que :
- une interface a changé ;
- une hypothèse précédente vient d’être invalidée ;
- un test révèle une contrainte importante ;
- un artefact dont dépend un autre agent vient d’évoluer.
L’émetteur transforme alors cette information en plusieurs petits vecteurs.
Dans la configuration pilote décrite pour Formic-Link, un message peut par exemple être représenté par 8 vecteurs de dimension 256.
Ces vecteurs ne correspondent pas à huit catégories écrites à l’avance comme « erreur », « plan » ou « conclusion ». Leur signification est apprise par le système en fonction de leur utilité pour le modèle qui les reçoit.
2. Le bus latent : transporter, router et versionner
Le message produit par l’émetteur est ensuite envoyé au Formic-Link Latent Bus.
Le bus n’est pas un nouveau modèle qui réfléchit à la place des agents.
C’est une infrastructure chargée de gérer la communication :
- quel agent a produit le message ;
- quels agents sont autorisés à le recevoir ;
- à quelle tâche il appartient ;
- à quelle version du projet il se rapporte ;
- quels artefacts sont concernés ;
- s’il est toujours valide ;
- et dans quel ordre causal il a été produit.
Chaque message comporte donc deux parties : une charge utile latente, destinée au réseau neuronal ; et une enveloppe structurée, utilisée par le runtime pour garantir provenance, routage et cohérence.
Cette distinction est essentielle.
Un vecteur peut transmettre le sens ou les implications d’une découverte. Mais l’identité exacte d’un fichier, d’une version ou d’un patch ne doit pas dépendre de l’interprétation approximative d’un latent.
3. Une boîte de réception propre à chaque agent
Lorsqu’un message arrive chez un autre agent, il n’est pas fusionné directement avec ses activations.
Il est d’abord placé dans une boîte de réception latente, ou latent inbox. Cette boîte contient un nombre limité de messages valides et conserve leurs métadonnées.
Chaque agent possède sa propre boîte.
Les agents continuent donc à avoir leur propre contexte, leur propre génération, leur propre historique et leurs propres caches natifs.
Formic-Link ne fusionne pas les états internes de plusieurs modèles. Chaque agent reste lui-même, relié aux autres uniquement par le canal Formic-Link.
4. Les lecteurs Formic-Link : intégrer l’information dans le Transformer
C’est ici que Formic-Link devient réellement une modification de l’architecture interne.
À certains endroits du réseau Formic, nous pouvons ajouter de petits lecteurs neuronaux.
Lorsqu’un agent atteint l’un de ces points pendant son calcul, le lecteur compare son état interne actuel aux messages présents dans sa boîte de réception. Il utilise pour cela un mécanisme de cross-attention.
Conceptuellement, le modèle se demande : parmi les informations que les autres agents m’ont envoyées, lesquelles sont réellement pertinentes pour ce que je suis en train de faire maintenant ?
Si une information est utile, le lecteur produit une petite contribution qui est ajoutée au flux résiduel du modèle. Les couches suivantes continuent alors leur calcul à partir de cet état enrichi.
Le message peut donc influencer directement :
- le prochain token produit ;
- une décision d’utiliser un outil ;
- la manière de construire un patch ;
- une vérification ;
- une correction ;
- ou la décision de relire une ressource.
Où Formic-Link se branche-t-il dans le modèle ?
Sur Formic Standard, le backbone étudié comporte 64 couches organisées en 16 groupes.
Formic-Link ne remplace pas ces couches, les mécanismes GDN, les MLP ou le tokenizer. Il ajoute seulement de petites branches de communication à certaines frontières du réseau.
Un lecteur intermédiaire permet aux couches suivantes de retraiter l’information reçue. Un lecteur très tardif permet au message d’avoir un chemin plus direct vers la prochaine décision.
Le latent transmet du sens, pas la vérité opérationnelle
C’est probablement l’un des principes les plus importants de Formic-Link.
Supposons que l’agent A envoie une information qui signifie approximativement : « La signature de cette fonction a probablement changé et ton code doit en tenir compte. »
Cette information peut être extrêmement utile à B. Mais elle ne doit pas suffire pour que B considère automatiquement que cette nouvelle signature est maintenant officiellement celle du dépôt.
Formic-Link sépare donc trois plans :
| Plan | Rôle |
|---|---|
| Neuronal | Comprendre les informations et influencer les prochaines décisions |
| Coordination exacte | Conserver tâches, versions, dépendances, artefacts et permissions |
| Exécution | Appliquer les modifications et effectuer les vérifications |
Latent communication for understanding.
Deterministic state for truth.
Un latent peut aider un agent à comprendre qu’une interface est importante. La signature exacte reste un artefact versionné.
Un latent peut avertir qu’un test a échoué. Le résultat exact du test reste une preuve externe.
Un latent peut influencer une proposition. Il ne peut pas accorder une nouvelle permission au modèle.
Une communication asynchrone
Formic-Link est également conçu pour éviter que tous les agents soient obligés d’avancer au même rythme.
Un agent n’a pas besoin d’attendre un nouveau message à chaque token. Il poursuit son travail avec les informations actuellement disponibles.
Lorsqu’un nouveau message arrive, le runtime prépare une nouvelle version de sa boîte de réception. Cette version ne remplace pas brutalement les données utilisées au milieu d’un calcul déjà commencé : elle devient visible au prochain point d’admission prévu.
Cela permet d’avoir plusieurs agents réellement parallèles, sans grande barrière où tout le monde doit attendre tout le monde.
Les caches restent totalement privés
Une solution apparemment simple aurait été de partager directement les caches internes entre plusieurs modèles.
Nous avons volontairement écarté cette approche pour Formic-Link.
Les caches natifs d’un modèle dépendent de son propre historique de tokens et de calculs. Copier ou fusionner arbitrairement ceux de deux agents reviendrait à mélanger deux trajectoires différentes sans sémantique claire.
Formic-Link utilise donc une mémoire de communication séparée. Les agents partagent de l’information, pas leur mémoire neuronale native.
Un exemple concret
Imaginons une mission répartie entre trois agents.
L’agent A travaille sur une structure de données. L’agent B adapte une fonction qui utilise cette structure. L’agent C travaille sur les tests.
Pendant son analyse, A découvre qu’un ancien cas particulier doit absolument rester compatible.
Sans communication rapide, B peut continuer à développer sur une hypothèse incorrecte et C peut produire des tests incomplets.
Avec Formic-Link, l’émetteur de A encode la contrainte et le bus l’envoie à B et C. Le lecteur de B l’intègre avant sa prochaine décision et adapte son implémentation, tandis que C ajuste en parallèle sa couverture de test.
L’artefact exact découvert par A reste parallèlement référencé dans le système déterministe.
B peut donc utiliser le latent pour comprendre rapidement l’implication, puis récupérer la donnée exacte lorsqu’il en a besoin. Ce type de coopération producteur, consommateur et tests correspond directement aux scénarios prévus dans l’architecture Formic-Link.
Formic Standard et Formic Lite peuvent partager un même langage latent
Une autre propriété importante de l’architecture est la possibilité d’utiliser Formic-Link entre modèles de tailles différentes.
Formic Standard et Formic Lite n’ont pas nécessairement les mêmes représentations internes.
Formic-Link prévoit donc un espace latent commun, auquel chaque modèle accède via ses propres encodeurs et lecteurs.
La compatibilité vient du codec de communication appris, et non du fait que les modèles auraient les mêmes neurones ou partageraient leurs caches.
Cela ouvre notamment la possibilité de construire des équipes hétérogènes : certains agents Lite pourraient prendre en charge des opérations économiques, tandis que des agents Standard interviendraient sur des tâches nécessitant davantage de capacité.
Comment apprend-on à un modèle à communiquer en latent ?
Formic-Link ne suppose pas qu’un état interne brut constitue automatiquement un bon message.
L’émetteur et les lecteurs doivent apprendre ensemble quelle information transmettre et comment l’utiliser.
Une première forme d’entraînement peut placer deux agents dans une situation contrôlée : A possède une information que B ne possède pas. B doit prendre une décision dont la bonne réponse dépend précisément de cette information.
Le message produit par A est transmis à B, puis la qualité de la décision de B fournit le signal d’apprentissage.
Pendant l’entraînement couplé, le gradient provenant de la décision du récepteur peut traverser le canal et contribuer à entraîner également l’émetteur.
Le système doit progressivement apprendre trois choses différentes :
- quoi communiquer ;
- comment utiliser ce qui est reçu ;
- quand communiquer est réellement utile.
C’est une distinction importante : le but de Formic-Link n’est pas que tous les agents communiquent constamment. Un bon système doit aussi savoir ne rien envoyer lorsque l’information n’apporte rien au travail collectif.
Ce que nous cherchons à améliorer
Formic-Link est avant tout pensé pour les missions où plusieurs agents ont des tâches différentes mais interdépendantes.
L’architecture vise notamment à réduire :
- les travaux devenus incompatibles, lorsque deux agents continuent trop longtemps sur des hypothèses différentes ;
- les lectures redondantes, lorsque plusieurs agents doivent indépendamment redécouvrir la même information ;
- les erreurs d’intégration, lorsqu’une modification d’interface n’est pas propagée suffisamment tôt ;
- la coordination textuelle intermédiaire, lorsqu’une information courte nécessite aujourd’hui un nouveau dialogue ;
- les temps d’attente, lorsqu’un agent peut commencer à travailler à partir d’une dépendance candidate versionnée ;
- et les cycles de réparation inutiles, lorsqu’un échec déjà observé par un agent pourrait guider immédiatement les autres.
Le but n’est donc pas simplement de remplacer quelques tokens par quelques vecteurs.
Peut-on faire en sorte que plusieurs modèles travaillant en parallèle adaptent réellement leur calcul les uns aux autres pendant l’exécution ?
Pas un cerveau collectif, mais une coopération plus étroite
La vision derrière Formic-Link n’est pas de fusionner plusieurs modèles en une intelligence unique et opaque.
Chaque agent reste un exécuteur identifiable, avec :
- une tâche précise ;
- des permissions précises ;
- un contexte propre ;
- des caches propres ;
- des responsabilités propres.
L’orchestrateur externe continue lui aussi à jouer son rôle habituel : il distribue les tâches, définit les contraintes et reçoit les résultats. Il ne participe pas au canal neuronal Formic-Link.
Formic-Link se situe uniquement entre les agents Formic qui exécutent la mission.
Notre ambition avec Formic-Link est d’explorer une nouvelle manière de faire coopérer plusieurs agents IA sur une même mission : leur permettre de mieux coordonner leur travail, partager plus rapidement les informations utiles, éviter les efforts redondants et adapter leur exécution en fonction de ce que découvrent les autres agents.
L’objectif final n’est pas que les agents communiquent davantage.
C’est qu’ils travaillent mieux ensemble.