Revenir au contenu principal
Agent Bricks

Comment mettre à l'échelle les applications agentiques sans prolifération de l'IA

Alors que les agents passent de la simple réponse aux questions à la prise d'actions sur les données, les modèles et les systèmes métier, les entreprises ont besoin d'un socle commun pour le choix, le contexte et le contrôle.

par Julia Brouillette et Sirui Sun

  • À mesure que les applications agentiques deviennent plus autonomes, les entreprises ont besoin d'une infrastructure partagée pour l'accès au contexte, aux modèles et aux outils, la gouvernance, l'évaluation et l'observabilité, plutôt que de recréer ces capacités pour chaque agent.
  • Le choix permet aux équipes d'adopter les modèles, outils et frameworks appropriés à mesure que l'écosystème évolue, tandis que le contexte ancre les agents dans des données d'entreprise gouvernées et une signification métier.
  • Le contrôle devient plus important à mesure que les agents effectuent des actions, ce qui nécessite des autorisations limitées, des politiques cohérentes, du traçage, de l'évaluation et une visibilité opérationnelle sur l'ensemble des applications.

Créer un agent devient de plus en plus facile. Des modèles plus performants et des agents de codage permettent de concevoir et d'itérer plus rapidement. Cependant, gérer de nombreux agents à l'échelle d'une entreprise est un autre défi.

À mesure que les agents passent de la simple réponse aux questions à la prise d'actions, ils dépendent de plus en plus d'un réseau de modèles, de données d'entreprise, de sémantique métier, d'outils et d'applications. Un seul workflow peut récupérer des données gouvernées, sélectionner un modèle, appeler plusieurs outils, transférer le travail à un autre agent et mettre à jour un système métier — le tout en fonctionnant avec les autorisations appropriées et en laissant une trace suffisante pour comprendre ce qui s'est passé.

À mesure que chaque équipe assemble ces éléments de manière indépendante, un nouveau type de prolifération de l'AI peut apparaître : des intégrations dupliquées, des politiques incohérentes, une augmentation des dépenses d'AI, un contexte fragmenté et des applications de plus en plus difficiles à modifier à mesure que le nombre d'agents augmente.

Le défi consiste à faire évoluer ces applications à l'échelle sans multiplier l'infrastructure autour de chacune d'elles.

Schéma de la boucle de l'agent

Nous avons récemment réuni Databricks, OpenAI et Stellantis pour examiner ce qu'il faut pour déployer des applications d'agents à l'échelle en production. L'un des thèmes centraux était que, à mesure que les agents deviennent plus performants et autonomes, l'infrastructure qui les entoure gagne en importance.

À l'échelle de l'entreprise, cette infrastructure doit offrir trois éléments : le choix, pour que les équipes puissent utiliser les modèles, outils et frameworks appropriés au fil de leur évolution ; le contexte, pour que les agents puissent travailler avec des données d'entreprise gouvernées et une sémantique métier ; et le contrôle, afin que les autorisations, les politiques, l'évaluation, l'observabilité et la gestion des coûts restent cohérentes à mesure que les applications se développent.

Sur Databricks, ce socle réunit Agent Bricks, Omnigent et Unity Gateway. Agent Bricks fournit la plateforme unifiée pour créer, gouverner et optimiser des flottes d'agents. Omnigent offre aux équipes une couche commune pour travailler sur différents frameworks d'agents, tandis que Unity Gateway centralise l'accès, le contrôle des coûts et l'observabilité pour l'ensemble des modèles, agents et outils utilisés par ces applications.

Grâce à ces fonctionnalités partagées entre les applications, les équipes peuvent ajouter de nouveaux agents et workflows sans avoir à transformer chacun d'eux en un projet d'intégration et de gouvernance distinct.

Le contexte doit être partagé, pas reconstruit

Un agent d'entreprise a besoin de plus qu'un simple accès à un modèle. Il a besoin des données, des définitions métier, des documents, des applications et des outils nécessaires pour comprendre la tâche à accomplir.

Ce contexte existe souvent déjà au sein de l'organisation. Le défi consiste à le mettre à la disposition des agents sous une forme gouvernée et réutilisable.

Prenons l'exemple de deux agents au service d'équipes différentes. Un agent commercial et un agent de support client peuvent tous deux avoir besoin de comprendre qui est considéré comme un client actif, quels produits ce client possède et comment les hiérarchies de comptes sont définies. Si chaque application recrée ces définitions de manière indépendante, un même concept métier peut signifier des choses différentes d'un workflow à l'autre.

Cette fragmentation crée également plus d'infrastructures à maintenir, car les équipes connectent les agents séparément aux données clients, aux définitions de produits, aux métriques et aux documents internes.

Agent Bricks s'appuie sur une couche de contexte partagée, construite autour de données d'entreprise gouvernées et de sémantique métier. Unity Catalog gouverne l'accès aux données et aux actifs d'AI, tandis que la Genie Ontology donne aux agents une compréhension commune des concepts métier et de leurs relations. Des fonctionnalités telles que Document Intelligence, AI Search et Agent Memory permettent d'enrichir ce contexte grâce à la compréhension de documents, à la recherche et à l'historique pour des workflows plus complexes.

Les équipes peuvent ensuite réutiliser le même contexte métier gouverné à travers les applications au lieu de le recréer à chaque fois.

Le choix ne doit pas créer de fragmentation

Le meilleur modèle, outil ou framework d'agent pour une tâche donnée est rarement définitif.

Différentes étapes d'une application d'agent peuvent nécessiter différents compromis entre qualité de raisonnement, latence et coût. De nouveaux modèles et frameworks continuent d'apparaître, et des workflows complexes peuvent en combiner plusieurs à la fois.

Cette flexibilité devient difficile à gérer lorsque chaque framework possède sa propre interface, ses propres sessions, ses propres politiques et son propre mode d'exécution.

Omnigent ajoute une couche commune au-dessus des frameworks d'agents, permettant aux équipes de composer des agents construits avec différents frameworks et de passer de l'un à l'autre avec moins de retravail. Unity Gateway gère le choix au niveau des modèles et des frameworks, offrant un accès cohérent aux modèles propriétaires et open source, ainsi que des fonctionnalités de Smart Routing, de gestion de la capacité et de contrôle des coûts.

Ensemble, ces couches permettent aux équipes de modifier les modèles et les technologies d'agents qui sous-tendent une application tout en maintenant la cohérence de l'infrastructure environnante.

Le contrôle doit suivre chaque action

Le besoin de contrôle s'accroît à mesure que les agents passent de la génération de réponses à la prise d'actions.

Un agent peut lire des données d'entreprise, appeler un système métier, exécuter du code, mettre à jour un workflow ou solliciter un autre agent. Chaque fonctionnalité supplémentaire élargit le champ d'action de l'application et crée de nouvelles interactions qui doivent être gouvernées.

Prenons l'exemple d'un agent gérant le remboursement d'un client. L'employé qui initie la demande peut disposer d'un accès étendu au compte du client. En revanche, l'agent n'a besoin que des détails de la commande, de la politique de remboursement applicable et de l'autorisation d'effectuer une transaction spécifique. Son niveau d'habilitation doit correspondre strictement à la tâche qui lui a été confiée.

Cela nécessite des contrôles qui couvrent l'ensemble de l'interaction d'AI.

Unity Gateway fournit un plan de contrôle centralisé pour les modèles, les agents, les serveurs MCP, les outils et les compétences. Les équipes peuvent appliquer des politiques d'accès et des garde-fous (guardrails), gérer les budgets et les limites de débit, contrôler les actifs d'AI disponibles et conserver des traces de ces interactions. Associés à Unity Catalog, ces contrôles peuvent refléter l'identité, les autorisations de données et le contexte de chaque requête.

Pour les charges de travail qui exécutent du code ou des outils, Databricks Sandbox ajoute un environnement d'exécution isolé avec un accès restreint aux données et aux systèmes dont l'agent a besoin.

Le résultat est une délimitation plus claire de ce à quoi un agent peut accéder, des actions qu'il peut entreprendre et de la manière dont ces décisions sont appliquées à mesure que les applications se développent.

Le contrôle exige également une visibilité sur ce qui s'est passé

Dès lors qu'une application peut récupérer du contexte, choisir des modèles, appeler des outils et coordonner plusieurs étapes, sa réponse finale ne raconte qu'une partie de l'histoire.

Une réponse en apparence correcte peut masquer un échec de récupération, l'appel d'un mauvais outil ou un chemin d'exécution inattendu. En cas de problème, les équipes doivent pouvoir reconstituer la manière dont l'application est parvenue à son résultat : quelles informations elle a utilisées, quels outils elle a appelés, quel modèle a traité la tâche, quelles politiques ont été appliquées et à quel moment le comportement a dévié des attentes.

Unity Gateway centralise la télémétrie de l'ensemble des interactions d'AI, y compris les traces, l'utilisation, le coût et l'activité des outils. MLflow complète cette visibilité opérationnelle par des workflows de traçage et d'évaluation qui permettent aux équipes d'inspecter le comportement des applications, de capturer des interactions représentatives dans des ensembles de données et d'évaluer les modifications apportées aux prompts, aux modèles, aux outils ou à l'orchestration.

Ce retour d'expérience peut orienter la prochaine itération de l'application. Les équipes peuvent comparer les changements avant un déploiement plus large, identifier les régressions et s'appuyer sur le comportement en production pour améliorer la qualité, la fiabilité et optimiser les coûts au fil du temps.

Une infrastructure partagée facilite la composition

Les flux de travail métier plus larges impliquent souvent plusieurs agents, modèles ou outils. Un composant peut comprendre la demande d'un utilisateur, un autre analyser des données, et un système déterministe effectuer un calcul ou mettre à jour un processus métier.

La capacité à assembler ces éléments gagne en valeur lorsque l'infrastructure qui les entoure est déjà partagée. Omnigent fournit une interface commune pour les agents conçus avec différents frameworks, tandis qu'Agent Bricks offre la plateforme plus large pour créer et exploiter la flotte d'agents qui en résulte. Le même contexte gouverné et les mêmes contrôles peuvent s'appliquer à l'ensemble du flux de travail.

Schéma d'architecture d'Agent Bricks

À mesure que les équipes développent de nouvelles applications, les agents, les outils, les compétences et le contexte métier peuvent devenir des blocs de construction réutilisables. Les nouveaux flux de travail peuvent s'appuyer sur une infrastructure existante, bien gouvernée et observable, plutôt que de créer une autre pile technologique isolée.

Concevoir pour le choix, le contexte et le contrôle

À mesure que les agents gagnent en capacités, l'architecture qui les entoure supporte une plus grande part de responsabilité pour les rendre fiables à l'échelle de l'entreprise.

Le choix donne aux équipes la flexibilité nécessaire pour adopter de nouveaux modèles, frameworks et outils au fil de l'évolution de l'écosystème. 

Le contexte ancre ces applications dans des données d'entreprise gouvernées et la sémantique métier. 

Le contrôle assure une gouvernance et des opérations cohérentes sur l'ensemble de la flotte d'agents qui en résulte, des autorisations et politiques aux budgets, traces, évaluations et coûts.

Agent Bricks rassemble ces capacités au sein d'une plateforme unifiée pour créer, gouverner et optimiser des flottes d'agents à grande échelle, Omnigent facilitant la composition entre différents frameworks et Unity Gateway fournissant un plan de contrôle commun pour toutes les interactions AI.

Les modèles et les frameworks continueront d'évoluer. Les entreprises n'ont pas besoin de se standardiser sur l'un d'eux pour réussir leur mise à l'échelle. Elles doivent plutôt standardiser l'infrastructure qui les entoure, afin que les nouveaux agents puissent hériter du même contexte, des mêmes contrôles et du même modèle opérationnel, sans créer une couche supplémentaire de prolifération de l'AI.

En savoir plus

Regardez Agents at Work: Shipping Agentic Apps at Scale à la demande pour approfondir l'infrastructure, le modèle opérationnel et les modèles de production qui sous-tendent les applications basées sur des agents en entreprise.

Pour commencer

Avec la CLI d'Agent Bricks, la prise en main est simple. En quelques lignes de code seulement, vous pouvez développer un agent intégré à toutes les fonctionnalités d'Agent Bricks, y compris Unity Gateway pour la capacité des modèles, le Runtime hébergé sur l'infrastructure Databricks, et le traçage d'agents optimisé par MLflow.

 

 

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original

Recevez les derniers articles dans votre boîte mail

Abonnez-vous à notre blog et recevez les derniers articles directement dans votre boîte mail.