Optimisation des ressources et des coûts pour Agentic Enterprise

Les agents autonomes consomment les ressources Salesforce différemment de l’automatisation déterministe. Les charges de travail des agents sont imprévisibles et continues, plutôt que fixes et liées aux transactions. La thèse de la valeur par coût du pilier Optimisation des ressources et des coûts s’applique directement à Agentic Enterprise. L’efficacité des ressources signifie utiliser la capacité que vous payez déjà, et l’optimisation des coûts signifie orienter délibérément les dépenses vers les capacités autonomes qui génèrent un rendement. Les agents changent la forme des deux. Une conception efficace des agents permet de contrôler la consommation, et la sélection du modèle de tarification, la modélisation du coût total de possession (TCO) et la gouvernance financière permettent d’aligner les dépenses sur la valeur. Ce document traite l’efficacité des ressources et l’optimisation des coûts comme une seule décision, car pour les agents, ce sont deux vues du même objectif.

Les agents changent la prévisibilité de la consommation. Un processus Apex traditionnel fonctionne sur un ensemble d’enregistrements connu avec un coût de ressource connu. Un agent opère de façon conversationnelle, et une seule conversation peut exécuter des douzaines d’actions lorsque l’agent raisonne à travers une tâche. Chaque action consomme les limites du gouverneur dans sa propre transaction au lieu de les accumuler dans la conversation. La préparation du contexte pour un seul tour peut interroger 200 enregistrements ou 20 000, selon les questions de l’utilisateur. La consommation d’API s’accélère, car les agents peuvent agir de façon autonome, et les agents proactifs, sortants et planifiés agissent de façon continue, pas seulement pendant une transaction utilisateur. Cette imprévisibilité explique pourquoi la gestion des ressources des agents doit être défensive par conception plutôt que ajustée après un pic de consommation.

Le côté coût change tout autant. Les agents autonomes introduisent une tarification basée sur la consommation qui se comporte différemment des licences traditionnelles par siège. Agentforce offre deux modèles de tarification basés sur la consommation, Flex Credits et Per-Conversation. Chaque déploiement d’agent sélectionne l’un de ces modèles. Une organisation utilise un seul modèle de consommation à la fois. , mais un complément Par utilisateur, offert par utilisateur et par mois pour une utilisation non mesurée, peut se superposer à un modèle de consommation afin de permettre aux agents qui s’adressent aux clients d’exécuter Flex Credits ou Per-Conversation pendant que les employés utilisent des licences non mesurées. Data 360 ancre les agents dans la recherche et la récupération de vecteurs, et consomme de la capacité de traitement des données, tandis que MuleSoft active les intégrations d’agents qui consomment de la capacité d’API. Ces coûts variables évoluent en fonction de l’utilisation des agents, ce qui crée un modèle d’investissement qui nécessite une gouvernance financière élaborée pour la variabilité plutôt que pour un abonnement annuel fixe.

Les solutions conçues pour la valeur métier avec un coût optimisé dans Agentic Enterprise permettent de consommer efficacement les agents grâce à des actions qui traitent les enregistrements en masse, des fenêtres de contexte disciplinées et la mise en cache. Ils orientent également délibérément les dépenses à travers le modèle de tarification approprié, une modélisation complète du TCO et un suivi continu des coûts par rapport aux résultats métiers. Sans cet alignement, les déploiements d’agents accumulent les coûts sans démontrer la valeur proportionnelle, et un agent qui raisonne dans une boucle illimitée peut brûler des crédits plus rapidement que la surveillance humaine ne peut intervenir. Le même travail d’efficacité qui maintient un agent dans les limites de son gouverneur le maintient dans son budget de crédit, qui est la thèse du pilier exprimée en termes agentsiques.

Ce document présente les modifications apportées lorsque les agents sont dans l’image. Pour les schémas d’optimisation des ressources et des coûts de base qui s’appliquent à chaque solution Salesforce, notamment l’optimisation des performances, les limites du gouverneur, l’analyse du TCO et la discipline en matière de licences, consultez le pilier Optimisation des ressources et des coûts. La gouvernance des agents et le contrôle humain sont liés aux piliers Confiance et équité, qui couvrent les composantes du programme qui assurent la sécurité et la responsabilité des comportements autonomes.

La consommation de ressources des agents suit la même mécanique de plate-forme que Flux ou Apex, mais son invocation imprévisible, pilotée par la conversation, rend la consommation plus difficile à prévoir et nécessite donc des schémas défensifs. Vos responsabilités d’optimisation couvrent la budgétisation limite du gouverneur à travers les chaînes d’action, la consommation d’API, la latence de réponse, l’efficacité de l’ancrage Data 360, la gestion des fenêtres de contexte et la conception composable qui permet aux agents d’évoluer sans duplication. Chaque responsabilité est une décision de valeur par coût avant d’être technique, car les agents répètent les inefficacités à chaque conversation.

Les agents invoquent des actions qui déclenchent Apex, des flux et des intégrations. Une seule conversation peut exécuter des dizaines d’actions lorsque l’agent raisonne à travers une tâche complexe. La discipline de base est la même que pour n’importe quelle solution Salesforce, mais le schéma d’invocation imprévisible augmente les enjeux. Concevez des actions pour accepter des collections afin de permettre à un agent qui met à jour 50 requêtes d’invoquer une action au lieu de 50 appels distincts. Une action unique exécutée sur une collection d’enregistrements consomme beaucoup moins de requêtes SOQL (Salesforce Object Query Language) et d’opérations DML (Data Manipulation Language) pour le même travail. Gérez délibérément le budget SOQL à travers les chaînes d’actions, car un workflow qui invoque 10 à 15 actions peut approcher ou dépasser la limite de 100 requêtes synchrones lorsque chaque action exécute plusieurs requêtes de sa propre initiative. Utilisez des requêtes de relation pour récupérer les données parentes et enfants dans une seule instruction, et référencez les données mises en cache dans le Cache de la plate-forme à travers les actions de la même conversation. Ces deux pratiques maintiennent une chaîne multi-actions dans son budget.

Déplacez les opérations des agents qui dépassent les limites synchrones vers Apex Queueable ou Batch, où le contexte asynchrone double à peu près l’espace libre SOQL et CPU disponible pour le travail. Les opérations analytiques volumineuses, telles que le score de 1000 pistes ou l’analyse du sentiment à travers des requêtes historiques, appartiennent au traitement asynchrone plutôt qu’au blocage d’une conversation. L’inférence de grand modèle de langage se produit elle-même hors de Salesforce et consomme des crédits Flex plutôt que du temps processeur Apex. Par conséquent, le budget processeur que vous profilez est consommé par la logique d’action, les transformations de données et les intégrations que l’agent déclenche. Les scénarios biaisés de données dans lesquels des enregistrements parents sont associés à des milliers d’enregistrements enfants méritent une attention défensive particulière avec les agents. Cette vulnérabilité est due au fait qu’un agent peut demander « tout l’historique » pour un compte avec des dizaines de milliers d’enregistrements associés, d’une façon qu’une requête déterministe ne pourrait jamais demander. Concevez des actions avec des limites en enregistrements enfants et une pagination rigides, et appliquez l’échantillonnage lorsque les volumes dépassent le seuil d’asymétrie des données. Ces limites empêchent la transformation d’une requête imprévisible en requête sans limite. Le Traçage des sessions Agentforce identifie les actions qui consomment des requêtes excessives au niveau de la session, et le Centre d’échelle surveille les performances globales des transactions Apex et l’intégrité de l’organisation.

Les architectures d’agents consomment des API plus rapidement que les workflows pilotés par l’utilisateur, car les agents fonctionnent de façon autonome et, pour les agents proactifs ou planifiés, en continu. La façon dont un agent est exposé détermine comment il diminue la capacité d’API. Les agents invoqués via l’API REST consomment un appel par tour de conversation. Les agents incorporés à des pages Lightning via des composants standard ne consomment pas d’appel d’API par interaction, bien que leur coût soit encore mesuré dans les crédits ou les conversations du modèle de tarification choisi. Les composants Web Lightning personnalisés qui effectuent des appels REST directs consomment la capacité de l’API. Les composants élaborés sur des adaptateurs wire Lightning Data Service ne le sont pas, car Lightning Data Service sert à partir d’un cache côté client partagé plutôt que d’émettre un appel d’API. Surveillez la consommation dans Event Monitoring pendant un pilote pour comprendre l’utilisation réelle avant un déploiement complet.

Les modèles pilotés par l’événement sont le plus grand levier de consommation d’API d’agent gaspilleur. La publication d’un Événement de plate-forme lorsqu’une condition nécessite l’intervention d’un agent évite l’interrogation planifiée qui consomme des appels d’API, qu’il y ait ou non du travail à faire, et qu’un agent qui s’abonne aux événements Capture des données de modification conserve le contexte actuel sans les appels d’interrogation quotidiens qu’un orchestrateur externe passerait autrement. La logique de la valeur par coût est directe : Un sondage qui ne trouve aucun travail est une capacité dépensée pour rien, et un événement qui déclenche uniquement un changement réel est une capacité dépensée uniquement pour un travail réel. La génération augmentée de récupération ajoute sa propre consommation, car chaque recherche vectorielle par rapport à Data 360 consomme du calcul. Par conséquent, définissez des limites de récupération pour renvoyer uniquement les résultats que l’agent utilise réellement.

La latence d’un tour d’agent est la somme du temps d’inférence LLM, du temps d’exécution de l’action, du temps de requête Data 360 et du temps d’intégration lorsque ces étapes sont exécutées en séquence. Sinon, c’est la branche parallèle la plus longue plus toutes les étapes séquentielles. La latence est un problème de coût ainsi qu’un problème d’expérience, car une action lente maintient les ressources ouvertes plus longtemps et un utilisateur frustré initie plus de conversations qu’un utilisateur résolu. Les invites plus courtes génèrent des réponses plus rapides. Par conséquent, retirez les instructions verbeuses, les exemples redondants et le contexte inutile. Le contexte sélectif améliore à la fois la latence et la qualité des réponses, où un vidage de contexte exhaustif ne fait qu’ajouter du bruit. Accélérez les actions en utilisant le langage SOQL sélectif dans les champs indexés, le traitement en masse et les données de référence mises en cache, car une action de 3 secondes devient un goulot d’étranglement, quelle que soit la vitesse d’inférence. Validez les requêtes d’action avec l’outil Plan de requête pour identifier les analyses complètes de tableaux qui augmentent la latence des actions.

L’orchestration du Générateur d’agents peut exécuter des actions en parallèle lorsqu’il n’y a aucune dépendance entre elles. Par exemple, la récupération simultanée des détails du compte et des opportunités associées prend autant de temps que la plus lente des deux, plutôt que la somme des deux. Pour les appels qui tombent en panne vers plusieurs systèmes en aval, couplez Agentforce à une plate-forme d’intégration comme MuleSoft; l’agent invoque une seule action, MuleSoft reçoit la requête et émet des appels parallèles aux systèmes back-end, puis renvoie une réponse agrégée. Le cache de la plate-forme supprime l’inférence et la latence des requêtes pour les requêtes répétées, et le traitement asynchrone des travaux non urgents, par exemple une longue analyse de document, permet à l’agent d’accuser réception immédiatement de la demande et de renvoyer le résultat lorsqu’elle est prête, au lieu de garder la conversation ouverte.

Data 360 fournit la recherche vectorielle qui fonde les réponses des agents sur les données actuelles plutôt que sur les seules données d’entraînement du modèle, et son efficacité détermine à la fois la qualité d’ancrage et le calcul que vous consommez pour y parvenir. La segmentation, la sélection incorporée, le filtrage des métadonnées et les limites en résultats sont les décisions les plus importantes. Chunk Knowledge dans des segments sémantiquement significatifs, car les segments trop petits forcent de nombreuses récupérations pour une seule question alors que les segments trop grands diluent la pertinence avec un contexte non pertinent et gonflent le budget de jeton porté dans l’inférence. Choisissez un modèle d’incorporation adapté à la méthode d’interrogation de vos agents, car le comportement de la similarité des questions-réponses est différent de celui de la classification des documents, et validez le choix par rapport aux requêtes représentatives. Combinez la similarité sémantique à des filtres de métadonnées afin de maintenir les contraintes métiers quelle que soit la similarité, par exemple exclure les produits abandonnés d’une recommandation quelle que soit la correspondance. Définissez des limites top-k pour renvoyer uniquement les résultats que l’agent utilise. Par exemple, si 5 résultats informent une réponse, la récupération de 50 ajoute 45 résultats inutilisés à la charge utile d’ancrage et au budget de jeton.

Les profils unifiés sont économes en ressources, car un agent qui interroge un profil unifié Data 360 récupère le contexte client complet en une seule opération plutôt que d’orchestrer des requêtes séparées avec Compte, Contact, Opportunité, Requête et Campagne à chaque tour. Configurez des instances Data 360 dans les régions que les exigences réglementaires exigent afin de permettre aux agents qui traitent les données d’une juridiction donnée d’interroger l’instance qui contient les données personnelles.

Les fenêtres de contexte de grand modèle de langue contiennent un nombre fini de jetons, et la gestion de ce budget permet de maintenir une longue conversation cohérente sans épuiser la capacité ni gonfler le coût de chaque appel d’inférence. Priorisez délibérément plutôt que de tronquer arbitrairement : L’historique des conversations récentes est prioritaire, les données métiers critiques telles que l’état actuel de l’enregistrement et les autorisations viennent en deuxième position, et l’historique plus ancien est inclus uniquement lorsque l’espace le permet. Après les premiers tours, résumez la conversation précédente dans une vue d’ensemble concise qui préserve les faits critiques sans renvoyer l’historique complet. Ce résumé préserve la continuité sans augmenter le budget de jeton . Stockez le contexte étendu dans Data 360 ou des objets personnalisés en tant que mémoire externe interrogée à la demande plutôt que de rejouer l’historique complet à chaque appel, et renvoyez uniquement les champs essentiels de chaque action, car une réponse qui transporte les 50 champs d’un enregistrement lorsque la tâche en a besoin de 8 dépense le budget du contexte mieux alloué à la conversation ou à l’ancrage.

L’élaboration d’agents à partir de composants réutilisables réduit les coûts de développement et de maintenance. Une capacité élaborée une fois et réutilisée est beaucoup moins chère sur sa durée de vie que la même capacité réimplémentée et gérée séparément pour chaque agent. Les bibliothèques d’actions centralisées couvrant les opérations d’enregistrement, les approbations, les notifications et la validation permettent aux équipes de la plate-forme de maintenir un comportement, une sécurité et des performances cohérents dans chaque agent consommateur, et permettent d’assembler un nouvel agent à partir de blocs de construction éprouvés en quelques jours plutôt que d’élaborer des actions personnalisées sur des semaines. Les agents spécialisés ciblés avec des frontières de domaine claires gardent un contexte plus étroit et un comportement plus clair qu’un agent universel unique qui tente chaque scénario, et l’orchestration du Générateur d’agent coordonne les spécialistes lorsqu’une tâche traverse des domaines. Les modèles d’invite validés dans le Générateur de répliques capturent des modèles éprouvés d’ancrage, de raisonnement et de mise en forme des réponses afin de garantir une qualité constante à mesure que le développement s’accélère. Une base de Knowledge partagée dans Data 360 ancre de nombreux agents d’une seule source. Par conséquent, une mise à jour touche chaque consommateur à la fois au lieu d’exiger une modification de chaque agent.

Les équipes d’entreprise composent de plus en plus plusieurs agents ensemble plutôt que de créer des agents monolithiques uniques, avec un agent orchestrateur qui décompose une requête et la délègue à des sous-agents spécialisés, ou des agents spécialisés qui se transmettent mutuellement pendant qu’une conversation progresse entre les domaines. Cette composition soulève des questions de ressources et de coûts qui dépassent celles auxquelles un seul agent est confronté, car les frais généraux d’orchestration, le Trust inter-agents et le transfert d’état sont tous composés à travers une chaîne au lieu de rester confinés à une seule action. Gardez les invites d’orchestration étroites, limitées à la classification de l’intention et de l’acheminement, plutôt que de demander à l’orchestrateur de raisonner également sur la tâche sous-jacente, car ce raisonnement appartient au sous-agent avec le contexte approprié, et limitez la profondeur de la chaîne, sauf si un cas d’utilisation nécessite clairement une imbrication plus profonde que orchestrateur à sous-agent. Traitez chaque réponse de sous-agent comme une entrée non approuvée, comme vous le feriez pour une réponse d’API externe. Validez sa forme attendue et sa conformité aux règles métiers avant d’agir dessus. Appliquez la sécurité et le partage au niveau du champ indépendamment pour chaque action de l’agent.

Transmettez uniquement l’état dont l’agent destinataire a besoin, en utilisant une charge de travail de transfert structurée d’ID d’enregistrement, de résumé de tâche et de champs pertinents, plutôt que de transférer l’historique des conversations brutes, afin de garder le contrôle du budget de jeton à travers la chaîne, et de conserver l’état de session inter-agents dans Data 360 ou un objet personnalisé lorsqu’un transfert doit survivre à travers des transactions séparées. Les limites du gouverneur s’appliquent par agent, pas une fois par conversation. Par conséquent, chaque agent d’une chaîne tire son propre budget SOQL, DML et CPU. Une chaîne d’un orchestrateur et de trois sous-agents consomme chacune de ces limites quatre fois plus, et des chaînes plus profondes multiplient encore la consommation. La même multiplication entraîne des coûts, ce qui fait de la profondeur de chaîne illimitée un risque de coût plus qu’un risque de limite du gouverneur.

Définissez ce que fait l’orchestrateur lorsqu’un sous-agent échoue, expire ou renvoie un résultat de faible confiance, que ce soit une nouvelle tentative limitée, une réponse de repli ou une escalade vers un humain, afin qu’un seul expiration de sous-agent n’entraîne pas l’échec de la chaîne complète. Corrélez une requête à travers chaque agent qu’elle touche avec un ID de trace partagé propagé à travers la charge utile de transfert, car diagnostiquer l’agent d’une chaîne qui a causé un pic de latence ou un pic de coût nécessite de corréler manuellement les journaux entre des sessions d’agent séparées.

Les actions échouées et les appels d’agents enfants échoués n’affectent pas seulement la fiabilité, car chaque nouvelle tentative peut réexécuter le travail SOQL, DML et CPU déjà dépensé sur la tentative échouée, et dans une chaîne d’agents multiples, ce coût est aggravé par le nombre d’agents en aval échoués. Dans la tarification basée sur la consommation, les mêmes composés de défaillance dépensent ainsi que calculent : une action réessayée consomme de nouveau des crédits sous Crédits flexibles. Concevez une nouvelle logique pour prendre en compte la fiabilité et le coût. Distinguez les échecs transitoires, par exemple une expiration d’appel ou un contentieux de verrouillage, des échecs logiques, par exemple une erreur de validation ou une entrée malformée, avant de décider comment répondre, car un échec transitoire peut valoir une nouvelle tentative limitée alors qu’un échec logique échoue identiquement lors d’une répétition et brûle uniquement le budget d’un échec répété garanti qui doit à la place escalader immédiatement.

Limitez les nouvelles tentatives par action, à deux ou trois tentatives, et appliquez un recul exponentiel entre elles plutôt qu’une réinvocation immédiate, car une nouvelle tentative illimitée ou en boucle serrée sur une action lourde en SOQL ou DML peut épuiser les limites synchrones dans une seule transaction ou brûler à travers le budget en chaîne cumulé et les dépenses de crédit cumulées à travers une conversation multi-agents. Concevez des actions pour qu’un nouvel appel produise le même état de fin qu’un appel réussi unique, en utilisant une clé d’idempotence telle qu’un ID de requête ou un ID externe avec une logique de mise à jour/insertion au lieu d’insérer. Par conséquent, une nouvelle tentative met à jour le même enregistrement au lieu de créer un doublon. Une action sans idempotence force une nouvelle tentative de doubler la consommation de ressources via des enregistrements en aval dupliqués ou de doubler les actions ou conversations facturées pour un travail déjà effectué.

Suivez l’état de réalisation par agent d’une chaîne, car l’action d’un agent peut engager DML avec succès avant qu’un agent en aval échoue, et un gestionnaire de défaillance qui sait ce qui a déjà réussi peut compenser ou reprendre à partir du point de défaillance au lieu de redémarrer et de refacturer toute la chaîne. Exposer le statut de nouvelle tentative ou en cours à l’utilisateur pendant qu’une nouvelle tentative limitée est en cours, car un utilisateur qui voit le silence et répète sa demande déclenche une conversation entièrement nouvelle et une nouvelle série d’actions, aggravant le coût de la ressource et de la facturation de la tentative d’origine avec une tentative dupliquée.

Les modèles d’optimisation des ressources décrits dans ce document sont utiles uniquement si un architecte peut déterminer où un agent dépense réellement des requêtes SOQL, du temps processeur, des lignes DML et des jetons lorsqu’il est exécuté en production. Sans visibilité par action et par session, un dépassement de limite ou une régression de latence apparaît comme un symptôme sans moyen de remonter à l’action ou à l’agent dans la chaîne qui l’a causé. Cette préoccupation est distincte de la visibilité des dépenses que Digital Wallet fournit sous Surveillance des coûts et gouvernance financière. Digital Wallet indique le nombre de crédits ou de conversations consommés par un agent, tandis que l’outillage indique les raisons pour lesquelles ils ont été consommés, au niveau de la requête individuelle, de la ligne DML, ou de l’action qui a entraîné cette consommation. L’outil approprié dépend de ce que l’organisation et le contrat de support d’un client donné accordent, pas de l’outil théoriquement le meilleur. Par conséquent, mappez la recommandation avec votre licence et niveau d’accès plutôt que d’utiliser par défaut l’outil le plus efficace disponible.

N’importe quel architecte peut élaborer des événements de plate-forme personnalisés qui se déclenchent au début et à la fin de chaque invocation d’action et de sous-agent. Ces événements tracent l’exécution à travers une conversation en utilisant uniquement les capacités standard de la plate-forme, associées à la consignation au niveau de l’action dans un objet personnalisé qui capture le nombre de requêtes SOQL, le temps processeur, le nombre de lignes DML et l’utilisation en tas lors de l’exécution de chaque action. Les deux événements peuvent être interrogés via des rapports ou SOQL et offrent à chaque organisation une capacité de diagnostic de référence, quelle que soit l’édition ou la licence complémentaire. Event Monitoring, introduit précédemment pour suivre la consommation d’API pendant les projets pilotes, expose également des modèles d’utilisation des ressources agrégées à travers les sessions des agents dans l’ensemble de l’organisation pour les clients dont l’organisation inclut ce complément, permettant à un architecte d’identifier les workflows qui tendent vers les limites du gouverneur dans de nombreuses conversations plutôt que de diagnostiquer individuellement. Le Centre d’échelle offre un traçage approfondi des transactions proches des limites du gouverneur, généralement accédées via un engagement de support ou disponibles directement aux niveaux de compte qui l’accordent.

Les agents de gestion des versions permettent indépendamment de contrôler le déploiement, l’annulation et la comparaison, et protègent l’investissement dans un agent actif pendant que vous l’améliorez. Conduisez le comportement à travers la configuration dans la mesure du possible, en utilisant Types de métadonnées personnalisées et Générateur de répliques afin de permettre aux administrateurs d’ajuster les modèles d’invite et la sélection d’actions sans cycle de développement. Utilisez la capacité de test A/B pilote pour acheminer une petite sélection d’utilisateurs vers une version expérimentale. Comparez la qualité, la satisfaction et la réalisation des tâches avant un déploiement complet. Cette comparaison valide les améliorations par rapport à l’utilisation réelle et détecte les régressions lorsque l’exposition est limitée. Définissez des contrats d’interface clairs entre les composants, en spécifiant les entrées, les sorties, les erreurs et les attentes en performance, afin de remplacer une implémentation sans modifier les agents qui en dépendent.

L’économie des agents commence par le coût total de possession mesuré par rapport à la valeur métier, mais la tarification basée sur la consommation des agents autonomes fait que le côté coût se comporte de la même façon que les licences traditionnelles. Le modèle de tarification que vous sélectionnez est une décision architecturale fondamentale, car il détermine ce pour quoi vous optimisez tout au long du cycle de vie de l’agent. Cette section établit les modèles de tarification, une vue complète du TCO d’une implémentation d’agent et la décision d’élaboration par rapport à l’achat pour les capacités des agents.

Agentforce offre deux modèles de tarification basés sur la consommation, et une organisation sélectionne l’un des deux pour un déploiement d’agent donné. Prix Flex Credits par action de l’agent, qui fait de l’efficacité de l’action le levier du contrôle des coûts. La tarification par conversation facture des frais fixes par conversation, quelle que soit la durée ou la complexité, ce qui fait de la limitation de la conversation le levier. Les abonnements par utilisateur fournissent une utilisation non mesurée de l’agent en tant que complément accessible aux employés plutôt qu’en tant que troisième modèle de consommation, et ils déplacent l’optimisation de l’efficacité de la consommation vers l’adoption, car la valeur provient de l’engagement actif des utilisateurs détenteurs d’une licence avec l’agent plutôt que de la minimisation de chaque interaction. Les deux modèles de consommation ne sont pas mélangés pour la même organisation, mais un complément Par utilisateur, offert par utilisateur et par mois pour une utilisation non mesurée, peut se superposer à un modèle de consommation afin d’exécuter les agents qui s’adressent aux clients avec des crédits Flex ou Par conversation pendant que les employés utilisent des licences non mesurées.

Sous Crédits flexibles, les coûts d’action sont fixes par action jusqu’à un plafond de jeton défini. Contrairement à la tarification par inférence basée sur un jeton, le coût du crédit ne varie pas avec la longueur de l’invite ou la complexité du modèle. Par conséquent, une réponse à une phrase et une réponse à plusieurs paragraphes coûtent le même prix. Une interaction multi-actions consomme des crédits pour chaque action. Par conséquent, une interaction qui récupère des données, des motifs et met à jour un enregistrement consomme les crédits de trois actions, et la génération augmentée de récupération ajoute d’autres actions via la recherche vectorielle et la récupération de documents avant le raisonnement. Comprendre le nombre moyen d’actions par transaction commerciale est donc le prérequis de la modélisation des coûts sous Flex Credits.

Sous la tarification par conversation, des frais fixes s’appliquent par conversation, et plusieurs tours de parole dans une session sont pris en compte dans une conversation unique. Par conséquent, le contrôle des coûts provient de la résolution d’un problème dans une conversation et de la définition de limites de session claires plutôt que de la réduction d’actions individuelles. L’ancrage Data 360 et l’intégration MuleSoft consomment leur propre capacité avec le modèle choisi, car la génération incorporée et la recherche de similarité réduisent la capacité de traitement des données pour chaque requête ancrée et chaque action externe consomme la capacité d’API dans les systèmes source et cible.

Le coût total de possession (TCO) d’une implémentation d’agent couvre six catégories, et la modélisation des six transforme une estimation de crédit en décision d’investissement informée. Les coûts de développement couvrent la conception des agents, l’ingénierie rapide, le développement de l’intégration et les tests, et vont d’un simple agent à usage unique à un système multi-agents avec une orchestration complexe. Les coûts d’inférence dépendent du modèle de tarification sélectionné et nécessitent de modéliser les volumes d’actions attendus sous Crédits flexibles, les volumes de conversations sous Par conversation ou le nombre d’utilisateurs licenciés sous Par utilisateur. Pour les agents ancrés dans de grandes bases Knowledge, l’infrastructure Data 360 qui pilote l’ancrage peut rivaliser ou dépasser le coût d’inférence. Les coûts d’infrastructure couvrent les licences Data 360 et MuleSoft, les sandbox supplémentaires et l’infrastructure de surveillance, et sont principalement fixes ou basés sur des niveaux de capacité. Les coûts opérationnels couvrent les opérations de surveillance, le raffinement rapide, la réponse aux incidents et le support utilisateur, et pour les programmes d’agent matures, ils sont généralement égaux à une fraction significative du coût de développement annuel, conformément aux critères généraux de l’industrie pour les agents IA plutôt qu’à un chiffre spécifique à Salesforce. Les coûts de gouvernance couvrent l’examen de la sûreté, la surveillance humaine, la consignation des audits et la validation de la conformité, qui augmentent avec l’autonomie et les risques des agents, et le pilier Équité couvre les composantes essentielles du programme. Les coûts de modification couvrent la formation des utilisateurs, l’adaptation des processus métiers et la gestion du changement organisationnel, et ce sont les catégories que les équipes sous-estiment le plus souvent.

Élaborez des modèles TCO de feuille de calcul qui projettent des coûts sur 3 à 5 ans. Documentez les hypothèses relatives aux volumes d’interactions, au nombre d’actions et à la croissance. Exécutez une analyse de sensibilité pour identifier les hypothèses qui affectent le plus le total, puis concentrez la validation sur ces hypothèses. Modélisez les trois structures de coûts, Crédits Flex, Par conversation et Par utilisateur, par rapport à l’utilisation projetée avant l’engagement, car la structure optimale dépend du modèle d’utilisation et le mauvais choix est coûteux à dérouler une fois qu’un agent est en production.

La décision d’élaboration par rapport à l’achat pour les agents suit la même logique que pour n’importe quelle capacité Salesforce, en comparant le délai immédiat avant la mise en valeur d’une solution prête à l’emploi à l’adéquation précise d’une élaboration personnalisée sur un horizon de coût de revient de 3 à 5 ans. Les workflows de produits de base favorisent l’achat alors que les capacités de base qui pilotent la différenciation propriétaire justifient l’élaboration. L’entreprise Agentic offre un éventail d’options plutôt qu’un choix binaire. Les agents Agentforce prédéfinis, par exemple un agent de service ou un représentant du développement des ventes, fournissent des fonctionnalités éprouvées avec un déploiement rapide et des mises à jour gérées par la plate-forme. Ils consomment des crédits sous le modèle de tarification sélectionné. Les agents disponibles dans le commerce de la communauté Salesforce Independent Software Vendor (ISV) sont offerts via AgentExchange, où vous pouvez trouver une solution qui répond déjà à une exigence plutôt que de l’élaborer. Les agents personnalisés élaborés avec Agent Builder offrent un ajustement précis et une différenciation concurrentielle au prix d’un développement initial et d’une amélioration et d’une maintenance rapides et continues. La personnalisation d’un agent prédéfini via le Générateur de répliques et la configuration d’actions offre un juste milieu qui coûte moins cher qu’un développement personnalisé complet tout en adaptant l’agent à votre organisation. Au-delà du coût, évaluez les exigences de temps à valeur, la capacité de développement interne, la différenciation stratégique et la tolérance à la dépendance du fournisseur, puis consignez la décision dans un enregistrement de décision d’architecture pour pouvoir la réévaluer à mesure que les exigences évoluent.

La mise en œuvre d’agents ayant une compréhension claire de la structure de coûts sous-jacente permet d’adapter durablement les capacités autonomes plutôt que d’épuiser une réserve budgétaire. Le levier d’optimisation dépend du modèle de tarification, car l’ajustement du coût diffère entre le paiement par action, le paiement par conversation et le paiement par utilisateur. Le principe est constant entre les trois : Ajustez la consommation à la valeur réellement livrée, afin qu’un agent compétent ne brûle pas tranquillement son budget plus rapidement qu’il ne renvoie de résultat métier.

Sous Flex Credits, l’optimisation signifie minimiser les actions par résultat métier tout en préservant la qualité. Résolvez les requêtes simples en une seule action plutôt qu’en un workflow à plusieurs étapes, afin de ne pas consommer les crédits d’une chaîne à trois actions en répondant à un FAQ ou en effectuant une recherche de routine. Regroupez les opérations en une seule action lorsque cela s’avère logique, en combinant la récupération, l’analyse et la réponse au lieu de payer pour chacune séparément lorsqu’une action sert. Mettez les réponses en cache pour les requêtes répétées afin que les questions fréquemment posées servent en cache plutôt que de consommer des actions actualisées sur chaque requête identique, ce qui est le plus grand levier d’efficacité de ce modèle lorsqu’une part significative de requêtes se répète.

Sous Tarification par conversation, l’optimisation signifie la résolution des problèmes dans une seule conversation plutôt que dans plusieurs. Concevez des limites et des expirations de session afin de maintenir une conversation appropriée sans se terminer prématurément et forcer la tenue d’une nouvelle conversation facturable. Concentrez les capacités de l’agent sur la résolution de la première conversation afin de terminer une tâche pendant la conversation initiale plutôt que de demander un suivi. Suivez le taux de résolution de la première conversation en tant que métrique de rentabilité, et découragez l’extension du périmètre lorsqu’un utilisateur ouvre des conversations séparées pour des problèmes associés que le contexte de conversation existant aurait pu traiter.

Dans les abonnements par utilisateur, l’optimisation signifie maximiser la valeur que renvoie chaque utilisateur licencié, car la consommation n’est pas mesurée et le coût est fixe par siège. Mettez l’accent sur l’adoption afin de permettre aux utilisateurs détenteurs d’une licence d’interagir activement avec l’agent, de suivre l’utilisation afin d’identifier les utilisateurs à faible utilisation pour une formation ciblée ou une réattribution de licence, et de connecter les interactions des agents aux résultats métiers par population d’utilisateurs afin de justifier l’investissement par des cas d’utilisation à forte valeur ajoutée et de signaler un besoin d’optimisation ou un modèle de tarification différent. Examinez les populations d’utilisateurs sur une cadence pour vous assurer que les licences correspondent à l’utilisation réelle.

Quel que soit le modèle de tarification, l’architecture influence le coût. Implémentez des agents de tri qui gèrent l’acheminement initial avec une logique simple et dirigent les utilisateurs vers un agent spécialisé uniquement lorsque la complexité l’exige, afin d’éviter les invocations complexes coûteuses uniquement lorsqu’elles sont justifiées. Revenez à l’automatisation traditionnelle pour les scénarios déterministes où la logique basée sur des règles suffit, en laissant les flux gérer les parcours déterministes à moindre coût pendant que les agents gèrent les situations ambiguës qui nécessitent un véritable raisonnement. Récupérez les données d’ancrage de façon sélective, en invoquant la recherche vectorielle et la récupération de documents uniquement lorsque le raisonnement de l’agent l’exige, plutôt que sur chaque interaction, afin que la consommation de Data 360 suive les besoins réels. Ces schémas maintiennent le coût de raisonnement et de consommation de l’architecture proportionnel à la difficulté du travail.

La surveillance des coûts pour les agents autonomes est plus difficile que pour les charges de travail traditionnelles, car les agents ne suivent pas un modèle requête-réponse prévisible. Un agent peut itérer à travers un raisonnement à plusieurs étapes, invoquer de façon adaptative des outils basés sur des conditions d’exécution et coordonner d’autres agents, ce qui produit une consommation de crédit très variable difficile à prévoir. Sans surveillance, un agent qui effectue un travail itératif approfondi peut consommer un volume important de crédits avant que quelqu’un n’intervienne, et une conception rapide inefficace ou des boucles de raisonnement redondantes peuvent ponctionner discrètement les budgets de tout un parc d’agents. Une gouvernance efficace nécessite donc une visibilité en temps réel sur la consommation par agent et par opération, des alertes automatisées, et des contrôles qui évitent l’emballement des coûts tout en préservant l’autonomie qui rend les agents utiles. La gouvernance financière des agents nécessite également une propriété claire et une approbation par paliers conçue pour la consommation variable plutôt que pour le coût de calcul statique.

Salesforce Digital Wallet est l’outil intégré de surveillance des produits basés sur la consommation, y compris les Crédits Flex Agentforce. Les organisations qui utilisent des Crédits Flex devraient le définir comme principal mécanisme de surveillance des coûts plutôt que d’élaborer des tableaux de bord personnalisés pour répliquer ce qu’il fournit. Digital Wallet fournit des données de consommation en temps quasi réel avec des connaissances sur l’utilisation au niveau de l’action, une répartition par agent montrant les agents qui consomment le plus, des alertes de consommation proactives, et des tendances historiques pour l’analyse des schémas et les prévisions. Mappez la surveillance avec le modèle de tarification. Sous Flex Credits, suivez la consommation par agent, population d’utilisateurs, période et type d’action, et complétez Digital Wallet avec des tableaux de bord personnalisés qui connectent la consommation de crédit aux transactions commerciales. Sous Tarification par conversation, surveillez les volumes de conversations, la durée moyenne et les taux de réalisation. Sous Abonnements par utilisateur, surveillez l’utilisation plutôt que la consommation, en suivant les utilisateurs actifs et la valeur métier par utilisateur afin d’afficher une valeur proportionnelle à l’investissement dans la licence.

L’attribution du coût par interaction connecte la consommation aux transactions commerciales et révèle le coût par requête résolue, par piste qualifiée ou par commande traitée, ce qui permet le calcul du retour sur investissement et la comparaison entre les cas d’utilisation. L’alerte budgétaire déclenche une notification lorsque la consommation approche des seuils définis, à des seuils tels que 70 % et 85 % du budget, de sorte que l’optimisation ait lieu avant qu’une limite soit atteinte. Configurez des alertes par agent et par cas d’utilisation, pas seulement à l’échelle de l’organisation, pour localiser un problème à sa source. La détection d’anomalies met en évidence le pic de consommation soudain qui signale un modèle d’utilisation inattendu ou une boucle de raisonnement qui nécessite une investigation. Partagez des tableaux de bord de coût avec les parties prenantes et les équipes techniques afin que la transparence favorise l’utilisation des agents conscients des coûts.

Appliquez la gouvernance financière avant d’engager des dépenses dans une architecture d’agent. Demander une analyse de rentabilisation pour un investissement de l’agent qui couvre le TCO projeté sur 3 à 5 ans dans le modèle de tarification sélectionné, les résultats commerciaux attendus avec une méthode de mesure, une comparaison avec des alternatives, y compris les processus manuels et l’automatisation traditionnelle, et une évaluation des risques couvrant la qualité, la sécurité et les risques opérationnels. Définissez des seuils d’approbation qui séparent les investissements qu’un ministère peut autoriser de ceux qui nécessitent l’approbation de la direction, afin de permettre à un agent d’investissement élevé ou à risque élevé de faire l’objet d’un examen approfondi. Obligez des déploiements pilotes qui valident les hypothèses avant la production complète, car un pilote révèle la consommation réelle, la qualité et l’adoption qui informent à la fois la décision d’investissement en production et la sélection du modèle de tarification.

Gérez la succession d’agents en tant que portefeuille plutôt qu’agent par agent, car une vue de portefeuille révèle les opportunités d’optimisation qu’un examen par un seul agent manque. Examinez tous les agents ensemble, en comparant le coût, l’utilisation, la valeur métier et l’alignement stratégique, et définissez des critères d’extinction qui imposent aux agents de retirer leur emploi avec une faible adoption, un retour sur investissement faible, une fonctionnalité remplacée ou un coût excessif, afin d’éviter que les agents à faible valeur n’accumulent et ne consomment un budget indéfiniment. Réaffectez les investissements des agents peu performants aux opportunités à valeur élevée en tant que pratique continue qui réaligne les dépenses sur l’évolution des priorités plutôt que sur un nettoyage unique.

L’allocation des coûts crée une responsabilité pour la consommation des agents, et les organisations l’implémentent à travers les deux mêmes modèles qui s’appliquent au reste de la plate-forme. Showback rapporte les coûts des agents par unité commerciale sans frais internes, ce qui crée une prise de conscience des coûts et informe la discussion sur l’optimisation sans se contenter de la facturation interne. La rétrofacturation alloue les coûts réels des agents aux unités commerciales consommatrices, ce qui favorise un comportement d’optimisation plus fort, car le coût affecte directement un budget ministériel, mais nécessite une méthode d’allocation précise pour éviter les litiges. Une approche hybride applique la rétrofacturation aux agents de production à haut volume tout en utilisant la rétrospective pour les agents expérimentaux ou à faible volume, ce qui équilibre la responsabilité des investissements majeurs et la flexibilité pour l’innovation.

Les architectures d’agents introduisent leurs propres considérations de développement durable, car l’inférence de grand modèle de langage est exigeante en calculs et certains agents sont exécutés en continu plutôt que seulement dans des transactions discrètes déclenchées par l’utilisateur. Les agents proactifs, sortants et planifiés fonctionnent sans utilisateur dans la boucle, les agents conversationnels accumulent la consommation à de nombreux moments, et la recherche vectorielle, la préparation du contexte et l’exécution d’actions augmentent la charge de l’infrastructure. La conception durable des agents réduit le gaspillage informatique tout en préservant la réactivité de l’expérience. Comme dans le pilier Optimisation des ressources et des coûts, la relation entre une solution et les émissions du centre de données est indirecte. L’efficacité d’un locataire unique ne réduit pas directement les émissions. Cependant, les gains d’efficacité entre tous les locataires aident Salesforce à exploiter son infrastructure à une plus grande échelle et à reporter l’expansion de la capacité. et les pratiques fondamentales de développement durable du pilier Optimisation des ressources et des coûts s’appliquent aux agents, et les stratégies d’efficacité qui en découlent traitent toutes les deux de ce qui est spécifique aux systèmes conversationnels pilotés par un grand modèle de langage. Chacune réduit également le coût, ce qui explique que la durabilité et la valeur par coût sont la même discipline mesurée par rapport à des résultats différents.

L’inférence est le composant le plus gourmand en ressources d’une architecture agentique. Par conséquent, l’efficacité est payante avec la longueur de l’invite, l’utilisation du contexte et la mise en cache. Optimisez les invites pour transmettre l’intention en moins de jetons en retirant les instructions verbeuses et les exemples redondants, car une invite plus courte réduit proportionnellement le calcul de préremplissage, même si elle ne change pas le calcul de génération de la réponse. Gérez la fenêtre contextuelle en résumant l’historique de la conversation après les premiers tours de table et en renvoyant uniquement les champs essentiels de chaque action, afin que le budget de jeton inclus dans chaque inférence reste limité au lieu de croître avec la conversation.

Les requêtes de recherche vectorielle et de profil unifié consomment des ressources de calcul. Par conséquent, la même discipline de limitation des résultats et de filtrage qui contrôle le coût d’ancrage réduit également la charge d’infrastructure d’ancrage. Définissez des limites top-k pour renvoyer uniquement les résultats que l’agent utilise, car la récupération de 50 lorsque 5 informe la réponse renvoie 45 résultats inutilisés qui consomment un budget de jeton d’ancrage sans avantage, et utilisez des filtres de métadonnées pour affiner la recherche avant le classement par similarité. Interrogez des profils unifiés pour assembler le contexte complet en une seule opération plutôt que d’émettre des requêtes séparées sur plusieurs objets à chaque tour, et mettez en cache les profils des agents qui ont une grande affinité avec l’utilisateur, par exemple un agent commercial travaillant sur un ensemble fixe de comptes, afin d’éviter que l’assemblage de contexte répété ne répète la requête.

Les actions des agents consomment des requêtes SOQL, des opérations DML et du temps processeur. Par conséquent, la mise en masse, la mise en cache et la discipline asynchrone du pilier Optimisation des ressources et des coûts s’appliquent directement aux actions des agents. Concevez des actions pour accepter des collections de sorte que la mise à jour de nombreux enregistrements soit une opération plutôt que plusieurs, utilisez des requêtes de relation pour récupérer les données parentes et enfants dans une instruction unique, mettez en cache les données de référence dans le Cache de la plate-forme et distribuez des fichiers DML par lot dans une collection plutôt que par enregistrement. Déplacez les opérations qui dépassent les limites synchrones vers Apex Queueable ou Batch, traitez les travaux non urgents tels que le score en masse ou l’enrichissement historique de façon asynchrone, et planifiez des tâches par lot déclenchées par l’agent pour les fenêtres creuses si possible afin que la charge se répartisse dans le temps plutôt que de se concentrer pendant les heures ouvrables. Surveillez l’exécution asynchrone afin d’éviter qu’un backlog de file d’attente ne signale un besoin de planification de capacité.

Les modèles de consommation des agents évoluent à mesure que l’utilisation augmente. Par conséquent, la durabilité nécessite une surveillance continue plutôt qu’un passage unique. Suivez le nombre moyen de jetons par inférence à travers la télémétrie d’utilisation disponible afin d’exposer une opportunité d’optimisation avec une taille d’invite croissante, surveillez la distribution de la durée des conversations afin d’identifier un problème lié à une tâche dans les conversations illimitées et analysez la fréquence d’exécution d’actions dans la Surveillance des événements afin de définir une action à haute fréquence comme une priorité d’optimisation. Examinez les modèles de requête Data 360 pour trouver les requêtes courantes qui méritent une mise en cache ou un précalcul, suivez le taux de succès de la mise en cache sémantique afin qu’un taux bas déclenche l’ajustement du seuil et mesurez les percentiles de latence afin d’exposer les goulets d’étranglement. Examinez régulièrement l’utilisation des agents pour détecter une dérive de l’étendue. Examinez par exemple un agent dont la durée moyenne de la conversation passe de quelques tours à plusieurs sur plusieurs mois. Affinez les limites de l’agent pour rétablir la consommation. Certaines de ces surfaces de surveillance exposent l’utilisation dans des tableaux de bord agrégés plutôt que dans un journal discret par inférence. Par conséquent, vérifiez la télémétrie exacte disponible pour votre configuration lorsque vous concevez la surveillance.

L’optimisation des ressources détermine si les architectures des agents évoluent à mesure que la population augmente et que les cas d’utilisation augmentent, et l’optimisation des coûts détermine si cette échelle renvoie une valeur métier proportionnelle. Ces deux décisions forment un mandat unique :

• Efficacité architecturale : concevoir des actions en masse, budgéter SOQL à travers les chaînes d’action, déplacer les traitements lourds vers l’asynchronisme, optimiser la consommation d’API à travers des modèles composés et pilotés par l’événement, gérer les fenêtres de contexte à travers la priorisation et la synthèse, et élaborer des architectures composables à partir de composants réutilisables.
• Orientations financières : sélectionnez délibérément le modèle de tarification, modélisez le TCO complet avant de vous engager, surveillez la consommation par rapport aux résultats commerciaux et régissez l’investissement par approbation par paliers et examen du portefeuille.

Les organisations qui maîtrisent ces modèles offrent des expériences réactives aux agents dans les contraintes de la plate-forme tout en adaptant les dépenses à la valeur renvoyée par les agents.

Le guide d’optimisation des ressources et des coûts de base de toutes les solutions Salesforce, y compris l’optimisation des performances, les limites du gouverneur, l’analyse TCO, la discipline de licence et la gouvernance des coûts, réside dans le pilier Optimisation des ressources et des coûts. Les composants de gouvernance des agents, de surveillance humaine et de programme de sécurité sont liés aux piliers Trust et Équité. Les conseils détaillés d’implémentation des agents de ce document, qui couvrent l’efficacité des ressources, l’économie, l’optimisation des actions, la gouvernance et la durabilité, sont rassemblés dans la bibliothèque de modèles d’agent.

Partagez vos commentaires sur l'infrastructure bien archivée.