Un système multi-agents (Multi-Agent System, MAS) est une organisation dans laquelle plusieurs agents IA se répartissent les rôles et travaillent en parallèle pour mener à bien une seule tâche. Un agent coordinateur découpe le travail, des agents exécutants (sous-agents) cherchent ou rédigent chacun dans leur propre contexte, puis le coordinateur assemble les résultats.
Mais ajouter des agents ne rend pas le système plus intelligent à lui seul. Dans une expérience menée par Google Research et d’autres sur six types de tâches, les configurations multi-agents ont fait jusqu’à environ 81 % mieux qu’un agent seul sur un travail découpable, et jusqu’à 70 % moins bien sur un travail qui doit avancer étape par étape. Cet article présente la définition et les cinq schémas, puis s’appuie sur cette expérience et sur les documents publiés par Anthropic, Cognition et d’autres pour vous permettre de juger pour quels travaux l’approche aide et pour lesquels elle nuit.
Multi-agents = une équipe qui se répartit les rôles et travaille en parallèle
— au lieu de tout confier à une seule IA, une petite équipe de spécialistes se partage le travail
Chacun dispose de sa propre fenêtre de contexte et tous travaillent en parallèle.
Le coordinateur vérifie les résultats avant de les assembler : dans les expériences, la présence ou non de ce coordinateur vérificateur a beaucoup changé la propagation des erreurs.
Table des matières
- 1. Qu’est-ce qu’un système multi-agents ?
- 2. Pourquoi faire coopérer plusieurs IA ?
- 3. Les cinq schémas
- 4. Ce que montrent les expériences : où cela aide et où cela nuit
- 5. Comment les produits réels l’utilisent
- 6. Coût : environ 15 fois les tokens d’un chat
- 7. Grille de décision : faut-il l’utiliser ?
- 8. Points clés de conception et types d’échec courants
- 9. Comment chaque schéma s’écrit dans les principaux SDK
- Résumé
- FAQ
1. Qu’est-ce qu’un système multi-agents ?
Un système multi-agents (Multi-Agent System, MAS) est une organisation dans laquelle plusieurs agents IA coopèrent pour résoudre une tâche. Chaque agent a ses propres instructions (prompt), ses outils et son contexte, et l’objectif global est atteint grâce à l’échange des résultats.
La brique de base, un agent seul, fait tourner tout seul la boucle « réfléchir → utiliser un outil → regarder le résultat », comme expliqué dans Qu’est-ce qu’un agent IA. La façon la plus juste de se représenter un système multi-agents est cette boucle, plus la répartition des rôles et le parallélisme.
Ce qui le distingue d’un agent seul
| Aspect | Agent seul | Multi-agents |
|---|---|---|
| Structure | Une IA fait tourner la boucle | Plusieurs IA travaillent ensemble |
| Contexte | Tout tient dans une seule fenêtre | Séparé par rôle (les informations sans rapport ne se mélangent pas) |
| Parallélisme | Surtout une étape après l’autre | Les exécutants peuvent avancer en même temps |
| Propagation des erreurs | Ses propres erreurs s’accumulent | Sans vérificateur, l’erreur d’un exécutant passe directement dans le résultat final |
| Coût | Plus faible (environ 4 fois un chat) | Plus élevé (environ 15 fois un chat) |
| Points forts | Travail séquentiel où chaque étape dépend de la précédente | Recherche, comparaison et vérification découpables en parties indépendantes |
Les multiplicateurs de tokens sont les chiffres publiés par Anthropic pour sa propre fonction de recherche (How we built our multi-agent research system, 13 juin 2025). Détails en section 6.
2. Pourquoi faire coopérer plusieurs IA ?
Le point de départ : « si un agent suffit, gardez-en un ». Un système multi-agents devient nécessaire quand vous heurtez trois murs qu’un agent seul franchit mal, du fait même de sa structure.
Trois murs difficiles à franchir pour un agent seul
Exemple d’effet : Anthropic indique que, pour la fonction Research de Claude, une configuration avec Claude Opus 4 comme coordinateur et Claude Sonnet 4 comme exécutants a obtenu un résultat supérieur de 90,2 % à celui d’Opus 4 travaillant seul sur son évaluation interne de recherche (même source). Le même article précise que la quantité de tokens utilisés expliquait à elle seule 80 % de la variance des performances (sur BrowseComp, une évaluation de recherche). Autrement dit, l’essentiel de la force d’un système multi-agents vient du fait de faire tourner des contextes séparés côte à côte pour lire plus que ce qui tient dans un seul agent.
3. Les cinq schémas
Les systèmes multi-agents prennent quelques formes typiques. Chaque produit les nomme autrement, mais elles se ramènent pour l’essentiel aux cinq suivantes. Le cas échéant, la catégorie correspondante de l’expérience de la section 4 (indépendante, centralisée, décentralisée, hybride) est aussi indiquée.
3-1. Orchestrateur–exécutants (le plus répandu)
Un coordinateur (orchestrateur) découpe le travail et le confie à plusieurs exécutants (sous-agents). Chaque exécutant tourne dans un contexte séparé et rend son résultat au coordinateur. Dans les termes de l’expérience, c’est la configuration centralisée. La fonction de recherche d’Anthropic, les sous-agents de Claude Code et la manière d’« appeler un agent comme un outil » de l’OpenAI Agents SDK (Agent.as_tool()) suivent ce schéma.
3-2. Passage de relais (handoff)
Les agents se passent la main sur la conversation en disant en substance : « à partir d’ici, c’est toi ». Dans la documentation de l’OpenAI Agents SDK, le spécialiste qui reçoit le relais devient l’agent actif pour le reste du tour. Cela convient aux guichets, par exemple pour orienter une demande de l’accueil vers la facturation ou le support technique. Swarm, le prédécesseur expérimental de ce SDK, indique désormais dans son dépôt qu’il a été remplacé par l’Agents SDK ; les nouveaux projets doivent donc utiliser l’Agents SDK.
3-3. Hiérarchie (une équipe d’équipes)
Un arbre où des coordinateurs intermédiaires se placent sous le coordinateur principal, avec des exécutants en dessous. Dans Claude Code, les sous-agents peuvent lancer leurs propres sous-agents jusqu’à trois niveaux par défaut (documentation officielle), et Cursor a lui aussi permis, avec la version 2.5 de février 2026, aux exécutants de lancer des exécutants. Chaque niveau supplémentaire ajoute des tokens et de l’attente : fixez une limite de profondeur.
3-4. Pair à pair (débat et consensus)
Pas de coordinateur : plusieurs agents donnent leur avis sur un pied d’égalité et recommencent jusqu’à s’accorder. Dans les termes de l’expérience, c’est la configuration décentralisée. Les travaux sur le Multi-Agent Debate font état de gains en exactitude factuelle et en raisonnement. Ce schéma réussit souvent sur les travaux qui exigent de confronter plusieurs points de vue, comme la recherche sur le Web (section 4).
3-5. Pipeline (un ordre fixe)
Chaque agent intervient dans un ordre fixe, par exemple « recherche → structuration → vérification → restitution ». Comme c’est un programme, et non l’IA, qui décide de l’agent suivant, les résultats sont stables et il est facile de voir où quelque chose a échoué. L’OpenAI Agents SDK présente le « chaînage » (la sortie de l’un devient l’entrée du suivant) et les « boucles d’évaluation » (alterner un agent producteur et un agent évaluateur) comme des schémas construits en code.
Les cinq schémas en un coup d’œil
4. Ce que montrent les expériences : où cela aide et où cela nuit
Le schéma gagnant s’inverse selon la nature du travail. L’article qui a chiffré ce phénomène est Towards a Science of Scaling Agent Systems, de chercheurs de Google Research, de Google DeepMind et d’autres institutions (dernière version d’avril 2026). Avec trois familles de modèles — GPT, Gemini et Claude —, il compare cinq configurations (un agent seul et quatre configurations multi-agents) sur six types de tâches et 260 combinaisons (présenté sur le blog de Google Research en janvier 2026 ; les 180 configurations citées sur le blog correspondent à la première version).
Source : section 4.2 de l’article. Pour la correction de code et la planification, toutes les configurations multi-agents testées ont fait moins bien qu’un agent seul ; nous indiquons celle qui a le moins perdu (correction de code de −2,1 % à −14,9 %, planification de −39,1 % à −70,0 %).
Trois enseignements ressortent.
- Le gain n’est net que sur un travail découpable : en analyse financière, chiffre d’affaires, coûts et marchés peuvent être étudiés séparément puis réunis à la fin, si bien que la configuration centralisée a dépassé un agent seul d’environ 81 %.
- Sur un travail qui dépend de l’ordre, l’effet s’inverse : dans la tâche de planification, où chaque coup détermine le suivant, toutes les configurations ont fait moins bien qu’un agent seul. Découper le travail fait diverger les hypothèses des exécutants et consomme des efforts en coordination.
- La correction de code ne s’est pas améliorée non plus : Anthropic écrit aussi que la plupart des tâches de programmation comportent moins de parties réellement parallélisables que la recherche (son article), ce qui concorde avec ce résultat.
Un coordinateur qui vérifie freine la propagation des erreurs
Le même article a mesuré, pour chaque configuration, à quel point les erreurs des exécutants se propagent jusqu’au résultat final (en multiple, avec un agent seul = 1).
Indépendante (ni échange ni vérification)
17,2×
Les résultats sont simplement juxtaposés, donc les erreurs restent
Décentralisée (débat entre égaux)
7,8×
Le débat corrige certaines erreurs, mais personne n’est chargé de vérifier
Hybride
5,1×
Coordinateur et un peu d’échange entre exécutants
Centralisée (le coordinateur vérifie)
4,4×
Le coordinateur vérifie les résultats avant de les assembler
Source : tableau 5 de l’article (Error Amp). Dans le même tableau, le nombre de tours par tâche était en moyenne de 7,2 pour un agent seul, contre 27,7 en configuration centralisée et 44,3 en hybride.
« Si un agent seul résout déjà 45 % ou plus, ajouter des agents tend à devenir contre-productif. » L’article rapporte que, sur les tâches où la précision d’un agent seul dépasse déjà environ 45 %, ajouter des agents tend à faire baisser le score. L’expérience conforte cet ordre : mesurer d’abord avec un agent, et ne décider d’en ajouter qu’après avoir vu ce chiffre.
5. Comment les produits réels l’utilisent
La fonction de recherche d’Anthropic : le nombre d’exécutants suit la difficulté
Research de Claude est un cas d’école du schéma orchestrateur–exécutants : le coordinateur découpe la question, les exécutants cherchent en parallèle et le coordinateur assemble les résultats. Le plus utile dans la conception publiée, c’est que le prompt précise combien d’exécutants employer selon la difficulté de la question (son article).
| Type de question | Nombre d’exécutants | Appels d’outils |
|---|---|---|
| Vérifier un fait simple | 1 (le coordinateur seul) | 3 à 10 |
| Comparaison directe | 2 à 4 | 10 à 15 chacun |
| Recherche complexe | Parfois plus de 10 | Chaque exécutant a une responsabilité clairement délimitée |
Anthropic raconte qu’avant ces règles, les premières versions commettaient des erreurs comme lancer 50 exécutants pour une question simple. Si vous construisez le vôtre, le plus rapide est de reprendre ce tableau tel quel dans votre prompt comme règle de dimensionnement. Par ailleurs, le passage à des appels en parallèle de la recherche et des autres outils a réduit le temps de recherche des questions complexes jusqu’à 90 %.
Les sous-agents de Claude Code et de Codex
Dans Claude Code, vous pouvez confier la recherche, les relectures et des tâches similaires à des sous-agents. Chaque sous-agent travaille dans son propre contexte et ne renvoie qu’un résumé à l’agent principal, si bien que le contexte principal ne se remplit pas. Par défaut, jusqu’à 20 peuvent tourner en même temps, avec jusqu’à trois niveaux d’imbrication. La différence avec les « équipes d’agents », où les exécutants se parlent en cours de route, est expliquée dans Sous-agents et équipes d’agents dans Claude Code, et la façon de demander du travail en parallèle, comparée à Codex, dans Sous-agents en parallèle dans Codex et Claude Code.
Devin (Cognition) : de « n’en construisez pas » à « coordonnez »
En juin 2025, Cognition a publié « Don’t Build Multi-Agents », soutenant que des exécutants parallèles qui ignorent les décisions des autres produisent des résultats contradictoires. Ses deux principes : « partager le contexte, et partager tout le déroulé de l’agent, pas seulement des messages isolés » et « les actions portent des décisions implicites, et des décisions contradictoires donnent de mauvais résultats ».
En mars 2026, la même entreprise a lancé une fonction où Devin découpe une grosse tâche et la délègue à plusieurs Devin travaillant en parallèle, chacun dans sa propre machine virtuelle. Le Devin principal suit l’avancement, résout les conflits et rassemble les résultats. Elle n’a donc pas renoncé au parallélisme, mais a opté pour une conception où l’agent principal prend en charge les divergences entre exécutants — ce qui rejoint la section 4 sur le coordinateur qui vérifie.
Cursor : avancer sans attendre les exécutants
Avec la version 2.5 (17 février 2026), Cursor a rendu les sous-agents asynchrones afin que l’agent principal continue à travailler sans attendre. Les exécutants peuvent aussi lancer leurs propres exécutants. Anthropic écrit également que l’exécution synchrone, où le coordinateur attend la fin des exécutants, crée des goulets d’étranglement ; ne pas faire attendre l’agent principal est donc devenu un problème commun à tous les éditeurs.
6. Coût : environ 15 fois les tokens d’un chat
Anthropic écrit que les agents consomment environ 4 fois plus de tokens qu’un chat, et les systèmes multi-agents environ 15 fois plus (son article). Appliqué à votre cas, le calcul donne ceci.
Exemple d’estimation (multiplicateurs issus de la fonction de recherche d’Anthropic ; ils varient selon le travail)
Une question qui coûte 10 000 tokens en chat → environ 40 000 avec un agent et environ 150 000 tokens avec un système multi-agents.
À 100 demandes par jour : chat 1 million, agent seul 4 millions, multi-agents 15 millions de tokens. Multipliez par le prix au token de la grille officielle du modèle que vous utilisez.
Les tokens ne sont pas seuls à augmenter
Séparez les limites qui arrêtent l’exécution des objectifs indicatifs
Quand des exécutants lancent des exécutants et que quelque chose part en boucle, la facture s’envole. Avec Claude, il existe deux sortes de limites qui fonctionnent différemment.
| Limite | Où la régler | Arrête-t-elle l’exécution ? |
|---|---|---|
| Plafond de dépense | max_budget_usd dans le Claude Agent SDK (maxBudgetUsd en TypeScript) | Oui (aucun nouvel exécutant n’est lancé et la requête prend fin) |
| Profondeur d’imbrication | Variable d’environnement CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH (3 par défaut, 1 pour aucune imbrication) | Oui (les exécutants du dernier niveau font le travail eux-mêmes) |
| Exécutants simultanés | Variable d’environnement CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS (20 par défaut) | Oui (aucun exécutant n’est lancé au-delà de la limite) |
| Budget de tâche | task_budget dans l’API Claude (bêta, 20 000 tokens minimum) | Non (un objectif sur lequel le modèle règle son rythme) |
Sources : Subagents in the Agent SDK et Task budgets (consultés le 12 novembre 2026). Les trois limites qui arrêtent l’exécution valent pour TypeScript SDK v0.3.219 et Python SDK v0.2.127 ou versions ultérieures ; dans les versions antérieures, certaines manquent ou ont d’autres valeurs par défaut. La documentation décrit le budget de tâche comme indicatif et non contraignant : combinez-le avec un plafond de dépense ou max_tokens quand l’exécution doit s’arrêter à coup sûr.
7. Grille de décision : faut-il l’utiliser ?
En réunissant tout ce qui précède, cinq questions tranchent la plupart des décisions. Répondez-y de haut en bas ; si l’une d’elles tombe du côté « agent seul », commencez avec un seul agent.
| Question | En faveur du multi-agents | En faveur d’un agent seul | Fondement |
|---|---|---|---|
| Le travail se découpe-t-il en parties indépendantes ? | Oui (par entreprise, par document, par angle) | Chaque étape dépend du résultat précédent | Analyse financière +80,8 %, planification de −39,1 % à −70,0 % |
| Que vaut déjà un agent seul ? | Précision faible avec un agent | Un agent résout déjà environ 45 % ou plus | L’article de Google Research et d’autres |
| Les exécutants doivent-ils partager le même contexte ? | Les informations propres à chacun suffisent | Les résultats se contredisent si tous ne voient pas le même contexte (la plupart des travaux de code) | Anthropic, Cognition |
| Tout tient-il dans un seul contexte ? | Trop de matière, le contexte d’un agent déborde | Tient dans le contexte d’un agent | La quantité de tokens expliquait 80 % de la variance des performances |
| Le résultat vaut-il 15 fois les tokens ? | Forte valeur par demande (rapports de recherche, d’audit et de comparaison) | Traitements routiniers en masse, guichets qui exigent une réponse immédiate | Les ~15 fois d’Anthropic |
Anthropic conseille elle aussi, dans son guide de conception d’agents, de chercher la solution la plus simple possible et de n’ajouter de la complexité que si nécessaire. Les premières étapes et des exemples de code minimaux se trouvent dans Comment construire un système multi-agents, et la façon de créer un premier agent seul dans Comment créer un agent IA.
8. Points clés de conception et types d’échec courants
① Donnez à chaque exécutant son objectif, son format de sortie, ses outils et ses limites
Anthropic écrit qu’avec des consignes vagues, les exécutants comprennent mal la tâche, refont les mêmes recherches que les autres ou passent à côté d’informations nécessaires. Indiquez à chaque exécutant (1) l’objectif, (2) le format à rendre, (3) les outils et sources autorisés et (4) les limites de la tâche. Un sous-agent du Claude Agent SDK ne reçoit pas la conversation de l’agent principal ; seul le prompt avec lequel vous l’appelez lui est transmis (documentation officielle) : écrivez donc dans ce prompt les chemins de fichiers et les décisions déjà prises.
② Précisez jusqu’où creuser
Les exécutants décident mal par eux-mêmes jusqu’où chercher. Écrivez des règles de dimensionnement comme le tableau de la section 5, et réglez aussi la profondeur de raisonnement. L’effort de Claude peut être fixé par exécutant, et les définitions d’agent du Agent SDK acceptent les valeurs de low à max. Garder légers les exécutants simples et approfondis ceux de vérification contient les coûts.
③ Faites de la vérification une partie du travail du coordinateur
Comme l’a montré la section 4, la configuration centralisée, où le coordinateur vérifie les résultats avant de les assembler, a beaucoup moins propagé les erreurs que la configuration indépendante sans vérification (4,4× contre 17,2×). Ajoutez aux consignes du coordinateur une étape consistant à chercher les contradictions entre les résultats des exécutants et vérifier les éléments de preuve avant de les retenir.
④ Connaissez les types d’échec
Des chercheurs de l’université de Californie à Berkeley et d’autres institutions ont classé les échecs en 3 catégories et 14 types, à partir de plus de 1 600 traces d’exécution de sept systèmes multi-agents (Why Do Multi-Agent LLM Systems Fail?). C’est une liste de contrôle utile pour revoir une conception.
| Catégorie | Ce qui se passe | Remède |
|---|---|---|
| Problèmes de conception | Les agents ignorent les consignes de rôle ou de tâche, répètent les mêmes étapes ou ne savent pas quand s’arrêter | Écrire rôles, périmètre et conditions d’arrêt dans les prompts |
| Désalignement entre agents | Les hypothèses divergent, les informations nécessaires ne circulent pas, l’apport des autres agents est ignoré | Partager tout le déroulé ; le coordinateur arbitre les divergences |
| Vérification insuffisante | Arrêt prématuré, absence de vérification ou vérification superficielle | Désigner un vérificateur (le coordinateur ou un exécutant dédié) |
⑤ Mettez en place la journalisation dès le départ
Si vous ne voyez pas ce que fait un système multi-agents, vous ne pouvez pas le corriger. Enregistrez dès le premier jour les entrées et sorties de chaque exécutant, le temps passé, les tokens et les outils appelés. Pour l’évaluation, Anthropic indique avoir commencé avec une vingtaine de requêtes représentatives de l’usage réel, notées par une IA à l’aide d’une grille. Observer l’évolution d’un petit jeu de requêtes, plutôt que d’attendre un grand dispositif d’évaluation, est la voie pragmatique.
9. Comment chaque schéma s’écrit dans les principaux SDK
Le même schéma porte un nom différent dans chaque SDK. Pour choisir entre eux (vitesse de prototypage, maturité en production, consommation de tokens), voyez Comparatif des frameworks d’agents IA ; ici, nous indiquons seulement quel élément correspond à chaque schéma de la section 3.
| SDK | Orchestrateur–exécutants | Passage de relais / pipeline |
|---|---|---|
| Claude Agent SDK | Les exécutants se définissent dans agents et s’appellent avec l’outil Agent (anciennement Task) | Pas d’élément dédié ; le pipeline consiste à appeler les agents dans l’ordre depuis votre propre code |
| OpenAI Agents SDK | Les exécutants s’appellent comme des outils avec Agent.as_tool() | La main se passe avec les handoffs ; chaînage et exécution parallèle se construisent en code |
| LangGraph | Branchement d’un nœud coordinateur vers des nœuds exécutants | Ordre, branches et boucles s’écrivent sous forme de graphe de nœuds et d’arêtes |
| Strands Agents (AWS) | Les exécutants s’appellent comme des outils avec Agents as Tools | Avec Swarm, les exécutants se passent le travail ; avec Graph ou Workflow, on fixe l’ordre |
| Microsoft Agent Framework | Fournit des schémas d’orchestration multi-agents comme éléments prêts à l’emploi | L’ordre se fixe sous forme de workflow |
Microsoft a archivé le dépôt d’AutoGen et ne fournit plus de correctifs de bugs ni de sécurité (consulté le 12 novembre 2026). Pour les nouveaux projets, il recommande son successeur, Microsoft Agent Framework. Des exemples de code minimaux pour chaque SDK figurent dans Comment construire un système multi-agents.
Résumé
- Un système multi-agents répartit les rôles entre plusieurs IA qui travaillent en parallèle pour mener à bien une tâche. Il franchit les murs d’un agent seul : contexte qui déborde, absence de parallélisme, et le fait d’être à la fois celui qui fait et celui qui vérifie.
- Les cinq schémas sont orchestrateur–exécutants, passage de relais, hiérarchie, pair à pair et pipeline. Le plus répandu est orchestrateur–exécutants.
- L’intérêt dépend du travail. Sur une analyse financière découpable, il a dépassé un agent seul de +80,8 % ; sur une planification qui dépend de l’ordre, il a perdu de 39,1 % à 70,0 % ; la correction de code ne s’est pas améliorée non plus.
- Avec un coordinateur qui vérifie, la propagation des erreurs est passée de 17,2× (indépendante) à 4,4×.
- Les tokens montent à environ 15 fois ceux d’un chat (environ 4 fois pour un agent seul). Réglez dépense, profondeur et simultanéité avec des limites qui arrêtent réellement l’exécution.
- Ordre de décision : construisez et mesurez d’abord avec un agent. Ne confiez à des exécutants que les parties découpables pour lesquelles un agent s’est révélé insuffisant.
FAQ
Q1. Un système multi-agents est-il toujours meilleur qu’un agent seul intelligent ?
Non. La fonction de recherche d’Anthropic a fait 90,2 % mieux qu’un agent seul, mais sur des recherches découpables en parties indépendantes. Dans l’expérience de Google Research et d’autres, toutes les configurations multi-agents ont fait moins bien qu’un agent seul sur la tâche de planification qui dépend de l’ordre. Tout dépend de la possibilité de découper le travail.
Q2. Le multi-agents aide-t-il pour la programmation ?
Faire écrire par plusieurs exécutants des morceaux d’une même correction aide rarement. Dans l’expérience, toutes les configurations multi-agents sont restées en dessous d’un agent seul en correction de code (SWE-bench Verified), de −2,1 % à −14,9 %. En revanche, confier à des exécutants des travaux indépendants comme la recherche, la relecture ou le lancement des tests pour garder libre le contexte principal est un usage typique des sous-agents de Claude Code.
Q3. Peut-on passer progressivement d’un agent seul au multi-agents ?
Oui. Construisez d’abord avec un agent et mesurez précision, tokens et temps ; quand vous voyez où le contexte déborde ou ce qui pourrait tourner en parallèle, confiez uniquement ces parties à des exécutants. Si vous concevez tout en multi-agents dès le départ, vous ne pourrez pas mesurer ce qui aide vraiment.
Q4. Existe-t-il un protocole de communication standard entre agents ?
Pour relier les agents aux outils et aux données, MCP (Model Context Protocol) est devenu le standard de fait. Né chez Anthropic, il a été confié en décembre 2025 à l'Agentic AI Foundation de la Linux Foundation et il est adopté par OpenAI, Microsoft, AWS et d'autres. Pour la communication entre agents, il existe A2A (Agent2Agent), lancé par Google et lui aussi transféré à la Linux Foundation. L'ACP (Agent Communication Protocol) d'IBM a rejoint A2A en août 2025.
Q5. Un budget de tâche suffit-il à éviter l’emballement des coûts ?
Pas à lui seul. Le budget de tâche de l’API Claude est un objectif sur lequel le modèle règle son rythme, et la documentation précise qu’il n’est pas contraignant. Pour arrêter une exécution à coup sûr, réglez le plafond de dépense du Agent SDK (max_budget_usd) ainsi que des limites de profondeur d’imbrication et d’exécutants simultanés (tableau de la section 6).
Q6. « Sous-agents » et « multi-agents », est-ce différent ?
Les sous-agents sont les exécutants du schéma orchestrateur–exécutants au sein d’un système multi-agents. Dans le Claude Agent SDK, l’agent principal reste unique et n’appelle des exécutants avec l’outil Agent que lorsque c’est nécessaire. Les configurations où les exécutants se parlent directement en cours de route (comme les équipes d’agents de Claude Code) se rapprochent davantage du schéma pair à pair ou hybride.
