Transfert Multi-Agents : Transmission de Contexte entre Sous-Agents

L’agent de recherche a trouvé le compte du client, confirmé le plan et extrait les quatre dernières factures. Il transmet ensuite le dossier à l’agent de facturation avec un résumé : « Le client souhaite un remboursement. » Sans l’ID du compte, le plan ni les factures, l’agent de facturation recommence par demander l’ID.

Essayez Apidog dès aujourd’hui

C’est un échec de transmission d’état : des appels API sont dupliqués et le second agent prend des décisions avec moins d’informations que le premier. La perte d’état est d’ailleurs un mode de défaillance majeur des agents en production, comme l’explique ce guide sur la fiabilité des agents IA en production.

Ce guide explique quoi transmettre, comment le structurer, comment tester la limite entre agents et pourquoi il vaut mieux transmettre des références que des charges utiles.

Ce qui doit franchir la limite

Ne copiez pas toute la conversation : un transcript long enterre les faits importants et gaspille le budget de contexte. Transmettez plutôt quatre catégories.

1. Identifiants : ID de compte, commande, tâche, ticket. Ils sont petits, stables et permettent au récepteur de relire les données à la source.
2. Décisions prises : par exemple, « remboursement éligible selon la politique 3 ». Le récepteur ne doit pas refaire une décision validée.
3. Contraintes : budgets, approbations, actions déjà effectuées. Elles évitent les doubles facturations et demandes d’approbation répétées.
4. Questions ouvertes : ce que le premier agent n’a pas pu résoudre. Les expliciter empêche les suppositions silencieuses.

Ne transmettez pas les réponses API brutes, le raisonnement interne ou toute donnée que le récepteur peut récupérer en un appel.

Trois stratégies de transmission

1. Transmettre toute la conversation

C’est acceptable pour deux agents et une tâche courte. Dès que le transcript s’allonge, le récepteur dépense son contexte à lire l’historique et perd les détails enfouis au milieu. Garder les réponses d’outils hors de la fenêtre de contexte est donc essentiel : voir ce guide sur les réponses d’outils et la fenêtre de contexte.

2. Transmettre un résumé

C’est simple, mais lossy. Les modèles privilégient le récit :

Le client est abonné depuis deux ans et est frustré.

Alors que le récepteur a besoin de données vérifiables :

Compte 8812, plan Pro, quatre factures, remboursement approuvé pour inv_44.

3. Transmettre un objet structuré

C’est l’option robuste. Le premier agent remplit un schéma ; le second lit des champs, pas seulement de la prose.

{
  "task_id": "task_2026_08_26_0031",
  "from_agent": "research",
  "to_agent": "billing",
  "entities": {
    "customer_id": "cus_8812",
    "invoice_ids": ["inv_41", "inv_42", "inv_43", "inv_44"],
    "subscription_id": "sub_119"
  },
  "decisions": [
    {
      "decision": "refund_eligible",
      "value": true,
      "basis": "politique 3.2, facturé deux fois en un cycle"
    }
  ],
  "constraints": {
    "max_refund_cents": 4900,
    "human_approval_granted": false,
    "actions_taken": ["read_invoices"]
  },
  "open_questions": [
    "Le client n'a pas confirmé quelle facture rembourser"
  ],
  "summary": "Le client cus_8812 a été doublement facturé en août. Le remboursement d'une facture est approuvé selon la politique 3.2, jusqu'à 4900 cents. En attente du choix de facture du client."
}

Conservez un champ summary pour les nuances, mais ne l’utilisez pas à la place des champs structurés. Validez l’objet au moment du transfert : si customer_id est absent, échouez immédiatement.

Transmettez des références, pas des charges utiles

Le transfert le plus fiable contient surtout des identifiants. L’agent récepteur récupère ensuite les données nécessaires via la même API.

Cette approche :

• garde l’état à jour ;
• réduit le transfert à quelques centaines d’octets ;
• améliore l’audit, car chaque lecture devient un appel API traçable.

Elle exige que chaque agent dispose des permissions adaptées. Donnez à chaque agent des clés distinctes et limitées à ses actions : un agent de recherche ne doit pas pouvoir émettre un remboursement. Consultez ce guide sur les clés API à moindre privilège pour les agents IA.

Si une nouvelle lecture est lente ou coûteuse, mettez l’enregistrement en cache dans l’orchestrateur et transmettez une clé de cache. Le récepteur doit toujours demander explicitement les données.

Les défaillances fréquentes

Identifiant omis

Le résumé dit « le client » sans donner d’ID. Le second agent recherche par nom, trouve deux correspondances et choisit la mauvaise.

Prévention : rendez les identifiants d’entité obligatoires dans le schéma.

Action répétée

Le premier agent a déjà envoyé l’e-mail ; le transfert ne le précise pas ; le second l’envoie à nouveau.

Prévention : stockez actions_taken, vérifiez-le avant chaque écriture et utilisez des clés d’idempotence. Voir l’idempotence pour les agents IA.

Approbation perdue

Un humain approuve un remboursement pendant l’exécution du premier agent. Le second agent, ignorant cette approbation, la redemande.

Prévention : transportez les approbations comme contraintes explicites liées à la tâche, pas à un agent.

Invention confiante

Le récepteur a besoin d’une valeur absente du transfert et l’invente au lieu de demander.

Prévention : maintenez open_questions et imposez une règle : si un identifiant requis manque, arrêter et demander une clarification.

Les boucles amplifient ces problèmes. Lorsque A transmet à B puis B à A, l’état se dégrade à chaque passage. Limitez les sauts et conservez le même objet de tâche durant toute l’exécution.

Testez la limite entre agents

Les transferts sont des intégrations : testez-les comme telles.

1. Testez l’objet de transfert. Exécutez le premier agent avec un scénario fixe et vérifiez les IDs, décisions et actions générés.
2. Testez le récepteur isolément. Fournissez un objet valide, puis un objet invalide sans customer_id. Vérifiez que l’agent demande une clarification au lieu de deviner.
3. Exécutez les deux agents contre des mocks. Ne testez pas les remboursements sur des systèmes réels. Utilisez des endpoints simulés, comme décrit dans ce guide sur les agents IA testés avec des APIs mockées.
4. Journalisez chaque transfert. Enregistrez l’objet complet avec l’ID de tâche pour identifier quel agent a perdu une information. Voir le traçage des appels d’outils d’agent IA.

Même si l’agent est non déterministe, l’objet structuré produit peut être testé de manière déterministe. Consultez également ce guide sur le test des agents non déterministes.

Ce que font les frameworks

Les frameworks fournissent souvent une primitive de transfert, mais ne définissent pas les faits essentiels à votre place.

• Le SDK OpenAI Agents modélise le transfert comme un outil appelé par le modèle. C’est pratique, mais la décision de transférer reste non déterministe : validez systématiquement la sortie.
• Le guide multi-agent de LangGraph utilise un état de graphe explicite lu et écrit par chaque nœud. Cela correspond bien à un objet de transfert structuré.
• L’article d’Anthropic sur la construction d’un système de recherche multi-agent détaille les instructions nécessaires pour rendre les sous-agents réellement autonomes.

Le point commun : les frameworks déplacent un état, mais vous devez décider quels champs sont obligatoires.

Gardez l’objet de tâche hors de la conversation

Stockez l’état durablement, indexé par task_id. Chaque agent lit et met à jour le même objet au lieu de se transmettre des messages contenant l’état.

La conversation est un mauvais stockage : elle peut être résumée, tronquée ou réécrite. Une base de données, elle, conserve les champs critiques.

Le flux recommandé :

1. L’agent charge l’objet de tâche au début de son tour.
2. Après chaque action, il ajoute l’action à actions_taken et enregistre.
3. Lors du transfert, il passe uniquement task_id.
4. Le récepteur charge le même objet.

Vous obtenez aussi un point de reprise : si l’étape 4 échoue, les résultats des trois premières étapes restent disponibles.

Exemple de plateforme orientée tâche

Certaines plateformes modélisent déjà cet état durable. Sharkly est un système de gestion du travail pour personnes et agents : une tâche contient l’objectif, le statut, la personne responsable, l’agent ou l’équipe assignée, les commentaires, l’état d’exécution et le résultat.

Une équipe associe un agent leader à d’autres agents et personnes. Les spécialistes travaillent alors sur une même tâche plutôt que de se transmettre des invites successives. Découvrez Sharkly et sa documentation.

Liste de contrôle

• [ ] Un schéma de transfert existe et est validé à la limite.
• [ ] Les identifiants d’entité sont obligatoires.
• [ ] Les décisions contiennent leur justification.
• [ ] Les actions effectuées sont enregistrées et vérifiées avant toute écriture.
• [ ] Les approbations et budgets appartiennent à la tâche.
• [ ] Les questions ouvertes sont explicites.
• [ ] Les données sont transmises par référence lorsque la récupération est peu coûteuse.
• [ ] Le nombre de sauts est plafonné.
• [ ] L’objet de tâche original survit à chaque saut.
• [ ] Chaque transfert est journalisé avec l’ID de tâche.
• [ ] Les tests CI utilisent des mocks et couvrent des transferts volontairement incomplets.

La plupart des échecs multi-agents ne viennent pas d’un mauvais raisonnement : un fait connu par un agent n’a simplement pas atteint le suivant. Traitez le transfert comme une interface avec un schéma, des validations et des tests.

Téléchargez Apidog pour maintenir les mocks et les tests de limite à côté de l’API utilisée par tous vos agents.

Foire aux questions

Un transfert structuré est-il utile pour seulement deux agents ?

Pour deux agents sur une tâche courte, transmettre la conversation peut suffire. Utilisez un objet structuré dès qu’il y a trois agents ou plus, une tâche longue, ou une limite de processus ou d’exécution.

Le modèle doit-il écrire l’objet de transfert ?

Utilisez le code lorsque c’est possible. L’orchestrateur doit renseigner les identifiants, les actions effectuées et les approbations à partir des événements réels. Le modèle peut rédiger le summary et les questions ouvertes.

Comment éviter la dégradation du contexte dans une boucle ?

Conservez un seul objet de tâche et mettez-le à jour. Ne le régénérez pas à chaque transfert. Limitez aussi le nombre de sauts : si une tâche en exige trop, sa décomposition est probablement incorrecte.

Que faire avec les frameworks ayant un transfert intégré ?

Utilisez-les, mais vérifiez ce qu’ils transmettent réellement. Beaucoup ne transmettent que l’historique des messages. Ajoutez une charge utile structurée pour garantir que les identifiants, décisions et contraintes survivent.

Les sous-agents ont-ils besoin de clés API distinctes ?

Oui. Chaque clé doit être limitée aux actions de l’agent concerné. Partager une clé puissante augmente le rayon d’explosion et rend l’audit plus difficile.

Que doit contenir le champ summary ?

Quelques phrases sur l’intention et les nuances qui ne rentrent pas dans le schéma. Les IDs, montants et statuts appartiennent aux champs structurés, où ils peuvent être validés.