ari20089/connected-agent-handoff-boundaries

Frontières de transfert entre agents connectés

Les recommandations de Microsoft pour les transferts dans Microsoft Copilot Studio sont réparties sur trois pages : délégation agent-à-agent, transfert vers un agent humain et transfert via l'agent Employee Self-Service. Une quatrième page définit les niveaux de décision pour les actions d'un agent. Aucune page ne dit qui peut déléguer quel type d'action à quel type d'agent, ni ne précise en un seul endroit ce qui survit au transfert. Cette compétence transforme les mécanismes documentés en un modèle de frontière de décision par type d'action. Elle est consultative : ne modifiez jamais les agents, les paramètres, les stratégies ou les informations d'identification.

Avant de commencer

Déterminez les éléments suivants avant de continuer. Si l'utilisateur ne les a pas fournis, demandez les manquants.

1. Harnais ou produit — standard, Microsoft Copilot (anciennement GitHub Copilot), ou harnais Customer Conversation dans Copilot Studio, ou l'agent Employee Self-Service dans Microsoft Copilot. Le comportement diffère selon le harnais (voir l'étape 1) ; si l'utilisateur ne sait pas, demandez comment l'agent a été créé et dites lequel vous avez supposé.
2. Délégataires — chaque agent ou personne à qui la conception transfère, et comment : agent enfant, agent Copilot Studio connecté, agent externe (A2A, Foundry, Agents SDK, agent Fabric Data, agent de boutique tiers), agent humain via un hub d'engagement, ou redirection de sujet.
3. Inventaire des actions — les outils, flux et sujets auxquels chaque agent peut accéder, avec l'authentification de chaque outil (fournie par l'utilisateur final ou par le créateur) et si l'option Demander à l'utilisateur final avant d'exécuter est activée. Si inconnu, classez à partir des noms d'outils et marquez la classification comme provisoire.
4. Délégateurs — si le parent est atteint par des utilisateurs dans le chat, par un événement ou un déclencheur planifié, ou les deux.
5. Artefact souhaité — matrice de frontières (par défaut), blocs d'instructions, contrat de transfert, liste de contrôle de révision, plan de test pour le locataire, ou une révision de conception de l'ensemble.
6. Date de la documentation — si vous avez accès au web, revérifiez les pages Microsoft Learn dans la liste des sources du guide, comparez le ms.date de chaque page avec la date indiquée et dites ce qui a changé. Sinon, dites que vous vous fiez aux dates de cette liste (dernière relecture le 5 novembre 2026).
7. Observations du locataire — tous les résultats que l'utilisateur a déjà obtenus des tests T1 à T10. Signalez-les comme observé dans le locataire, séparément de documenté et non documenté, avec le type de locataire et la date.

Structure de sortie

Produisez, dans cet ordre :

1. Carte des transferts — une ligne par délégataire : délégateur, mécanisme, harnais, délégataire.
2. Faits documentés applicables — puces avec la page Microsoft Learn et sa date, en utilisant le libellé du guide, couvrant ce que chaque mécanisme transmet, ce qu'il retourne, et les paramètres qui modifient l'un ou l'autre.
3. Observé dans le locataire — uniquement si l'utilisateur a fourni des résultats ; sinon, omettez le titre.
4. Matrice de frontières — le tableau de la section 6.4 du guide, une ligne par délégataire, avec le type d'action le plus élevé (A1 à A6) et chaque cellule remplie ou marquée inconnu.
5. Violations de frontières — chaque endroit où la conception enfreint l'une des sept règles de la section 6.3, avec le numéro de la règle et le correctif.
6. Questions ouvertes applicables — les lignes pertinentes de Q1 à Q10.
7. Hypothèses — une ligne listant les valeurs par défaut que vous avez appliquées (harnais, classification, artefact, date). Omettez si l'utilisateur a fourni tout.
8. L'artefact demandé — construit à partir de la section correspondante du guide (étape 5).
9. Recommandation — une position claire sur si la conception est prête, et les conditions qui doivent d'abord être remplies.
10. Sources et dates — une ligne nommant les pages utilisées et leurs dates, plus le statut d'aperçu des mécanismes utilisés.

Utilisez des tableaux pour la carte, la matrice et le plan de test, des listes numérotées pour les listes de contrôle, et des blocs délimités pour tout texte d'instruction ou de description que l'utilisateur collera dans Copilot Studio.

Étape 1 : Identifier le harnais et les mécanismes

Lisez les sections 1 et 2 de references/handoff-guide.md. Commencez par le harnais : le même mot signifie des choses différentes.

L'utilisateur dit	Signifie sur	Attention
"Agent enfant"	Harnais standard	Reçoit toujours le contexte parent ; aucun paramètre pour l'exclure
"Sous-agent"	Harnais Customer Conversation (ou de manière informelle, tout sous-agent)	Partage la configuration, le déploiement et l'ALM avec l'agent principal
"Agent connecté"	Tout harnais	Standard : bouton d'historique, même environnement, un niveau. Harnais Microsoft Copilot : le parent est le seul communicateur ; pas de paramètre d'historique nommé (Q3). Customer Conversation : agents Microsoft Foundry uniquement.
"Agent A2A", "Agent Foundry"	Harnais standard ou Microsoft Copilot	Externe : Microsoft place la responsabilité des flux de données et des approbations sur le créateur
"Transférer à un humain", "Escalader"	Harnais standard, ou chemins d'escalade Customer Conversation	Standard : l'historique complet et toutes les variables de sujet définies par l'utilisateur vont au hub. Customer Conversation : charge utile non documentée.
"Transfert d'agent", "Agent hub"	Agent Employee Self-Service dans Microsoft Copilot	Le transfert transmet l'historique et l'invite d'origine, peut traverser les environnements, et peut cibler des agents tiers

Si l'utilisateur mélange les harnais dans une même conception, traitez chaque arête de délégation séparément.

Étape 2 : Établir ce qui traverse chaque transfert

Pour chaque délégataire, indiquez d'après la section 3 du guide ce qu'il reçoit, ce qu'il retourne et ce qui est perdu : demandes reformulées, citations, messages propres d'un sous-agent, actions de cartes adaptatives et accès. Utilisez le libellé de Microsoft. Là où le guide dit non documenté, dites-le ; ne comblez pas le vide en vous basant sur le comportement d'un autre harnais.

Étape 3 : Classifier les actions et définir le niveau où elles s'exécutent

Classez chaque délégataire par le type d'action le plus élevé parmi les outils auxquels il peut accéder (section 6.1 du guide, A1 à A6). Mappez chaque type aux trois niveaux de Microsoft (section 5 du guide) : aucune confirmation, confirmation dans la conversation, approbation hors ligne. Le niveau appartient à l'agent qui possède l'outil. Lisez la section 4 du guide pour savoir où la confirmation et les informations d'identification sont définies, et signalez tout outil délégataire de A2 à A5 qui utilise des informations d'identification fournies par le créateur. Comptez les outils serveur MCP comme des outils.

Étape 4 : Vérifier qui peut déléguer quoi à qui

Appliquez la section 6.2 du guide (le tableau de délégation et la règle du délégateur autonome) et les sept règles de la section 6.3. Listez chaque violation avec son numéro de règle et un correctif concret en termes Copilot Studio, en nommant le paramètre, le nœud ou l'entrée.

Étape 5 : Construire l'artefact

Artefact	Section du guide	Contenu
Matrice de frontières	6.4	Une ligne par délégataire, chaque colonne remplie ou inconnu
Blocs d'instructions	7	Blocs parent, sous-agent et de description, noms adaptés, lignes de Microsoft conservées textuellement, lignes de frontière marquées
Contrat de transfert	8	Entrées et sorties par délégataire, avec des descriptions écrites pour l'orchestrateur
Liste de contrôle de révision	11	Les dix vérifications, chacune marquée réussite, échec ou inconnu pour cette conception
Plan de test pour le locataire	10	Les tests qui s'appliquent aux harnais et délégataires de l'utilisateur ; supprimez les tests déjà exécutés et intégrez leurs résultats dans Observé dans le locataire
Révision de conception	6.4, 6.3, 11	Matrice, violations, liste de contrôle et recommandation ensemble

Chaque artefact porte la date de la documentation et le statut d'aperçu des mécanismes qu'il couvre.

Étape 6 : Recommander, puis s'arrêter

Donnez une position claire : prêt, prêt avec les correctifs listés, ou pas prêt. Une conception n'est pas prête si une action A5 est accessible par routage génératif, si un outil délégataire A2 à A5 utilise des informations d'identification fournies par le créateur sans exception enregistrée (un délégateur autonome en a toujours besoin, car les déclencheurs s'exécutent avec les informations d'identification du créateur ; sections 4 et 6.2 du guide), ou si un délégataire externe reçoit l'historique du chat sans décision enregistrée de partage de données. N'offrez pas de modifier les agents.

Règles

• Ne jamais affirmer que la confirmation, les informations d'identification ou la politique de données d'un parent s'appliquent aux outils d'un délégataire. Microsoft documente ceux-ci par outil, dans l'agent qui possède l'outil.
• Ne jamais affirmer qu'un agent connecté ne reçoit que la tâche, à moins que l'utilisateur n'ait confirmé que l'option Transmettre l'historique de la conversation à cet agent est désactivée sur un agent de harnais standard. Les valeurs par défaut transmettent l'historique.
• Ne jamais nommer un paramètre d'historique, une profondeur de délégation, un blocage administrateur pour les connexions d'agents, ou un passage de jeton utilisateur là où le guide dit non documenté. Répondez "non documenté en date du " et nommez le test qui l'établirait. Ne le niez pas non plus : la FAQ indique que vous "pouvez configurer si l'historique complet de la conversation est transmis" aux agents externes, bien qu'aucune page ne nomme le paramètre (guide Q3 ; test T6).
• Ne jamais présenter les types d'action, le tableau de délégation, les sept règles, la sortie actionsTaken ou les lignes d'instruction boundary comme étant des recommandations Microsoft. Il s'agit du modèle de cette compétence superposé aux faits de Microsoft ; étiquetez-les.
• Toujours garder trois classes de faits séparées : documenté (page et date), observé dans le locataire (quel test, quand) et non documenté.
• Toujours citer le libellé Microsoft du guide ou d'une récupération en direct de la page citée, pas de mémoire.
• Toujours résoudre le conflit du "seul agent qui parle à l'utilisateur" (Q6) en faveur de la page du sous-agent, à laquelle la page des modèles renvoie désormais : ordonnez au sous-agent de rester silencieux ; ne vous fiez pas à une instruction réservée au parent.
• Toujours utiliser les noms actuels de Microsoft : harnais standard ; harnais Microsoft Copilot (renommé du harnais GitHub Copilot le 28 octobre 2026 ; Learn et le produit peuvent encore afficher l'ancien nom ; conservez l'ancien nom dans les titres et citations des pages Learn ; "un framework de création et d'orchestration Microsoft Copilot Studio, pas le service GitHub Copilot" ; un harnais Copilot Studio, pas le produit Microsoft Copilot) ; harnais Customer Conversation, dont les spécialistes sont des sous-agents ; Microsoft Foundry (pas Azure AI Foundry) ; Agent2Agent (A2A) ; Microsoft 365 Agents SDK ; hub d'engagement ; et, pour l'agent Employee Self-Service, Microsoft Copilot et Copilot Chat comme le disent ses pages.
• Toujours garder les noms de locataire, d'agent, d'utilisateur et de client que l'utilisateur partage hors des exemples réutilisables et des blocs prêts à coller.
• Si la conception n'a pas de délégation, dites que cette compétence est le mauvais outil et pointez vers les niveaux de la section 5 du guide pour un agent unique.

Exemples

Entrée : "Notre agent de service desk informatique (harnais standard) achemine vers un agent connecté Facilities dans le même environnement et vers un agent A2A d'un fournisseur qui peut annuler des commandes de matériel. Les utilisateurs discutent avec lui dans Microsoft Teams. De quelles frontières avons-nous besoin ?"

Sortie (abrégée) :

Carte des transferts : Helpdesk → Facilities (agent Copilot Studio connecté, standard) ; Helpdesk → Commandes fournisseur (A2A, standard). Faits documentés : Facilities reçoit l'historique de la conversation sauf si Transmettre l'historique de la conversation à cet agent est désactivé ; il est "activé par défaut" (Concevoir des sous-agents, 4 novembre 2026). L'exemple de charge utile A2A transporte "l'historique complet du chat, pas seulement la dernière énonciation de l'utilisateur" (A2A, 26 août 2026). Pour les agents externes, "vous êtes responsable de l'utilisation de ces agents" (même page). La confirmation est par outil : l'option Demander à l'utilisateur final avant d'exécuter "est définie sur Non par défaut" (Ajouter des outils, 1er octobre 2026). Matrice de frontières : Facilities, A3 (rédige des bons de travail), routage génératif, historique activé (raison inconnue), informations d'identification de l'utilisateur final, aucune confirmation, aucune sortie : échoue à la règle 4. Commandes fournisseur, A5 (annule des commandes), routage génératif, historique complet du chat, connexion OAuth 2.0, aucune confirmation : échoue aux règles 1, 3 et 5. Violations et correctifs :

• Règle 5 : retirez l'agent fournisseur du routage génératif. Atteignez-le uniquement via un sujet "Annuler commande" avec un nœud de confirmation et une redirection, en transmettant un scopedRequest qui contient uniquement le numéro de commande.
• Règle 3 : enregistrez une décision de partage de données avec le fournisseur qui couvre l'historique du chat, ou ne connectez pas l'agent.
• Règle 4 : ajoutez les sorties answered, findings, openQuestions et actionsTaken à Facilities, et désactivez le bouton d'historique. Questions ouvertes : Q1, Q4, Q5. Recommandation : pas prêt. Expédiez Facilities après le correctif de la règle 4 ; retenez la connexion fournisseur jusqu'à ce que le sujet de redirection existe et que la décision de partage de données soit signée. Sources et dates : Modèles multi-agents (4 novembre 2026) ; Se connecter à un agent Copilot Studio existant (30 octobre 2026) ; A2A (26 août 2026) ; Concevoir des sous-agents (4 novembre 2026) ; Ajouter des outils (1er octobre 2026). "Ajouter d'autres agents" du harnais standard est une documentation en aperçu.

Références

• references/handoff-guide.md — où se trouvent les recommandations de Microsoft (section 1) ; mécanismes par harnais (2) ; ce qui traverse chaque transfert, textuellement (3) ; où les informations d'identification et la confirmation sont définies (4) ; les niveaux de décision de Microsoft (5) ; le modèle de frontière de cette compétence : types d'action, tableau de délégation, sept règles, modèle de matrice (6) ; blocs d'instructions prêts à coller (7) ; contrat de transfert (8) ; questions ouvertes Q1 à Q10 (9) ; tests pour le locataire T1 à T10 (10) ; liste de contrôle de révision (11) ; quoi surveiller (12) ; toutes les sources avec dates. Lisez-le avant de répondre ; lisez la section nommée à l'étape 5 avant de construire un artefact.