Il y a un an, quand MCP a décollé, cela ressemblait à une manière simple, plug-and-play, de connecter l’IA aux données et aux actions — et beaucoup se demandaient si l’index avait encore de l’avenir. Un an plus tard, la question a changé, car la qualité des outils MCP prêts à l’emploi n’a pas répondu aux exigences de niveau entreprise : qui dispose réellement de la meilleure couche de contexte enterprise ?
Il est désormais largement admis que de bons agents reposent sur un contexte de haute qualité, associé à des modèles de raisonnement puissants. On l’observe dans toute l’industrie : Cursor utilise la recherche de code pour améliorer la précision des réponses de 12,5 %. Les recommandations d’Anthropic sur l’ingénierie du contexte soulignent que le contexte est une ressource critique pour les agents et qu’il doit être activement curationné. Même les connaissances d’entreprise d’OpenAI incluent des connecteurs synchronisés (indexés).
Nous avons donc examiné comment la stack que Glean a construite au cours des six dernières années autour du contexte enterprise se comparait aux nouveaux entrants sur le marché, comme les connaissances d’entreprise de OpenAI ChatGPT et la recherche enterprise de Anthropic Claude. Nous avons découvert que les évaluateurs humains, lorsqu’ils exprimaient une préférence, choisissaient la réponse de Glean comme correcte 1,9x plus souvent que celle de ChatGPT, et 1,6x plus souvent que celle de Claude.
La pérennité du contexte
Avant d’entrer dans les résultats, nous voulons expliquer pourquoi le contexte compte pour le travail agentique, et pourquoi les modèles seuls ne suffisent pas pour le gérer.
Les LLMs ont un budget d’attention fixe. Ils traitent les entrées comme une seule séquence de tokens, avec une perception limitée de la structure ou de l’importance. À mesure que le contexte s’étend, le mécanisme d’attention doit se répartir sur de plus en plus de tokens, ce qui affaiblit sa capacité à se concentrer sur les bons. Cela entraîne aussi des interférences, où le contexte commence à se télescoper dans la mémoire du modèle : les faits deviennent flous, les preuves anciennes et nouvelles entrent en concurrence, et des tokens non pertinents captent l’attention.
Ce phénomène s’appelle la dégradation du contexte (« context rot »). Timothy Lee, auteur de la newsletter Understanding AI, l’a très bien résumé dans un article mettant en avant une étude d’Adobe. Il a noté qu’à mesure que la « botte de foin » grandissait, la précision du modèle pour trouver « l’aiguille » chutait fortement. Et ce n’était que pour un seul saut de raisonnement : les performances baissaient encore davantage lorsque les modèles devaient enchaîner plusieurs sauts. ;
Chez Glean, nous pensons que le problème de la dégradation du contexte est sur le point de prendre une ampleur bien plus grande. Les agents sont à l’aube d’exécutions plus longues et de tâches complexes, qui nécessitent beaucoup plus de contexte. Les agents ont besoin du bon contexte au bon moment de l’exécution sinon, les erreurs de récupération au début se propagent, sapant le reste de l’exécution de l’agent.
Conception de l’évaluation
Jeu de requêtes et jeu de données
La difficulté, pour évaluer la recherche enterprise, c’est qu’il n’existe pas de bons benchmarks publics. La recherche enterprise ne concerne pas seulement le contenu : elle est façonnée par tout ce qui entoure ce contenu. La pertinence dépend de signaux qui n’apparaissent jamais dans des jeux de données statiques : à quelle fréquence les équipes ouvrent un fichier, qui interagit avec lui, dans quels systèmes il vit, comment il se relie à des tickets ou à des commits, etc. Les connecteurs comptent aussi : différentes applications exposent différents métadonnées, horodatages et types d’objets, et ces signaux influencent fortement le ranking et la fraîcheur. Il faut réellement connecter des données enterprise réelles et exécuter de vraies requêtes enterprise pour pouvoir évaluer la recherche enterprise.
C’est ce que Glean a fait pour cette évaluation. Nous avons conçu notre jeu de données et nos requêtes pour reproduire un environnement enterprise réel au plus près, sans toucher aux données client. Notre proxy était le déploiement live de Glean en interne. Nous avons déterminé la distribution des classes de requêtes — des groupements d’intention utilisateur lors de la formulation d’une requête — à partir de notre base client agrégée et anonymisée afin de préserver leur confidentialité. Nous avons ensuite extrait ~280 requêtes à partir du déploiement interne de Glean, sans aucune donnée client, en cherchant à correspondre au plus près à cette distribution, tout en tenant compte des profils de connecteurs limités disponibles dans ChatGPT et Claude. ;
Nous avons concentré le jeu de requêtes sur des requêtes plus « complexes », en utilisant comme proxy de complexité le nombre de sources de données concernées : « Quelle est notre politique RH ? » est relativement simple, car cela repose généralement sur un document canonique unique. En revanche, si une requête touche plusieurs sources de données, elle peut nécessiter un raisonnement multi-hop pour réconcilier des entités entre les sources, ce qui la rend bien plus difficile à réussir.
Pour le jeu de données, nous avons connecté des sources de données comparables entre Glean et ChatGPT, puis entre Glean et Claude, afin que, dans chaque appariement, nous puissions tester la stack de recherche : profondeur des connecteurs, manière dont les pipelines de recherche et de classement produisent la pertinence, et capacité du modèle à utiliser les outils de recherche. ;
Pour la comparaison avec ChatGPT, nous avons utilisé ChatGPT Business avec les connaissances d’entreprise, connecté à Google Drive, Google Calendar, GitHub et Slack. Pour la comparaison avec Claude, nous avons utilisé la recherche enterprise de Claude Teams sur Sonnet 4.5, connectée à Confluence, Jira, GitHub, Google Drive, Slack et Salesforce. Au moment de cette évaluation, ChatGPT ne disposait pas de ce que nous considérons comme des connecteurs essentiels, comme Jira et Salesforce, ce qui a limité la complexité de son jeu de requêtes et de son jeu de données. ;
Comme Glean est agnostique au modèle et utilise à la fois Anthropic et OpenAI, nous avons exécuté Glean sur les mêmes modèles. Nous avons isolé les performances de recherche et les harnesses d’agent en comparant Glean (GPT-5.1) à ChatGPT, et Glean à Claude (tous deux sur Sonnet 4.5).
Évaluation
Nous avons mené une évaluation à l’aveugle, randomisée, en utilisant une échelle de préférence en cinq points (nous avons regroupé les préférences en catégories pour ce blog) sur les dimensions suivantes :
- Exactitude : précision factuelle et validité logique par rapport à la requête
- Exhaustivité : couverture de toutes les parties de la question et des étapes nécessaires
Nous avons choisi ces métriques d’évaluation car elles reflètent ce qui compte réellement pour les entreprises : La réponse est-elle fiable, ou s’agit-il d’une hallucination ? L’IA a-t-elle répondu complètement à la requête de l’utilisateur, ou l’utilisateur doit-il encore finir le travail ? ;
Les citations étaient affichées à côté des réponses afin que les évaluateurs puissent vérifier les affirmations factuelles. Lorsqu’une question dépassait leur domaine d’expertise, les évaluateurs pouvaient « passer un coup de fil à un ami » en utilisant la recherche d’experts de Glean pour trouver un expert métier, puis confirmer leur jugement avec lui.
Nous avons privilégié une évaluation relative (comparaison des réponses entre elles) plutôt qu’une évaluation subjective, car les personnes ne se calibrent pas de la même façon sur ce qu’elles considèrent comme « correct » ou « exhaustif », et les comparaisons relatives réduisent ce biais propre à chaque personne. Nous avons aussi atténué le biais de position en inversant aléatoirement la position de Glean et de ChatGPT ou Claude selon les requêtes. ;
Nous avons utilisé quatre évaluateurs pour l’évaluation initiale, puis nous avons recoupé les résultats avec notre propre équipe qualité IA afin de nous assurer que la notation respectait les consignes.
Résultats de l’évaluation
Nous avons évalué les résultats à l’aide de ratios victoires-défaites. Lorsque les évaluateurs avaient une préférence, ils choisissaient Glean plutôt que ChatGPT 1,9× plus souvent et plutôt que Claude 1,6× plus souvent sur la justesse.
Glean a résolu la question du contexte en combinant des données indexées pour une recherche rapide, des Enterprise Graphs pour comprendre les relations, et une mémoire d’entreprise (via le trace learning) pour optimiser l’utilisation des outils, en se concentrant sur les structures de données sous-jacentes qui alimentent la recherche. ;
Lorsque nous avons examiné Claude et ChatGPT, nous avons constaté qu’ils ont tendance à compenser les lacunes de qualité des outils en effectuant davantage d’appels aux outils. Ils récupèrent donc trop de données (« overfetching »), ce qui est à la fois coûteux et peut introduire du bruit menant à des résultats inexacts.
Claude et ChatGPT utilisent toutefois des stratégies d’appel d’outils différentes. Nous observons que Claude emprunte une voie « en profondeur » : ;
- il réfléchit davantage à la question
- effectue des appels d’outils séquentiels
- lit les résultats en intégralité et en détail
- et si ce n’est pas la bonne piste, il bifurque et en explore une autre
Comme il s’appuie sur des outils basés sur MCP, qui ont tous des paramètres par défaut, des limites et des formats de données différents, Claude peut se retrouver avec un contexte inégal selon la source. Par exemple, si Slack renvoie de longs fils de discussion tandis qu’un autre outil ne fait remonter que quelques enregistrements courts, Slack peut facilement dominer la fenêtre de contexte et biaiser ce à quoi le modèle prête attention. De plus, nous avons constaté qu’il était difficile pour Claude de se réorienter une fois engagé sur une piste donnée. Par exemple, une fois qu’il avait déterminé que Slack pouvait répondre à la question, il n’invoquait souvent pas d’autres outils MCP pour trouver la source canonique.
ChatGPT, à l’inverse, adopte une stratégie « en largeur » en lançant des recherches en parallèle et en ne consultant que les extraits les plus pertinents de chaque document. Il optimise la vitesse et la couverture en survolant d’abord les documents, en déclenchant de nombreuses recherches et en parcourant de nombreux documents, puis en approfondissant quelques documents parmi les plus pertinents. Malgré les meilleurs efforts d’OpenAI pour explorer en largeur et en profondeur, il arrive encore qu’il ne parvienne pas à trouver l’information pertinente à cause de la qualité des outils de recherche sous-jacents. L’autre difficulté de cette approche est qu’elle peut entraîner une surcharge de contexte, car OpenAI lit des documents issus de nombreuses sources et peine à synthétiser des données contradictoires, notamment en mélangeant des documents plus anciens avec des plus récents.
Bien que nous n’ayons pas mesuré la latence ni le coût, chaque appel à un outil représente une dépense. S’appuyer sur de nombreux appels d’outils et tokens pour passer au crible des données largement non pertinentes devient une solution de contournement coûteuse et peut aussi heurter des limites de débit, entraînant l’échec de requêtes futures pour d’autres utilisateurs de l’organisation. Les index et les graphes de connaissances continuent d’exister parce qu’ils sont très précis et évitent le piège classique du « brute force » via la puissance de calcul. ;
Classes de requêtes
Nous avons ensuite analysé en détail les performances de Glean selon différentes classes de requêtes. Bien que la recherche soit souvent considérée comme une catégorie unique, en pratique elle soutient de nombreux types de travail agentique, notamment :
- Analyse de données : calcul de métriques, recherche de tendances, génération de graphiques et de tableaux
- Développement et débogage : écriture de code ou dépannage de configurations techniques
- Prise de décision : évaluation d’options, comparaison de compromis, recommandation d’une marche à suivre
- Rédaction de contenu : rédaction ou modification d’e-mails, de documents, de spécifications et de présentations
- Apprentissage : explication, définition et guides pas à pas
- Recherche d’informations : recherche classique — localiser un document ou une ressource spécifique
Lorsque nous examinons la répartition des requêtes pour lesquelles Glean a été préféré, les victoires se répartissent sur l’ensemble de ces catégories, reflétant les différentes façons dont les entreprises utilisent réellement l’IA aujourd’hui.
Les résultats quantitatifs ne racontent qu’une partie de l’histoire nous avons donc également mené une évaluation qualitative pour comprendre où et pourquoi Glean, ChatGPT et Claude ont chacun mieux performé.
Justesse
Victoires
Glean était plus performant pour trouver le document canonique, comprendre le jargon propre à l’entreprise, gérer les requêtes ambiguës et répondre aux requêtes techniques.
En matière de justesse, Glean a mieux réussi sur les tâches nécessitant une source faisant autorité pour répondre. Cela reflète nos racines dans la recherche d’entreprise, où la précision dépend de la récupération du bon document, puis du bon extrait.
En coulisses, Glean construit un modèle de recherche sémantique pour chaque entreprise, stocké de manière sécurisée dans le VPC du client. Le modèle apprend la langue de l’entreprise et se règle sur ses produits, ses clients, ses projets, ses abréviations et les termes du secteur. Ces modèles sémantiques expliquent en partie pourquoi Glean a surperformé sur les requêtes reposant sur du jargon propre à l’entreprise.
Glean maintient également un Enterprise Graph sur les données, cartographiant les relations entre les projets, les clients, les équipes, les tickets, les documents et le code. Lorsqu’une requête est ambiguë, Glean peut s’appuyer sur ce graphe pour identifier le projet ou l’entité visé(e) par l’utilisateur.
Les fondations de recherche de Glean vont aussi au-delà d’un index unique : nous construisons plusieurs index spécialisés sur vos données, ajustés au type de requête. Par exemple, nous maintenons des index lexicaux et sémantiques dédiés à la recherche dans le code, ce qui nous aide à mieux performer sur les requêtes techniques, lorsque le contexte pertinent se trouve dans le code plutôt que dans les documents. ;
Je vais rechercher dans Salesforce les comptes attribués à Martinique. Martinique Charleston est assignée à 43 comptes dans Salesforce en tant que Customer Success Manager. Voici la liste complète :
Comptes (A-Z)
- Adler Street Capital
- Aether Ridge Energy
- AlioraCorp
- Antivex Systems
- Apexion Materials
- Aurora Global Logistics
- Brookline Inc.
- CashTrail Rewards
- Cepora
- ChromaWave
- CloudBridge Nexus (Partner)
- CodeFountain Labs
- Cyphin Labs
- Diamond Analytics
- Diatris Foundation
- DualSight Metrics
- Elora
- Exonaa Financial
- Fork Analytics
- Fortisense Labs
- Granite Edge Management
- Harborline Capital Group
- Harmony Capital
- Hyperine
- Intellibug Labs
- Keystone Balance Advisors, LLC
- LoopTransit Labs
- Lumina Vector AG
- Northwind Strategy Group
- NovaCredi México
- Onyx Harbor Security
- Pathwise Learning Institute
- PulseLink Safety Systems
- SeatPilot Systems
- Sparklift Intelligence
- Starlight Arcade Studios
- Stonegate Payments
- Summit Ridge Ventures
- TreeLine Field Systems
- VectorSignal Insights
- Wavecrest IT Services
Souhaitez-vous voir plus de détails sur certains comptes en particulier, ou filtrer cette liste par secteur, taille ou d’autres critères ?
Je vais rechercher dans Salesforce les comptes attribués à Martinique. Martinique Charleston est attribuée à un compte dans Salesforce : Neptune
Détails du compte :
- Nom du compte : Neptune
- ID du compte : XXXX
- Propriétaire : Martinique Charleston
- Secteur : Logiciels et services Internet
- Type : Prospect avec opportunité ouverte
Remarque : ces informations sont basées sur les données actuelles de Salesforce, où Martinique Charleston est indiquée comme propriétaire du compte.
Glean a déduit que Martinique est Customer Success Manager et a interprété « owner » comme le CSM assigné au compte, plutôt que comme le propriétaire du compte. Claude n’a récupéré qu’un seul enregistrement indiquant Martinique comme propriétaire du compte. Glean parvient mieux à déduire l’intention de l’utilisateur à partir de la requête grâce à la profondeur de son indexation, en extrayant des champs plus riches et mieux structurés, ainsi qu’à l’Enterprise Graph qui associe les employés, comme Martinique, aux comptes.
Je vais rechercher des informations sur la fréquence des statistiques de corpus dans la documentation de votre entreprise. D’après les résultats de recherche, les statistiques de corpus s’exécutent à plusieurs fréquences selon la variante du pipeline :
Pipeline principal des statistiques de corpus
corpus_stats s’exécute selon une double planification :
-
Quotidien : Minuit UTC
(
0 0 * * *) -
Toutes les heures : Chaque heure de 1 à 23 UTC
(
0 1-23 * * *), uniquement si le dernier dump « fresh » a moins de 65 minutes
Les exécutions horaires se déclenchent uniquement pour des dumps « fresh » d’un âge maximal de 65 minutes, tandis que l’exécution quotidienne a lieu независимоamment de la fraîcheur du dump afin d’assurer une couverture complète.
Corpus Stats DAC uniquement
corpus_stats_dac_only s’exécute
chaque semaine le dimanche à minuit UTC
(0 0 * * 0).
Cette variante calcule spécifiquement les décomptes de documents X avec une période de lookback Y.
Pipeline associé
corpus_insights s’exécute selon une planification différente — deux fois par mois — le 1er et le 16 à minuit UTC, avec des exécutions consécutives espacées de 15 jours
Vous pouvez consulter les planifications actuelles d’exécution du pipeline et les exécutions des jobs sur go/xxx. Besoin d’aide pour comprendre pourquoi une exécution spécifique des statistiques de corpus a échoué ou pour ajuster la fréquence ?
Je vais rechercher des informations sur les statistiques de corpus et leur fréquence dans les systèmes de votre entreprise. D’après mes recherches dans les communications internes et la documentation, les statistiques de corpus s’exécutent selon une cadence hebdomadaire.
Le pipeline corpus_stats dépend de l’achèvement de docs_data et s’exécute environ une fois par semaine. En examinant les fichiers X générés par le pipeline, les dates montrent un schéma hebdomadaire cohérent (4 octobre, 11 octobre, 18 octobre, 4 novembre).
Il existe également une variante appelée corpus_stats_xxx_only qui s’exécute selon le même rythme hebdomadaire.
Il convient de noter que le pipeline comporte une vérification de seuil : il ne s’exécutera pas si le docs_data le plus récent n’est pas suffisamment à jour. Le seuil est d’environ 1 heure et 5 minutes.
Glean a correctement identifié le planning par paliers d’exécution des statistiques de corpus, tandis que Claude a conclu à tort à une unique cadence hebdomadaire. Glean n’a pas eu besoin de s’appuyer uniquement sur des documents potentiellement obsolètes ou inexacts — il a aussi pu consulter directement le code comme source de vérité. À l’inverse, la recherche de Claude s’est fortement appuyée sur Slack.
Faiblesses
Cela dit, il y avait des domaines où d’autres ont fait mieux que Glean. L’un d’eux : savoir quand demander des précisions. Claude reconnaissait souvent qu’il n’y avait pas suffisamment d’orientation ou de données pour répondre et choisissait plutôt de poser des questions de suivi. ;
ChatGPT avait tendance à mieux suivre des instructions utilisateur explicites liées à une source de données ou à une procédure particulière, en se concentrant exactement sur ce qui était demandé. Glean, à l’inverse, optimise l’utilité. Lorsque nous constatons un manque de contexte ou des occasions d’ajouter des détails utiles, nous allons parfois au-delà du libellé littéral de la requête pour combler les lacunes, tout en ancrant l’ensemble dans les connaissances de votre entreprise.
Exhaustivité
Points forts
En matière d’exhaustivité, nous avons constaté que Glean surperformait sur les requêtes nécessitant des détails techniques complets, des prochaines étapes actionnables et une compréhension de cadres complets.
En examinant les commentaires des évaluateurs, ils ont préféré les réponses qui détaillaient les étapes concrètes et incluaient les bons canaux Slack, formulaires de demande, tickets Jira ou playbooks. Cela vient en partie de l’Enterprise Graph et de sa capacité à comprendre comment les tickets Jira se rattachent à différents projets, mais aussi de la reconnaissance de l’intention de l’utilisateur dans le contexte de l’entreprise, et d’une réponse plus holistique en faisant remonter des prochaines étapes concrètes. ;
Glean est également meilleur pour rester centré sur l’intention de l’utilisateur, car il récupère un contexte plus pertinent pour la requête. Lorsque ce contexte est riche, spécifique et pertinent, le modèle peut déduire « de quoi il s’agit vraiment » à partir des éléments environnants, plutôt que de s’appuyer uniquement sur la requête. Autrement dit, un meilleur contexte permet à l’agent d’inférer l’intention plutôt que de la deviner.
Lorsque la tâche consiste à créer un cadre cohérent (analyse concurrentielle, cadre de décision, plan en plusieurs étapes), l’avantage de Glean est qu’il peut voir de manière fiable une plus grande partie du paysage pertinent et le structurer avec l’Enterprise Graph. Ainsi, l’IA peut parcourir systématiquement les contenus associés au lieu de surpondérer les résultats d’une seule source.
D’après les documents liés à Juniper Beta, le projet est principalement géré par :
- Product management / programme beta global : Arvin Allworth (Product Manager, Growth & ; Knowledge Management). Il est le PM sur Juniper et possède des documents tels que « Juniper - Weekly Update » et « Juniper Beta Candidate Apps », qui décrivent et suivent la beta.
- Direction engineering pour Juniper : Sam Aimes (Software Engineer, EM pour l’équipe Juniper). Il apparaît comme manager des ingénieurs Juniper principaux et est indiqué comme owner sur « Proactive intelligence (Juniper) ».
- Déploiement beta au quotidien / configuration des expérimentations : Bradley Murphey (Software Engineer). est le principal contributeur individuel qui édite et possède des configurations comme « [Juniper] Draft of experiment config to greenlist Juniper BETA users » et « Juniper beta : add Crema Inc. and Popsicle Io testers to home_page_task_list_greenlist », qui portent spécifiquement sur la cohorte beta et les mécanismes de déploiement.
Donc : Arvin gère le programme Juniper Beta côté produit, Sam dirige l’équipe engineering et Bradley pilote la configuration des expérimentations beta et le travail de déploiement.
Souhaitez-vous leurs coordonnées ou les noms précis des documents cités ?
La beta Juniper est pilotée par Arvin Allworth — il est le PM/DRI du projet Juniper (annoncé sur Slack et indiqué comme PM dans le document d’exécution R& ;D).
Glean a fourni une réponse plus exhaustive en listant l’ensemble des responsables du projet, tandis que ChatGPT n’a mentionné que le PM global. L’Enterprise Graph de Glean peut identifier différents types de propriétaires de projet et comprendre sur quoi les personnes travaillent à l’échelle de l’organisation.
Faiblesses
Nous avons constaté que ChatGPT a tendance à l’emporter sur le terrain de l’exhaustivité lorsque la requête gagne à s’appuyer sur plusieurs approches ou exemples, par exemple en présentant 3 méthodes différentes, en comparant des modèles et en proposant des alternatives dans différents langages de programmation.
Nous avons également observé un biais constant en faveur d’explications causales, avec un contexte enrichi. ChatGPT aime dérouler une narration complète, étape par étape, et développer avec des analogies ou des exemples, ce qui donne l’impression que les réponses sont plus complètement expliquées. Glean, à l’inverse, est optimisé pour être plus concis et orienté vers l’exécution, avec moins de mise en récit. En comparaisons côte à côte, ce pragmatisme peut parfois sembler manquer de contexte face au style plus expansif de ChatGPT.
À mesure que Glean continue de personnaliser l’expérience, nous nous éloignons des préférences globales pour devenir plus adaptables à chaque individu. Si un utilisateur préfère une réponse plus directe et unique, la mémoire de Glean s’adaptera au fil de nos apprentissages issus des interactions et des préférences personnelles. Au final, l’exhaustivité est une notion subjective, et notre objectif est de garantir que chacun obtienne toutes les informations qu’il souhaite, de la manière dont il le souhaite.
Tout contexte ne se vaut pas
Fournir un contexte d’entreprise de qualité exige les bonnes fondations techniques. C’est précisément ce dans quoi nous investissons chez Glean : des connecteurs, des index, Enterprise Graph, la mémoire d’entreprise (via trace learning) et des skills qui travaillent de concert pour donner aux agents le contexte dont ils ont besoin pour opérer pleinement et avec précision.
À mesure que la taille et la diversité des données d’entreprise utilisées par l’IA augmentent, ces fondations deviennent encore plus essentielles. La plupart des nouveaux entrants ne prennent toujours en charge qu’une poignée d’intégrations, loin d’être représentatives des applications d’une entreprise moderne, puis comblent le manque de couverture via MCP. Les implémentations naïves de MCP posent des défis sur la manière dont les outils sont appelés, en exposant souvent des outils dont la qualité est faible ou inégale, ce qui complique la réconciliation et la fusion des résultats entre outils. ;
Glean dispose de plus de 100 connecteurs, et cela compte. Nous pouvons prendre en charge davantage de travail agentique parce que nous couvrons une plus grande partie de l’entreprise et parce que la pile de contexte sous-jacente est conçue pour fonctionner à cette échelle. Et via le serveur MCP distant de Glean, nous rendons ce contexte unifié disponible où que vous choisissiez d’utiliser l’IA, afin que vous puissiez aussi intégrer le contexte Glean dans ChatGPT ou Claude. Nous continuons d’améliorer la façon dont Glean s’intègre à ces deux environnements, avec pour objectif de faire du contexte d’entreprise complet l’épine dorsale de votre travail dans ChatGPT et Claude.
Auteurs : Matthew Zhao, Karthik Rajkumar, Neil Dhruva, Julie Mills, Matt Ding, Anshul Negi
