Architecture des agents : outils, mémoire et contexte

Un agent qui appelle des outils n'est pas seulement un modèle de langage avec une boucle autour. Entre le modèle et le résultat se trouvent un harnais qui guide la planification, une politique qui décide quels agents travaillent ensemble, une mémoire qui conserve les leçons des exécutions passées, un mécanisme qui choisit quelle partie de l'historique relire, et une infrastructure qui alloue du CPU, du disque et du réseau. Huit preprints récents examinent ces couches séparément. Aucun ne propose une architecture complète ; pris ensemble, ils dessinent la liste des décisions qu'un projet doit trancher.

Ces travaux se lisent ensemble parce qu'ils partagent une même méthode : isoler un composant du système agentique, mesurer ce qu'il apporte, et refuser de conclure que davantage de ce composant produit un meilleur agent. Davantage d'agents ne rend pas un workflow plus efficace. Davantage de contexte relu ne rend pas une décision plus juste. Davantage de cœurs CPU n'accélère pas toujours une tâche. Deux papiers portent sur la mémoire et aboutissent au même réflexe : une mise à jour doit être localisée, testée et réversible.

Le lecteur en retire une grille d'instrumentation plutôt qu'une recette. Ce dossier indique, pour chaque couche, ce que les auteurs ont réellement mesuré, avec quels chiffres, et ce que leurs propres sections de limites signalent comme non démontré. Les propositions purement conceptuelles sont identifiées comme telles.

Ce qu'un harness apporte vraiment

Comparer deux systèmes agentiques complets ne dit pas lequel de leurs composants produit la différence. Yukun Zhang, Kemu Xu et Yishen Chen construisent donc un protocole qui sépare la valeur de l'information de planification, celle de la vérification terminale et celle du coût, dans des agents LLM à état.

Le dispositif principal est une comparaison entre un plan écrit pour la tâche et un texte de politique mélangé de même longueur. Cette construction distingue le contenu du guidage de la simple quantité de contexte fourni au modèle. Un vérificateur en lecture seule examine ensuite la trace après exécution.

Sur 265 cellules appariées, le plan fixe améliore la réussite vérifiée par oracle de 7,17 points de pourcentage, avec un intervalle bootstrap annoncé de 1,15 à 13,36 points. Les gains se concentrent sur les tâches les plus complexes. Le vérificateur rejette 61 % des épisodes invalides dans Retail, tout en retenant 17 % des épisodes corrects, pour un coût additionnel annoncé inférieur à un cent par épisode.

La contribution relative des deux composants dépend du coût attribué à une acceptation erronée : à faible responsabilité, le plan domine ; à responsabilité élevée, éviter les faux passages compte davantage. Les auteurs signalent que la couverture des blocs expérimentaux est inégale et que les tâches ne représentent pas tous les dépôts ou domaines. Le coût d'un vérificateur dépend aussi de la configuration retenue.

Quand ajouter des agents dégrade le workflow

Ajouter des agents isole des contextes et répartit une tâche longue. Cela ajoute aussi des messages, des résumés et des décisions de coordination. « Rethinking Multi-Agent Collaboration: When More Is Less » cherche les structures de tâches où le bénéfice compense ce coût, en opposant les tâches longues à dépendances clairsemées aux workflows séquentiels et fortement couplés. Dans le premier cas l'isolation peut aider, dans le second la coordination devient une surcharge.

La contribution technique s'appelle SAIGE, pour Semantic-Aware Incremental Graph Evolution. La collaboration y est représentée comme un graphe qui évolue : les nœuds sont des instances créées à la demande, les arêtes codent des dépendances sémantiques établies par récupération de contenu. Un agent est relié à un autre lorsqu'une dépendance est identifiée, au lieu de lancer systématiquement un pool fixe et de multiplier les échanges par défaut.

Sur des benchmarks de tâches longues et complexes, les auteurs rapportent un compromis favorable entre efficacité du contexte et performance pour SAIGE. Ils observent que l'augmentation du nombre d'agents ou de la profondeur de récursion n'améliore pas systématiquement les résultats. La conclusion est structurelle : la supériorité multi-agent dépend de la forme de la tâche.

En pratique, cela invite à cartographier les dépendances avant de paralléliser, et à mesurer le coût de synchronisation, le volume de contexte recopié et la qualité des décisions de fusion. Le résumé ne fournit ni les scores détaillés de tous les benchmarks ni une loi de dimensionnement ; la performance dépendra du modèle, du coût des appels et de la qualité de la récupération qui construit les arêtes.

Une architecture d'agent pour une décision multidomaine

Le preprint « A Proposal for an Agentic AI Architecture to Support Multi-Domain Decision-Making in the Brazilian Armed Forces » ne présente pas un produit livré. Il propose un cadre conceptuel pour une chaîne de décision couvrant les domaines terrestre, aérien, naval, cyber et électromagnétique. Le point de départ est la saturation du cycle observe-orient-decide-act par le volume et la vitesse des données.

La proposition regroupe quatre usages : aide à la décision, analyse de situation, études de faisabilité et suggestion de contre-mesures. Un cœur d'orchestration répartit les sous-tâches entre des agents spécialisés et limite chaque agent à un sous-ensemble de données et d'outils. Les niveaux administratif, stratégique, opérationnel et tactique n'ont pas les mêmes exigences : plus l'action proposée est proche d'un effet opérationnel, plus le contrôle humain, la traçabilité et les permissions doivent être explicites. Une recommandation susceptible d'affecter un système opérationnel ou d'armes doit passer par une approbation humaine obligatoire.

L'agent reçoit donc un rôle d'intégration et de raisonnement, pas une autorité autonome illimitée. Cette séparation entre préparation d'options et autorisation d'exécution est transférable à d'autres environnements sensibles, où une politique distincte décide ce qui peut réellement être lancé.

Le papier ne rapporte aucune évaluation opérationnelle. Les auteurs indiquent qu'il faudrait un prototype, un exercice simulé, des protocoles précis avec les systèmes existants et une analyse de conformité avec la doctrine et la législation applicables. Ils signalent les risques de dégradation sur des tâches longues, d'accumulation d'erreurs, de souveraineté technologique et de défaillances liées à des preuves hétérogènes. L'architecture ne peut donc pas se lire comme une preuve d'efficacité en conditions réelles, et toute adaptation civile sensible demanderait sa propre analyse des risques et des responsabilités. Les lecteurs intéressés par la couche de contrôle trouveront des éléments voisins dans le dossier sécurité des modèles et des agents.

Mettre à jour des skills sans propager chaque erreur

Une trajectoire ratée peut venir d'un mauvais déclencheur, d'une étape d'exécution, d'une frontière d'applicabilité ou d'une relation entre skills. Modifier tout le référentiel à partir du seul résultat final risque de dégrader des tâches qui fonctionnaient. Ziqiao Shang, Ling-Yue Ge et Lan-Zhe Guo proposent SkillAA pour localiser la réparation avant de l'appliquer.

SkillAA représente dans un graphe les conditions d'utilisation, l'exécution et la composition des skills. Le système compare des exécutions réussies et échouées, puis route une réparation vers l'objet de graphe jugé responsable. L'édition reste locale, et une catégorie d'échec peut conduire à ne rien modifier lorsqu'il s'agit d'une erreur ponctuelle ou d'un manque de preuve. Deux contrôles filtrent les propositions : la Local Gate teste les cas probablement affectés, la Big Gate vérifie ensuite la modification sur l'ensemble de mise à jour. Une proposition rejetée revient à l'état précédent, et les jeux de test restent réservés à l'évaluation finale.

Le résumé rapporte 81,5 % sur SearchQA, 66,7 % sur LiveMath et 91,2 % sur DocVQA avec gpt-5.6-sol, ainsi que la meilleure moyenne observée dans chaque réglage principal. Ces chiffres soutiennent l'utilité du routage par attribution et de la validation à l'échelle du graphe dans le protocole présenté.

Le pattern reste utile même sans adopter l'algorithme : diagnostiquer, éditer localement, tester les voisins, promouvoir avec une preuve. Une bibliothèque de skills qui croît par simple accumulation finit par contenir des corrections qui en cassent d'autres. Les auteurs signalent que les performances dépendent des benchmarks, des modèles et de la définition des gates, et qu'une attribution erronée peut encore envoyer la réparation dans la mauvaise zone.

Une mémoire des erreurs attachée à un rôle

Un agent de codage clinique peut répéter une erreur déjà observée : code non justifié, condition manquée ou mauvais niveau de précision. « LearnActCoder: Role-Aware Error Memory for Adaptive Clinical Coding Agents » convertit un petit lot d'erreurs étiquetées en une base appelée MistakeKDB. Les leçons issues de faux négatifs sont dirigées vers un Coder orienté rappel, celles issues de faux positifs vers un Judge orienté précision. Le workflow ne change pas et le modèle n'est pas réentraîné.

Sur 150 notes MIMIC-III appariées, la mémoire structurée fait passer le F1 CPT moyen par note de 11,5 % à 17,4 %, soit +5,9 points, avec une différence rapportée comme significative. Le F1 ICD-9 augmente de 1,5 point, mais l'intervalle et le test ne concluent pas à un gain significatif. Sur 250 notes MIMIC-IV, la mémoire augmente la précision ICD-10 de 4,2 points et réduit le rappel de 3,1 points ; le F1 reste statistiquement inchangé.

Ce que les auteurs rapportent est donc un déplacement du point de fonctionnement, pas une amélioration uniforme. La forme du souvenir compte : une collection d'exemples bruts ou une réflexion générale n'a pas le même effet qu'une leçon rattachée à une classe d'erreur et à un rôle précis dans le workflow.

L'étude est rétrospective, utilise des données MIMIC désidentifiées et ne valide pas un système autonome en production clinique. Les performances CPT/HCPCS restent faibles, un seul modèle est étudié, et la sensibilité aux versions, aux souvenirs obsolètes et à l'intégration prospective reste ouverte. Ce texte est informatif et ne constitue ni un dispositif médical ni un conseil clinique.

Décider quand relire tout l'historique

À chaque étape de génération, l'attention complète relit un historique qui grandit. Dans un agent, cet historique contient des observations, des sorties d'outils et des traces anciennes dont seule une petite partie sert à la prochaine décision. Haibo Feng, Ruiqi Liang, Hanyang Peng et Shiqi Yu se demandent si le modèle peut apprendre à décider quand une lecture globale est nécessaire.

On-Demand Attention, ou ODA, commence par une lecture locale. Une petite tête de rappel estime le bénéfice attendu d'une attention globale et ne l'active que lorsque ce bénéfice évolue suffisamment. Les poids du modèle préentraîné restent inchangés, seule cette tête est entraînée. Le cache complet reste disponible pour un rappel ultérieur : la méthode ne supprime pas l'information historique, elle évite de la parcourir à chaque token. Les auteurs implémentent aussi une exécution conditionnelle côté GPU dans vLLM pour relier la sélection à un gain pratique.

Le résumé indique des expériences sur des modèles Qwen et Gemma, y compris des architectures à attention hybride. ODA récupère une grande partie des performances perdues avec une attention uniquement locale tout en réduisant sensiblement le nombre de lectures globales. Les gains de vitesse dépendent toutefois de la longueur de contexte et de l'implémentation matérielle.

Pour un agent, la question n'est pas seulement quel outil appeler, mais quelle partie de la mémoire relire avant d'agir. Une intégration prudente comparerait le comportement avec et sans rappel sélectif sur des tâches où la preuve se trouve au début de l'historique, et journaliserait la portée de lecture, les rappels globaux et les erreurs de récupération. ODA est présenté comme une méthode d'inférence, pas comme une garantie de pertinence pour tous les workflows agentiques.

Deux agents ne consomment pas les mêmes ressources

Un agent qui appelle une API distante et exécute des outils locaux mélange plusieurs temps d'attente. La latence du modèle, le CPU du conteneur, la mémoire, le disque et le réseau ne se comportent pas de la même façon. « Not All AI Agents Are Equal » mesure cette dynamique au lieu d'appliquer une moyenne unique à tous les agents, sur trois tâches représentatives : question-réponse augmentée par récupération, recherche web et programmation.

Les goulots diffèrent. La RAQA est très sensible à la contention CPU locale. La recherche web est dominée par l'attente des services distants. Le codage combine plusieurs goulots, notamment les commandes locales, les accès disque et l'état propre à chaque requête. D'où un résultat contre-intuitif : une réponse LLM plus rapide ou davantage de cœurs CPU n'accélère pas toujours l'agent, puisque la file d'attente réelle peut se trouver ailleurs.

Les auteurs proposent une admission d'outils consciente du CPU et une allocation des cœurs adaptée à la tâche. Le résumé rapporte une amélioration de latence d'environ 5,4 fois pour les tâches sensibles au CPU et une réduction moyenne d'environ 32 % avec plusieurs tâches, par rapport aux agents natifs évalués. Ces chiffres décrivent leur protocole et leurs tâches, pas une promesse pour un serveur aux outils et profils de concurrence différents.

L'instrumentation utile sépare le temps de génération, le temps d'outil, le temps d'attente réseau et le temps de file, puis mesure chaque classe de tâche sous plusieurs niveaux de concurrence. Une trace d'agent sans consommation CPU, I/O et mémoire ne suffit pas pour choisir une politique d'ordonnancement. L'étude caractérise un environnement donné ; le gestionnaire en ligne pour tâches hétérogènes et déploiements multi-agents est annoncé comme suite, non démontré. Le dossier systèmes, réseaux et edge prolonge ce versant infrastructure.

Identifier et découvrir des agents de confiance

Un agent capable d'appeler un outil n'est pas automatiquement capable de choisir un autre agent fiable. Dans un écosystème ouvert, il faut savoir qui publie une capacité, quelle interface est proposée et si l'identité découverte peut être vérifiée. « A Scalable Trust Discovery Architecture for the Internet of Agents » traite cette couche d'infrastructure, en partant du constat que les protocoles d'agents se concentrent souvent sur l'appel d'outils et la communication entre agents déjà connus, laissant l'enregistrement, la découverte orientée capacité et la confiance entre domaines moins structurés.

L'architecture propose un Agent Root chargé de la gouvernance des registres de confiance, un Agent Registry pour l'enregistrement et la publication des métadonnées, et un Agent Resolver pour la découverte distribuée et la résolution tenant compte de la confiance. Une identité composite est ancrée dans le suffixe du registre, ce qui rattache l'identifiant natif d'un agent à un espace de nommage vérifiable. Un mécanisme à deux certificats et plusieurs niveaux d'authentification couvre les connexions intra-domaine et inter-domaines.

Le prototype est évalué sur l'enregistrement et la résolution d'agents. Le résumé rapporte une latence moyenne de 58 ms pour l'enregistrement et de 25 ms pour la découverte, avec plus de 19 000 demandes d'enregistrement par seconde et plus de 29 000 demandes de découverte par seconde. Ces valeurs montrent une faisabilité de service dans le cadre testé ; elles ne prouvent ni la qualité des fiches de capacité, ni la résistance à un registre compromis, ni la pertinence sémantique de la découverte.

Trois questions restent séparables pour une plateforme : qui publie, que sait faire l'agent, et peut-on accepter son résultat dans ce contexte. Cette séparation évite de traiter un certificat comme une preuve de compétence métier. Le fulltext disponible est une extraction PDF courte, qui n'expose pas l'ensemble des expériences.

Ce qui se recoupe entre ces travaux

Le recoupement le plus net est négatif. Quatre papiers, sur des couches différentes, concluent qu'augmenter une quantité ne suffit pas. SAIGE observe que plus d'agents ou plus de profondeur de récursion n'améliore pas systématiquement le résultat. « Not All AI Agents Are Equal » montre qu'une réponse LLM plus rapide ou plus de cœurs CPU n'accélère pas toujours l'agent. ODA montre qu'une lecture complète de l'historique à chaque token n'est pas nécessaire pour conserver l'essentiel de la performance. L'étude sur les harnais isole le cas le plus clair : à longueur de contexte égale, un plan écrit pour la tâche vaut mieux qu'un texte de politique mélangé, ce qui signifie que le volume de contexte n'est pas l'information. Le facteur limitant n'est jamais la ressource ajoutée, c'est la structure de la tâche ou celle de l'information.

Deuxième recoupement, sur la mémoire. SkillAA et LearnActCoder partent du même problème, à des échelles opposées, et aboutissent à la même exigence : une leçon doit être attachée à un objet précis avant d'être réutilisée. SkillAA route la réparation vers le nœud de graphe jugé responsable et autorise explicitement l'option de ne rien modifier faute de preuve. LearnActCoder dirige les leçons de faux négatifs vers un rôle orienté rappel et celles de faux positifs vers un rôle orienté précision. Aucun des deux ne réentraîne le modèle. Les deux montrent que la forme du souvenir produit l'effet, pas son volume. Le résultat MIMIC-IV est le plus instructif à cet égard : la précision ICD-10 gagne 4,2 points, le rappel perd 3,1 points, le F1 reste statistiquement inchangé. Une mémoire déplace parfois un point de fonctionnement sans améliorer la performance globale, et seule une mesure séparée des deux côtés le révèle.

Troisième recoupement, la séparation entre produire et autoriser. L'architecture multidomaine impose une approbation humaine pour toute recommandation touchant un système opérationnel. L'étude sur les harnais mesure un vérificateur en lecture seule qui rejette 61 % des épisodes invalides au prix de 17 % d'épisodes corrects retenus. L'architecture de découverte sépare le certificat d'identité de la preuve de compétence métier. SkillAA soumet chaque édition à deux gates et à un rollback. Quatre travaux, quatre domaines, un même principe : l'agent ne doit pas être seul juge de ce qui passe.

Ce qui reste ouvert tient surtout à la généralisation. Les chiffres cités proviennent chacun d'un protocole donné, et les sections de limites le disent toutes. Deux propositions, l'architecture multidomaine et l'architecture de découverte, sont conceptuelles : la première ne rapporte aucune évaluation, la seconde mesure un prototype de service sans valider la pertinence sémantique de ce qu'il retourne. Rien dans ces huit travaux ne permet de dimensionner un système agentique a priori. En revanche, ils indiquent quoi mesurer : les dépendances avant de paralléliser, le temps par classe de ressource, la portée de lecture et les rappels, le point de fonctionnement précision/rappel de chaque mise à jour mémoire, et le coût d'une acceptation erronée. Sur ce dernier point les travaux convergent avec la littérature d'évaluation, traitée dans le dossier évaluation des LLM et incertitude, et avec la question du partage du contrôle, abordée dans le dossier agents et interaction humaine.

Sources

arXiv:2609.20474v1 — How Do Agent Harnesses Create Value? Planning Information and Release Control in Stateful LLM Agents
arXiv:2609.19759v1 — Rethinking Multi-Agent Collaboration: When More Is Less
arXiv:2609.20080v1 — A Proposal for an Agentic AI Architecture to Support Multi-Domain Decision-Making in the Brazilian Armed Forces
arXiv:2609.20455v1 — SkillAA: Attribution-Guided Skill-Graph Updating with Targeted Validation and Rollback
arXiv:2609.19721v1 — LearnActCoder: Role-Aware Error Memory for Adaptive Clinical Coding Agents
arXiv:2609.20734v1 — On-Demand Attention: Language Models Know When to Recall
arXiv:2609.19947v1 — Not All AI Agents Are Equal
arXiv:2609.20095v1 — A Scalable Trust Discovery Architecture for the Internet of Agents