.jpg)
Les agents sont désormais sur le point de prendre en charge des tâches de bout en bout de longue durée. Ils peuvent résoudre des tickets de support, écrire du code, soumettre des PR et même finaliser des plans complets de comptes commerciaux. Mais à mesure que les agents s'attaquent à des tâches plus complexes, ils sont de plus en plus contraints par la fenêtre de contexte du modèle. Quand vos données encombrent la fenêtre de contexte, les agents sont forcés de faire des compromis : plafonner les résultats, résumer de façon agressive ou supprimer des détails, ce qui limite artificiellement l'ampleur du travail réel qu'ils peuvent accomplir. Même avec des modèles qui prennent en charge de grandes fenêtres de contexte, nous observons encore une perte d'attention chez les agents, et le coût des tâches à long contexte reste élevé.
Ce que nous avons constaté, c'est que si vous donnez à un agent un bac à sable, un ordinateur virtuel équipé d'un système de fichiers, d'une ligne de commande, d'un runtime de code et d'un index d'outils, il peut utiliser cet environnement pour étendre sa mémoire courte effective et traiter bien plus de données que ne le permettent les fenêtres de contexte des LLM. Les agents peuvent lire directement depuis les systèmes de fichiers, ce qui rend les données entièrement itérables : l'agent peut ainsi récupérer ce dont il a besoin à chaque phase d'exécution, plutôt que d'essayer de tout faire tenir dans la fenêtre de contexte. ;
Dans l'entreprise, nous voyons cela débloquer de nouveaux cas d'usage analytiques, notamment l'agrégation d'ensembles de données à grande échelle qui étaient auparavant hors de portée des agents. Dans cet article, nous vous présentons un cas d'usage réel que cela rend possible.
Analyse complète de toutes vos données structurées et non structurées
De nombreuses tâches courantes pour les responsables commerciaux semblent simples : « Passe en revue toutes mes opportunités T4 pour analyser la santé du pipeline. » En réalité, cela nécessite de rassembler des milliers de points de données provenant de systèmes d'enregistrement et d'applications de productivité pour obtenir une vision complète.
À mesure que l'agent s'exécute et récupère le contenu nécessaire au rapport sur le pipeline, il approche de la limite de la fenêtre de contexte du modèle et lance un bac à sable d'agent. ;
Le bac à sable de l'agent fonctionne de concert avec le contexte d'entreprise de Glean, en intégrant des données d'opportunités structurées depuis Salesforce ainsi que des transcriptions d'appels Gong non structurées, des messages Teams, des e-mails Outlook, des documents Word, des présentations Powerpoint et bien plus encore. ;
Glean permet à l'agent de donner du sens à ces données en les cartographiant dans le Enterprise Graph, qui relie les clients, les responsables de compte et les activités dans toutes vos applications métier. Ainsi, seules des données pertinentes et de haute qualité entrent dans le bac à sable et sont utilisées à chaque étape de l'exécution de l'agent, empêchant celui-ci de subir une surcharge de contexte et des interférences. Le bac à sable permet aux agents d'extraire un maximum de valeur d'une grande quantité de contexte, mais seulement lorsque celui-ci contient dès le départ le bon contexte. ;
Le bac à sable de l'agent inclut un runtime Python pour l'analyse et le traitement des données. Au fur et à mesure de son exécution, l'agent peut utiliser l'exécution de code pour évaluer le risque du pipeline, lancer des analyses de sensibilité, détecter des valeurs aberrantes et générer une liste classée d'opportunités avec des probabilités de gain prédites. ;
La véritable avancée, c'est que cette analyse ne se limite pas aux données propres et structurées qui apparaissent dans les rapports CRM : l'agent peut intégrer et analyser des données non structurées issues de toutes vos conversations clients, conversations qui étaient auparavant hors de portée pour mener l'analyse complète. Désormais, vos prévisions reflètent la véritable histoire qui se joue avec les clients, et non plus seulement la portion étroite capturée dans les champs de données structurées. ;
Leçons tirées de l'ingénierie de la gestion de la mémoire courte
Avant que nous construisions les bacs à sable, les fenêtres de contexte des LLM étaient la seule mémoire courte dont disposaient Glean Agents. Même si les fenêtres de contexte s'élargissaient à chaque nouvelle version de modèle, les agents avaient toujours besoin d'une gestion de contexte courte efficace et structurée pour atteindre de bonnes performances. ;
Chez Glean, nous avons conçu une hiérarchie de classification pour les données entrant dans la fenêtre de contexte. Cela a permis aux agents de distinguer les entrées utilisateur, les instructions système et les sorties d'outils selon différentes parties d'une conversation. Ces heuristiques aidaient les agents à décider quel contenu réduire tout en préservant les faits et instructions critiques. Le bac à sable utilise cette même hiérarchie pour une approche plus puissante. Au lieu de supprimer des informations, un agent conserve dans la fenêtre de contexte du LLM les données dont il a immédiatement besoin et stocke les données supplémentaires dans le système de fichiers pour un accès à la demande plus tard. Avec le bac à sable, la gestion de la mémoire est passée de la suppression à la persistance. ;
Nous avons également construit des outils de sélection qui permettent aux agents de charger en mémoire des extraits précis de documents volumineux sur la base d'une similarité sémantique propre à l'entreprise. Cela permettait aux agents de comprendre rapidement de longs documents sans le coût de tout lire d'emblée. Le système de fichiers du bac à sable alimente une stratégie similaire avec une capacité bien plus grande. Avec les bacs à sable, nous pouvons utiliser les outils de sélection pour cibler rapidement les bons extraits, puis les associer à une matérialisation gourmande, en analysant le document complet, en revenant sur des sections spécifiques ou en écrivant du code pour les analyser.
Nous avons exposé des filtres avancés dans les outils de recherche de Glean, afin que les agents puissent mieux exploiter les données, plus rapidement, en leur permettant de spécifier des plages de dates, des types de documents et des signaux de classement comme la similarité sémantique et la popularité. Ces mêmes filtres avancés servent désormais à rendre le bac à sable plus efficace. ;
Si nos premiers systèmes étaient efficaces, ils étaient aussi fragiles. Un cadre qui fonctionnait pour GPT-5 pouvait ne pas suffire pour Claude Sonnet 4.5. Même des mises à jour mineures (par exemple, GPT-5.1 vers 5.2) entraînaient de grandes variations de performance. Cela tient au fait que la mémoire dans la fenêtre de contexte repose sur l'attention du modèle, qui change à chaque mise à jour. En conséquence, l'interprétation par le LLM des résumés, des instructions et des états de tâche varie d'une version à l'autre, ce qui provoque une dérive de qualité même si le système d'agent reste inchangé. Maintenir la qualité d'un modèle à l'autre signifiait ajuster en permanence la mémoire. C'est pourquoi les agents n'ont pas besoin de fenêtres de contexte plus grandes : le problème d'une mémoire courte fragile resterait le même. Ce dont ils ont besoin, ce sont de bacs à sable.
Cette fragilité était le coût caché du fait de traiter la fenêtre de contexte comme la seule forme de mémoire. Les bacs à sable nous permettent de déplacer cet état hors de la fenêtre de contexte fragile et dans un environnement stable dans lequel l'agent peut travailler de manière fiable. Beaucoup de nos investissements antérieurs dans la classification, la récupération et le classement restent pertinents aujourd'hui. En même temps, une grande partie du travail consacré à la troncature agressive, à la compression et à la micro-gestion du budget de jetons a disparu avec les bacs à sable.
Comment nous avons sécurisé le bac à sable de l'agent
La sécurité est intégrée dès la conception au bac à sable de l'agent. Chaque bac à sable s'exécute dans un environnement isolé au sein de votre propre VPC, avec des limites de ressources strictes, des systèmes de fichiers à portée définie et une isolation au niveau de la session. Les données, le code et les artefacts intermédiaires d'une session ne fuient jamais vers une autre. L'accès réseau du bac à sable est désactivé par défaut et sera entièrement configurable à l'avenir, ce qui minimise l'exposition tout en offrant un contrôle précis lorsque la connectivité externe est nécessaire. Comme les appels aux outils et aux LLM continuent d'être acheminés par les mêmes chemins d'orchestration qu'auparavant, le bac à sable hérite de toutes les protections, permissions et contrôles de gouvernance existants de Glean.
Les modèles et le contexte fonctionnent mieux ensemble avec le bac à sable de l'agent
Les bacs à sable d'agent ne remplacent pas de meilleurs modèles ni un contexte plus riche. Ils rendent simplement les deux plus utiles ensemble. Lorsque vous donnez un bac à sable aux agents, ils cessent de lutter contre la fenêtre de contexte et commencent à prendre en charge davantage de travail qu'auparavant. ;
Pour une plateforme d'IA de travail où des agents capables rencontrent un contexte d'entreprise complet, inscrivez-vous dès aujourd'hui à une démonstration de Glean !
Disponibilité : les bacs à sable d'agent de Glean arrivent bientôt.
