La recherche Web dont votre agent a hérité n'est pas assez performante

Un agent qui a besoin du monde extérieur

Un ingénieur dans une entreprise de logiciels conçoit un agent pour maintenir à jour la vision du marché de l'entreprise. Il surveille quelques centaines de milliers de prospects et de comptes clients à la recherche de signaux indiquant qu'un compte est ouvert à un engagement : une nouvelle levée de fonds, un changement de direction, le lancement d'un produit ou une vague d'embauches indiquant un budget disponible.

Les dossiers clients résident déjà dans Databricks, dans des tables Delta régies par Unity Catalog et associées aux données d'utilisation et de pipeline de l'entreprise. Mais les signaux qui font évoluer un compte se trouvent en dehors de l'entreprise, sur le web. Le rôle de l'agent est de combiner les deux, en continu, pour obtenir une image cohérente et actualisée de chaque compte, afin d'indiquer aux commerciaux quels comptes appeler en priorité cette semaine.

Version 1.0 : un désordre fonctionnel

La première version n'est pas un système unique. Il s'agit de la même logique d'enrichissement, reconstruite à partir de zéro à trois reprises, dans chacun des outils utilisés par l'ingénieur. La première étape s'exécute dans Claude Code, où les aspects agentiques (décider quels comptes nécessitent une nouvelle analyse, enchaîner les recherches, rédiger le résumé) représentent la majeure partie du travail. Lorsqu'un collègue mentionne que Codex gère plus rapidement un certain type de script par lots, l'ingénieur y transfère la boucle d'enrichissement pour tester. Une troisième version contourne complètement le harnais et appelle directement un modèle via l'API, pour une tâche nocturne légère qui ne nécessite qu'un seul prompt et une réponse, sans aucune orchestration d'outils. Même tâche, trois versions, chacune façonnée par l'outil le plus adapté à ce moment-là.

Chaque harnais intègre ses propres outils et sa propre recherche web et les connecte à sa manière. L'ingénieur doit donc créer la même logique d'enrichissement trois fois, dans le format de configuration de chaque harnais. C'est là que passe la journée. Au lieu d'améliorer l'enrichissement des comptes, l'ingénieur cherche à comprendre comment Claude Code souhaite que ses outils soient déclarés, pourquoi le même serveur MCP se connecte différemment dans Codex, et ce qui manque au chemin d'accès brut de l'API que les deux autres offraient nativement.

Les outils ne sont pas équivalents, et les résultats non plus. La recherche web intégrée à un harnais renvoie des données différentes de celles du suivant. Une source accessible dans l'un est manquée dans l'autre. Les outils de recherche web intégrés pour les LLM peuvent trouver des informations de haut niveau comme les levées de fonds et les changements de direction, mais passent à côté de détails granulaires comme les changements de pile technique. L'accès aux informations en ligne est la raison d'être de cet agent, mais sa qualité dépend désormais d'une recherche web qui ne parvient pas à faire remonter de manière fiable les détails clés du web.

Et rien ne chapeute ces trois éléments. Aucun compteur partagé, de sorte que personne ne peut voir ni plafonner le coût d'un cycle sur quelques centaines de milliers de comptes. Pas de guide de règles commun, ce qui signifie que les sources qu'un agent peut lire et le moment où une validation humaine est requise sont définis de trois manières différentes ou pas du tout. Aucun historique partagé, de sorte que lorsqu'un résultat est erroné, il est impossible de reconstituer ce que l'agent a lu, dépensé ou décidé.

Cela fonctionne à peu près, dans le sens où cela produit un résultat. Et c'est précisément pour cela que ce n'est jamais corrigé. Cela fonctionne assez bien pour être conservé, mais pas assez pour qu'on puisse s'y fier pleinement.

Omnigent : une seule définition, n'importe quel harnais

Omnigent est la couche qui permet de canaliser cette dispersion. Située au-dessus des différents harnais, elle permet à l'ingénieur de définir l'agent une seule fois : le modèle sur lequel il s'exécute, les outils auxquels il a accès, ainsi que les politiques et les limites dans lesquelles il opère. Les trois versions se fondent en une seule définition, et l'attention de l'ingénieur peut se reporter sur l'enrichissement des comptes. Les outils ne dépendent plus de ce qui est fourni avec chaque harnais, mais deviennent des déclarations sur l'agent, configurées une fois et interchangeables librement. S'exécutant sur un modèle hébergé par Databricks, les appels de modèle sont acheminés via les API Foundation Model, où chaque appel est enregistré pour le coût, l'audit et la gouvernance dans un emplacement unique, plutôt que d'être dispersé sur trois environnements d'exécution. Et lorsque le modèle ou les contraintes économiques changent, l'ingénieur modifie une seule ligne, choisissant un nouveau modèle ou passant à un modèle moins cher sans interruption.

Cela élimine la majeure partie de la dispersion, mais laisse un élément critique décidé par défaut plutôt que par conception. La recherche web est l'une des fonctionnalités clés intégrées à chaque harnais, et aucun n'intègre la même. Une même requête donne un résultat via Claude Code et un autre via Codex. Omnigent vous permet de définir un choix cohérent pour chaque tâche, mais ne prend pas la décision à votre place. Vous devez attribuer une fonctionnalité de recherche partenaire. Avec un partenaire comme Nimble, vous pouvez intégrer une solution qui s'adapte à la tâche et offrir à chaque harnais sous-jacent la même analyse d'expert.

Nimble : occuper l'emplacement de recherche

L'API Search de Nimble peut ancrer les réponses dans des données web fraîches et en temps réel grâce à la recherche en direct. Pour les tâches de recherche approfondie, les Web Search Agents de Nimble automatisent l'orchestration de la recherche et de l'extraction web pour mener à bien votre tâche, en exploitant de nombreuses sources, en les recoupant et en renvoyant une réponse accompagnée des citations pour appuyer chaque affirmation, offrant ainsi une piste d'audit qu'une approche classique ne pourrait jamais produire.

Alors que les outils de recherche web généraux traitent tous les cas d'usage de la même manière, Nimble se spécialise dans le cas d'usage spécifique de l'agent, apprend par lui-même les meilleures méthodes de récupération et adapte la recherche et l'exploration web pour approfondir le domaine afin de capturer les données que les outils de recherche génériques manquent. Il accède aux données situées derrière le JavaScript, les filtres et la pagination, là où un robot d'exploration ordinaire abandonne. Et parce qu'il mémorise la meilleure façon de récupérer les données pertinentes, il réutilise les chemins de récupération de données plutôt que de tout redécouvrir à partir de zéro, réduisant ainsi les coûts de jetons. Désigné comme fournisseur dans la configuration, c'est la voie rapide vers un contexte web plus complet pour vos agents.

Lors des tests de Nimble, l'ajout de la recherche web de Nimble a fait passer la précision de référence des LLM de 46 % à 71 %, tout en divisant par deux les coûts de recherche web (coûts de recherche web de Claude par rapport à Nimble). Les Web Search Agents peuvent être orientés vers un domaine et y rester, de sorte qu'ils mémorisent quelles sources et quels chemins de récupération ont produit les bonnes données pour les réutiliser la fois suivante. Ils gagnent en efficacité à mesure qu'ils travaillent sur un domaine, et le coût de la recherche de l'emplacement d'un signal diminue pour les comptes les plus fréquemment analysés.

Version 2.0 : conçue une seule fois, sur Databricks et Nimble

Pour en revenir à notre ingénieur, l'agent est désormais en passe de devenir un ensemble cohérent, gérable et fiable. L'agent est défini une seule fois dans Omnigent, sur un modèle hébergé par Databricks, avec ses outils, ses politiques et ses limites dans une spécification unique. Les trois versions reconstruites ont disparu, tout comme la complexité d'intégration ; l'ingénieur se concentre à nouveau sur l'enrichissement, et non sur la manière dont chaque harnais souhaite que ses outils soient déclarés.

La recherche web est désormais une décision unique au lieu de trois. Spécifier Nimble sur la fonction intégrée web_search oriente chaque harnais sous-jacent vers la même API Nimble Search pour une recherche web rapide et efficace :

Pour les comptes qui nécessitent une réponse justifiable plutôt que des données web brutes, Omnigent peut faire appel aux Web Search Agents de Nimble, qui automatisent la recherche et l'extraction web pour la recherche, l'enrichissement ou la création de jeux de données.

La clé provient d'un compte Nimble, que vous pouvez créer gratuitement.

Le contrôle est désormais centralisé. Les appels de modèle sont acheminés via les API Foundation Model sous gouvernance, le coût est visible et plafonné en un seul endroit, et ce que l'agent lit, dépense et décide est capturé de manière cohérente sur une surface de gouvernance unique.

Et les deux facettes de la situation sont enfin réunies. Les données internes dans Databricks et le signal externe de Nimble, regroupés au même endroit, régis et lus par un seul agent. La version 1.0 comptait trois harnais et aucun point de vue global. Il s'agit ici d'un agent unique, ancré dans ce que l'entreprise sait et ce que le web peut lui apprendre, s'exécutant là où se trouvent déjà les données. Cohérent là où il y avait auparavant des dérives, approfondi là où il était superficiel, avec une gouvernance complète sur la récupération du contexte web externe.

Essayez dès aujourd'hui

La mise en place se fait en deux étapes.

Connectez Omnigent à Databricks. Databricks exécute le serveur Omnigent pour vous. Sur votre propre machine, installez le CLI avec l'intégration Databricks et enregistrez la machine en tant qu'hôte :

Connectez-vous ensuite avec l'identité de votre espace de travail et exécutez votre premier agent sur un modèle hébergé par Databricks. Omnigent sur Databricks est le point de départ idéal ; il couvre la configuration managée de bout en bout et détaille les étapes du CLI. Deux prérequis sont à vérifier au préalable : la version bêta d'Omnigent doit être activée pour votre espace de travail, et l'espace de travail doit se trouver dans une région qui prend en charge Unity AI Gateway. Pour les autres méthodes d'installation et exigences, la référence d'installation complète les détaille.

Vos agents s'exécutent sur le serveur managé, de sorte que les mêmes sessions vous suivent sur toutes les interfaces :

• le terminal, où vous l'avez installé
• l'application de bureau, une fenêtre native avec des notifications et un badge dans le dock pour les agents en attente de votre intervention
• le mobile, via les applications natives iOS et Android, ou l'interface utilisateur web dans n'importe quel navigateur de téléphone, en saisissant l'URL de votre espace de travail

Orientez la recherche vers Nimble. Indiquez Nimble sur la fonction intégrée web_search, la modification d'une seule ligne mentionnée précédemment, et chaque agent hébergé par Databricks basera ses réponses sur celle-ci. Pour un travail justifiable et auditable, optez pour le pass de recherche. La documentation du connecteur Nimble couvre ces deux aspects. Vous aurez besoin d'une clé Nimble, commencez un essai gratuit pour en obtenir une.

Les données internes vous appartiennent déjà. C'est tout ce qu'il faut pour permettre à vos agents de raisonner sur le reste du Web, avec la même plateforme qui héberge ces deux aspects.

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