LangSmith AI Search détecte des échecs d’agents que les filtres de traces traditionnels ne voient pas

LangSmith a lancé AI Search en bêta publique, offrant aux équipes une nouvelle façon de repérer les échecs d’agents que les filtres ordinaires ne détectent pas. La fonctionnalité accepte des descriptions de comportements en langage naturel, puis recherche les traces correspondantes dans les interactions enregistrées des agents.

Un développeur peut demander des cas où un utilisateur s’est montré frustré, où un agent a revendiqué une réussite sans avoir accompli sa tâche, ou encore où des informations personnelles sont apparues dans une réponse. Ces questions reposent sur le sens et la séquence des événements, et non sur un tag connu ou une expression exacte.

Cette distinction crée la véritable tension derrière LangSmith AI Search. L’observabilité des agents s’est largement appuyée sur des filtres structurés, des requêtes de texte intégral et des évaluateurs configurés avant même que les équipes ne sachent quels échecs comptent. LangSmith parie qu’un modèle peut examiner un comportement inconnu au moment où la question se présente.

Cette approche soulève également une question moins rassurante. Si un autre modèle décide quelles conversations de production correspondent à une description subjective, les équipes doivent comprendre ce que ce modèle lit, exclut et classe incorrectement.

LangSmith AI Search ajoute des requêtes comportementales à l’exploration des traces

La sortie transforme l’investigation des traces, d’un problème de requête de base de données en un problème d’interprétation.

LangChain a annoncé la bêta publique le 13 octobre 2026. Elle est disponible via LangSmith Cloud dans les régions États-Unis, Europe et Asie-Pacifique de Google Cloud. Un administrateur de l’organisation doit l’activer avant que les autres membres puissent l’utiliser.

LangSmith permet déjà aux équipes de filtrer les traces à l’aide de champs tels que le statut, la latence, les tags, les métadonnées, les coûts et les retours. Sa recherche en texte intégral peut également faire correspondre des mots présents dans les entrées, sorties, métadonnées et erreurs des traces.

Ces outils fonctionnent lorsqu’un enquêteur sait quel champ ou quelle expression identifie la cible. Un filtre de statut peut trouver des erreurs, tandis qu’une requête textuelle peut localiser les conversations contenant « refund ». Aucun des deux ne peut déterminer de manière fiable si un utilisateur a silencieusement abandonné après avoir reçu une réponse peu utile.

LangSmith AI Search accepte plutôt une description comportementale. Les exemples de recherche comportementale de traces de l’entreprise incluent des utilisateurs montrant de la frustration, des agents exposant des détails internes d’implémentation et des agents ne terminant pas le travail qui leur a été confié.

La fonctionnalité opère sur les threads, les traces et les exécutions individuelles. Une trace enregistre une requête et ses opérations imbriquées, tandis qu’un thread relie plusieurs traces issues de la même conversation.

Les équipes peuvent combiner la requête en langage naturel avec les filtres structurés existants. Elles peuvent par exemple commencer par limiter les résultats aux traces de production comportant des erreurs, puis demander quelles conversations montrent des utilisateurs devenant confus pendant l’intégration.

Cette combinaison est importante. Elle permet aux filtres conventionnels de réduire la zone de recherche avant qu’un modèle n’examine les conversations restantes. Elle préserve également des contrôles déterministes pour les attributs qui ne devraient pas exiger d’interprétation.

Les résultats arrivent avec des scores de confiance. L’ouverture d’une correspondance mène l’examinateur vers une vue de trajectoire, dans laquelle LangSmith met en évidence les messages disponibles qui ont influencé la correspondance.

Une trajectoire est une séquence normalisée de messages humains, de réponses d’agents, d’appels d’outils et de résultats d’outils. Elle présente la session une seule fois, au lieu de répéter l’historique de conversation inclus dans les appels successifs au modèle.

Il ne s’agit pas simplement d’une couche de syntaxe plus conviviale au-dessus des filtres existants. LangSmith indique que le modèle de décision lit chaque trajectoire candidate et évalue si le comportement demandé s’est produit.

La différence devient évidente avec une demande telle que « l’agent a dit avoir terminé la tâche, mais ne l’a pas fait ». Une trace réussie comme une trace infructueuse peuvent contenir des sujets, outils et termes presque identiques.

Un embedding, qui représente du texte sous forme de vecteur numérique, peut placer ces conversations à proximité parce qu’elles traitent de la même tâche. La classification comportementale doit au contraire comparer l’affirmation avec les actions enregistrées dans l’ensemble de la trace.

L’entreprise a donc intégré directement un schéma de LLM-as-a-judge à la découverte interactive de traces. Les ingénieurs n’ont plus besoin de définir chaque évaluateur avant de commencer leur investigation.

Ce changement accélère l’analyse exploratoire. Il ne rend pas chaque résultat définitif.

Pourquoi la recherche dans les traces d’agents est devenue un problème de données

Les longues sessions d’agents contiennent des éléments précieux, mais leur ampleur et leurs répétitions rendent l’examen manuel de plus en plus impraticable.

La supervision traditionnelle des applications se concentre sur des signaux prévisibles. Les ingénieurs recherchent des codes d’erreur, des requêtes lentes, des appels de base de données échoués ou une consommation inhabituelle de ressources. Ces signaux correspondent généralement à des champs structurés.

Les agents d’IA produisent une surface d’échec différente. Un agent peut fournir une réponse techniquement réussie tout en ayant mal compris la demande, appelé un outil inapproprié ou exagéré ce qu’il a accompli.

La télémétrie qui en résulte est également particulièrement dense. Une tâche d’agent peut contenir des messages utilisateur, des sorties de modèle, des documents récupérés, des commandes shell, des réponses d’outils, des tentatives répétées et des transferts vers d’autres agents.

LangChain a examiné 150 conversations sélectionnées aléatoirement dans Open SWE, son agent de codage open source. Selon l’entreprise, plusieurs dépassaient un million de tokens.

La conversation médiane contenait environ 72 000 tokens. Seuls quelque 2 000 provenaient des messages utilisateur et des réponses finales de l’agent, tandis qu’environ 85 % consistaient en sorties d’outils.

Ces chiffres proviennent de l’échantillon de LangChain, et non d’une référence sectorielle indépendante. Ils illustrent néanmoins pourquoi la recherche dans chaque événement brut engendre à la fois des coûts de contexte et d’inférence.

Les agents envoient souvent l’intégralité de l’historique de conversation à chaque nouvel appel de modèle. Une représentation naïve des traces stocke donc à plusieurs reprises les mêmes messages antérieurs.

LangSmith traite cette répétition au moyen de trajectoires. Sa couche de données de traces convertit les formats de traces pris en charge en une représentation commune à mesure que les données arrivent.

Ces formats comprennent les traces produites via LangChain, LangGraph, les SDK OpenAI et Anthropic, le Vercel AI SDK et OpenTelemetry. La normalisation fournit au système de recherche une séquence cohérente à examiner.

Cela accroît également les enjeux concurrentiels. Les fournisseurs d’observabilité proposent de plus en plus des évaluations au niveau des traces, et pas seulement du stockage et du filtrage.

Datadog, par exemple, documente des évaluations au niveau des traces qui placent chaque span d’une trace dans un prompt de juge LLM. Ces évaluations peuvent classifier l’achèvement d’un objectif, l’ordre des outils ou la qualité d’une conversation.

Arize Phoenix combine de la même façon le traçage, les annotations, les évaluations, les jeux de données et les expériences dans un workflow de traçage open source. Ses évaluateurs peuvent noter les traces de production et convertir des exécutions sélectionnées en jeux de données pour des tests ultérieurs.

La distinction porte principalement sur le moment et le workflow. Les évaluateurs représentent généralement des critères qu’une équipe définit, teste et applique de façon répétée. LangSmith AI Search cible les questions qui émergent au cours d’une investigation.

Prenons un agent de support confronté à une hausse soudaine des demandes d’annulation. Un tableau de bord structuré pourrait montrer une latence stable et peu d’erreurs explicites. La recherche en texte intégral pourrait identifier le mot « cancel », mais pas la raison qui le sous-tend.

Un responsable produit pourrait plutôt rechercher les utilisateurs qui ont tenté d’annuler après avoir reçu des réponses contradictoires. Cette description combine l’intention, la séquence et la qualité perçue.

Si les correspondances s’avèrent utiles, l’équipe peut les examiner, ajouter des exemples à un jeu de données et construire un évaluateur durable. La recherche devient l’interface exploratoire d’un processus qualité plus formel.

Ce workflow pousse les plateformes d’observabilité à relier la découverte à l’évaluation. Stocker des traces détaillées ne suffit plus lorsque les clients ne peuvent pas retrouver le comportement dissimulé en leur sein.

Il change aussi les équipes capables d’utiliser les données de traces. Les responsables produit, les examinateurs de sécurité et les responsables du support peuvent décrire un problème sans devoir d’abord apprendre un langage de requête propre à la plateforme.

La couche de requêtes techniques reste nécessaire. Le langage naturel rapproche simplement la première étape d’investigation des personnes qui reconnaissent le problème métier.

Comment LangSmith AI Search lit une trace sans tout lire

LangSmith réduit le coût de recherche en donnant la priorité aux éléments conversationnels, mais cette compression détermine quels échecs restent visibles.

Lorsqu’un utilisateur soumet une description à AI Search, les filtres existants réduisent d’abord l’ensemble des candidats. SmithDB prépare ensuite les trajectoires pendant qu’un modèle de décision les examine en parallèle.

Les correspondances apparaissent progressivement dans l’interface à mesure que le système les identifie. Les utilisateurs n’ont pas besoin d’attendre que l’ensemble des candidats ait été traité.

Le mécanisme central repose sur un budget de contexte de 8 000 tokens pour chaque trajectoire. LangSmith remplit ce budget selon un ordre de priorité fixe au lieu d’envoyer chaque token enregistré.

Les messages utilisateur et les réponses directes de l’agent reçoivent la priorité la plus élevée. Les messages intermédiaires du modèle, les appels d’outils, les résultats d’outils et les messages système remplissent l’espace restant.

Si le message suivant ne tient pas, LangSmith le tronque. Le contenu ultérieur sort du champ de vision du modèle une fois le budget épuisé.

Ce choix rend de nombreuses recherches conversationnelles praticables. La frustration, le refus, la confusion, l’intention d’annulation et les promesses non étayées apparaissent souvent dans le dialogue visible.

Il crée aussi un angle mort prévisible. Certains échecs n’existent que dans les sorties d’outils ou les étapes intermédiaires d’exécution.

Un agent peut rencontrer une erreur d’autorisation, l’ignorer, puis dire à l’utilisateur qu’une tâche a réussi. La réponse visible contient l’affirmation erronée, mais l’élément décisif se trouve dans un résultat d’outil.

Le modèle de recherche peut manquer cet élément lorsque du contenu antérieur, de priorité plus élevée, consomme le budget de tokens. LangChain reconnaît cette limite et indique explorer une sélection de contexte dépendante de la requête.

Une telle sélection modifierait l’ordre des éléments selon la question. Une requête sur des erreurs d’outils ignorées devrait donner la priorité aux réponses d’outils, tandis qu’une requête sur le sentiment de l’utilisateur devrait mettre l’accent sur la conversation.

La version actuelle utilise plutôt un ordre général unique. C’est compréhensible pour une bêta, mais les équipes devraient considérer la couverture qui en résulte comme dépendante de la requête.

Le mécanisme explique également pourquoi LangSmith ne s’est pas appuyé uniquement sur la recherche vectorielle. La récupération vectorielle fonctionne bien lorsque l’objectif est de trouver des éléments concernant un sujet.

Une conversation sur la facturation se situera probablement près d’autres conversations sur la facturation dans un espace d’embeddings. Toutefois, des interactions de facturation réussies et échouées peuvent rester sémantiquement similaires.

Les requêtes comportementales exigent un jugement sur ce qui s’est produit. Un modèle de décision évalue la trajectoire au regard d’une proposition précise, par exemple si l’agent a accompli la tâche demandée.

Cette approche fondée sur un modèle améliore l’expressivité, mais remplace une incertitude de récupération par une autre. Le système dépend désormais de l’interprétation par un modèle d’un langage ambigu.

La « frustration de l’utilisateur » peut englober des plaintes directes, des questions répétées, du sarcasme, des départs brusques ou un refus poli. Différents examinateurs pourraient ne pas être d’accord sur les cas limites.

Les scores de confiance aident à classer les résultats, mais n’établissent pas la vérité de terrain. Un score élevé du modèle reflète toujours la définition du comportement, le contexte disponible et le modèle juge.

Le schéma opérationnel le plus robuste inclut donc une révision humaine. Les équipes peuvent examiner les éléments mis en évidence, corriger les correspondances faibles et affiner la description avant de considérer l’ensemble des résultats comme représentatif.

Pour les risques récurrents, elles peuvent transformer les cas examinés en jeu de données d’évaluation. Les évaluateurs en ligne existants de LangSmith peuvent ensuite appliquer un critère défini aux futures traces.

Cela sépare l’exploration de la supervision. AI Search aide les équipes à découvrir un schéma, tandis qu’un évaluateur mesure ce schéma de manière cohérente une fois sa définition stabilisée.

Cette séparation est particulièrement importante pour la sécurité et la conformité. Une recherche en langage naturel portant sur des informations personnelles peut révéler des traces suspectes, mais elle ne doit pas remplacer des analyseurs déterministes ou des contrôles formels.

Le jugement d’un modèle peut élargir une enquête. Il ne doit pas devenir l’unique couche d’application des règles pour des décisions à fortes conséquences.

La principale concurrence repose sur l’évaluation prédéfinie

LangSmith remet en question l’idée selon laquelle les équipes doivent connaître toutes les défaillances importantes avant que le trafic de production ne les révèle.

Avant la recherche comportementale, les équipes disposaient généralement de trois moyens pour localiser les traces problématiques. Elles pouvaient rechercher du texte, filtrer des attributs connus ou exécuter un évaluateur sur un trafic sélectionné.

La recherche plein texte offre rapidité et reproductibilité. Elle est utile lorsque les éléments pertinents comprennent une expression distinctive, un identifiant, un message d’erreur ou un nom de produit.

Le filtrage structuré est encore plus précis. Les équipes peuvent isoler les traces comportant des codes d’état en échec, une latence élevée, des appels de modèle coûteux, des outils spécifiques ou de faibles scores de feedback.

Les évaluateurs prédéfinis traitent le sens. Un juge LLM peut déterminer si une réponse était utile, étayée, sûre ou complète, puis associer ce résultat à chaque trace.

La voie de l’évaluation est efficace lorsqu’une équipe comprend déjà la catégorie de défaillance. Elle devient moins pratique lors d’un incident inattendu.

Quelqu’un doit définir la grille d’évaluation, sélectionner les champs de trace requis, choisir les règles d’échantillonnage, tester l’évaluateur et l’appliquer au trafic passé ou futur. Cette préparation crée une mesure durable, mais ralentit l’enquête ouverte.

LangSmith AI Search condense ce travail dans une description saisie au moment de la requête. Il offre un chemin plus rapide entre un soupçon et des éléments candidats.

La fonctionnalité n’élimine pas les évaluateurs. Elle crée une phase de découverte avant eux.

Une équipe peut constater une hausse des escalades auprès du support sans en connaître la raison. Un analyste pourrait rechercher les utilisateurs qui ont répété une demande après que l’agent a affirmé l’avoir résolue.

Les réviseurs pourraient découvrir que l’agent interprétait régulièrement la fermeture de compte comme une résiliation d’abonnement. Ce schéma peut ensuite devenir un évaluateur nommé, doté d’une grille testée.

Cette séquence constitue la partie la plus déterminante du lancement. Elle relie l’exploration qualitative, la construction de jeux de données, l’évaluation et la supervision en production.

Elle crée également une pression au-delà des concurrents directs de LangSmith. Les équipes d’analytique internes exportent souvent les traces vers des entrepôts de données, des notebooks ou des systèmes de recherche personnalisés, car les questions produit dépassent les tableaux de bord d’observabilité.

La recherche comportementale dans les traces pourrait conserver une plus grande part de cette analyse au sein de la plateforme d’observabilité. Les équipes produit et d’ingénierie travailleraient à partir du même enregistrement d’exécution sous-jacent.

L’approche rappelle l’évolution plus large de la recherche par mots-clés vers la récupération assistée par modèle dans les systèmes de connaissance d’entreprise. Toutes deux cherchent à trouver un sens que les utilisateurs n’ont pas encodé sous forme de métadonnées.

La différence est que les traces d’agents contiennent des actions, et non seulement des documents. Un résultat utile dépend de la reconstitution de ce qui s’est passé à travers les messages et les outils.

Pour les équipes d’ingénierie, cela fait de l’organisation des traces une composante de l’infrastructure de qualité du produit. Le même principe s’applique lorsque les équipes créent une base de connaissances consultable à partir de dossiers techniques fragmentés.

L’avantage reviendra aux systèmes qui préservent les éléments de preuve tout en réduisant les frictions d’enquête. L’accès en langage naturel aide, mais la possibilité de révision compte tout autant.

LangSmith met en évidence les messages correspondants dans la vue de trajectoire. Cette conception offre aux réviseurs un chemin allant de la classification du modèle jusqu’à la conversation enregistrée.

Cependant, la documentation indique que toutes les correspondances ne peuvent pas être mises en évidence. Un texte répété ou des messages absents de la vue de trajectoire peuvent empêcher la localisation des éléments de preuve.

Un résultat peut donc afficher un score de confiance sans présenter toutes les raisons qui le sous-tendent. Les équipes doivent distinguer la confiance du modèle des éléments de preuve auditables.

Les concurrents peuvent répondre en rendant leurs propres interfaces d’évaluation plus conversationnelles. Ils peuvent également proposer des juges ad hoc, des requêtes comportementales enregistrées ou la génération automatique de jeux de données.

La compétition produit ne consiste pas simplement à savoir qui proposera en premier la recherche en langage naturel. Il s’agit de savoir qui transformera des découvertes incertaines en tests reproductibles avec le moins de lacunes possible.

Le contexte, la confidentialité et la reproductibilité définissent les limites de la bêta

L’utilité de la fonctionnalité dépend de la compréhension, par les équipes, des données qu’elle exclut et des obligations de gouvernance qu’elle ajoute.

La documentation sur les filtres de LangSmith identifie plusieurs limites du produit. Les descriptions AI Search ne peuvent actuellement pas être enregistrées comme vues ni conservées dans des liens de page copiés.

Les recherches n’apparaissent pas non plus dans l’historique des filtres récents. Le panneau de statistiques devient indisponible lorsqu’une requête AI Search est active.

Ces restrictions affectent la reproductibilité. Un ingénieur qui enquête sur un incident ne peut pas simplement envoyer une requête comportementale enregistrée à un autre réviseur et espérer un flux de travail identique.

Les équipes peuvent consigner la formulation ailleurs, mais cela ajoute un processus manuel. C’est également important car de petites modifications de formulation peuvent influer sur les classifications du modèle.

Le système applique des limites de débit au niveau de l’espace de travail. LangChain ne publie pas le seuil dans la documentation citée ; les équipes ne peuvent donc pas encore déterminer si cette solution convient à des enquêtes automatisées fréquentes.

Des limites plus importantes proviennent de la trajectoire elle-même. AI Search lit la conversation principale de l’agent, mais pas le contenu des messages de sous-agents, de middleware ou de compaction.

Un flux de travail multi-agent peut donc masquer un comportement décisif en dehors de la représentation consultable. L’agent parent peut signaler une réussite alors qu’un sous-agent enregistre l’échec réel.

Le système ne peut pas non plus déduire le statut d’exécution, les tags, les métadonnées ou la structure de trace à partir de la description en langage naturel. Les utilisateurs doivent appliquer des filtres conventionnels pour ces propriétés.

Cette répartition doit figurer dans les guides opérationnels des équipes. La recherche comportementale traite le sens au sein de la trajectoire, tandis que les filtres structurés traitent les attributs opérationnels connus.

La confidentialité présente une contrainte distincte. L’activation d’AI Search permet le transfert et le traitement des données de trace aux États-Unis via l’inférence et les sous-traitants gérés par LangChain.

L’administrateur de l’organisation active la fonctionnalité pour tous les membres. Aucune clé distincte de fournisseur de modèle n’est requise.

LangChain indique explicitement que les clients ne doivent pas utiliser AI Search pour des informations de santé protégées. La fonctionnalité n’est couverte par aucun Business Associate Agreement qu’une organisation a signé avec LangChain.

Cet avertissement mérite attention, car le lancement met en avant les recherches d’informations personnelles identifiables divulguées. La recherche de données sensibles exige l’envoi du contenu de trace concerné au système de classification.

Les organisations doivent distinguer l’examen général des PII du traitement de données de santé réglementées. Elles doivent également confirmer les exigences relatives à la conservation, à l’accès, à la résidence des données et aux sous-traitants avant d’activer la fonctionnalité.

Un risque d’observabilité plus large demeure, quel que soit le fournisseur. Des traces riches peuvent capturer des prompts, des réponses de modèles, des dossiers clients, des documents récupérés et des résultats d’outils.

Une télémétrie plus complète améliore le débogage tout en augmentant les conséquences d’une collecte excessive. Les équipes doivent minimiser les champs sensibles avant qu’ils n’atteignent une plateforme d’observabilité.

Elles doivent également tester les faux positifs et les faux négatifs sur des échantillons examinés. Un benchmark bêta utile inclurait des incidents comportementaux connus, des négatifs difficiles et des exemples couvrant différents frameworks d’agents.

Les informations publiques ne communiquent ni précision, ni rappel, ni distributions de latence, ni comparaisons indépendantes avec les embeddings et les évaluateurs prédéfinis. Elles décrivent l’architecture et un échantillon interne de longueur de trace.

Les acheteurs ne disposent donc pas d’une mesure commune de la qualité de recherche. Une fonctionnalité qui renvoie des correspondances plausibles peut tout de même négliger les défaillances rares qui comptent le plus.

L’interprétation appropriée reste donc limitée. LangSmith a introduit une interface d’enquête prometteuse, et non un remplacement vérifié de l’évaluation, de l’analyse de sécurité ou de la révision humaine.

Sa valeur dépendra de la rapidité avec laquelle les utilisateurs peuvent valider un résultat, reproduire la requête et transformer la découverte en contrôle qualité durable.

Ce qu’il faut surveiller après la bêta de LangSmith AI Search

Trois signaux montreront si la recherche comportementale dans les traces devient une infrastructure centrale ou demeure un raccourci d’enquête utile.

Le premier signal est la sélection adaptative du contexte. LangChain affirme explorer des méthodes qui choisissent les éléments de preuve en fonction de la requête et indiquent quand le modèle doit effectuer un second passage.

Ce travail répond directement à la limite de 8 000 tokens. Si les recherches axées sur les outils commencent à prioriser les résultats d’outils, le système devrait détecter davantage d’échecs d’exécution cachés dans les éléments conversationnels.

Sans sélection adaptative, les utilisateurs devront adopter des approches distinctes selon les types de traces. Les recherches conversationnelles pourront bien fonctionner, tandis que les recherches opérationnelles produiront une couverture incohérente.

Le deuxième signal est la reproductibilité. Des recherches enregistrées, des requêtes partageables, des ensembles de résultats stables et des limites de débit documentées faciliteraient l’intégration d’AI Search dans la réponse aux incidents.

Le regroupement des correspondances similaires aiderait également les équipes à aller au-delà des traces individuelles. LangChain affirme vouloir résumer les schémas courants au lieu de renvoyer uniquement une liste plate.

Cette capacité pourrait transformer une recherche ad hoc en flux de travail d’analyse produit. Les équipes pourraient identifier des groupes de défaillances récurrentes, examiner des traces représentatives et créer des évaluateurs ciblés.

Le troisième signal est la réponse concurrentielle. Datadog, Arize et d’autres fournisseurs d’observabilité combinent déjà le traçage avec une évaluation fondée sur des modèles.

S’ils ajoutent la découverte comportementale interactive, la recherche de traces en langage naturel deviendra une interface attendue. La concurrence se déplacera alors vers la qualité des éléments de preuve, la gouvernance et l’intégration avec les jeux de données.

Si les concurrents mettent plutôt l’accent sur une précision évaluée et une supervision reproductible, LangSmith devra démontrer que l’exploration produit des améliorations mesurables après le déploiement.

Les utilisateurs devraient également surveiller la publication de benchmarks sur la qualité de recherche. La précision et le rappel concernant la frustration, les tâches incomplètes, les divulgations dangereuses et les erreurs d’outils ignorées offriraient une base de comparaison plus claire.

Pour l’instant, les équipes qui évaluent LangSmith AI Search devraient commencer par un ensemble examiné de traces connues. Elles peuvent tester plusieurs descriptions, comparer les correspondances renvoyées et documenter les éléments que le modèle omet.

Elles devraient ensuite utiliser la fonctionnalité pour la découverte, et non pour l’arbitrage final. Confirmez manuellement les résultats à fort impact et transformez les définitions comportementales stables en évaluateurs ou en contrôles déterministes.

Le lancement est important parce qu’il change le moment où les équipes peuvent poser des questions sur le comportement des agents. Elles n’ont plus besoin de prédire chaque défaillance avant de collecter des traces de production.

Il s’agit d’une avancée significative pour l’observabilité des agents. Le test le plus difficile consiste à déterminer si LangSmith AI Search peut rendre ces découvertes reproductibles, auditables et sûres dans de véritables charges de travail de production.