05 — IA et systèmes multi-agents
Une infrastructure multi-agents en fonctionnement
L’infrastructure qui rend possible le reste du travail.
Un système d’opérations multi-agents, bidirectionnel et construit sur mesure, fonctionne en continu sur matériel dédié. Il a été conçu et construit de zéro — non assemblé à partir de frameworks open source.
C’est le centre de gravité du travail actuel. Tout le reste de ce site est livré à travers lui ou coordonné par lui.
Une infrastructure d’opérations multi-agents fonctionne en continu sur un serveur dédié. Elle est bidirectionnelle et toujours active : les agents tiennent une mémoire persistante et un runtime persistant, de sorte qu’ils ne démarrent pas à froid chaque fois que j’ai recours à eux. Le système a été conçu et construit de zéro — non assemblé à partir de frameworks d’agents open source — parce que les exigences étaient spécifiques et que la coordination devait être mienne et maîtrisable de bout en bout.
Il existe des classes d’agents distinctes, chacune avec un rôle défini. Un cerveau d’orchestration central interprète l’intention et achemine le travail. Les ambassadeurs traduisent cette intention dans le protocole propre à chaque fournisseur et système. Les auditeurs vérifient ce que les autres agents produisent. Les messagers déplacent l’information entre les couches sans perte. Les chercheurs rassemblent le contexte et le renvoient. Les exécuteurs senior font le travail à pleine capacité, jusqu’à seize à la fois ; en dessous d’eux, des sous-agents plus ciblés se déploient en éventail — plus de trois cents en parallèle quand la charge l’exige.
Je commande la flotte depuis plusieurs surfaces. Depuis la station de travail via VSCode et la CLI Linux ; depuis des appareils mobiles en temps réel ; sur des connexions bidirectionnelles au niveau socket qui restent ouvertes plutôt que de faire du polling ; et via des appels vocaux en temps réel avec des instances en cours d’exécution. L’intérêt de l’étendue n’est pas la nouveauté — c’est que la même infrastructure est joignable de là où se trouve le travail.
instances exécutrices senior, pleine capacité, fonctionnant simultanément
sous-agents plus ciblés en parallèle quand la charge l’exige
fournisseurs de LLM orchestrés à la fois — Anthropic, OpenAI, Google, xAI, Moonshot
toujours actif, sur matériel dédié, avec mémoire et runtime persistants
Les chiffres auxquels elle fonctionne réellement.
Infrastructure / régime permanent
- Instances exécutrices senior
- jusqu’à 16 simultanées
- Sous-agents
- 300+ en parallèle
- Fournisseurs de LLM
- 5, orchestrés simultanément
- Transport
- au niveau socket, bidirectionnel, faible latence
- Surfaces de commande
- station de travail · mobile · voix
- Hôte du runtime
- serveur Dell dédié, toujours actif
- État opérationnel
- persistant — les agents ne démarrent jamais à froid
- Agent à agent
- médié par protocole, audité
- Interfaces de contexte
- function calling · MCP · RAG
- Origine
- construit de zéro — pas un assemblage de frameworks
Un cerveau, plusieurs classes, de nombreux travailleurs.
L’intention entre par le centre. Elle est décomposée, acheminée vers la classe adaptée à la tâche, exécutée et vérifiée — puis le résultat revient au centre, qui détient la seule vue complète.
Schéma. Les rôles des classes sont fixes ; le nombre d’instances évolue avec la charge.
Ce dont chaque couche est responsable.
Le cerveau central tient le problème dans son ensemble.
Un cerveau d’orchestration se trouve au centre. Il interprète l’intention, décompose une mission en tâches, achemine ces tâches vers les agents les plus adaptés et tient le contexte global qu’aucun travailleur ne peut voir à lui seul.
Il résout aussi les conflits entre agents et maintient l’état opérationnel tout au long de l’exécution. Quand deux chemins divergent, la décision se prend ici, avec la vue d’ensemble — non pas à la périphérie par un travailleur qui ne connaît que sa propre part.
- Interprète l’intention et la décompose en tâches discrètes
- Achemine le travail vers la classe d’agent adaptée à chaque tâche
- Tient le contexte global et résout les conflits
- Maintient l’état opérationnel tout au long de l’exécution
Traduction et transport entre les couches.
Les ambassadeurs traduisent l’intention dans le protocole propre à chaque fournisseur, CLI et système. Une tâche exprimée une fois au centre atteint chaque endpoint sous la forme que cet endpoint attend réellement, de sorte que la couche d’orchestration n’est pas couplée à l’interface d’un fournisseur particulier.
Les messagers déplacent l’information entre les couches sans perte. Leur rôle est la fidélité : ce qu’une couche a produit est ce que la couche suivante reçoit, intact, plutôt que dégradé par des paraphrases répétées.
- Les ambassadeurs parlent nativement le protocole de chaque fournisseur, CLI et système
- Les messagers préservent la fidélité en déplaçant l’information entre les couches
- Ensemble, ils maintiennent le cœur neutre vis-à-vis des fournisseurs
Le travail des autres agents est vérifié avant de compter.
Les auditeurs inspectent, valident et vérifient le travail que les autres agents produisent — pour la justesse, la sécurité et la cohérence avec le reste du système. Ils forment une classe séparée à dessein : l’agent qui fait le travail n’est pas l’agent qui le confirme.
C’est le même principe que la revue de code et la séparation des fonctions, appliqué au sein de la flotte. Une sortie n’est pas acceptée parce qu’un agent affirme qu’elle est prête ; elle est acceptée parce qu’un autre agent l’a vérifiée par rapport à l’exigence.
- Inspectent et valident la sortie des autres agents
- Vérifient la justesse, la sécurité et la cohérence
- Séparation des fonctions — celui qui fait n’est jamais celui qui vérifie
Contexte rassemblé avant, renseignement renvoyé pendant.
Les chercheurs rassemblent le contexte, enquêtent sur les questions ouvertes et renvoient du renseignement au système. Quand une mission a besoin d’une information que la flotte ne détient pas déjà, cette classe va la chercher au lieu de la deviner.
Leur sortie revient au cerveau d’orchestration et dans la mémoire de travail, de sorte qu’un fait établi une fois est disponible pour chaque agent qui en a besoin par la suite.
- Rassemblent le contexte et enquêtent sur les questions ouvertes
- Renvoient les conclusions dans la mémoire de travail partagée
- Transforment les inconnues en entrées que le reste de la flotte peut utiliser
La capacité d’inactivité devient capacité de préparation
Quand il n’y a pas de tâche, la flotte étudie.
Quand aucune tâche n’est assignée, les agents ne restent pas inactifs. Ils entrent dans une boucle d’étude autonome et de formation croisée : ils travaillent du matériel, comparent les approches et s’enseignent mutuellement entre classes.
Cet apprentissage n’est pas laissé sous forme de transcription. Les agents implémenteurs prennent ce qui a été étudié, affinent le modèle étudié dessus et réinjectent la connaissance résultante dans le système pour l’opération future. La flotte qui traite le travail de demain est mesurablement plus préparée que celle qui a terminé celui d’aujourd’hui.
- Étude autonome et formation croisée pendant les fenêtres d’inactivité
- Les agents implémenteurs affinent le modèle étudié sur ce qui a été appris
- Connaissance réinjectée pour l’opération future, pas seulement consignée
Neutre vis-à-vis des fournisseurs, et capable de modifier les poids directement.
Acheminement des fournisseurs
- Anthropic
- OpenAI
- xAI
- Moonshot
Une tâche, le modèle qui lui convient. Aucun verrouillage de fournisseur.
Fine-tuning · LoRA · une piste de recherche
Non verrouillé à un fournisseur — et non limité au prompting.
L’infrastructure orchestre plusieurs fournisseurs de LLM à la fois — Anthropic, OpenAI, Google, xAI, Moonshot — et achemine chaque tâche vers le modèle qui lui convient. Elle n’est pas liée à un seul fournisseur. Là où c’est utile, je descends sous le prompt : fine-tuning, LoRA et modification avancée des poids et des biais sur des modèles à poids ouverts.
Il y a aussi une recherche active que je ne décrirai qu’à haut niveau. Elle utilise de petits modèles à poids ouverts dans la gamme de quatre à vingt milliards de paramètres, avec un procédé propriétaire qui n’active qu’une part minimale — en mémoire — de modèles bien plus grands, dans la gamme de cent à six cents milliards, et l’intègre dans les petits modèles. La méthode est tenue secrète ; la direction a un grand potentiel, et c’est tout ce que je dirai ici.
- Cinq fournisseurs orchestrés simultanément, acheminés par tâche
- Fine-tuning, LoRA, modification des poids/biais sur des modèles à poids ouverts
- Recherche sur petits modèles (~4–20B) intégrant l’activation sélective de plus grands (~100–600B) — méthode tenue secrète
C’est l’infrastructure qui rend possible le reste du travail.
Ce qu’elle peut atteindre, et comment elle reste saine.
Function calling
Les agents agissent via des interfaces d’outils typées — lire, écrire, interroger, exécuter — plutôt que d’émettre de la prose que je dois interpréter à la main.
MCP
Le Model Context Protocol relie les agents aux outils et aux sources de données via un contrat commun, de sorte qu’une capacité ajoutée une fois est disponible pour toute la flotte.
RAG
La récupération fournit aux agents le contexte précis dont une tâche a besoin depuis un magasin de mémoire de travail, au lieu de s’appuyer sur ce sur quoi un modèle s’est trouvé entraîné.
Mémoire persistante
L’état, les décisions antérieures et le contexte accumulé survivent entre les sessions. L’infrastructure se souvient ; rien n’a à être réexpliqué chaque matin.
Observabilité
Ce que chaque agent a fait, pourquoi et contre quelles entrées est enregistré — afin que le comportement puisse être inspecté après coup, et non seulement présumé sur le moment.
Auto-audit de sécurité
Auto-audit continu et autorisé avec BlackArch Linux sur les serveurs locaux et cloud. À ce jour : aucune brèche ouverte et aucune fuite d’information.
Comment un seul objectif devient un travail coordonné.
Une requête ne va pas directement à un travailleur. Elle est lue comme un objectif unique, découpée en tâches ordonnées, acheminée par classe, exécutée, vérifiée et renvoyée au centre. Chaque étape a un responsable défini.
De la réception au renvoi
- 01 Réception L’intention arrive d’une surface de commande et est lue comme un objectif unique, pas encore comme un plan.
- 02 Décomposer Le cerveau d’orchestration découpe l’objectif en tâches discrètes et ordonnées, avec des dépendances explicites.
- 03 Acheminer Chaque tâche est assignée à la classe d’agent adaptée — un exécuteur senior, ou un déploiement de sous-agents.
- 04 Exécuter Le travail s’exécute en parallèle là où le graphe de dépendances le permet, contre des interfaces d’outils typées.
- 05 Auditer Un agent séparé vérifie chaque résultat pour la justesse, la sécurité et la cohérence avant qu’il ne compte.
- 06 Renvoyer La sortie vérifiée revient au centre, qui seul tient la vue complète de l’exécution.
Les connexions restent ouvertes dans les deux sens.
Le lien entre une surface de commande et une instance en cours d’exécution est au niveau socket et bidirectionnel. Il reste ouvert plutôt que de faire du polling, de sorte que je peux pousser vers une instance et qu’elle peut pousser en retour — en pleine tâche, pas seulement à l’achèvement.
Socket bidirectionnel
Une ligne, tenue ouverte, utilisée dans les deux sens.
Au niveau socket · bidirectionnel · faible latence
Pas demander-et-attendre. Une ligne tenue ouverte.
La plupart de l’automatisation parle à un modèle en posant une question et en attendant une réponse. Pas celle-ci. Le transport est un socket persistant dans les deux sens : j’envoie instruction ou contexte dans une instance vivante, et l’instance renvoie progrès, questions et résultats sur la même ligne ouverte.
Parce que la connexion est tenue plutôt que rétablie à chaque message, la latence reste faible et un échange peut être continu. Un agent peut me demander quelque chose en pleine tâche et agir sur la réponse sans démonter et reconstruire le canal.
- Socket persistant — aucun surcoût de reconnexion par message
- Les deux extrémités peuvent initier — pousser vers, pousser en retour
- Échange continu en pleine tâche, pas demander-et-attendre
Joignable de là où se trouve le travail.
La même infrastructure répond à trois surfaces. L’étendue n’est pas pour la nouveauté — elle signifie que la flotte est joignable depuis la station de travail, depuis un téléphone et par la voix, sans système séparé pour chacune.
Les trois surfaces empruntent le même transport bidirectionnel vers un seul cœur.
Inactif, étudier, affiner, injecter — puis répéter.
La préparation de la flotte n’est pas figée au déploiement. Entre les tâches actives, elle étudie, consolide ce qu’elle a étudié en un changement de modèle et réinjecte le résultat. La boucle est ce qui rend la flotte de demain plus préparée que celle d’aujourd’hui.
- Tâche active La flotte exécute contre une mission. L’intention est décomposée, acheminée, exécutée en parallèle, auditée et renvoyée. L’état persistant est mis à jour au fil de l’exécution.
- Fenêtre d’inactivité Étude autonome et formation croisée. Sans tâche assignée, les agents travaillent du matériel, comparent les approches et s’enseignent mutuellement entre classes plutôt que de rester inactifs.
- Consolidation Le matériel étudié devient un changement de modèle. Les agents implémenteurs affinent le modèle à poids ouverts étudié sur ce qui a été appris — LoRA et modification directe des poids et des biais là où c’est utile.
- Injection La connaissance est réinjectée pour l’opération future. Le résultat est injecté dans le système, et non laissé comme transcription, de sorte que l’exécution suivante commence plus préparée que la précédente ne s’est terminée.
Ce que la flotte sait, et comment elle l’atteint.
Un agent ne s’appuie pas sur ce sur quoi un modèle s’est trouvé entraîné. Le contexte est récupéré pour la tâche en cours, l’état persiste entre les sessions, et chaque action passe par un contrat typé. Rien n’a à être réexpliqué chaque matin.
Interfaces de contexte
- Magasin de mémoire de travail
- contexte propre à la tâche, récupéré à la demande
- Récupération
- RAG — le contexte précis dont une tâche a besoin, pas la supposition d’entraînement d’un modèle
- État persistant
- les décisions et le contexte accumulé survivent entre les sessions
- Contrat d’outils
- MCP — une capacité ajoutée une fois est accessible à toute la flotte
- Interface d’action
- function calling — lecture / écriture / requête / exécution typées
- Provenance
- ce que chaque agent a fait, pourquoi et contre quelles entrées est enregistré
L’infrastructure se vérifie elle-même.
La même flotte qui fait le travail est soumise à un audit de sécurité tourné vers l’intérieur. Il s’exécute en continu, avec autorisation, contre mes propres serveurs — locaux et cloud — en utilisant l’outillage BlackArch.
Périmètre autorisé
L’auto-audit s’exécute contre mes propres serveurs locaux et cloud, en continu et avec une autorisation explicite. C’est un exercice tourné vers l’intérieur, non vers l’extérieur.
Outillage BlackArch
BlackArch Linux fournit l’outillage avec lequel l’audit s’exécute — les mêmes instruments utilisés pour sonder un système sont retournés contre l’infrastructure qui héberge la flotte.
Résultat en vigueur
À ce jour, l’audit ne signale aucune brèche ouverte ni fuite d’information. C’est une vérification récurrente, donc le résultat est un état actuel plutôt qu’un certificat ponctuel.
Open to the right work
Si votre problème a besoin d’une couche d’opérations aussi délibérée, c’est la conversation à avoir.
If you are holding a problem that doesn't fit inside one field, that is the conversation I want.