Le bon modèle dépend de celui qui doit rester propriétaire de la décision, de la durée de la tâche et de la capacité du receveur à accepter ou refuser le mandat.
Un passage de relais fiable ne transmet pas seulement du contexte. Il transfère un mandat identifiable entre deux agents, avec un résultat attendu, un état de travail vérifiable, des preuves référencées, une autorité bornée et une règle explicite pour accepter, refuser ou rendre la tâche. Tant que le receveur n'a pas accepté ces éléments, l'agent émetteur, ou l'orchestrateur qui le gouverne, reste responsable de la suite.
Cette distinction devient décisive dès qu'une équipe autonome répartit un processus entre plusieurs spécialistes. Un agent de qualification peut préparer un dossier, un agent financier peut contrôler une anomalie et un agent de communication peut rédiger une réponse. Si chacun reçoit seulement un résumé de conversation, l'entreprise sait ce que les agents se sont dit, mais pas nécessairement qui porte la prochaine décision, sur quelles preuves elle repose ni quelle action demeure autorisée.
Un handoff transfère une responsabilité, pas une conversation
Dans un échange humain, la continuité paraît souvent implicite. Un collègue comprend qu'un dossier lui est confié parce qu'il connaît l'organisation, les rôles et les habitudes de l'équipe. Un système d'agents ne dispose pas de cette évidence organisationnelle. Il peut interpréter un historique, mais cet historique ne constitue ni une délégation formelle ni une preuve d'autorité.
La documentation de l'OpenAI Agents SDK matérialise le handoff comme un transfert de contrôle vers un agent spécialisé. Elle permet de définir un schéma d'entrée, une fonction exécutée au moment du relais et un filtre sur le contexte transmis. Le même SDK distingue ce modèle de l'agent utilisé comme outil : dans ce second cas, le coordinateur conserve la conversation et appelle un spécialiste pour une contribution bornée. Le premier choix de gouvernance consiste donc à décider si le spécialiste conseille le propriétaire actuel ou devient lui-même propriétaire de l'étape.
Ce choix ne doit pas être dicté uniquement par les capacités du modèle. Il dépend du droit de produire la prochaine décision métier. Un spécialiste peut être meilleur pour analyser un contrat sans pour autant être autorisé à engager l'entreprise ; un agent de support peut reprendre la relation avec un client, mais ne devrait pas hériter automatiquement d'un droit de remboursement. La compétence explique où demander de l'aide. L'autorité explique qui peut conclure l'étape.
Trois modèles de relais, trois propriétaires différents
Une architecture multi-agent recouvre plusieurs formes de collaboration. Les traiter comme des synonymes crée des zones d'ombre : la tâche semble avancer, alors que sa responsabilité change sans événement observable. La grille suivante permet de choisir à partir du fonctionnement attendu, pas du vocabulaire du framework.
| Critère de décision | Spécialiste appelé comme outil | Transfert de contrôle | Tâche durable ou file de travail |
|---|---|---|---|
| Propriétaire de la décision | Le coordinateur | Le receveur après acceptation | Le service qui possède l'état durable |
| Durée adaptée | Courte et synchrone | Limitée à une session ou un tour | Longue, intermittente ou asynchrone |
| Résultat attendu | Avis ou sortie bornée | Suite directe de l'interaction | Changement d'état et artefacts persistants |
| Contexte transmis | Entrée minimale structurée | Historique filtré et mandat | Identifiants, état, références et événements |
| Autorité | Reste chez le coordinateur | Doit être redéfinie pour le receveur | Attachée à l'étape et vérifiée à l'exécution |
| Échec du receveur | Le coordinateur reprend | Retour ou escalade explicite | Nouvelle tentative, file d'erreur ou propriétaire humain |
| Observation | Trace d'un appel spécialisé | Événement de transfert et agent actif | Cycle de vie, statut, horodatage et artefacts |
| Bon cas d'usage | Analyse, classement, synthèse | Routage vers un spécialiste responsable | Traitement nécessitant attente, reprise ou coordination externe |
L'appel comme outil convient lorsqu'un seul agent doit assembler la réponse finale ou appliquer une politique commune. Il réduit l'ambiguïté parce que le coordinateur reste comptable du résultat, même s'il exploite plusieurs expertises. Son défaut apparaît lorsque ce coordinateur devient un goulot d'étranglement, accumule trop de contexte ou prétend valider un domaine qu'il ne maîtrise pas.
Le transfert de contrôle convient quand le spécialiste doit poursuivre directement l'interaction avec ses propres instructions. Il rend la spécialisation plus nette, mais exige de rendre le changement de propriétaire visible. Pour les travaux qui dépassent une session, attendent une validation ou dépendent d'un autre système, une tâche durable est préférable : son état ne disparaît pas avec la conversation, et sa reprise ne dépend pas de la mémoire d'un modèle.
Le contrat de relais doit être accepté
Un handoff robuste peut être représenté comme une enveloppe contractuelle. Elle ne cherche pas à décrire tout ce qui s'est passé. Elle rassemble ce dont le receveur a besoin pour décider s'il peut prendre le mandat et ce dont le système de gouvernance a besoin pour vérifier cette prise en charge.
Schéma Atlensia : le mandat ne change de propriétaire qu'après une acceptation explicite ; un refus ou une expiration le renvoie vers un propriétaire connu.
L'objectif décrit un résultat observable, pas une intention vague. « Vérifier l'éligibilité de cette demande selon la politique P-17 » est exploitable ; « regarder le dossier » ne l'est pas. L'état précise l'étape atteinte, les hypothèses déjà testées, les questions ouvertes et les blocages. Les preuves restent des références vers les systèmes qui font autorité, avec leurs identifiants et leur version utile, plutôt qu'une copie qui pourrait devenir obsolète.
L'autorité indique les lectures, écritures et décisions possibles pendant ce mandat. Elle doit aussi nommer les actions interdites, car l'absence d'un droit dans une longue liste est plus difficile à interpréter qu'une limite explicite. Les conditions de sortie définissent ce qui compte comme terminé, ce qui déclenche une escalade, quand le relais expire et où il revient si le receveur ne peut pas agir.
Enfin, l'acceptation doit produire un événement distinct du simple envoi. Le système peut alors enregistrer l'identifiant de la tâche, l'émetteur, le receveur, la version du mandat, le moment de l'acceptation et le prochain statut attendu. Si le receveur refuse parce qu'il manque une preuve ou une capacité, le dossier retourne vers un propriétaire connu avec une raison structurée. Une tâche non acceptée ne doit jamais rester entre deux agents.
Le contexte utile est plus petit que l'historique
Transmettre toute la conversation rassure parce que rien ne semble perdu. En pratique, cette stratégie mélange des instructions périmées, des tentatives abandonnées, des données sensibles et des sorties d'outils qui n'ont plus la même validité. Elle augmente aussi le coût de traitement et oblige le receveur à reconstruire l'état de la tâche au lieu de l'utiliser.
L'OpenAI Agents SDK prévoit précisément des filtres d'entrée pour modifier ce que reçoit le nouvel agent. Ce mécanisme illustre un principe plus général : le journal complet sert à l'audit, tandis que le paquet de travail sert à l'exécution. Ils peuvent être reliés par des identifiants, mais ne devraient pas être confondus. Le receveur doit obtenir le minimum suffisant pour agir et pouvoir retrouver les preuves originales si une vérification est nécessaire.
Une bonne réduction de contexte ne résume pas librement les faits critiques. Elle conserve les identifiants, les champs structurés et les décisions validées, puis résume seulement le raisonnement intermédiaire qui n'a pas de valeur d'enregistrement. Pour une exception de facture, le montant, la devise, le fournisseur, l'identifiant de commande et le motif de l'écart doivent rester structurés. Le commentaire expliquant pourquoi l'écart semble bénin peut rester une hypothèse, clairement séparée de la preuve.
Cette séparation rejoint la conception d'une mémoire d'agents gouvernée. Une mémoire utile ne remplace pas le système de référence. Dans un handoff, elle ne doit pas transformer un souvenir conversationnel en vérité métier simplement parce qu'un nouvel agent le reçoit.
Les droits ne voyagent pas avec le texte
Le risque le plus important n'est pas qu'une information manque, mais qu'une autorité soit supposée. Copier dans le mandat « le client est éligible à un remboursement » ne confère pas au receveur le droit d'effectuer ce remboursement. Une équipe autonome doit résoudre séparément la question informationnelle et la question d'autorisation.
Le mandat peut décrire l'action envisagée, son niveau de risque et l'approbation requise. Au moment de l'exécution, le système vérifie pourtant le droit effectif du receveur, la portée de ce droit, l'objet concerné et sa durée de validité. Cette vérification doit se produire près de l'outil métier, car un prompt ou un message de handoff n'est pas une barrière de sécurité.
Pour une action réversible et faible risque, le receveur peut disposer d'une capacité limitée, comme préparer un brouillon dans un espace dédié. Pour une action financière, contractuelle ou destructrice, le transfert devrait s'arrêter avant l'effet métier et demander une décision humaine ou un service d'approbation distinct. La continuité opérationnelle ne justifie pas la continuité automatique des privilèges.
NIST place la clarté des rôles, des responsabilités et des lignes de communication au cœur de la fonction Govern de l'AI Risk Management Framework. Appliqué aux agents, ce principe signifie que le changement d'acteur ne doit pas effacer la chaîne de responsabilité humaine. Le propriétaire du processus, le propriétaire de la politique et l'opérateur qui traite les exceptions restent identifiables, même si plusieurs agents réalisent le travail préparatoire.
Les tâches longues ont besoin d'un état durable
Un relais dans une conversation convient à une interaction courte. Il devient fragile si le receveur doit attendre une pièce, une approbation ou la fin d'un traitement externe. Une session peut expirer, être rejouée ou être interrompue sans que l'entreprise sache si la tâche a réellement commencé.
La spécification Agent2Agent 1.0 formalise une distinction utile entre message, tâche, statut et artefact. Une tâche possède un identifiant et un cycle de vie ; elle peut être en cours, demander une entrée, être terminée, refusée ou échouer, tandis que ses résultats sont matérialisés comme artefacts. Le protocole ne résout pas à lui seul la gouvernance d'une entreprise, mais il rappelle qu'une collaboration asynchrone a besoin d'un objet durable distinct du fil de discussion.
Pour un processus long, le handoff devrait donc créer ou mettre à jour une tâche dans un registre exploitable. L'agent reçoit une référence, pas la responsabilité de garder seul l'état en mémoire. Les événements permettent de suivre l'acceptation, l'attente, la reprise et la clôture. Si le canal de streaming s'interrompt, le cycle de vie de la tâche persiste, ce qui évite de confondre perte de connexion et perte de propriété.
Concevoir l'échec avant le chemin nominal
Les démonstrations multi-agent montrent volontiers un routeur qui choisit le bon spécialiste. En production, la question utile est ce qui arrive lorsque ce spécialiste ne répond pas, refuse le mandat, découvre un conflit ou produit une sortie non conforme. Sans réponse préalable, les nouvelles tentatives peuvent dupliquer une action et deux agents peuvent se croire propriétaires du même dossier.
Chaque relais doit être idempotent ou protégé par une clé de corrélation. Une nouvelle tentative portant le même identifiant ne crée pas une seconde demande métier. Le registre doit distinguer « envoyé » de « accepté », puis « en cours » de « terminé ». Une expiration rend la tâche au propriétaire défini ; elle ne l'assigne pas silencieusement au prochain agent disponible.
La récupération dépend aussi de la nature du travail. Une analyse sans effet peut être relancée. Une réservation, un paiement ou une modification de données doit d'abord vérifier l'état réel dans le système de référence avant toute reprise. L'audit des agents IA doit alors conserver les décisions et références nécessaires à la reconstitution, sans enregistrer indistinctement toutes les données de la conversation.
L'équipe d'Anthropic qui a décrit son système de recherche multi-agent souligne les difficultés de coordination, d'évaluation et de fiabilité introduites par plusieurs agents. Son architecture orchestrateur-travailleurs est efficace pour explorer des pistes parallèles parce que le responsable principal synthétise les résultats. Ce cas illustre aussi la limite : une architecture adaptée à des contributions de recherche n'implique pas que chaque travailleur doive recevoir la propriété d'une action métier.
Recommandations selon le scénario
Dans un support client, le triage peut transférer la conversation à un spécialiste lorsque celui-ci doit répondre directement et possède une politique claire. Le paquet de relais contient le motif, l'identité vérifiée, les références du dossier, les démarches déjà accomplies et la limite d'autorité. Une demande de geste commercial au-delà d'un seuil quitte toutefois le dialogue agentique pour un mécanisme d'approbation explicite.
Dans une opération financière, le coordinateur devrait généralement conserver la propriété et appeler les agents spécialisés comme outils pour l'extraction, le rapprochement ou l'analyse d'anomalie. Si l'étape attend une pièce ou une validation, elle devient une tâche durable avec un statut et un propriétaire métier. Le relais ne transmet jamais un droit de paiement ; il prépare une décision dont l'exécution suit une séparation des fonctions.
Dans une recherche ou une préparation de décision, plusieurs travailleurs peuvent explorer des pistes en parallèle puis restituer des artefacts au coordinateur. Le mandat de chaque travailleur précise le périmètre, la date limite, les sources acceptables et le format de sortie. Le coordinateur demeure responsable de comparer les résultats, de signaler les contradictions et de produire la synthèse finale.
Pour choisir simplement, il faut poser quatre questions : qui doit signer la prochaine décision, combien de temps la tâche peut-elle vivre, l'action est-elle réversible et quel système peut prouver son état ? Si un coordinateur doit signer, le spécialiste reste un outil. Si un spécialiste doit poursuivre immédiatement, un transfert accepté convient. Si le travail attend, reprend ou produit un effet durable, il doit devenir une tâche gouvernée par un état persistant.
Conclusion
Un bon handoff n'est ni un résumé élégant ni un mécanisme de routage isolé. C'est un changement de responsabilité observable. Il déclare l'objectif, l'état, les preuves, les limites d'autorité et les critères de sortie, puis attend une acceptation avant de considérer le mandat comme transféré.
Cette discipline permet à une équipe autonome de se spécialiser sans créer de zones orphelines. Elle conserve un propriétaire pendant les erreurs, empêche les privilèges de voyager avec le texte et distingue les interactions courtes des tâches qui exigent un état durable. Le bon test est simple : après une interruption, l'entreprise doit encore pouvoir dire qui possède la tâche, ce qui est prouvé, ce qui reste autorisé et où le travail doit reprendre.
Sources primaires et références
OpenAI Agents SDK, Handoffs, documentation active en août 2026
OpenAI Agents SDK, Agent orchestration, documentation active en août 2026
Agent2Agent Protocol, spécification 1.0.0, 2026
NIST, AI Risk Management Framework Core, fonction Govern, 2023
Anthropic, How we built our multi-agent research system, 13 juin 2025
Atlensia, plateforme pour équipes autonomes en entreprise, 2026