Agent Builder, bien plus qu’une interface de discussion : vers une infrastructure augmentée

Ce n'est pas une discussion. Nous le faisons.

Nous avons tous été témoins de l’essor des agents d’IA. Ils se révèlent particulièrement performants pour le résumé de textes, l’écriture de scripts et l’extraction de réponses issues de bases documentaires. Pourtant, dans les domaines du DevOps et de la fiabilité système (SRE), nous faisions face à un obstacle particulièrement frustrant. L’immense majorité des agents reste confinée au modèle du support client ; s’ils analysent et échangent, ils demeurent incapables d’intervenir directement sur les couches d’infrastructure dont ils ont la charge.

Lors de notre récent hackathon, nous avons pris le parti de briser définitivement cette contrainte.

Nous avons conçu l’Infrastructure augmentée : un copilote d’infrastructure qui ne se contente pas de vous conseiller, mais qui crée, déploie, surveille et répare également votre environnement de production.

Le problème : copier, reformater, coller

Les agents standards fonctionnent en vase clos. Face à une panne majeure représentant une perte de 5 millions de dollars, l’assistance d’un agent standard se limite à la simple lecture du protocole de remise en service. Mais c’est toujours à vous d’effectuer le travail. Il vous reste encore à extraire le code, à en assurer la compatibilité avec votre environnement, puis à procéder manuellement à sa saisie dans la console.

Nous recherchions un agent capable de faire la part des choses entre le discours sur Kubernetes et l’exécution technique sur Kubernetes.

Au cœur du système : présentation d’Elastic Agent Builder.

Pour concevoir cette solution, nous ne sommes pas partis d’une page blanche. Nous l’avons conçue sur la base d’Elastic Agent Builder. À titre de rappel, Elastic Agent Builder est une architecture logicielle dédiée au développement rapide d’agents, agissant comme interface entre un modèle de langage (LLM), tel que Google Gemini, et les données propriétaires hébergées dans Elasticsearch.

Agent Builder peut être utilisé pour l’IA conversationnelle en l’ancrant sur des données internes, comme des documents ou des logs. Mais sa fonctionnalité la plus puissante est la possibilité d’assigner des outils. Ces outils permettent au LLM de sortir de l’interface de discussion pour accomplir des tâches spécifiques. Nous avons compris qu’en exploitant tout le potentiel de cette fonction, l’Agent Builder pourrait devenir un véritable pilier de l’automatisation.

Le faire fonctionner : création de la première version

Dès le début du projet, notre ambition était de permettre aux agents d’exercer une action concrète sur leur environnement externe. Une idée a germé : pourquoi ne pas créer un « runner », un logiciel chargé d’exécuter sur la machine hôte toutes les instructions générées par l’agent ? Puis, nous avons envisagé ceci : et si les « runners », Elastic Agent Builder et l’utilisateur communiquaient en temps réel, comme lors d’une conférence téléphonique ?

Nous avons commencé par concevoir un projet Python, Augmented Infrastructure Runners, qui consistait essentiellement en une boucle while(true) interrogeant chaque seconde l’API des conversations d’Elastic Agent Builder pour y détecter une syntaxe spécifique que nous avions créée :

Nous avons ensuite mis à jour l'invite pour l'enseigner sur notre nouvelle syntaxe d'appel d'outil. Bill contribue à la maintenance de FastMCP, la solution de référence en Python pour le développement de serveurs conformes au Model Context Protocol (MCP). Il a entrepris d’utiliser le client FastMCP conjointement avec ce nouveau runner afin de coupler les serveurs MCP et d’exposer leurs outils au sein de l’environnement d’exécution. Lorsque l’agent voyait cela, il exécutait l’appel de l’outil et POST les résultats dans la conversation, comme si l’utilisateur lui-même les avait envoyés. Cela incitait le LLM à répondre au résultat, et c’est ainsi que tout a commencé !

C'était génial mais cela posait deux problèmes principaux :

1. L’agent se contenterait de projeter l’intégralité des données JSON au beau milieu de l’échange avec l’utilisateur.
2. Dans l’API des conversations, les messages n’étaient accessibles qu’une fois le tour de parole terminé, soit après l’émission de la réponse par le LLM.

Nous nous sommes alors attachés à trouver comment déporter cette tâche en tâche de fond.

Nous avons ensuite donné à l'agent un outil appelé call_external_tool avec deux arguments : le tool_name et les arguments JSON sous forme de chaîne. Bien que cet appel d’outil externe ne produise aucun retour, il resterait néanmoins détectable au sein de la requête GET envoyée à l’API des conversations. L’étape suivante a consisté à donner aux runners la permission d’alimenter Elasticsearch en documents, que l’agent d’Elastic Agent Builder pouvait alors consulter à la demande. L'agent fonctionne toujours en réponse à un message d'utilisateur, nous devons donc démarrer l'agent avec un message d'utilisateur afin qu'il recherche des résultats et poursuive le traitement. Nous avons donc demandé aux agents d’insérer un petit message dans le chat pour reprendre la conversation :

Ainsi, nous avions désormais des appels d'outils externes. Cependant, en raison du deuxième problème mentionné ci-dessus, nous avons dû supprimer cette dernière partie de démarrage. Sinon, chaque appel à un outil externe nécessitait un cycle complet de conversation pour récupérer les résultats !

Pour aller plus loin : présentation des workflows

En plus des appels d’outils via ES|QL et la recherche d’index, les agents d’Agent Builder peuvent solliciter des outils Elastic basés sur des workflows. Les workflows Elastic offrent une méthode flexible et simple à gérer pour exécuter une séquence arbitraire d’actions et de logiques. Dans notre cas, le rôle du workflow se limite à l’enregistrement d’une demande d’outil externe dans Elasticsearch et à la transmission d’un identifiant (ID) pour le suivi des résultats. Le résultat est une définition de workflow simple, articulée comme suit :

Ainsi, au lieu de compter sur l’écriture de la requête d’appel d’outil dans la conversation, les runners peuvent simplement interroger l’index distributed-tool-requests d’Elasticsearch pour de nouvelles requêtes d’outils externes et faire un rapport des résultats dans un autre index Elasticsearch avec le execution.id fourni.

Cela élimine les deux principaux problèmes mentionnés ci-dessus :

1. L’historique de la conversation n’est plus encombré par les données de transfert des appels d’outils externes.
2. Comme les runners interrogent l’index Elasticsearch au lieu de l’historique de conversation, ils ne sont plus bloqués par l’achèvement du cycle d’échange pour que les requêtes d’outils externes deviennent visibles.

L’intérêt principal de ce deuxième point est que l’exécution des requêtes vers les outils externes débute pendant que l’agent « réfléchit », sans attendre que le tour de parole soit terminé. Cela nous permet d’instruire le LLM, via le prompt système, d’interroger les résultats de l’outil externe jusqu’à ce qu’ils soient disponibles, éliminant ainsi le besoin d’un message de relance. Dans l’ensemble, cette approche fluidifie l’interaction : le LLM est désormais capable de gérer simultanément plusieurs appels d’outils externes lors d’une seule itération. Cela lui permet de traiter des requêtes utilisateur complexes de manière groupée, plutôt que de fragmenter le processus.

Mise en commun

Pour combler le fossé entre le LLM et la baie de serveurs, nous avons développé une architecture spécifique en exploitant les fonctionnalités des outils d'Agent Builder :

1. Les runners de l'infrastructure augmentée : Nous avons déployé des runners légers à l'intérieur des environnements cibles (serveurs, clusters Kubernetes, comptes cloud). Ces exécuteurs sont connectés directement à Elastic, en utilisant des endpoints sécurisés et des secrets accessibles uniquement à chacun des runners.
2. Recherche ES|QL : Le copilote utilise ES|QL d'Elastic pour effectuer des recherches hybrides. Il ne se contente pas de rechercher des connaissances ; il recherche des capacités. Il interroge les exécuteurs connectés pour voir quels outils sont disponibles (par exemple, list_ec2_instances, install_helm_chart).
3. Exécution du workflow : Une fois que l'agent a décidé d'un plan d'action, il crée un workflow structuré.
4. Boucle de rétroaction : Les runners exécutent la commande localement et rapportent les résultats dans Elasticsearch. Le copilote lit le résultat de l’index et décide de l’étape suivante.

Démonstration : transformer un incident critique en levier d’observabilité

Dans la vidéo, nous avons présenté deux scénarios distincts démontrant la puissance de cette architecture.

Scénario 1 : DevOps à la rescousse

Le point de départ est un incident critique : un utilisateur confronté à une perte de 5 millions de dollars due à un défaut de visibilité dans son cluster Kubernetes.

• La demande : « Comment m'assurer que cela ne se reproduise plus ? »
• Action : L’agent ne s’est pas contenté de fournir un tutoriel. Il a identifié le cluster, créé les espaces de nom nécessaires, généré des secrets Kubernetes, installé l’opérateur OpenTelemetry et a immédiatement fourni un lien vers un tableau de bord APM en direct.
• Le résultat : Une observabilité complète de Kubernetes et des informations sur les applications sans que l'utilisateur n'écrive une seule ligne de YAML.

Scénario 2 : Transfert de Security

En sécurité des infrastructures, un principe de base prévaut : l’impossibilité de protéger ce qui échappe à notre visibilité. En pleine intervention de secours DevOps, l’agent identifie une occasion d’optimiser la sécurité globale de l’infrastructure.

En s’appuyant sur une alerte générée lors d’une analyse Elastic Observability, nous illustrons la capacité d’un analyste sécurité à interagir en langage naturel avec son infrastructure. L’objectif est double : recenser précisément les ressources cloud existantes et mettre en œuvre les solutions de protection indispensables.

• Découverte : Le copilote a énuméré les ressources AWS pour le spécialiste de la sécurité et a identifié une lacune critique : une instance Amazon Elastic Compute Cloud (EC2) et un cluster Amazon Elastic Kubernetes Service (EKS) avec des points de terminaison publics dépourvus de protection des points de terminaison.
• Remédiation : Avec une simple approbation, le copilote a déployé Elastic Security détection et réponse étendues (XDR) et détection et réponse cloud (CDR) sur les ressources vulnérables, assurant la sécurité de l'environnement en temps réel.
• Le résultat : Protection des ressources AWS déployées avec une sécurité totale à l’exécution.

Perspectives : vers une infrastructure intégralement augmentée

Ce projet démontre la capacité d’Elastic Agent Builder à agir comme le centre de pilotage de vos opérations distribuées. Notre champ d’action dépasse désormais le cadre strict de l’infrastructure. Les capacités de notre technologie de runner s’étendent à :

• Synthetics augmenté : Diagnostiquer les erreurs TLS chez les runners du monde entier.
• Développement augmenté : Création de requêtes d'extraction et implémentation de CAPTCHA sur les services frontend.
• Opérations augmentées : reconfiguration automatique des résolveurs DNS en cas de panne.

Essayez par vous-même

Nous pensons que l'avenir de l'IA ne se limite pas à l'assistance par chat, mais aussi à une infrastructure augmentée. Il s'agit d'avoir un partenaire qui peut déployer, réparer, observer et protéger à vos côtés.

Consultez le code et essayez-le par vous-même avec les runners distribués (GitHub) et Elastic Agent Builder sur Elastic Cloud Serverless dès aujourd'hui !

• Créez un projet sans serveur sur Elastic Cloud.
• Déployer le code vers un runner.
• Configurer le runner.
• Configurer votre fichier mcp.json.
• Démarrer l'agent, qui créera automatiquement votre agent et ses outils.
• Dialoguez avec un agent capable de raisonner, de planifier et d’exécuter des actions sur vos runners distribués !

L’équipe : Alex, Bill, Gil, Graham et Norrie