Guide de l'architecte sur l'interopérabilité Agentforce

Rédigé par : l'équipe produit Agentforce (Pragya Anand , Moe Basi , Shiv Ramanna , Kyle Bransky )

Poursuivez votre lecture pour en savoir plus sur la définition de votre approche en matière d'interopérabilité.
Téléchargez ensuite la partie 2, qui vous servira de guide de référence lors de la conception.

Avant de concevoir des systèmes multiagents, il est important de comprendre comment fonctionne un agent unique. Un agent Agentforce est composé de sous-agents (anciennement appelés « Rubriques »), des modules de base adaptés à des thèmes spécifiques, chacun disposant d'actions définies (par exemple, Flux, Apex, Répliques).

Chaque agent Agentforce lance sa propre boucle de raisonnement LLM, afin d'orchestrer la manière dont les tâches sont déléguées aux sous-agents et dont les réponses sont formulées jusqu'à ce que l'objectif soit atteint. Le moteur de raisonnement Agentforce développe cette boucle en y intégrant un déterminisme basé sur le script d'agent, ajoutant ainsi des transitions et un enchaînement explicites entre les sous-agents, ce qui garantit un comportement prévisible et contrôlable au lieu de s'en remettre uniquement aux décisions du LLM. C'est cette combinaison de raisonnement LLM et de script déterministe qui aide à la mise en œuvre des workflows métier. Un agent unique peut gérer un volume important de tâches, mais à mesure que la complexité augmente, il se heurte aux obstacles suivants :

• Limites liées aux contraintes de données : les données, les workflows et les autorisations résidant dans différentes organisations Salesforce ou différents systèmes ne sont pas accessibles. Il s'agit là d'un obstacle architectural qu'une conception à agent unique ne peut franchir.
• Surcharge contextuelle : le moteur de raisonnement du LLM est saturé d'instructions, de résultats d'actions et d'historique de conversation, au point de commencer à ignorer les règles fondamentales ou à confondre les thèmes.
• Effondrement de la spécialisation par thème : un agent qui tente d'être spécialiste dans tous les domaines applique une logique erronée pour invoquer des sous-agents spécifiques. Un bloc d'instructions volumineux réduit la précision.

Framework décisionnel : utilisez des agents uniques lorsque votre processus métier est relativement simple, s'inscrit dans un seul domaine et nécessite un ensemble unifié d'accès aux données entre ses sous-agents.

L'orchestration SOMA (Single-Org, Multi-Agent, organisation unique, multiagents) aide plusieurs agents Agentforce spécialisés à collaborer de manière fluide au sein d'une même organisation Salesforce. Au lieu d'obliger les utilisateurs à gérer individuellement leurs conversations avec différents agents, SOMA met à disposition un agent de premier contact unifié. En coulisses, un « super-agent » ou « orchestrateur » coordonne et délègue de manière intelligente les tâches à des agents spécialisés, garantissant ainsi que chaque tâche soit traitée par l'agent le mieux à même de s'en charger.

Framework décisionnel : utilisez SOMA lorsque vos clients souhaitent bénéficier d'une expérience unifiée, accessible depuis un point d'entrée unique, auprès d'agents spécialisés opérant au sein d'un seul environnement Salesforce.

• Avantages : simplifie l'expérience utilisateur en fournissant un point d'entrée conversationnel unique pour plusieurs agents spécialisés.
• Inconvénients : limite l'accès aux données et aux workflows disponibles au sein d'une seule organisation Salesforce.

L'orchestration MOMA (Multi-Org Multi-Agent, plusieurs organisations, multiagents), qui constitue l'évolution logique du modèle à organisation unique (SOMA), permet à plusieurs organisations Salesforce de fournir une expérience d'agent unifiée sans nécessiter de consolidation complexe des données. Cette architecture repose sur une philosophie de délégation intentionnelle plutôt que sur un réseau ouvert, et impose une contrainte intentionnelle à un seul niveau (Agent A>Agent B, et non Agent A->B->C) afin d'empêcher tout enchaînement imprévisible. La sécurité est assurée grâce à une exécution tenant compte de l'identité des utilisateurs et au fonctionnement au sein d'une frontière de confiance Data 360 One (DC1).

Framework décisionnel : utilisez MOMA lorsque votre réseau Agentforce natif doit déléguer des tâches en toute sécurité entre différentes organisations Salesforce sans consolider les modèles de données.

• Avantages : apporte une expérience d'agent unifiée dans des environnements d'entreprise complexes tout en respectant strictement la résidence des données.
• Inconvénients : la mise en correspondance de l'identité des utilisateurs entre plusieurs organisations et le partage du contexte entre celles-ci peuvent s'avérer complexes.

Le client Model Context Protocol (MCP) permet aux administrateurs Agentforce d'enregistrer des serveurs MCP externes afin que les développeurs puissent intégrer des outils, des ressources et des actions distants au sein d'Agentforce de manière standardisée. Ainsi, Agentforce peut exploiter des capacités externes via un contrat d'outil plutôt que par le biais d'intégrations point à point sur mesure.

Framework décisionnel : utilisez le client MCP lorsque Agentforce doit rester l'orchestrateur principal et a simplement besoin d'accéder à des capacités externes en tant qu'outils. Par exemple, extraire des données d'un système externe, lancer un workflow, effectuer une recherche dans une source de connaissances ou effectuer une action via une plateforme tierce.

Utilisez le client MCP lorsqu'Agentforce doit exploiter une fonctionnalité externe en tant qu'outil.

• Avantages : transforme les services externes en outils sécurisés et gouvernables pour Agentforce sans nécessiter de code personnalisé. Comprend des fonctionnalités de sécurité, telles que des contrôles d'intégrité sémantique (contre les tentatives d'escroquerie financière « rug pull ») et une notation des risques afin d'empêcher l'empoisonnement des outils. Cela permet de maintenir la boucle de raisonnement centrée sur Agentforce tout en élargissant les capacités d'Agentforce.
• Inconvénients : l'abstraction est délibérément axée sur les outils. Si la fonctionnalité à distance se prête mieux à être modélisée sous la forme d'un agent spécialisé chargé de gérer une partie du raisonnement ou du workflow, l'intégrer de force dans le MCP peut s'avérer peu naturel. De plus, le schéma étant défini par le serveur externe, toute modification du contrat peut entraîner l'échec de l'intégration jusqu'à ce que celle-ci soit actualisée ou réenregistrée.

Agent-à-Agent Agentforce sortantest le moyen natif permettant aux agents Agentforce de collaborer directement avec un agent tiers. Pour activer cet élément, les administrateurs doivent d'abord enregistrer l'agent externe en précisant ses compétences spécifiques, ses capacités et ses protocoles de transport. Une fois enregistré et connecté à un agent Agentforce, il devient disponible lors de l'exécution pour une délégation de tâches sécurisée et multiplateforme.

Framework décisionnel : utilisez l'Agent-à-Agent Agentforce lorsque votre réseau Agentforce natif doit interagir en toute sécurité avec des agents de fournisseurs externes, tels que Google ou Box. Remarque : ici, un agent doit déléguer une tâche à un autre agent qui prend en charge une partie du raisonnement, de la planification ou de l'exécution.

• Avantages : comme cette technologie est directement intégrée à Agentforce, vous n'avez pas besoin d'acheter d'outils d'orchestration externes pour gérer ces workflows multiagents. Elle fournit aux utilisateurs un écosystème d'IA avec une marque unifiée et s'appuie sur l'expertise prête à l'emploi issue de plateformes externes.
• Inconvénients : faire confiance à des agents tiers et garantir la confidentialité des données d'un système à l'autre peut s'avérer difficile. Cela implique d'enregistrer manuellement les capacités de l'agent tiers et de s'assurer de la conformité aux normes d'authentification.

Appliquez cette règle simple : la question n'est pas de savoir si l'IA est présente des deux côtés. Ce qui fait la différence, c'est la manière dont la capacité à distance est modélisée :

• Si elle est modélisée comme un outil, utilisez MCP
• Si elle est modélisée comme un agent collaboratif, utilisez A2A

L'A2A entrant permet à des agents tiers externes de faire appel de manière native aux compétences spécialisées et aux données d'un agent Agentforce. Dans cette configuration, Agentforce est considéré comme un véritable « expert » pouvant être sollicité par des systèmes externes pour effectuer des actions spécifiques à Salesforce. Grâce à l'exposition des fonctionnalités Agentforce sur un point de terminaison API sécurisé, les plateformes externes peuvent déléguer des tâches à Salesforce sans que l'utilisateur n'ait à quitter son application tierce.

Framework décisionnel : utilisez l'A2A entrant lorsque votre interface IA principale réside dans un système tiers (tel qu'un portail personnalisé ou un bot externe), mais doit exécuter des workflows complexes au sein de Salesforce.

• Avantages : renforce les applications externes grâce aux données Salesforce en temps réel et à l'automatisation, sans duplication de la logique.
• Inconvénients : le système externe doit prendre en charge la logique d'orchestration et de transfert afin de garantir une expérience utilisateur fluide.

Le serveur MCP hébergé par Salesforce permet de mettre les fonctionnalités Agentforce à la disposition d'hôtes externes, tels que des agents tiers, des copilotes et des plateformes LLM, via une interface MCP standardisée. Ainsi, les plateformes externes peuvent faire appel à Agentforce en tant que fournisseur d'outils, tandis que Agentforce continue d'encapsuler en arrière-plan les actions d'entreprise, la logique métier et l'orchestration pour les tâches complexes et spécialisées.

Framework décisionnel : utilisez les agents Agentforce en tant que serveur MCP lorsqu'une plateforme externe doit exploiter Agentforce en tant que fournisseur d'outils. Cette approche est particulièrement utile dans deux cas de figure :

• Interopérabilité des agents d'entreprise : lorsqu'un agent d'entreprise tiers, tel que Microsoft Copilot, doit faire appel à un agent Agentforce car Agentforce fournit les actions d'entreprise utiles pour accomplir la tâche.
• LLM externe/Distribution des canaux : lorsque vous souhaitez que les fonctionnalités Agentforce de votre marque soient accessibles au sein d'interfaces conversationnelles externes, telles que ChatGPT, Gemini ou d'autres plateformes similaires.

Dans ce modèle, la plateforme externe reste l'expérience principale pour l'utilisateur, tandis qu'Agentforce est délibérément accessible via le MCP en tant que point de terminaison d'outil. Même si Agentforce dispose d'une capacité d'agent en interne, le modèle d'interopérabilité reste le MCP, car la relation externe consiste en une invocation d'outil plutôt qu'en une délégation entre agents pairs.

• Avantages : Facilite l'utilisation d'agents Agentforce puissants et spécialisés, conçus pour votre entreprise à partir des données Salesforce (facturation, assistance, etc.) et réutilisables en dehors de Salesforce grâce à un protocole standardisé. Les assistants externes et les agents d'entreprise peuvent ainsi utiliser l'orchestration et les actions métier d'Agentforce sans avoir à les recréer. Cette solution prend en charge à la fois l'interopérabilité d'entreprise et la distribution via des canaux externes.
• Inconvénients : l'hôte externe est responsable de l'expérience utilisateur principale et de la boucle de raisonnement. Par conséquent, Agentforce dispose d'une gestion moindre sur la manière et le moment où il est invoqué Les scénarios d'entreprise doivent également s'appuyer sur des mécanismes robustes d'authentification, d'autorisation, de propagation d'identité et de transmission de contexte.

La présentation ci-dessus n'est qu'un début, pour vous aider à identifier le modèle d'orchestration le mieux adapté à votre cas d'utilisation. Poursuivez votre lecture pour découvrir comment le concevoir et le mettre en œuvre.

Voici ce que vous apprendrez en téléchargeant la partie 2 : guide de référence sur l'orchestration multiagents destiné aux architectes :

• Décomposer les processus complexes en agents qui restent responsables de leurs actions. Trois stratégies (par expertise métier, par étape du workflow ou par capacité) permettent de transformer un agent surchargé en un ensemble de spécialistes qui accomplissent chacun une tâche avec efficacité.
• Adapter votre architecture à l'un des cinq modèles d'orchestration. Les modes Supervisé et Transfert sont désormais disponibles pour tous. L'exécution parallèle, les agents d'arrière-plan axés sur les événements, ainsi que la planification et la présentation figurent dans la feuille de route.
• Choisissez entre un acheminement piloté par LLM et un acheminement déterministe. Le moteur de raisonnement s'adapte aux requêtes ouvertes. Le script d'agent permet d'exercer un contrôle déterministe lorsqu'un workflow nécessite une séquence garantie. La plupart des architectures multiagents utilisent les deux.
• Éviter les sept anti-modèles les plus courants. L'orchestration en maillage, le chevauchement des sous-agents et un nombre excessif de niveaux de délégation constituent les moyens les plus rapides de compromettre la gouvernance et l'observabilité à grande échelle.
• Concevoir dans le respect des fonctionnalités actuellement prises en charge. Les contraintes actuelles des scripts d'agent (transfert délicat, délégation imbriquée, limite de sept sous-agents connectés) déterminent les modèles que vous pouvez déployer dès maintenant par rapport à ceux qu'il convient de prévoir pour le trimestre prochain.