Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Les agents rencontrent la multilocation
Il est facile de considérer les agents comme des éléments de base, les agents étant considérés comme une série de composants autonomes assemblés pour répondre aux besoins d'un domaine ou d'un problème commercial spécifique. Là où cela devient plus intéressant, c'est lorsque nous commençons à réfléchir à la manière dont ces agents sont conditionnés et consommés par les fournisseurs. À bien des égards, un agent devient une source de coûts et de revenus pour une entreprise. Les fournisseurs d'agents doivent tenir compte des différentes personnes qui consomment leurs services, du profil de consommation de ces personnes et des stratégies de monétisation qui permettent aux fournisseurs d'agents de créer des modèles de tarification et de hiérarchisation adaptés aux consommateurs.
Les fournisseurs d'agents peuvent prendre en charge plusieurs modèles de déploiement de leurs agents afin de répondre aux besoins des clients. Le schéma suivant présente une vue conceptuelle des deux principaux modèles de déploiement d'agents.
Le côté gauche du schéma montre le modèle d'agent dédié au client. Un fournisseur d'agent crée un agent en déployant une instance d'agent distincte pour chaque client intégré. Avec cette approche, les capacités de l'agent et sa capacité à acquérir des connaissances seraient limitées à l'environnement d'un client donné. Cela finit par représenter une expérience par client qui hérite de certaines des complexités et des avantages liés à la prise en charge d'environnements clients dédiés.
En revanche, le schéma sur le côté droit du diagramme comporte un seul agent déployé dans l'environnement du fournisseur. L'agent traite les demandes de plusieurs clients, évolue et apprend en fonction de l'expérience collective de tous les clients. Chaque nouveau client ajouté représentera simplement un autre client valide de l'agent. L'agent fonctionne comme un modèle d'agent en tant que service (AaaS), en utilisant des structures partagées pour répondre aux besoins du client. Dans les deux cas, les consommateurs d'agents peuvent être des applications, des systèmes ou même d'autres agents.
Il existe deux manières d'envisager le modèle AaaS. Le modèle ci-dessus offre la même expérience à tous les clients. Cela signifie que le personnel interne de l'agent n'inclura aucun niveau de spécialisation tenant compte du contexte du client demandeur. En général, pour ce mode, l'hypothèse est que la nature du champ d'action, des objectifs et de la valeur d'un agent est centrée sur un ensemble partagé de ressources, de connaissances et de résultats qui sont appliqués universellement à tous les clients.
L'approche alternative de l'AaaS est celle où le contexte des clients influence l'expérience et la mise en œuvre de l'agent. Le schéma suivant fournit une vue conceptuelle de l'empreinte d'un agent AaaS dans ce contexte.
Dans cette vue AaaS, l'origine et le contexte des demandes entrantes affectent de manière significative l'empreinte de l'agent. Les ressources, les actions et les outils qui font partie de l'implémentation sous-jacente de l'agent peuvent varier en fonction de chaque demande entrante du locataire. La valeur d'un agent est liée à sa capacité à utiliser le contexte du locataire pour parvenir à des actions et à des résultats influencés par l'état, les connaissances et d'autres facteurs du locataire. Certaines demandes peuvent produire un résultat unique pour le locataire, tandis que d'autres peuvent conduire à des résultats plus personnalisés par locataire. Cela ajoute une nouvelle dimension à la capacité d'apprentissage de l'agent, notamment en étant plus contextuel et en acquérant et en appliquant des connaissances qui améliorent les résultats ciblés.
Pour les fournisseurs, le modèle AaaS présente de nombreux avantages. Lorsque plusieurs clients utilisent un seul agent, le fournisseur a de meilleures chances de réaliser des économies d'échelle, de renforcer l'efficacité opérationnelle, de contrôler les coûts et de créer une expérience de gestion unifiée. Cela a le potentiel d'améliorer l'agilité, l'innovation et la croissance du secteur des agents.
Ces qualités se recoupent avec les mêmes principes qui sous-tendent l'adoption du modèle SaaS (logiciel en tant que service). Essentiellement, le modèle AaaS est conçu comme un service mutualisé qui hérite de nombreux attributs d'échelle, de résilience, d'isolation, d'intégration et opérationnels identiques à ceux d'un environnement SaaS. À bien des égards, l'expérience AaaS s'inspire largement des stratégies et pratiques utilisées par les fournisseurs de SaaS, mais il est raisonnable de séparer ces termes. Pour nos besoins, l'accent est principalement mis sur les implications liées aux agents de construction et d'exploitation qui ont besoin d'un soutien multilocataire.
Pour un système capable de traiter tous les utilisateurs de la même manière et ne nécessitant pas la gestion de données persistantes, sensibles ou spécifiques au client, la notion de location affecterait très peu ses agents. Pour les systèmes censés servir plusieurs clients tout en préservant l'isolation des données, la personnalisation et la connaissance du contexte, la prise en charge de plusieurs locataires peut être un élément essentiel de la conception, de la stratégie et des objectifs d'un agent. Le schéma suivant montre comment la mutualisation peut être utilisée dans des environnements agentiques.
Sur le côté gauche de ce schéma se trouve une architecture multi-locataires classique. Il inclut une application Web et une série de microservices qui mettent en œuvre une logique métier. Plusieurs locataires utilisent l'infrastructure partagée de cet environnement, qui évolue pour répondre aux charges de travail changeantes d'une population de locataires en constante évolution. L'environnement est exploité et géré par le biais d'une seule vitre pour tous les locataires.
Imaginez comment ce modèle mental correspond à l'agent sur le côté droit de ce diagramme. Un agent exécute un modèle AaaS utilisé par un ou plusieurs locataires. Les agents peuvent provenir de plusieurs fournisseurs avec un contexte de locataire circulant entre eux, car une seule instance d'un agent doit traiter les demandes de plusieurs locataires.
L'exemple au milieu de ce diagramme est un modèle hybride dans lequel les agents font partie de l'expérience globale du SaaS. Certaines parties du système sont mises en œuvre selon un modèle plus traditionnel, tandis que d'autres font appel à des agents. Ce schéma est susceptible d'être courant pour de nombreuses offres SaaS, en particulier pour les organisations qui passent à une expérience agentique. Il est courant que ce modèle persiste, car tous les systèmes ne sont pas fournis en tant que pur AaaS. Notez également que la mutualisation s'applique toujours aux agents du modèle. Bien que les agents puissent être intégrés dans un système, ils peuvent toujours traiter les demandes de plusieurs locataires.
Il est naturel de se demander si la mutualisation est vraiment importante. Vous pourriez faire valoir qu'un agent traite les demandes, de sorte que le soutien à la location peut avoir peu d'effet. Mais au fur et à mesure que nous étudions les implications agentiques du multi-tenant, la location peut affecter directement la manière dont les agents influencent la manière dont les outils, la mémoire, les données et les autres composants de l'agent sont accessibles, déployés et configurés pour prendre en charge les locataires individuels. La location influence également la manière dont la mise à l'échelle, la limitation, la tarification, la hiérarchisation et d'autres aspects commerciaux s'appliquent à l'architecture de votre agent.
L'un des points à retenir est qu'il existe des cas d'utilisation d'agentic qui nécessitent une assistance multi-locataires. Le défi consiste à déterminer comment la mutualisation façonne la conception globale et l'architecture de votre expérience agentique. Pour certains agents, le support mutualisé représente une capacité de différenciation, permettant aux agents d'appliquer un contexte spécifique au locataire aux agents qui fournissent des résultats ciblés.
Dans les sections suivantes, vous verrez en quoi la terminologie et les modèles de conception que nous créons pour décrire les architectures SaaS multi-locataires seront utiles. Ces concepts peuvent être adoptés par le modèle AaaS en empruntant des aspects utiles, qui introduisent de nouveaux concepts spécifiques aux agents là où ils sont nécessaires.
Identité, contexte du locataire et systèmes agentiques
Ajouter le contexte du locataire à des agents individuels n'est pas particulièrement difficile. Dans de nombreux cas, les équipes peuvent s'appuyer sur des mécanismes classiques qui lient les utilisateurs et les systèmes aux locataires et transmettent des jetons tenant compte des locataires aux agents. Cela est pertinent lorsque nous examinons la manière dont le contexte et l'identité des locataires prennent en charge plusieurs agents. Dans ce modèle, les locataires doivent être liés à une identité qui couvre tous les agents collaborateurs.
En général, le domaine agentique nécessite un modèle d'identité plus transversal qui s'aligne sur les besoins actuels et émergents des systèmes agentiques. Les fournisseurs d'agents ont besoin de mécanismes d'identité qui prennent en charge les modèles uniques de sécurité, de conformité et d'autorisation fournis avec les systèmes d'agentic d'exploitation. Cela est particulièrement difficile dans les environnements où les systèmes sont composés par des clients ou d'autres agents. Chaque agent intégré doit associer son identité et son contexte de locataire aux interactions avec les agents. Le schéma suivant met en évidence les défis potentiels liés à l'identité et au contexte des locataires qui font partie des interactions agent-to-agent (a2a).
Ce schéma montre une série d'agents créés par les fournisseurs interagissant dans le cadre du système agentic que nous avons abordé. Il est désormais modernisé en fonction de l'identité et du contexte du locataire. Ce scénario est un exemple de système agentique qui prend en charge plusieurs points d'entrée. Nous partons du principe que chaque agent de ce système a besoin de son propre mécanisme d'authentification pour attribuer le système ou l'utilisateur à un locataire donné. Lorsque ces agents interagissent, le contexte du locataire est transmis à un jeton Web JSON (JWT) qui sera utilisé pour autoriser l'accès et injecter le contexte du locataire dans l'agent.
Conceptuellement, la principale différence avec ce scénario est que les agents se déploient et opèrent de manière indépendante, ce qui signifie que chaque agent doit être en mesure de résoudre son identité et d'autoriser l'accès. L'essentiel est que son identité doit avoir une certaine capacité distribuée pour répondre aux besoins du système agentique au sens large. Il doit également y avoir un alignement sur la manière dont les agents partagent le contexte des locataires.
Appliquer la valeur commerciale du SaaS à l'AAaS
En général, lorsque nous examinons l'utilisation d'un système dans un as-a-service modèle, nous prenons en compte la nature de l'expérience et la manière dont son empreinte technique et opérationnelle améliore les résultats commerciaux. Lors de l'adoption du SaaS, par exemple, les entreprises utilisent les économies d'échelle, l'efficacité opérationnelle, les profils de coûts et l'agilité pour stimuler la croissance, les marges et l'innovation.
Les agents fournis sous forme d'AaaS sont susceptibles de viser des résultats commerciaux similaires. En prenant en charge plusieurs locataires, un agent peut aligner la consommation de ressources sur les activités des locataires. Cela permet de réaliser des économies d'échelle, comme c'est le cas avec les environnements SaaS traditionnels. L'AaaS permet également aux entreprises de gérer, d'exploiter et de déployer des agents de manière à permettre des mises à disposition fréquentes et à accroître l'agilité des fournisseurs d'agents. L'essentiel est que le modèle AaaS ne dépend pas de la technologie. Il crée et met en œuvre des stratégies commerciales qui favorisent la croissance, rationalisent l'adoption et simplifient les opérations.