Guide Agentforce pour former des agents fiables : un cadre pour 6 niveaux de déterminisme

Olfa Kharrat, Directrice de la gestion des produits - Agentforce
Reinier van Leuken, Directeur senior de la gestion des produits - Agentforce

La confiance est au cœur des préoccupations de Salesforce depuis sa création en 1999, pour lancer un nouveau modèle technologique de cloud computing et de SaaS. Les entreprises accordent leur confiance à Salesforce et stockent leurs données précieuses dans le cloud, en ayant la certitude que ces données sont protégées et soumises aux contrôles d'accès appropriés. Cela reste essentiel, mais à l'ère de l'IA agentique, la définition de la confiance ne cesse de s'élargir. À mesure que les entreprises s'appuient de plus en plus sur des agents autonomes pour effectuer des fonctions commerciales critiques, les agents doivent devenir des partenaires commerciaux de confiance dont le travail est précis, pertinent et, surtout, fiable.

Dans ce contexte, comment peut-on créer un agent fiable ? La fiabilité signifie généralement fournir le même résultat pour la même saisie. Cependant, les agents ne fonctionnent pas nécessairement de cette manière, car ils sont alimentés par des modèles de langage de grande taille (LLM), qui sont par nature non déterministes. Cela donne aux agents la fluidité nécessaire pour développer des solutions créatives adaptées à des circonstances particulières, sans avoir à programmer explicitement chaque condition ou situation qu'ils rencontrent. Cependant, les agents ont également besoin d'une gouvernance pour se conformer aux exigences de l'entreprise et respecter les directives opérationnelles. Lorsqu'ils exécutent des processus métier, ils doivent faire preuve de fiabilité et produire des résultats commerciaux conformes aux contraintes déterministes. Le déterminisme impose une rigidité et une discipline qui sont difficilement compatibles avec l'autonomie et la fluidité des agents. Par conséquent, la clé de la réussite de la création d'agents est de trouver le bon équilibre entre la fluidité créative et le contrôle de l'entreprise.

Ce document traite des considérations clés pour le développement d'agents fiables. Il définit six niveaux de contrôle agentique et fournit les meilleures pratiques pour acquérir et conserver le contrôle du comportement agentique à chacun de ces niveaux. Les directives spécifient le fonctionnement du moteur de raisonnement d'Agentforce. À mesure qu'Agentforce s'étoffera, les conseils pratiques de ce document seront mis à jour.

Ce document suppose une connaissance de base de la conception et de la création d'agents Agentforce. Pour une présentation de Agentforce, nous vous proposons les ressources suivantes :

• Consultez les ressources sur agentforce.com.
• Suivez le parcours Devenir un Agentblazer Champion . Ce parcours explore les concepts fondamentaux de l'IA et vous aide à créer un agent de base pour les tâches clés.
• En savoir plus sur Agentforce sur help.salesforce.com , en particulier le chapitre relatif à la conception et la mise en œuvre d'agents . Cette carte d'apprentissage vous guide à travers toutes les étapes clés du cycle de vie, de l'élaboration de votre solution à la création et à la configuration de votre agent, en passant par les tests, le déploiement et la surveillance.

Pour mieux comprendre le comportement agentique, comparons d'abord les agents à leurs homologues rigides : les chatbots.

Chatbots : suivi strict des règles

Les chatbots suivent des arbres de décision prédéterminés qui structurent les dialogues auxquels ils peuvent participer. La traversée de ces arbres de décision est basée sur les réponses données par l'utilisateur. Cette réponse peut être une sélection parmi un ensemble prédéterminé d'options, ou une réponse en texte libre. Dans le cas d'une réponse en texte libre, un modèle prédictif est utilisé pour la classification des intentions. Ces arbres cartographient tous les parcours conversationnels potentiels et dictent les réponses du chatbot à chaque étape. Le comportement du chatbot est strictement déterminé par des règles prédéfinies. Si la saisie d'un utilisateur ne correspond pas à un parcours reconnu, ou si le modèle prédictif n'a pas été entraîné à reconnaître une certaine intention, le chatbot ne répond pas de manière appropriée.

Agents : adaptatifs et intuitifs

En revanche, les agents exploitent la puissance des LLM et leurs capacités avancées en matière de traitement du langage naturel (NLP). Les LLM permettent aux agents de comprendre l'intention derrière la saisie d'un utilisateur, même si elle est formulée de manière inattendue. Sur la base de sa compréhension de l'intention, l'agent peut sélectionner l'action la plus appropriée parmi un éventail de possibilités. Un agent peut même formuler des réponses entièrement nouvelles. Cette flexibilité et cette adaptabilité distinguent les agents de leurs homologues, les chatbots.

Une analogie culinaire

La différence entre les chatbots et les agents peut être comparée au contraste entre un cuisinier novice et un chef chevronné.

• Le cuisinier novice (le chatbot) suit à la lettre une recette détaillée et complète, avec des mesures précises, des instructions étape par étape et des temps de cuisson spécifiques. Tout écart par rapport à la recette entraîne un désastre culinaire. De même, un chatbot doit fonctionner dans les limites de son arbre de décision préprogrammé.
• Le chef chevronné (l'agent) possède des années d'expérience culinaire et d'intuition. En disposant d'une compréhension générale de vos préférences et d'une brève description des ingrédients disponibles, il est en mesure de préparer un délicieux repas qui répondra à vos besoins. Les étapes exactes peuvent varier à chaque fois, et chaque version du plat peut présenter de légères différences, mais le résultat global est toujours satisfaisant. De même, un agent peut adapter son approche en fonction du contexte et de l'intention de la saisie de l'utilisateur, ce qui se traduit par une interaction réussie.

En résumé, la différence fondamentale entre les agents et les chatbots réside dans leur adaptabilité et leur capacité à gérer des saisies inattendues.

Une fonctionnalité distincte de l'intelligence d'un agent réside dans sa capacité à orchestrer et à déclencher les actions les plus appropriées au bon moment. Cette flexibilité élimine la nécessité de programmer de manière approfondie chaque interaction potentielle avec l'utilisateur.

Dans Agentforce, la création d'un agent implique des rubriques, des actions et des instructions et des descriptions en langage naturel.

Sujets

Les rubriques sont les « tâches à accomplir » pour l'agent. Les rubriques ont des attributs tels qu'une description de classification, un champ d'application et des instructions qui définissent chaque tâche et la manière dont elle est effectuée. Les rubriques contiennent des actions que l'agent peut exécuter, ainsi que des instructions qui régissent la manière dont ces actions sont exécutées.

Actions

Les actions sont les tâches prédéfinies que l'agent peut effectuer pour faire son travail. Il existe cinq types d'actions différents :

• exécuter le code Apex ;
• appeler une API ;
• exécuter un flux ;
• obtenir une réponse LLM à un modèle de réplique ;
• appeler un modèle prédictif.

Instructions et descriptions en langage naturel

La définition d'un agent contient des instructions en langage naturel qui décrivent les actifs de l'agent et définissent les directives qu'il doit respecter lors de son fonctionnement. Des instructions sont écrites pour les actions et les rubriques.

• Actions. Une action contient :
  • des instructions qui décrivent ce que fait l'action, ce qui indique au moteur de raisonnement quand exécuter cette action ;
  • des saisies avec une description en langage naturel afin que l'agent puisse les préparer ;
  • des réponses avec une description en langage naturel de la manière de les formater et de les utiliser.
• Rubrique. Une rubrique contient des instructions qui régissent l'exécution de ses actions à un niveau supérieur. Par exemple, les instructions peuvent spécifier des garde-fous sur le ton, la séquence d'actions souhaitée, les conditions préalables possibles ou le moment où transmettre les conversations à des êtres humains. La rubrique contient également une description de la classification et une délimitation du champ d'application. Dans l'ensemble, cela garantit que l'agent reste dans le cadre de son rôle défini et exécute le travail.
• Données. Les agents ont besoin de données pour réussir dans leur travail. Les données peuvent être structurées, comme les données CRM, ou non structurées, comme les articles de connaissance de l'entreprise. Les agents accèdent aux données à l'aide de saisies d'action. Par exemple, une action peut appeler un modèle de réplique basé sur des données CRM ou contextualisé avec des morceaux de données non structurées à l'aide de techniques de génération augmentée de récupération (RAG).

Ces différents composants de base, lorsqu'ils sont correctement construits, aident un agent à atteindre son objectif tout en respectant les limites appropriées.

Le moteur de raisonnement Agentforce orchestre ces composants de base dans le comportement agentique correct. Il s'appuie sur les instructions et les descriptions en langage naturel définies dans les rubriques et les actions. Il est construit sur ReAct, un nouveau paradigme de raisonnement pour les LLM introduit en 2022 par Yao et al. Ce paradigme imite la gestion des tâches humaines en raisonnant sur un problème, en prenant des mesures, en observant les résultats de l'action et en répétant le cycle jusqu'à l'achèvement de la tâche.

Les agents Salesforce respectent ce paradigme :

1. Raisonner : comprendre l'intention de l'utilisateur et l'aligner sur la bonne rubrique et la ou les actions adéquates.
2. Agir : lancer la chaîne d'actions correcte.
3. Observer : évaluer les résultats de l'action par rapport à l'intention de l'utilisateur. Si l'intention n'est pas remplie, raisonnez davantage en fonction du résultat obtenu jusqu'à présent, ainsi que des instructions et des descriptions de la rubrique/de l'action. Si l'intention est remplie, fournissez la réponse finale tout en respectant les instructions de formatage possibles.
4. Répéter : répéter ces étapes jusqu'à ce que l'étape finale indiquée soit atteinte.

Le moteur de raisonnement utilise les LLM à chaque étape de raisonnement et d'observation. Selon le type d'action, il peut également utiliser les LLM à l'étape d'action.

Cette section présente une approche en couches pour améliorer le déterminisme des agents. Chaque niveau s'appuie sur le précédent, avec une complexité croissante et des capacités qui permettent de mieux contrôler le comportement de l'agent.

Le premier niveau vise à permettre aux agents d'identifier de manière autonome les rubriques pertinentes, puis de sélectionner les actions appropriées en utilisant des objectifs plutôt que des instructions explicites. Le mécanisme de base consiste à utiliser une compréhension contextuelle pour répondre aux saisies des utilisateurs. Bien que techniquement, n'importe quel type d'action puisse être ajouté, à ce niveau, nous supposons que les actions sont des actions de prompt. Les rubriques sans instruction avec des actions de prompt fournissent un moyen rapide et efficace de traiter les requêtes courantes.

À ce niveau, l'accent est mis sur l'établissement d'un niveau de référence de réactivité et d'autonomie des agents grâce à une compréhension dynamique.

S'appuyant sur la base de la sélection d'actions sans instruction, ce niveau introduit des instructions explicites pour guider le comportement des agents. L'ajout d'instructions précises permet de mieux contrôler la manière dont les agents réagissent aux différentes situations. Les instructions aux agents peuvent être exprimées sous forme de règles, de directives, de garde-fous et d'exemples. Celles-ci fournissent à l'agent des instructions spécifiques sur la manière de traiter diverses rubriques, d'exécuter des actions et de traiter leurs réponses. L'objectif de ce niveau est de fournir des conseils clairs à l'agent afin d'accroître la cohérence et d'améliorer le respect des directives et des processus de l'entreprise.

La contextualisation consiste à relier la compréhension de l'agent et ses réponses à des sources de connaissances externes. La contextualisation permet de s'assurer que les informations fournies par l'agent sont plus précises, à jour et pertinentes. Ce niveau intègre l'accès aux bases de données, aux bases de connaissances et à d'autres référentiels d'information. La contextualisation des réponses de l'agent dans des données vérifiées améliore sa fiabilité.

Ce niveau permet aux agents de travailler avec des variables. Les variables permettent aux agents de personnaliser les interactions, de conserver le contexte de plusieurs interactions et d'ajuster dynamiquement leur comportement en fonction de points de données spécifiques conservés pendant la session de l'agent. Par exemple, un agent peut capturer les préférences de l'utilisateur, les détails de la commande et d'autres informations pertinentes, puis utiliser ces données pour adapter l'interaction. Avec les variables, les agents sont mieux à même de gérer des interactions plus complexes, plus prescrites et plus personnalisées.

Cette étape consiste à intégrer l'agent aux fonctionnalités principales de Salesforce : Apex, les API et les flux. L'intégration permet à l'agent d'effectuer des actions complexes au sein de l'écosystème Salesforce, telles que l'accès aux données et leur manipulation, le déclenchement de workflows et l'interaction avec d'autres systèmes.

• Apex fournit un contrôle programmatique.
• Les API permettent une intégration transparente avec d'autres applications.
• Les flux permettent l'automatisation de processus métier complexes.

Ce niveau transforme l'agent en un outil puissant capable d'exécuter des tâches sophistiquées et de contribuer directement aux résultats de l'entreprise.

En s'appuyant sur les intégrations techniques du niveau 5, ce dernier niveau introduit un raisonnement déterministe pour combler le fossé entre l'IA probabiliste et la logique métier stricte. Alors que les niveaux précédents s'appuient sur le LLM pour décider de l'outil à utiliser, le script d'agent vous permet de « coder en dur » le processus de raisonnement lui-même. En utilisant un canevas de style document ou la saisie directe de code, vous pouvez définir des parcours immuables, tels que des points d'authentification obligatoires, des branchements conditionnels if/else et des transitions de rubriques forcées, que l'agent doit suivre quelle que soit la saisie de l'utilisateur. Cette approche de raisonnement hybride vous permet d'intégrer la flexibilité conversationnelle d'un LLM entre les couches d'exécution garantie. Le niveau 6 transforme l'agent en un partenaire d'entreprise Zero Trust capable de gérer la conformité à enjeux élevés, les divulgations réglementaires et les dépendances complexes en plusieurs étapes avec une précision absolue.

En commençant par une référence en matière de réactivité et d'autonomie des agents, envisagez un agent composé uniquement de rubriques et d'actions, avec les descriptions correspondantes. Nous pouvons utiliser cet exemple d'agent pour présenter les différentes étapes du moteur de raisonnement et pour montrer comment il exploite ces descriptions pour sélectionner les bons sujets, puis les actions à exécuter. En omettant les instructions de la rubrique de cet exemple, nous pouvons constater que les agents de ce premier niveau ont le plus grand degré de liberté par rapport aux agents des niveaux supérieurs. Au niveau un, l'agent est entièrement libre de sélectionner l'action qu'il juge appropriée, en se basant uniquement sur la conversation en cours.

Passez en revue les considérations suivantes pour le moteur de raisonnement :

• Les paramètres de configuration sont fixes pour le LLM du moteur de raisonnement. Les générateurs d'agents ne peuvent pas les modifier. À l'heure actuelle, le générateur d'agents peut choisir entre un LLM d'OpenAI ou un LLM d'Anthropic hébergé sur l'infrastructure Salesforce pour le raisonnement. Cela est susceptible de changer à mesure que de nouveaux modèles seront ajoutés.
• Historique par défaut du moteur de raisonnement : lorsqu'une requête est adressée au moteur de raisonnement (étapes 2 à 5), ce dernier récupère automatiquement l'historique des requêtes et réponses les plus récentes. Cela garantit que le contexte de la conversation est conservé pour le moteur de raisonnement. Outre les interactions avec les clients, ces appels vers le LLM du planificateur incluent des appels vers le LLM du moteur de raisonnement pour d'autres demandes, telles que la sélection de rubriques.

Le processus de raisonnement comprend quatre étapes principales :

1. Sélection de la rubrique
2. Sélection de l'action
3. Boucle agentique
4. Vérification de la contextualisation

Les rubriques sont conçues pour améliorer la précision avec laquelle les agents classent la bonne action ou séquence d'actions. Chaque rubrique doit être composée d'actions sémantiquement distinctes qui peuvent toutes appartenir à une description concise de la rubrique et donc appartenir à une fonction d'agent similaire.

La rubrique adéquate est sélectionnée par le LLM du moteur de raisonnement (étapes 2-3 du schéma). Il sélectionne la rubrique dont la description de classification correspond le plus au dernier énoncé, à l'aide d'un prompt de rubrique. Ce prompt de rubrique contient les descriptions de classification de toutes les rubriques et l'historique des conversations. En plus des énoncés et des réponses des agents, l'historique des conversations comprend les actions exécutées et leurs résultats. De plus, le prompt intègre des instructions cruciales qui imposent une analyse dans le contexte de l'historique des conversations et exigent que le LLM partage son processus de réflexion.

Considérations supplémentaires :

• Une rubrique masquée supplémentaire pour les énoncés « hors sujet » existe automatiquement à côté des rubriques visibles. Cette rubrique est sélectionnée lorsqu'aucune autre rubrique existante ne correspond à l'énoncé. Cela permet à l'agent d'éviter les erreurs de classification. Cette rubrique ne comporte aucune action. Son seul objectif est d'aider le moteur de raisonnement à formuler une réponse appropriée plus tard.
• Seuls le nom et la description de la classification de la rubrique sont utilisés dans le prompt de rubrique.
• Le LLM du moteur de raisonnement ne peut choisir qu'une seule rubrique à la fois.
• Les conversations peuvent prendre une tournure inattendue. À chaque réception d'un énoncé, le moteur de raisonnement passe à l'étape de sélection de la rubrique, ce qui signifie qu'une nouvelle rubrique peut être sélectionnée à chaque nouvel énoncé.

L'objectif des rubriques est double :

1. réduire le risque de confusion du moteur de raisonnement en regroupant les actions, évitant ainsi qu'il ne sélectionne les mauvaises actions ;
2. guider la sélection et l'exécution des actions à l'aide d'instructions (pour en savoir plus, consultez Contrôle agentique de niveau deux : ajout d'instructions).

En organisant soigneusement les capacités de l'agent en rubriques clairement définies et composées d'actions connexes, l'agent fonctionne de manière plus efficace et prévisible, et il est plus facile de le mettre à jour et de l'étendre. Il existe deux approches possibles pour la conception de rubriques : descendante et ascendante.

• Dans l'approche descendante, les rubriques sont d'abord définies en tant que tâches générales que l'agent doit accomplir, puis chaque action spécifique est définie pour ces rubriques.
• Dans l'approche ascendante, toutes les actions individuelles sont d'abord définies, puis regroupées en rubriques.

Les deux approches conduisent à de bons résultats lorsqu'elles sont suivies correctement.

Approche ascendante

Cette section présente l'approche ascendante, car elle est étroitement liée aux raisons pour lesquelles le moteur de raisonnement a besoin de rubriques.

Étape 1 : répertorier toutes les actions des agents

Commencez par répertorier toutes les actions spécifiques que l'agent doit être capable d'effectuer. À ce stade, il est préférable d'être très spécifique plutôt que trop général. Évitez d'essayer de regrouper ou de simplifier les actions prématurément. L'objectif est de créer une vue complète et granulaire de ce que l'agent peut faire.

Par exemple, dans le cas d'un agent du service client, la liste initiale peut inclure :

• Retourner une commande : utilisée pour lancer le processus de retour d'une commande.
• Vérifier la disponibilité des stocks : utilisée pour vérifier si un produit est en stock.
• Vérifier les politiques d'échange de produits : utilisée pour récupérer des informations sur les règles d'échange.
• Répondre aux questions avec des connaissances : utilisée pour répondre à des questions générales ou de type FAQ.
• Vérifier les promotions : utilisée pour vérifier les promotions ou les remises disponibles.
• Prévoir la date de livraison : utilisée pour estimer la date et l'heure de livraison prévues.
• Vérifier l'état de la commande : utilisée pour trouver l'état actuel de la commande d'un client.
• Rechercher les commandes d'un client : utilisée pour récupérer toutes les commandes passées ou actives d'un client spécifique.
• Résoudre les problèmes techniques : utilisée pour résoudre les problèmes techniques liés à un produit ou à un service.
• Rechercher les conditions de la commande client : récupérer toutes les conditions relatives à une commande.
• Rechercher les actifs d'un client : utilisée pour identifier ou récupérer les actifs associés à un client.
• Modifier l'adresse de livraison.

À noter qu'une action telle que « Résoudre les plaintes des clients » est trop large à ce stade. Les actions doivent représenter le plus petit niveau de granularité dans le comportement des agents. Les plaintes peuvent être de plusieurs types, et différentes actions les couvrent déjà :

• les problèmes post-livraison, tels que le dépannage de produits endommagés ou défectueux, sont déjà couverts par la rubrique « Résoudre les problèmes techniques » ;
• les problèmes de pré-livraison, tels que les livraisons manquantes, la nécessité de modifier les dates de livraison ou la modification d'une commande, sont déjà couverts par des actions telles que « Vérifier l'état de la commande », « Prévoir la date de livraison » ou « Retourner une commande » ;
• les préoccupations générales des clients, telles que les questions liées aux politiques, sont déjà couvertes par « Répondre aux questions avec des connaissances » ou « Vérifier les politiques d'échange de produits ».

Étape 2 : marquer les paires (ou multiples) d'actions qui peuvent engendrer une confusion dans le raisonnement

Marquez les actions qui sont de nature similaire car elles peuvent engendrer de la confusion pour le moteur de raisonnement. Leurs descriptions ne seront pas suffisamment différentes sur le plan sémantique et, par conséquent, le moteur de raisonnement ne saura pas quelle action sélectionner à l'étape 5.

Par exemple, « Résoudre les problèmes techniques » et « Répondre aux questions avec des connaissances » ont des descriptions similaires, mais leurs fonctionnalités peuvent différer considérablement. Le marquage de ces chevauchements sémantiques aidera à identifier les actions à séparer entre plusieurs rubriques.

Étape 3 : créer des regroupements initiaux d'actions en rubriques

Une fois que les actions sont clairement définies et que leurs chevauchements sémantiques ont été identifiés, elles peuvent être regroupées en rubriques préliminaires. Une rubrique est une catégorie logique de fonctionnalités, un regroupement d'actions qui représentent une capacité ou une compétence cohérente de l'agent.

Lors de la création de ces regroupements :

• évitez les chevauchements sémantiques en utilisant le nombre minimum de rubriques nécessaires ;
• assurez-vous que chaque rubrique contient des actions qui sont liées de manière significative ;
• assurez-vous que les actions de soutien qui doivent être exécutées dans une chaîne sont présentes dans la même rubrique.

Voici un exemple de regroupement initial pour un agent de service client :

Rubrique 1 :

• Retourner une commande
• Vérifier la disponibilité des stocks
• Vérifier les politiques d'échange de produits
• Vérifier les promotions
• Prévoir la date de livraison
• Rechercher les conditions de la commande client
• Vérifier l'état de la commande
• Rechercher les commandes d'un client
• Rechercher les actifs d'un client
• Répondre aux questions avec des connaissances
• Modifier l'adresse de livraison

Rubrique 2 :

• Résoudre les problèmes techniques
• Rechercher les actifs d'un client

Étape 4 : rédiger des descriptions de classification pour les rubriques et diviser les rubriques si nécessaire

Une fois le regroupement initial en place, rédigez des descriptions de classification pour chaque rubrique.

• Dans notre exemple, la rubrique 2 concerne clairement les problèmes techniques liés aux produits.
• La rubrique 1 couvre toutefois un champ d'application plus large. Il s'agit principalement de la gestion des commandes, mais elle contient certaines actions qui ne sont pas liées à la gestion des commandes, telles que la vérification des promotions et la réponse aux questions avec des connaissances. La rubrique 1 ne peut pas être décrite de manière claire et concise en une seule phrase. Par conséquent, elle doit être divisée en plusieurs rubriques.

Après affinage, nous obtenons :

• Rubrique 1 : gestion des commandes : décrit les actions liées à la gestion et à la modification des commandes des clients et à la logistique associée, à l'exception de tout ce qui concerne l'échange et le retour.
  • Vérifier la disponibilité des stocks : déterminer si un produit est en stock.
  • Prévoir la date de livraison : estimer quand une commande arrivera.
  • Vérifier l'état de la commande : rechercher l'état de la commande d'un client.
  • Rechercher les commandes d'un client : récupérer toutes les commandes passées par un client.
  • Modifier l'adresse de livraison.
• Rubrique 2 : dépannage
  • Rechercher les actifs d'un client : récupérer les appareils ou les produits enregistrés par le client.
  • Résoudre les problèmes techniques : fournir une assistance technique ou des diagnostics.
• Rubrique 3 : échange : décrit les actions liées à l'échange et au retour de commandes.
  • Retourner une commande : lancer le processus de retour d'une commande.
  • Vérifier les politiques d'échange de produits : fournir des règles d'échange pour les produits.
  • Rechercher les commandes d'un client : récupérer toutes les commandes passées par un client.
  • Rechercher les conditions de la commande client : récupérer toutes les conditions relatives à une commande.
• Rubrique 4 : assistance produit : décrit les actions transversales utilisées pour la récupération et l'acheminement des informations.
  • Répondre aux questions avec des connaissances : répondre aux demandes générales des clients à l'aide des informations de la base de connaissances.
  • Vérifier les promotions : voir les promotions ou remises en cours.

Pour récapituler, créez d'abord une liste complète de toutes les actions possibles, puis marquez le chevauchement sémantique entre ces actions. Ensuite, créez un ensemble de rubriques qui, au minimum, résout tous les chevauchements sémantiques (afin que le moteur de raisonnement visualise clairement les limites d'une rubrique). Écrivez ensuite la description de la classification de chaque rubrique. Si le champ d'application des rubriques est trop large, divisez-les en rubriques plus granulaires. En suivant ces conseils, vous pouvez créer un agent qui non seulement fonctionne bien, mais qui est également facile à maintenir et à étendre.

Cette structure permet un meilleur raisonnement, une exécution plus précise et des limites de décision plus claires dans le comportement de l'agent. Elle s'appuie également sur la collaboration entre les concepteurs, les ingénieurs et les experts en la matière pour rendre les capacités de l'agent plus transparentes et modulaires.

Autres éléments à prendre en compte pour la création de rubriques efficaces

• Nombre optimal de rubriques : pour améliorer les performances des LLM en matière de classification dans la bonne rubrique, il est généralement conseillé de ne pas dépasser 10 rubriques. Mais ce n'est qu'une règle empirique. De plus, chaque rubrique doit avoir une description claire et distincte. En fin de compte, le nombre optimal de rubriques dépend de la distance sémantique entre les descriptions de classification des rubriques. Si les rubriques ont des descriptions de classification qui diffèrent beaucoup, le risque de chevauchement des rubriques est minimisé. D'autres meilleures pratiques pour éviter les chevauchements entre les rubriques sont décrites ici .
• Équilibre entre la taille et la clarté de la rubrique : bien qu'il soit généralement avantageux d'avoir de petites rubriques en termes d'actions et d'instructions, car cela facilite la classification, la création d'un trop grand nombre de rubriques avec des descriptions très similaires peut entraîner de la confusion, tout comme le chevauchement sémantique entre les actions conduit à une mauvaise classification. Il est donc important d'avoir des descriptions de rubriques clairement différenciées sémantiquement. Vous pouvez utiliser les LLM pour vous aider à créer ces classifications bien différenciées.
• Langage standard et clarté contextuelle : les LLM peuvent ne pas connaître les significations et abréviations spécifiques de l'entreprise ou du secteur. Utilisez un langage standard ou soyez très explicite en expliquant la signification des mots dans votre contexte particulier.
• Seuls le nom et la description de la rubrique sont envoyés dans le prompt de la rubrique. Par conséquent, la modification du champ d'application ou des instructions de la rubrique n'aura aucun impact sur la sélection de la rubrique.

Exemple concret

Imaginez qu'un agent de service reçoive une demande de garantie pour une montre. Le problème de garantie ne semble pas être lié à l'échange de produit ou à l'assistance. La gestion des commandes semble être la rubrique la plus appropriée pour répondre à cette demande. Par conséquent, le moteur de raisonnement choisit cette rubrique comme étant la plus probable pour répondre à la demande.

Après la sélection de la rubrique, le moteur de raisonnement sélectionne les bonnes actions à exécuter à partir de la rubrique sélectionnée. Encore une fois, le LLM du moteur de raisonnement est en charge de cette étape, pour laquelle il utilise un autre prompt appelé prompt d'observation. L'objectif du prompt d'observation est d'obtenir l'étape suivante du processus de raisonnement. L'étape suivante peut être l'une des suivantes :

• Lancer une action
• Demander à l'utilisateur de saisir des actions
• Demander des éclaircissements sur la demande de l'utilisateur
• Envoyer la réponse finale à l'utilisateur (en répondant à la demande de l'utilisateur) une fois la boucle d'action terminée (pour plus de détails, voir Étape 3 du raisonnement)

La saisie dans le prompt d'observation est formée par toutes les descriptions de toutes les actions de la rubrique, ainsi que par l'historique des conversations.

Les meilleures pratiques à suivre pour la conception d'actions

Les actions sont les tâches prédéfinies que l'agent peut effectuer pour faire son travail. Les actions sont les définitions les plus fines du travail. Il existe cinq types différents d'actions de l'agent : (1) exécuter le code Apex, (2) appeler une API, (3) exécuter un flux, (4) obtenir une réponse LLM à un modèle de réplique et (5) appeler un modèle prédictif. La plupart de ces actions peuvent être déterministes. Une exception est l'obtention d'une réponse à un modèle de réplique (à condition que le système externe, le flux ou l'action Apex ne contienne pas d'éléments probabilistes tels que les invocations de prompt). Nous aborderons ces questions dans le cinquième niveau du contrôle agentique.

1. Contrôle du comportement agentique dans les actions de prompt : Il existe deux façons d'appliquer un contrôle sur le comportement de l'agent dans les actions de prompt : (1) ajouter plus d'instructions au modèle de réplique par le biais de l'ingénierie en répliques, et (2) configurer les hyperparamètres du LLM qui génère la réponse au prompt, en particulier la température (voir la documentation ). La réduction de la température diminue la variabilité des réponses générées, ce qui augmente leur reproductibilité et la fiabilité des agents.
2. Nombre optimal d'actions dans une seule rubrique : comme pour le nombre maximal de rubriques, le nombre d'actions à l'intérieur d'une rubrique ne doit pas dépasser 10. Mais encore une fois, il s'agit d'une règle empirique. Le véritable facteur est la distance sémantique entre les actions. Lorsque les actions se distinguent clairement par leur description, ce nombre peut être plus important. Cependant, il n'existe pas de mesure numérique pour la distance sémantique ; cela dépend de l'interprétation du générateur d'agent. Plus la différence de signification entre les descriptions d'action est grande, plus la distance sémantique l'est aussi. Il faut éviter à tout prix les chevauchements ici.
3. Description des actions : contrairement à ce que son nom suggère, l'« instruction d'action » sert en réalité d'instruction que le LLM du moteur de raisonnement utilise pour sélectionner la bonne action dans la rubrique. Notez que l'utilisation de descriptions d'actions sémantiquement distinctes peut considérablement améliorer la qualité de leurs classifications. Lisez attentivement ces descriptions, et comparez en particulier toutes les descriptions d'actions appartenant à une même rubrique.

Exemple concret

Continuons avec l'exemple précédent dans lequel un agent de service a reçu une question concernant la politique de garantie d'une montre. Après avoir sélectionné la rubrique Gestion des commandes, l'action la plus probable est choisie. Comme il s'agit de la rubrique Gestion des commandes, la première étape logique consiste à rechercher la commande (sinon, qu'est-ce qui permet de récupérer les informations sur la garantie ?) en lançant l'action de recherche de commande.

L'énoncé d'un utilisateur peut déclencher l'exécution de plusieurs actions avant qu'une réponse ne soit renvoyée à l'utilisateur. Cela est dû à la boucle agentique, qui continue à sélectionner et à exécuter l'action suivante la plus appropriée jusqu'à ce que l'une des conditions suivantes soit remplie :

• Le LLM du moteur de raisonnement détermine que la demande est complète. Dans le cas présent, il constate que la demande de l'utilisateur est satisfaite par la réponse. Notez qu'une partie de cette vérification comprend une vérification de la contextualisation, qui s'assure que la réponse est contextualisée dans les réponses de l'action. Aucune information dans la réponse ne doit être inventée par le LLM du moteur de raisonnement, car cela peut conduire à des hallucinations ou à des réponses incorrectes.
• Aucune autre action appropriée n'a été trouvée.
• Le nombre maximal d'appels LLM autorisés pour l'étape en cours est atteint. Ce nombre est défini par le moteur de raisonnement lui-même.

Les actions ne sont pas soumises à un délai d'attente spécifique. Cela permet d'éviter les interruptions lorsque les délais d'exécution des actions varient en fonction de leur complexité. Certaines actions sont tout simplement plus complexes à exécuter que d'autres.

Exemple concret

Après avoir lancé une recherche de commande, le moteur de raisonnement évalue la réponse générée jusqu'à présent, puis décide qu'il doit effectuer plus de travail avant qu'une réponse puisse être renvoyée à l'utilisateur. Il est sur le point de consulter la politique de garantie, maintenant que la commande est présente dans l'historique des conversations.

Cependant, ce faisant, l'agent se rend compte que le client a en réalité acheté deux montres, comme le montre l'action de recherche de commande. Par conséquent, dans la boucle agentique, le moteur de raisonnement décide désormais de demander au client de préciser pour quelle montre il a besoin d'informations sur la garantie.

Évitez de trop scénariser

Évitez de créer des scripts excessifs sur la manière dont les agents doivent converser avec les utilisateurs. L'overscripting peut empêcher un agent d'établir une relation, de comprendre les besoins uniques des utilisateurs et de répondre efficacement en temps réel à des circonstances dynamiques. De plus, de longues instructions peuvent ralentir la réponse de l'agent et compliquer la tâche du moteur de raisonnement. Forcer le déterminisme par des instructions n'est pas l'approche privilégiée.

À ne pas faire

Par exemple, il n'est pas nécessaire de dire à un agent d'éviter de faire référence aux concurrents dans les réponses de service. Cela peut conduire à un comportement indésirable, car l'agent peut également refuser de répondre à des questions relatives à l'intégration avec un fournisseur qui est également un concurrent. Au lieu de cela, l'instruction peut être quelque chose comme « Lorsque vous parlez des concurrents, répondez en gardant à l'esprit l'intérêt de l'entreprise ». Cela évite les instructions restrictives et conditionnelles telles que « Mentionner le concurrent xyz uniquement dans le cas de… », et exploite à la place les capacités de raisonnement du LLM. Cet exemple montre comment les instructions peuvent être données à un niveau plus élevé et plus abstrait, de la même manière qu'un employé humain serait formé après avoir rejoint l'entreprise.

Voyons d'autres exemples de ce qu'il ne faut pas faire. Il s'agit de mauvaises instructions données à un agent de service qui traite les profils des candidats sur un site Internet de recrutement. Ces instructions tentent d'anticiper tous les énoncés possibles des clients et doivent donc être évitées :

Instruction 1 : L'agent reçoit l'énoncé suivant : « Puis-je ajouter une photo à mon profil ? » et demande immédiatement au client : « Quel est votre type de profil ? ».

Instruction 2 : si le client indique qu'il dispose d'un profil Premium, répondez « Laissez-moi vérifier les détails de votre contrat », puis recherchez les détails du contrat et vérifiez s'il a été convenu qu'il peut mettre à jour la photo de profil.

S'il a été convenu que le candidat peut le faire, répondez « Oui, je peux effectuer la mise à jour pour vous. Pouvez-vous fournir votre nouvelle photo ? ». Une fois la photo reçue, mettez à jour le profil du candidat en conséquence. Si le contrat n'inclut pas de modifications de la photo de profil, dites « Désolé, ce n'est pas possible. Laissez-moi vous diriger vers un agent humain. ».

Instruction 3 : Profil non Premium : si le client indique qu'il dispose d'un profil non Premium, répondez « Vous ne pouvez pas mettre à jour votre photo. Si vous souhaitez le faire, dites-le-moi et je vous transférerai vers un agent humain. ».

Instruction 4 : si le type de profil n'est pas clair, répondez par « Je n'ai pas compris votre type de profil. ».

Approche à privilégier

Au lieu de ce type de micro-gestion, utilisez une approche plus flexible qui indique le comportement et la conduite des agents. Tenez compte des meilleures pratiques suivantes :

1. Utilisez les actions RAG / Knowledge pour les politiques et règles contenues dans les articles de connaissance (au lieu de les rédiger sous forme d'instructions). Les informations pertinentes sont récupérées au bon moment. Dans l'exemple ci-dessus, cela signifie qu'un article de connaissance intitulé « Mise à jour de la photo » doit indiquer : « Seuls les candidats disposant d'un profil Premium et dont le contrat permet de modifier leur image peuvent mettre à jour leur image. »
2. Décrivez les principales directives et les garde-fous individuellement, indépendamment de la conversation. Fournissez aux agents une explication claire et concise du comportement attendu ou de la procédure en question.

Sur la base de ces meilleures pratiques, ce qui suit pourrait être un meilleur ensemble d'instructions :

Instruction 1  : « Utilisez les actions de connaissance pour vérifier les politiques en cas de demandes de modification de compte. »

Instruction 2  : « Ne répondez pas aux questions pour lesquelles aucune politique applicable n'a pu être trouvée. »

Le respect des directives ci-dessus peut améliorer les résultats des agents. Désormais, si le client demande à l'agent de modifier son profil, l'agent comprendra qu'il doit récupérer la politique requise dans la base de connaissances, interpréter les règles récupérées, appliquer ces règles au contexte et enfin répondre au client. Par opposition à l'overscripting, cette approche comportementale est beaucoup plus générique et largement applicable. Sans avoir à écrire chaque conversation possible, l'agent peut désormais répondre de manière flexible avec le comportement souhaité à un plus large éventail de sujets de conversation.

Appliquer la séquence d'actions (ne s'applique pas au script d'agent)

Le prompt d'observation comprend des instructions et des descriptions d'actions, mais aucun ordre n'est défini. Si la séquence d'actions est critique, cela doit être explicitement indiqué dans la même instruction. Veuillez noter qu'avec le script d'agent, nous pouvons imposer un ordre d'exécution grâce à des transitions. Cela vous sera expliqué plus en détail dans le sixième chapitre.

Continuons avec l'exemple des agents de sites Internet de recrutement. L'agent doit être en mesure de gérer la planification des entretiens avec la personne en charge de ces derniers. Pour ce faire, l'agent doit d'abord vérifier la disponibilité des recruteurs, puis proposer trois créneaux possibles au candidat.

Dans ce cas, afin de conserver l'ordre d'exécution, les instructions ne doivent pas être placées dans des cases distinctes :

1. Instruction 1 : Vérifiez les disponibilités des personnes en charge des entretiens.
2. Instruction 2 : Ensuite, proposez des créneaux appropriés au candidat.

Ces instructions ne produisent aucun effet, car le moteur de raisonnement ne sait pas à quoi fait référence « Then » dans l'instruction 2. Cela est dû au fait que les instructions sont envoyées au moteur de raisonnement sous forme de groupe, sans ordre particulier.

Au lieu de cela, les instructions définissant les séquences doivent être combinées en une seule déclaration et rédigées comme suit :

1. Instruction 1 : Vérifiez la disponibilité des personnes en charge des entretiens. Ensuite, proposez des créneaux appropriés au candidat.

Appliquer les résultats d'actions sans réécriture

Le moteur de raisonnement est lui-même un LLM. Il est chargé de générer la réponse finale en fonction de la boucle agentique. L'approche est nécessaire pour appliquer les instructions des agents qui fournissent des garde-fous à la génération de réponses, ou pour combiner les réponses de plusieurs actions qui faisaient partie de la boucle agentique, afin de répondre à la demande de l'utilisateur.

Cependant, lorsque l'on s'attend à ce qu'une seule action de prompt ait été exécutée, une instruction peut être mise en œuvre pour demander à l'agent de ne jamais modifier la réponse d'une action. Ainsi, le comportement des agents est plus prévisible et plus fiable.

Le respect strict de ces éléments dans les modèles de réplique approuvés devient crucial dans certains scénarios, en particulier lorsque la cohérence, la conformité et la messagerie prédéfinie sont importantes. Voici deux exemples :

• Secteurs d'activité réglementés : les organisations opérant dans des secteurs hautement réglementés (tels que la finance, la santé ou le juridique) exigent souvent un contrôle strict de toutes les communications directes avec les clients. Les modèles de réplique approuvés garantissent que les réponses sont conformes aux exigences légales et réglementaires, ce qui minimise le risque de mauvaise interprétation, de responsabilité ou de diffusion d'informations inexactes.
• Réponses prétestées et validées : Lorsque les modèles de réplique ont fait l'objet de tests rigoureux et d'une validation pour garantir l'exactitude, l'efficacité et les résultats souhaités. S'écarter de ces modèles peut nuire à leur efficacité et à leur valeur. Le strict respect garantit que le message éprouvé est fourni de manière cohérente.

Cette instruction limite la liberté de l'agent de modifier la réponse des actions. Assurez-vous que l'instruction fait référence à la réponse du modèle de réplique (par exemple « promptResponse »), comme indiqué dans ce traceur de plan.

Dans ce cas, l'instruction peut être la suivante :

«  Ne modifiez pas la réponse promptResponse, quel que soit le canal de l'agent.  »

Limites à l'application d'un respect strict :

Lorsqu'une interaction nécessite plusieurs actions distinctes de l'agent, il n'est pas possible de faire respecter strictement un modèle unique. En réalité, dans ce scénario, le moteur de raisonnement doit consolider ces actions en une seule réponse, et donc modifier le résultat de chaque action.

Nombre optimal d'instructions

Sur la base des caractéristiques générales du LLM, le nombre cible d'instructions est compris entre 5 et 10, en fonction de la complexité de l'instruction et de l'interaction avec l'instruction. Ces caractéristiques d'instruction influencent le nombre d'instructions que le moteur de raisonnement peut suivre :

• Clarté et spécificité : les règles bien définies sont plus faciles à suivre.
• Conflits entre les règles : si les règles se contredisent, une logique supplémentaire est nécessaire pour les résoudre.
• Longueur et complexité : si chaque règle nécessite un raisonnement approfondi, envisagez de les décomposer en instructions plus petites.

Si une instruction est très importante à suivre explicitement, ajoutez des termes qui reflètent son importance :

• Urgence et importance (immédiate, urgente, critique, essentielle, obligatoire)
• Autorité et exécution (requise, obligatoire, strictement appliquée)
• Conséquences et avertissements (la violation entraînera, le non-respect entraînera, la non-conformité peut entraîner, des sanctions strictes s'appliqueront, tolérance zéro)
• Clarté et franchise (doit, interdit, non autorisé, toujours/jamais)

Le fait d'ancrer les réponses dans les données améliore considérablement la fiabilité et la crédibilité des agents. Les réponses ancrées reposent sur des informations factuelles plutôt que sur des spéculations ou des connaissances obsolètes. La génération augmentée de récupération (RAG) est une technique largement adoptée qui permet à un agent d'accéder à une base de connaissances et de l'utiliser afin de formuler des réponses plus précises et plus pertinentes selon le contexte. En fonction de la requête d'un utilisateur, un agent utilise la RAG pour extraire les informations pertinentes des sources de données applicables, puis enrichit le prompt avec ces informations avant de l'envoyer au LLM. Un agent utilisant la RAG offre une meilleure qualité ainsi qu'une plus grande justesse, et l'utilité globale des interactions entre agents est accrue, ce qui renforce la confiance et la satisfaction des utilisateurs. Les meilleures pratiques en matière de RAG sont décrites en détail dans un livre blanc accessible au public intitulé Agentforce and RAG: best practices for better agents.

Connaissances et instructions

Il est important de faire la différence entre les connaissances et les instructions pour trouver le bon équilibre entre les conseils et la flexibilité, car elles remplissent des objectifs différents :

• Connaissances : pensez aux connaissances comme à la bibliothèque de livres à laquelle l'agent a accès lorsqu'il génère ses réponses. Les documents, les articles de connaissances et les livres blancs en sont des exemples. Il peut s'agir de politiques et de règles générales de l'entreprise. Les connaissances peuvent également faire référence à des fichiers transactionnels, tels que les e-mails, les transcriptions d'appels et même l'historique des conversations (de l'agent). Enfin, les connaissances incluent les champs de texte long dans les données structurées. Les connaissances sont généralement apportées à l'agent par le biais de la RAG.
• Instructions : les instructions sont l'ensemble minimal de règles qui expliquent à l'agent à quel moment utiliser chaque action. Les instructions peuvent également placer des garde-fous sur l'ensemble de la conversation, comme le ton requis. Souvent, les instructions peuvent être rendues plus concises et flexibles sans diminuer la clarté ou l'intention. Au lieu de fournir un script rigide avec des réponses spécifiques pour chaque scénario client possible, envisagez de mettre en œuvre des directives et des principes généraux qui aident l'agent à choisir la ou les bonnes actions dans diverses situations.

Génération augmentée de récupération

La génération augmentée de récupération (RAG) agit comme une couche de données intelligente pour les connaissances. Elle permet aux agents d'accéder aux informations dans différents formats et fournit des fragments de texte pertinents pour répondre aux questions. Avec la RAG, les agents peuvent obtenir des réponses LLM plus précises sans submerger le prompt LLM de contenu étranger ou dépasser sa fenêtre contextuelle.

Au moment de l'exécution, la RAG exécute trois étapes :

1. Récupération : le système d'IA effectue une recherche dans une grande base de données ou une source de connaissances afin de recueillir des informations pertinentes pour le prompt LLM. Pour ce faire, la recherche sémantique est une technique plus sophistiquée que la recherche traditionnelle par mots-clés. Contrairement à la recherche par mots-clés, qui recherche des termes exacts, la recherche sémantique comprend la signification ou le contexte derrière les mots. Elle identifie les informations pertinentes sur la base des concepts ou des relations entre les termes, plutôt que de simplement rechercher des correspondances précises de mots. La recherche par mots-clés peut également jouer un rôle dans ce processus de récupération, en renforçant la recherche sémantique grâce à la correspondance par mots-clés pour une terminologie ou des noms spécifiques. Ce type de recherche est appelé recherche hybride.
2. Augmentation : les informations récupérées sont ajoutées au prompt.
3. Génération : le LLM génère une réponse contextuellement appropriée et plus précise grâce au prompt qui a été complété par les connaissances récupérées.

Dans Agentforce, la RAG peut être utilisée avec ou sans modèle de réplique :

1. RAG basée sur les prompts : dans cette approche, les instructions qui spécifient comment générer la réponse se trouvent dans les instructions de prompt d'un modèle de réplique. Dans ce cas, la réponse dépend entièrement de ce que le LLM génère. En plus des instructions de prompt, il existe des moyens d'influencer la réponse, tels que les paramètres de configuration LLM dans Einstein Studio, mais le résultat n'est toujours pas déterministe.
2. RAG basée sur le moteur de raisonnement : Au lieu d'utiliser un modèle de réplique, l'agent utilise une action qui récupère des fragments (via un flux ou une classe Apex) et les stocke dans une variable (voir la section suivante). Dans cette approche, le moteur de raisonnement (au lieu du LLM) génère des réponses directement, basées sur les données récupérées. Les instructions qui régissent la génération des réponses sont des instructions d'agent plutôt que des instructions de modèle de réplique. La variable qui contient le contenu récupéré peut toujours être transmise explicitement comme entrée à une action. Elle peut également être remise au moteur de raisonnement en lui accordant un accès par défaut au contenu de la variable. Cette approche nécessite des compromis. Il existe un risque potentiel de surcharge du moteur de raisonnement avec du contenu et des responsabilités. De plus, contrairement à un prompt, les paramètres du LLM du moteur de raisonnement ne sont pas configurables. D'autre part, le moteur de raisonnement peut générer sa réponse en utilisant à la fois les fragments récupérés et l'historique de la conversation.

La méthode recommandée est l'option 1. Elle réduit le nombre de tâches que le moteur de raisonnement doit effectuer et améliore ainsi la qualité de ses réponses. La section suivante explore une exception à cette règle, dans laquelle le contenu est préservé tout au long de la conversation et est donc attribué explicitement à une action.

Meilleures pratiques RAG

• Éviter les instructions de génération augmentée de récupération (RAG) scénarisées : au lieu de lier directement les instructions à des articles spécifiques pour des questions particulières, exploitez l'intelligence de la RAG pour trouver dynamiquement la source de données et le fragment de texte le plus pertinent. Le processus de mise en correspondance de la RAG repose sur une compréhension plus large de la question, et pas uniquement sur une mise en correspondance exacte entre la question et la source.
• Consolider les rubriques : regroupez les catégories de questions apparentées sous une seule rubrique. La RAG peut identifier efficacement les réponses pertinentes en fonction du type de question, y compris dans une rubrique plus large. Par exemple, les problèmes liés aux produits, tels que la maintenance et les défauts de batterie, peuvent être regroupés sous une rubrique plus générale.
• Stockage du résultat de la RAG dans une variable : lorsque le nombre de limites d'interaction peut être atteint, stockez le résultat de la RAG dans une variable. Les informations restent ainsi accessibles pour guider les interactions des agents au-delà du seuil standard. Un exemple vous sera fourni dans la section suivante.

Certains processus métier exigent une exécution encore plus prévisible, comme l'application d'une séquence d'actions ou de conditions spécifiques pour déclencher des actions ou des rubriques.

Pour obtenir ce comportement déterministe, des variables peuvent être utilisées. Les variables fonctionnent comme une forme structurée de mémoire d'agent à court terme qui peut servir de saisies ou de réponses d'action. De plus, l'état d'une variable peut régir le déclenchement de rubriques et d'actions spécifiques.

Façons dont les variables soutiennent la détermination

Les variables peuvent aider à atteindre le déterminisme guidé des agents des manières suivantes :

1. Contextualisation dynamique persistante : les variables permettent aux agents de mettre à jour en permanence leur compréhension du monde tout en conservant des informations importantes qui ne sont pas affectées par les interactions ultérieures. Cette méthode garantit que les informations critiques, qui peuvent être des données non structurées récupérées via la génération augmentée de récupération (RAG), ou des données structurées telles que les informations de profil d'utilisateur, sont conservées tout au long de la conversation, quelle que soit la durée de la conversation.
2. Saisies/réponses de l'action : les variables peuvent être utilisées à la fois comme saisie et réponse pour les actions. L'action fait explicitement référence à des variables, et l'exécution de l'action ne repose pas sur le moteur de raisonnement pour définir ces saisies et ces réponses, ce qui augmente le déterminisme de l'agent.
3. Filtrage : les variables peuvent être utilisées pour déterminer l'exécution conditionnelle d'actions ou de rubriques. Les variables permettent un flux d'informations spécifique entre les actions et le déterminisme dans l'exécution des actions. Cette capacité est particulièrement importante pour les règles de sécurité dans lesquelles il est impossible de lancer des actions si des variables d'entrée spécifiques, telles que l'e-mail, ne sont pas vérifiées.

Types de variables dans Agentforce

Agentforce a deux types de variables :

• Les variables de contexte sont des variables générées par le système qui contiennent des informations sur l'utilisateur et les sessions de conversation.
• Les variables personnalisées peuvent être instanciées par l'utilisateur. Elles contiennent tout type d'information utilisée pour l'une des trois manières dont les variables soutiennent le déterminisme.

Les types de variables prennent en charge les capacités suivantes :

Penchons-nous un peu plus sur les variables avec un exemple de cas d'usage : un agent de dépannage en contact avec le client. Dans cet exemple, les variables sont utilisées pour les trois objectifs : contextualisation dynamique persistante, saisies/réponses d'action et filtrage.

Dans cet exemple, l'agent aide un client à résoudre un problème technique lié à un appareil. Le dépannage implique généralement de passer par un certain nombre d'étapes. L'agent doit offrir une expérience de service qui imite le travail d'un agent de service humain. Pour ce faire, l'agent ne doit pas fournir toutes les étapes de dépannage au client en même temps. Au lieu de cela, il doit proposer des instructions étape par étape, ainsi que la possibilité de naviguer entre les étapes (y compris de revenir aux étapes précédemment couvertes) en fonction de la manière dont le client répond.

La capacité de l'agent à conserver toutes les étapes de dépannage tout au long de la conversation est un défi. Étant donné la mémoire limitée de l'agent en raison du nombre restreint d'interactions qu'il peut stocker, ces étapes peuvent être supprimées du contexte du moteur de raisonnement si la conversation devient longue.

Pour relever ce défi, il est possible d'utiliser une variable pour contextualiser le moteur de raisonnement de manière dynamique au cours des étapes de dépannage. En récupérant les informations et en les stockant dans une variable, elles restent disponibles et peuvent être mises à jour tout au long de la conversation. Le moteur de raisonnement utilise les informations stockées dans cette variable pour la contextualisation dynamique.

Dans cet exemple, une rubrique comprend deux actions. Ces deux actions sont nécessaires pour maintenir un flux de données cohérent. La première action est utilisée pour renseigner la variable qui contient toutes les étapes de dépannage. La deuxième action utilise cette variable pendant le dépannage lui-même.

1. Action 1 : « Renseigner les étapes de résolution des problèmes ». Il s'agit de l'action initiale, déclenchée par la première présentation du problème à l'agent. Elle utilise la génération augmentée de récupération (RAG) pour extraire toutes les étapes de résolution nécessaires d'une base de connaissances indexée. L'action stocke la réponse obtenue dans une variable nommée « Étapes de résolution ».
2. Action 2 : « À utiliser lors de la résolution d'un problème ». Il s'agit d'une action basée sur un prompt qui renvoie l'étape de dépannage la plus probable à utiliser au cours du processus de dépannage. L'agent est invité à utiliser cette action lorsqu'il est en train de résoudre un problème.

La question initiale du client sert de saisie pour les deux actions. La deuxième action a une autre saisie : le contenu de la variable « Étapes de résolution ». Cette variable a été définie par la première action. Notez que la deuxième action ne récupère pas les étapes de dépannage elle-même, mais les récupère en tant que saisie de la première action via la variable. Le diagramme suivant illustre le flux de données entre ces deux actions.

L'action « À utiliser lors de la résolution d'un problème » fera toujours référence aux étapes de dépannage d'origine récupérées par l'action Étapes de résolution des problèmes. Ce flux de données garantit que les étapes de dépannage sont maintenues de manière cohérente et qu'elles sont toujours présentes, quelle que soit la durée de la conversation.

Pour exécuter les actions définies dans cet exemple, des instructions spécifiques sont nécessaires, telles que « Toujours exécuter les étapes de Renseigner les étapes de résolution des problèmes en premier ». Cependant, étant donné la nature non déterministe des LLM utilisés par les agents, cela peut conduire à un ordre différent dans certains cas. Pour garantir un ordre d'exécution déterministe, nous introduisons des filtres conditionnels sur ces variables afin d'appliquer la séquence d'actions appropriée. L'agent lit la valeur de la variable « Étapes de résolution » et définit deux filtres selon que cette variable a une valeur ou non.

• L'action Étapes de résolution des problèmes ne peut être exécutée que si la variable « Étapes de résolution » est vide.
• L'option « À utiliser lors de la résolution d'un problème » ne peut être exécutée que si la variable « Étapes de résolution » est remplie.

Ces filtres conditionnels appliquent désormais de manière déterministe la séquence d'exécution de l'action : « À utiliser lors de la résolution d'un problème » doit attendre que « Étapes de résolution d'un problème » soit terminée, garantissant ainsi que la variable « Étapes de résolution » a toujours une valeur.

Pour garantir l'exécution correcte de l'action, une troisième action est nécessaire pour réinitialiser la variable « Étapes de résolution » si le problème est entièrement résolu. Par conséquent, l'agent est réinitialisé à l'état requis pour aider à résoudre un éventuel nouveau problème différent. Cette troisième action est appelée « Vider la variable de résolution ». Le diagramme complet de l'action figure ci-dessous.

Les variables sont essentielles pour permettre à notre agent de dépannage de résoudre les problèmes des clients en permettant :

• Une contextualisation dynamique persistante : les variables stockent les étapes de dépannage, en veillant à ce qu'elles soient disponibles tout au long de la conversation, quelle que soit la durée ou le nombre d'interactions. Cela empêche l'agent d'oublier le contexte.
• Un flux de données : les variables simplifient le flux de données entre les actions. Par exemple, la variable « Étapes de résolution » stocke les étapes de dépannage récupérées à partir de l'action Étapes de résolution des problèmes et les fournit comme saisie pour l'action « À utiliser lors de la résolution d'un problème ».
• Le déterminisme : les variables peuvent être utilisées comme filtres pour appliquer un ordre spécifique d'exécution des actions. Par exemple, l'action À utiliser lors de la résolution d'un problème ne s'exécute que si la variable Étape de résolution est remplie, ce qui garantit que l'action Étapes de résolution d'un problème s'exécute en premier.

À l'ère de l'IA générative, l'IA prédictive reste d'une importance cruciale, dans la mesure où elle constitue l'intelligence fondamentale qui guide, améliore et contextualise les capacités génératives. Alors que l'IA générative se concentre sur la création de contenus (tels que du texte, des images ou des vidéos), les modèles prédictifs émettent des prévisions sur l'avenir à partir de données d'entreprise en temps réel. Parmi les exemples de résultats commerciaux, citons la probabilité d'attrition des clients, les probabilités de conversion, la probabilité de remontée des requêtes, la valeur à vie du client et la classification des cas. Les prédictions peuvent aider à anticiper les besoins des utilisateurs, à personnaliser les réponses, à prendre des décisions, à optimiser la pertinence du contenu en temps réel, le tout en analysant les tendances et les chiffres. Par exemple, dans des applications telles que l'apprentissage personnalisé, les soins de santé ou la planification financière, l'IA prédictive garantit que les réponses génératives s'alignent sur les contextes individuels et les scénarios futurs probables. Ensemble, l'IA prédictive et générative créent une puissante synergie, en fusionnant la prévoyance et la créativité pour créer des solutions technologiques plus intelligentes, adaptatives et percutantes.

Intégrer le résultat d'un modèle prédictif dans les workflows des agents

Pour intégrer les réponses des modèles prédictifs dans les flux de travail des agents, il suffit d'ajouter des actions de modèles prédictifs aux actifs Agentforce. Le générateur de modèles permet de créer ou d'enregistrer des modèles prédictifs (BYO), qui sont ensuite utilisés par l'agent pour faire des prédictions. Les prédictions qui en résultent (ainsi que les prédicteurs) peuvent être stockées dans des variables personnalisées. Les agents peuvent utiliser ces valeurs de variable comme saisies pour des actions et des rubriques spécifiques et définir des conditions pour l'exécution de ces dernières.

Exemples de cas d'usage intégrés avec des modèles prédictifs

• Segmentation : Effectuez une classification multi-classes pour la segmentation des clients et utilisez le segment résultant pour filtrer certaines actions. Par exemple, réservez des actions Premium aux clients de niveau Premium.
• Probabilité d'escalade : prédisez la probabilité d'une escalade pour un cas de service. Si cette probabilité dépasse un certain seuil, autorisez l'exécution d'actions qui résolvent le cas plus rapidement ou transmettent plus rapidement aux agents humains.
• Biens de grande consommation : planifiez une promotion uniquement si l'augmentation des ventes (score calculé par un modèle prédictif) dépasse un certain seuil.
• Commerce : ne proposez un produit que si la propension à acheter dépasse un certain seuil.

Certains processus métier doivent être exécutés dans un ordre précis et ne nécessitent pas de saisie de l'utilisateur au cours de l'exécution. Dans ce cas, un flux prédéterminé d'étapes peut être appliqué via des flux, des API ou Apex. Si vous disposez d'un flux existant qui est utilisé en production, c'est une bonne indication qu'il peut être conservé et utilisé par l'agent pour l'exécution de ce processus métier. Tous les exemples suivants comprennent des séquences prédéterminées d'étapes que l'agent peut exécuter sans saisie de l'utilisateur. Dans ce cas, le comportement agentique consiste à identifier le processus déterministe à exécuter, comment recueillir les saisies nécessaires et comment interpréter et traiter les réponses.

Les processus métier comportant de nombreuses étapes séquentielles (plus de trois, en règle générale) et de nombreuses dépendances sur des variables deviennent trop complexes et encombrants pour être appliqués avec des instructions. Dans ce cas, il est possible de les coder simplement en dur à l'aide des types d'actions déterministes répertoriés dans cette section. Enfin, notez que ces implémentations peuvent inclure des éléments non déterministes, tels que l'appel de LLM avec des modèles de réplique résolus. Par conséquent, elles ne sont pas nécessairement complètement déterministes, de bout en bout, et elles peuvent toujours offrir les niveaux de fluidité souhaités pour lesquels les agents sont connus.

La séquence des étapes d'un parcours marketing est conditionnée par des règles fixes et ne dépend d'aucune entrée conversationnelle de l'utilisateur. Par conséquent, le flux peut être utilisé comme une action Agentforce. Une action invocable peut être créée pour effectuer des tâches déclenchées en arrière-plan ou par un événement à partir d'un composant de solution qui peut appeler un flux ou une classe Apex. Ajoutez une action invocable à un flux ou à une classe Apex et spécifiez la tâche que l'agent effectue, ainsi que les conditions qui déclenchent l'agent. Les actions invocables peuvent également porter les variables contextuelles de l'agent et transmettre des informations importantes.

Les flux Salesforce peuvent être utilisés pour automatiser les tâches de routine, telles que la création de tâches de suivi, l'envoi d'e-mails de rappel ou la mise à jour d'enregistrements. Les flux rendent le travail plus efficace et plus productif. Les agents peuvent également exécuter des flux à l'aide d'actions de flux. En raison de leur déterminisme, les flux constituent un excellent moyen d'orienter le comportement agentique lorsqu'un processus métier doit être exécuté dans une séquence particulière. Lorsque la rubrique contiendrait autrement des instructions telles que « Faites d'abord ceci, puis faites ceci, et enfin faites ceci », c'est un signe qu'une action de flux est préférée. L'application de séquences de plus de trois étapes devient lourde à gérer via des instructions et des variables.

Les flux peuvent également inclure des éléments non déterministes en appelant des prompts. Un nœud de prompt dans un flux invoque un modèle de réplique et recueille la réponse qui peut être transmise à d'autres éléments du flux. Ces éléments supplémentaires peuvent encore être des nœuds de prompt, par exemple résumant la réponse précédente, créant ainsi une chaîne de prompts. Ceci est particulièrement utile lorsque les règles de chaînage de répliques sont définies par des éléments fixes et ne dépendent pas de la saisie de l'utilisateur. La génération augmentée de récupération (RAG) agentique en est un exemple : une séquence prédéfinie de récupérateurs ou de prompts dans un flux peut accéder à des sources de données spécifiques dans un ordre particulier, par exemple en récupérant initialement des données à partir d'un document du pays d'un utilisateur avant de consulter d'autres sources si nécessaire. Ce mécanisme de chaînage permet une extraction fiable et ordonnée des informations pertinentes.

À l'instar des flux, les actions Apex et API sont déterministes en ce sens qu'une séquence prédéfinie d'actions peut être codée. Ces actions peuvent inclure des éléments non déterministes, tels que l'appel de modèles de réplique ou d'appels LLM. Cependant, dans leur définition, elles exécutent ces étapes de manière déterministe, ce qui réduit la variabilité agentique en appelant l'action au bon moment, en recueillant les données nécessaires et en traitant la réponse. Ces responsabilités doivent tout de même être régies par des instructions agentiques. Elles sont donc non déterministes. Les actions Apex et API sont l'équivalent pro-code des actions de flux.

Du raisonnement probabiliste au raisonnement déterministe

Dans les niveaux de déterminisme 1 à 5, nous avons progressivement ajouté une structure à l'environnement de l'agent. Nous avons défini ce qu'il pouvait faire (niveau 1, rubriques), puis guidé son comportement (niveau 2, instructions), nous l'avons ancré dans un contexte fiable (niveau 3, données), nous avons géré son état (niveau 4, variables) et lui avons donné des outils strictes (niveau 5, actions déterministes). Cependant, le moteur central de prise de décision est resté fondamentalement probabiliste. Le moteur de raisonnement décidait toujours lui-même de l'outil à choisir ou de la question à poser, et pour cette décision, nous nous sommes entièrement appuyés sur le modèle de langage de grande taille (LLM).

Le niveau 6, script d'agent, modifie fondamentalement cette architecture. Il introduit la capacité de coder en dur le processus de raisonnement lui-même.

Avec le script d'agent, nous passons du prompting du modèle à la création de script pour l'agent. Il ne s'agit pas d'un retour aux anciens chatbots strictes. Il s'agit d'un raisonnement hybride. Il vous permet d'intégrer la puissance créative et conversationnelle du LLM entre des couches de logique immuable et déterministe. Vous définissez explicitement le parcours critique d'exécution (les « tâches à effectuer ») tout en laissant des espaces de liberté spécifiques permettant au LLM de gérer la compréhension du langage naturel et la génération de réponses.

Lors de la conception de workflows, il est essentiel d'éviter d'utiliser des agents basés sur LLM à l'aide de scripts uniquement pour remplacer la logique déterministe lorsque les étapes suivantes sont déjà clairement définies. Si un processus suit un parcours prévisible sans avoir besoin d'un raisonnement complexe pour décoder les actions ultérieures, l'introduction d'un modèle génératif ajoute une latence inutile, des coûts et une marge d'erreur. Les flux programmatiques traditionnels restent supérieurs pour les processus purement déterministes et ne nécessitant pas de raisonnement. L'utilisation d'un LLM pour un routage simple ou des transitions linéaires est un choix trop complexe qui compromet la fiabilité d'un système pouvant être géré par un flux procédural standard.

En règle générale, les solutions agentiques doivent être envisagées lorsque le système traite des saisies non structurées qui doivent être synthétisées à partir de sources disparates et à forte variance (et éventuellement des saisies conversationnelles) avant qu'une décision ne puisse être prise.

Mais comment atteindre ce niveau de contrôle ? Il existe deux parcours distincts, conçus à la fois pour l'architecte d'entreprise et le développeur pro-code.

Intégrer le déterminisme de niveau 6 à votre agent ne nécessite pas strictement l'écriture de code. Salesforce propose deux modalités pour générer le script d'agent sous-jacent, démocratisant l'accès au raisonnement déterministe.

Pour les analystes commerciaux, les administrateurs et les spécialistes du low-code, le niveau 6 est accessible directement dans le générateur d'agents.

Nous avons introduit un canevas de style document qui sert d'interface texte-vers-script. Au lieu d'écrire du code, vous écrivez la logique de la rubrique en langage naturel structuré. Le générateur interprète ensuite votre intention et la compile dans le script d'agent en arrière-plan.

• Vous écrivez : « Tout d'abord, vérifie si la commande date de plus de 30 jours. Si c'est le cas, dis à l'utilisateur que nous ne pouvons pas accepter les retours et mets fin poliment à la conversation. Si ce n'est pas le cas, renseigne-toi sur l'état de l'article. »
• Le système compile automatiquement cette description en langage naturel dans les structures if/else, les vérifications de variables et les commandes end_conversation nécessaires.

Cela vous permet d'écrire la logique en langage naturel et de faire en sorte que la plateforme la convertisse en code, ce qui permet même aux utilisateurs non-développeurs d'appliquer des garde-fous et un déterminisme strictes.

Pour les développeurs recherchant une précision optimale, il est également possible d'écrire un script d'agent directement dans le générateur d'agents. Le canevas comprenant la description en langage naturel peut être inversé pour faire apparaître le script sous-jacent, afin que le développeur puisse coder le script directement. Cette approche permet même une expérience de création hybride : certaines instructions sont écrites en langage naturel sur le canevas, tandis que d'autres sont scénarisées (ou modifiées) directement à l'aide de code. En passant d'une expérience à l'autre, vous constaterez que les deux modalités sont toujours parfaitement alignées.

Les deux modalités exploitent tout le potentiel du niveau 6 :

• Suivi détaillé : vous pouvez suivre l'exécution du script pour voir exactement où les variables ont changé et d'où proviennent les branches.
• Gestion des boucles complexes : gérez une logique de relance sophistiquée ou bien des changements d'état à variables multiples qui sont difficiles à décrire en langage naturel.
• Contrôle des versions : traitez le comportement des agents comme du code, compatible avec les pipelines Git et CI/CD pour la gestion des versions d'agents.

Que vous produisiez un script d'agent via le générateur ou que vous l'écriviez à la main, le résultat est le même : le script d'agent est converti en un graphique d'agent qui est exécuté par Atlas Reasoning Engine.

Pour maîtriser le niveau 6, il faut comprendre ce qui se passe en coulisses. Le script d'agent contrôle le comportement par le biais de structures programmatiques spécifiques au sein de blocs de raisonnement. À la différence des prompts standard, qui sont des suggestions à suivre pour le LLM, ce sont des commandes qui seront exécutées quoi qu'il arrive. Cela se produit avant, pendant ou après le processus de raisonnement, et il existe plusieurs types de déterminisme distincts. Nous allons d'abord examiner certains de ces modèles de manière générale et fournir quelques exemples simples, puis les illustrer plus en détail avec des exemples de plans architecturaux d'agents scénarisés.

Aux niveaux 1 à 5, nous espérions que l'agent ferait quelque chose (effectuer une action) avant ou après une certaine étape du processus. Au niveau 6, nous l'y forçons. Tout ce qui est écrit dans les blocs before_reasoning et after_reasoning sera toujours exécuté, respectivement avant et après l'invocation du LLM pour raisonner sur la base d'instructions. Il peut s'agir d'exécuter d'autres actions, de passer à des rubriques, de définir des variables, etc.

Par exemple, en utilisant la commande run dans les instructions before_reasoning d'une rubrique, vous pouvez exécuter une action avant même que le LLM ne soit invoqué pour générer une réponse. Cela garantit la disponibilité immédiate des données, éliminant ainsi la latence du raisonnement ou le risque que l'agent oublie d'appeler l'outil.

Structure du script :

Avec le déterminisme conditionnel, vous pouvez utiliser une logique de programmation standard pour contrôler le flux. Cela est essentiel pour les workflows de conformité où les étapes ne peuvent pas être ignorées ou repensées.

Structure du script :

Dans cet exemple, le LLM n'a jamais la possibilité d'être sujet aux hallucinations et d'approuver la demande d'un utilisateur non VIP. La branche est sélectionnée de manière déterministe par le moteur.

La capacité de forcer l'agent à quitter la rubrique actuelle pour passer à une autre représente également un contrôle puissant. Cela évite à l'agent de rester bloqué ou de dériver vers une conversation sans rapport.

Structure du script :

Cette transition n'est pas une suggestion. Il s'agit d'une redirection forcée du flux d'exécution qui dépend de la valeur d'une variable. Notez que, bien que la redirection soit stricte et non négociable, un processus de raisonnement normal se déroule à nouveau dans la rubrique à laquelle l'agent est désormais contraint.

De plus, avec le script d'agent, vous avez la possibilité de forcer explicitement une transition d'une action à l'autre immédiatement après son exécution. Cette fonctionnalité garantit que l'agent suit un flux stricte et déterministe plutôt que de s'appuyer sur une prise de décision probabiliste ou autonome à chaque étape. En enchaînant ces actions dans une séquence prédéfinie, vous pouvez garantir l'exécution des tâches spécifiques dans un ordre précis, ce qui permet de contrôler totalement la logique et le comportement de l'agent.

Le script d'agent vous donne un accès direct en lecture/écriture à la mémoire à court terme de l'agent (variables). Vous pouvez définir explicitement des variables en fonction des résultats d'actions, ce qui évite un effet de transmission déformée où un LLM pourrait mal interpréter la sortie JSON d'un outil.

Structure du script :

Pour vraiment comprendre la puissance du script d'agent, nous devons regarder au-delà des commandes individuelles et les observer ensemble. Les modèles architecturaux suivants (dérivés de notre collection de recettes de script d'agent ) démontrent comment le déterminisme de niveau 6 résout les défis complexes de l'entreprise.

Le problème : les agents standard pâtissent souvent d'une latence de raisonnement. Ils attendent que l'utilisateur pose une question, réfléchissent à l'outil qu'ils doivent utiliser, et peuvent même demander à l'utilisateur des informations qui auraient déjà pu être récupérées. Ce n'est qu'à ce moment-là qu'ils déclenchent l'action. Cela crée une expérience lente et décousue. Le script d'agent : déterminisme pré-raisonnement.

Nous utilisons la commande run pour injecter des données avant même que le LLM ne s'active.

Exemple : l'agent de triage d'urgence. Imaginez un agent traitant un rapport de panne de courant. Au lieu de demander à l'utilisateur son adresse et d'attendre, au moment où la session démarre, le script exécute automatiquement une commande get_current_location_by_IP et check_grid_status.

Résultat : l'agent ne commence pas par « Comment puis-je vous aider ? ». Il commence par : « Je vois que vous appelez depuis le secteur nord où un incendie de transformateur a été confirmé. J'ai déjà ajouté votre foyer à la liste de restauration prioritaire. Disposez-vous d'un générateur de secours en état de fonctionnement ? »

Logique :

De longs prompts (donnant à l'agent toutes les règles en même temps) augmentent la probabilité d'hallucinations dans le processus de raisonnement. L'agent oublie la règle A, parce qu'il regarde la règle Z.

La solution de script d'agent : injection d'instructions juste à temps avec ancrage conditionnel grâce à une combinaison de génération augmentée de récupération (RAG) et de logique conditionnelle. Elle montre uniquement à l'agent les règles qui s'appliquent au moment exact de la conversation.

Exemple : fournir des règles pour les offres non éligibles. Pourquoi donner à l'agent les règles relatives aux demandes d'augmentation des limites de crédit, alors que la cote de solvabilité du client ne le permet pas ?

Logique :

L'ancrage conditionnel élimine la possibilité d'erreur en supprimant entièrement les informations susceptibles de créer une perturbation lorsqu'elles ne sont pas nécessaires.

Le problème : dans une conversation complexe avec un agent (comme une demande de prêt hypothécaire, un entretien de présélection ou une session de dépannage technique), l'agent détient une liste de questions obligatoires afin que toutes les informations nécessaires soient récupérées auprès de l'utilisateur. Cependant, les utilisateurs vont souvent s'écarter du sujet. Un agent standard peut suivre le fil et oublier de revenir à ces questions obligatoires, laissant la candidature ou la conversation incomplète.

Au cœur de ce système se trouve la navigation avec état, qui traite la conversation comme une liste de contrôle rigoureuse qui doit être entièrement cochée avant qu'une transition ne puisse avoir lieu.

Grâce à la navigation avec état, l'agent passe d'une rubrique à l'autre uniquement en fonction de l'état actuel de la variable ou reste contraint dans une rubrique jusqu'à ce que des conditions spécifiques soient remplies. Cela empêche l'agent de suivre des parcours inadmissibles, même lorsqu'un utilisateur tente de faire dévier la conversation avec des digressions. Par exemple, dans une demande de prêt hypothécaire à enjeux élevés, si un utilisateur demande les heures d'ouverture d'une agence, l'agent ne se contente pas de suivre son but premier. Au lieu de cela, le script détecte la digression et peut déclencher une transition forcée vers une rubrique de réinitialisation de conformité. En contraignant l'agent dans un « espace logique » spécifique, il devient mathématiquement impossible pour lui d'évoquer des rubriques non approuvées ou de quitter une session tant que toutes les variables indispensables n'ont pas été récupérées avec succès.

Exemple : l'inspecteur de maintenance. Un agent guide un technicien lors d'un contrôle de sécurité en 10 points sur un moteur d'avion. Le technicien dit : « Attendez, j'ai remarqué une égratignure sur le fuselage. »

Comportement :

1. L'agent confirme l'égratignure (langage naturel).
2. Il l'enregistre dans une variable (gestion de l'état).
3. Il refuse de fermer la session ou de changer de rubrique jusqu'à ce qu'il confirme : « J'ai pris en compte l'égratignure sur le fuselage, mais nous ne pouvons pas passer à la section « Extérieur » tant que vous n'avez pas confirmé le couple de serrage sur la soupape d'admission. Quelle était la valeur indiquée ? »

Logique :

Une conversation guidée doit être plus qu'une simple liste séquentielle de questions. Dans le cas contraire, l'agent ressemble davantage à un « formulaire déguisé ». Sa valeur principale réside dans le tri intelligent : l'utilisation de questions de découverte initiale pour diriger l'utilisateur vers le bon formulaire ou workflow.

La transition d'un script simple à un script d'agent robuste devient logique lorsque la complexité augmente. Au lieu de se contenter de poser des questions, l'agent commence à réaliser les actions suivantes : Par exemple, l'agent peut extraire des étapes de dépannage de la documentation, naviguer dans les politiques internes ou exécuter des appels d'API vers des systèmes externes pour résoudre les problèmes en temps réel.

Avec l'introduction du script d'agent au niveau 6 du cadre de déterminisme, vous disposez désormais d'une gamme complète de contrôles, de la créativité libre d'une rubrique de niveau 1 à la logique stricte et pilotée par le code d'un script d'agent de niveau 6.

Mais avoir un marteau ne fait pas de chaque problème un clou.

L'erreur la plus courante est de penser qu'il faut obligatoirement renforcer ce cadre, et que les agents doivent désormais être entièrement contrôlés à l'aide de scripts pour tous les sujets. Ce n'est pas vrai. La véritable maîtrise de l'architecture et de la conception des agents réside dans le fait de dimensionner correctement le déterminisme en appliquant un contrôle adéquat pour garantir la sécurité, sans sacrifier la flexibilité conversationnelle qui rend l'IA précieuse en premier lieu. Ne scénarisez pas vos agents à outrance au point de les transformer en chatbots déguisés.

Ce chapitre fournit un cadre décisionnel pour vous aider à déterminer quand vous devez vous appuyer sur l'autonomie guidée des niveaux 1 à 5 et quand appliquer la précision scénarisée du niveau 6. Il ne s'agit pas de lois strictes, mais plutôt de règles générales destinées à fournir un cadre contextuel sur la manière de penser les différentes options et les niveaux de déterminisme.

Pour simplifier la décision, nous pouvons diviser les six niveaux en deux zones stratégiques distinctes :

• Philosophie : « fais confiance, mais vérifie. » Vous donnez à l'agent l'objectif, les données et les outils (qui peuvent être déterministes, voir niveau 5), mais vous laissez le moteur de raisonnement décider du meilleur parcours pour y parvenir.
• Mécanisme : le raisonnement probabiliste. L'agent analyse l'intention de l'utilisateur et sélectionne dynamiquement l'outil le mieux adapté à la tâche.
• Idéal pour : la découverte, les Q&R généraux, les tâches à faible risque, les périmètres de service étendus.

Vous devez vous appuyer sur les comportements probabilistes standard des niveaux 1 à 5 lorsque :

1. Le parcours adéquat n'est pas toujours le même

Dans de nombreux scénarios conversationnels, un parcours strict et codé en dur est en fait un inconvénient, car le parcours conversationnel correct est variable. Pour les interactions dynamiques telles que le shopping personnalisé ou la planification de vacances, il n'y a pas de séquence correcte unique ; un utilisateur peut donner la priorité au prix, au lieu ou aux infrastructures dans l'ordre de son choix. Dans ces cas, forcer un script avec état crée une expérience robotique frustrante. Il est donc plus efficace de s'appuyer sur des instructions pour définir le profil et les objectifs de l'agent tout en permettant à l'utilisateur de diriger le flux. Cette approche augmente également considérablement la vitesse de mise sur le marché, car la création de scripts complexes de niveau 6 avec des variables et des branches imbriquées est souvent excessive pour des tâches telles que les agents internes de FAQ RH. En ancrant l'agent dans les données et la RAG, vous pouvez éviter d'avoir recourt à un script manuel exhaustif et laisser le moteur de récupération gérer la conversation de manière dynamique en s'appuyant sur votre base de connaissances existante.

2. Évolution grâce au déterminisme modulaire : éviter le cauchemar de la maintenance

Lorsque la portée de votre agent atteint une ampleur considérable, par exemple s'il traite 500 requêtes différentes de support IT avec ses propres processus, le principal défi n'est pas de savoir si vous pouvez créer un script d'agent déterministe unique, mais si vous le devez. Essayer de mapper toutes les permutations possibles de 500 tâches dans un script d'agent géant peut vite virer au cauchemar en termes de maintenance. Chaque fois qu'une politique change ou qu'une nouvelle étape de dépannage est ajoutée, vous risquez de faire tomber un vaste réseau logique interconnecté.

La solution consiste à passer d'un script monolithique à des actions déterministes de niveau 5. Au lieu de scénariser l'ensemble de la conversation, vous créez des flux robustes et isolés pour les actions de premier plan à forte valeur ajoutée, telles que la réinitialisation de mots de passe ou le déverrouillage de comptes. Vous permettez ensuite au moteur de raisonnement d'agir comme un contrôleur de trafic, en identifiant l'intention de l'utilisateur à partir de sa formulation unique et en l'acheminant vers l'action déterministe appropriée. Cette approche vous offre le meilleur des deux mondes : la fiabilité d'un script pour les tâches critiques et une architecture flexible et évolutive qui ne s'effondre pas sous son propre poids à mesure que votre bibliothèque de tâches s'agrandit.

• Philosophie : « Quoi que tu fasses et peu importe ton raisonnement, fais exactement cela. » Vous définissez le parcours. L'agent représente l'interface d'exécution de votre logique. Il intègre la créativité de l'agent dans les couches de logique essentielle.
• Mécanisme : le raisonnement déterministe. Le « cerveau » suit un graphique précompilé ; le LLM est utilisé uniquement pour le raisonnement, la compréhension du langage naturel et la génération de réponses lorsque le script le permet.
• Idéal pour : la conformité, les transactions financières, les arbres de diagnostic, les workflows à enjeux élevés et des secteurs très réglementés.

Notez que dans les parcours déterministes que le niveau 6 propose, toutes les options du niveau 1-5 restent disponibles !

Vous devez passer au script d'agent lorsque le « généralement correct » n'est pas suffisant.

1. Les points d'accès incontournables (sécurité et authentification)

Si un utilisateur demande à transférer de l'argent, vous ne pouvez pas compter sur le fait que le LLM va probablement demander une authentification. Vous avez besoin d'une garantie mathématique que le flux d'authentification s'exécute avant le flux de transaction.

• Solution de script d'agent : utilisez run @actions.verify_identity dans un bloc before_reasoning ou tout en haut de votre script pour forcer la conformité avant que le LLM ne génère un jeton unique.

2. Conformité réglementaire

Dans des secteurs tels que la santé ou la finance, les agents doivent souvent lire une clause de non-responsabilité mot pour mot ou poser des questions dans un ordre légalement imposé.

• Solution de script d'agent : coder en dur la divulgation.

3. Dépendances complexes à plusieurs étapes et séquences d'actions obligatoires

Si l'étape B nécessite la réponse à l'étape A, et que l'étape C dépend d'un calcul effectué à l'étape B, il est risqué de s'appuyer sur un LLM pour transmettre ces variables via un contexte de prompt dans une chaîne de transmission indirecte. De plus, lorsque l'exécution d'une action donnée est strictement obligatoire après une autre action, la séquence doit être reliée.

• Solutions de script d'agent : utilisez set @variables.x = @output.y pour associer explicitement les données entre les étapes, garantissant ainsi une fidélité parfaite. Utilisez les instructions run et @utils.transition pour coder la séquence.

4. Éviter la dérive vers d'autres rubriques

Dans le cadre d'un dépannage à enjeux élevés (par exemple, « Mon stimulateur cardiaque émet un signal sonore »), vous ne voulez pas que l'agent soit distrait si l'utilisateur demande soudainement « Quel temps fait-il ? »

• Solution de script d'agent : Utilisez @utils.transition pour garder l'utilisateur dans la rubrique Protocole d'urgence jusqu'à ce que le problème soit résolu, ce qui désactive explicitement la possibilité de dérive.

Les architectures d'agents les plus matures ne choisissent pas l'un ou l'autre des niveaux ; elles utilisent le niveau 6 comme structure et les niveaux 1 à 5 comme mécanisme d'action. Le modèle qui émerge alors est celui d'un schéma multicouches déterministe. Vous pouvez utiliser le script d'agent pour gérer le début et la fin d'une conversation, qui sont des éléments déterminants, tout en laissant le reste ouvert à un raisonnement flexible.

• Étape 1 (niveau 6) : le script d'agent force le triage et l'authentification.
  • Résultat : l'utilisateur est identifié de manière sécurisée et l'intention est classifiée.
• Étape 2 (niveaux 1 à 5) : le script d'agent effectue le transfert vers une rubrique standard.
  • Résultat : l'agent utilise une RAG standard et des actions, des instructions et peut-être même des variables pour résoudre le problème de l'utilisateur de manière flexible.
• Étape 3 (niveau 6) : l'agent détecte que le problème est résolu et revient au script d'agent pour les actions de clôture.
  • Résultat : le script d'agent force la collecte des scores CSAT et l'utilisation d'une formule de clôture conforme.

Recommandation finale : commencez par les niveaux 1 à 5 pour la rapidité et la découverte, puis surveillez vos journaux. Lorsque l'agent a du mal à obtenir de la cohérence, n'arrive pas à suivre une séquence ou hallucine des paramètres, renforcez ce workflow spécifique avec le niveau 6.

Le script d'agent est la dernière pièce du puzzle dans l'intégration du déterminisme aux mécanismes d'action des agents. Il reconnaît que si l'IA est probabiliste, le monde de l'entreprise est déterministe. En adoptant le script d'agent (que ce soit par le biais du canevas qui prend en charge la création d'agents en langage naturel ou par le biais de code direct), vous ne limitez pas l'intelligence de votre agent, vous l'orientez. Vous créez un système où l'art de la conversation rencontre la science de l'exécution des processus, ce qui permet à vos workflows les plus critiques de s'exécuter exactement comme prévu, à chaque fois.

Le niveau 6 permet également de prendre conscience du fait que l'autonomie n'est pas synonyme de non contrôle.

Pendant des années, le secteur a débattu de l'opposition entre règles et IA en matière de prise de décision et d'optimisation des processus. Le camp des règles strictes préconise la prévisibilité. Le camp de l'IA préconise la flexibilité. Le script d'agent met fin à ce débat en prouvant que l'architecture correcte n'est pas ou, mais et.

En adoptant le script d'agent, vous créez des agents hybrides : des systèmes dotés de l'ossature robuste du code et de l'esprit flexible d'un LLM. L'avenir de l'IA d'entreprise ne repose pas sur des modèles plus grands, mais sur un meilleur contrôle. Avec le script d'agent, ce contrôle est enfin à votre portée.