Les tests de l’agent navigateur d’Asana réduisent les coûts des modèles d’un facteur 76 avec GPT-6.1 Sol

Asana affirme que son agent navigateur est devenu 76 fois moins cher et cinq fois plus rapide après que ses ingénieurs ont modifié la manière dont il conservait et mettait en cache l’historique de navigation. Les tests de l’agent navigateur d’Asana ont utilisé GPT-6 Astra dans Codex pour étudier le système, mener des expériences et analyser les traces. GPT-6.1 Sol a ensuite affiché le coût de modèle estimé le plus bas dans le cadre du flux de travail optimisé.

Le résultat phare ressemble à une victoire de modèle. La conclusion la plus importante concerne l’architecture des agents. Asana a modifié le moment où l’agent supprimait les captures d’écran, augmenté sa capacité d’historique et mis en cache l’enregistrement croissant des étapes précédentes. Ces changements ont réduit les traitements répétés tout en préservant les informations dont l’agent avait besoin pour accomplir sa tâche.

Cette distinction compte pour toute entreprise qui évalue des agents navigateur. Une équipe peut adopter un modèle moins coûteux tout en gaspillant des tokens à cause d’une mauvaise gestion du contexte. Elle peut aussi choisir un modèle plus performant, préserver le bon historique et réduire les coûts d’exploitation totaux. L’expérience d’Asana met ces deux stratégies directement en concurrence.

L’étude d’Asana sur les agents navigateur a changé bien plus que le modèle

Les gains les plus importants d’Asana proviennent d’une refonte du flux de travail autour du modèle, et non du simple remplacement d’un modèle par un autre.

L’entreprise a publié les résultats le 8 octobre 2026, suivis d’une étude de cas d’OpenAI le 9 octobre. Les travaux portaient sur un agent navigateur intégré à StackAI, la plateforme d’automatisation no-code qu’Asana a acquise plus tôt en 2026.

StackAI permet aux clients de créer des agents qui naviguent sur des sites web, collectent des informations et remplissent des formulaires dans des applications métier. Ces flux de travail ressemblent à la navigation humaine, mais l’agent sous-jacent envoie de manière répétée des instructions, des outils, du texte de page, des captures d’écran et des actions antérieures à un modèle.

Ce contexte répété crée une structure coûteuse. Chaque nouvelle étape inclut davantage d’historique que la précédente. Si le contenu antérieur change constamment, un fournisseur ne peut pas réutiliser de manière fiable sa représentation mise en cache.

L’agent initial d’Asana mettait en cache les instructions fixes et les définitions d’outils. Il ne mettait pas efficacement en cache l’historique de navigation croissant. L’agent supprimait également d’anciennes captures d’écran et tronquait fréquemment le texte, modifiant ainsi les premières parties de la requête.

Ces modifications rompaient le préfixe stable, c’est-à-dire le début inchangé partagé par des requêtes de modèle consécutives. Une fois ce préfixe modifié, une grande partie de l’historique de navigation devait être traitée de nouveau.

Frank Hidalgo, directeur de la technologie de StackAI chez Asana, a chargé GPT-6 Astra dans Codex d’examiner ce comportement. Le modèle a cartographié la base de code, étudié la composition des requêtes et identifié les variables à tester.

Asana indique que l’étude qui en a résulté comprenait 144 exécutions principales sur quatre modèles de pointe. Elle a testé six politiques de mise en cache et de captures d’écran, deux capacités d’historique et trois exécutions pour chaque condition. L’entreprise a ensuite mené un suivi plus restreint.

Chaque configuration recevait la même mission. L’agent navigateur devait collecter six champs pour chacun de 32 livres à partir d’un catalogue de démonstration public. Cela impliquait de trouver 192 informations tout en conservant suffisamment de contexte pour fournir une réponse finale correcte.

Les modèles comprenaient GPT-6.1 Sol et trois alternatives anonymisées. Asana a appelé ces systèmes les modèles A, B et C. Le modèle B alimentait la configuration de production initiale, tandis que le modèle C représentait un modèle plus récent du même fournisseur.

Asana n’a pas divulgué ces fournisseurs, limitant les comparaisons concurrentielles directes. L’entreprise a toutefois indiqué que le flux de travail optimisé avec GPT-6.1 Sol coûtait 76 fois moins cher que la configuration initiale du modèle B. Il s’est également achevé environ cinq fois plus rapidement.

L’entreprise a depuis déployé les modifications de navigation web dans StackAI. L’exercice passe ainsi d’une comparaison de laboratoire à un changement en production, même si Asana n’a pas publié de données générales de performance au niveau des clients.

Pourquoi la mise en cache des prompts est devenue le mécanisme décisif

La variable déterminante était la capacité de l’agent à conserver inchangée la majeure partie de son historique accumulé entre les appels.

La mise en cache des prompts stocke l’état computationnel réutilisable associé à un préfixe de prompt inchangé. Les requêtes ultérieures peuvent réutiliser cet état au lieu de traiter le même contenu depuis le début.

Le cache ne stocke pas une réponse finale à rejouer. Le modèle traite toujours le nouveau contenu et génère une nouvelle réponse. Il évite simplement de répéter le travail pour le contexte éligible qui reste identique.

Le guide sur la mise en cache des prompts d’OpenAI recommande de placer les instructions stables et les documents de référence avant le contenu changeant. Il conseille également aux applications d’ajouter l’historique de conversation au lieu de réécrire sans cesse les tours antérieurs.

La conception initiale d’Asana enfreignait ce second principe pendant les sessions de navigation. À presque chaque étape, elle supprimait une capture d’écran antérieure et tronquait parfois du texte plus ancien. La requête suivante différait donc au milieu de son historique.

La mise en cache du seul prompt système fixe ne pouvait pas couvrir la principale source d’entrées répétées. L’agent navigateur accumulait du texte de page, des captures d’écran, des observations et des résultats d’outils à mesure qu’il avançait dans la tâche.

Asana a testé une autre politique appelée élagage par lots. L’élagage consiste à supprimer l’ancien contexte avant que l’historique accumulé ne devienne trop volumineux. Avec la politique retenue, l’agent conservait jusqu’à 20 captures d’écran avant de réduire l’ensemble à la plus récente.

Cette approche créait de plus longues séquences d’historique uniquement enrichies par ajout. L’agent pouvait ajouter de nouvelles observations à la fin sans modifier le contenu antérieur à chaque étape. Une plus grande partie de chaque requête restait donc éligible à la réutilisation.

Le flux de travail optimisé a également augmenté la capacité de l’historique textuel de 120 000 caractères à 480 000 caractères. Cela a donné à l’agent davantage d’espace pour préserver les informations déjà recueillies au lieu de les écarter.

Cette capacité accrue a eu un effet important sur l’achèvement. Avec le réglage d’historique plus limité, GPT-6.1 Sol n’a produit une réponse que dans trois exécutions sur 18. Avec le réglage plus élevé, il a répondu dans les 18 exécutions, selon Asana.

Asana affirme que chacune de ces exécutions avec un historique plus long a produit la bonne réponse. Ce résultat remet en cause l’hypothèse selon laquelle une réduction agressive du contexte améliore toujours l’efficacité des agents.

Supprimer du contexte réduit la taille immédiate d’une requête. Cela peut toutefois contraindre un agent à revisiter des pages, répéter des appels d’outils ou poursuivre sans les preuves recueillies auparavant. Cela peut aussi compromettre la réutilisation du cache lorsque la suppression modifie le préfixe de la requête.

La meilleure politique dépend donc de l’économie globale de la tâche. Les équipes doivent prendre en compte le traitement des entrées, la navigation répétée, les taux d’achèvement, la qualité des réponses et la reprise après des exécutions échouées.

Asana a indiqué que 89 % des entrées de GPT-6.1 Sol provenaient du cache dans la configuration optimisée. Ce ratio explique pourquoi un modèle plus performant a pu devenir l’option testée la moins coûteuse pour l’ensemble de la tâche.

C’est le mécanisme central du résultat obtenu par l’agent navigateur d’Asana. L’entreprise n’a pas simplement demandé à un modèle d’utiliser moins de tokens. Elle a réorganisé le flux de travail afin que les tokens répétés deviennent moins coûteux à traiter.

Davantage de contexte a aidé l’agent à achever ses tâches de façon fiable

L’expérience suggère que la requête la moins chère ne fait pas toujours partie du flux de travail achevé le moins coûteux.

Les concepteurs d’agents considèrent souvent le contexte comme une ressource à minimiser. Cette vision est logique, car les prompts longs augmentent le traitement des entrées et peuvent approcher la limite de contexte d’un modèle.

Les agents navigateur compliquent ce calcul. Leurs observations antérieures font office de mémoire de travail. Supprimer une adresse, un attribut de produit, un avertissement ou un résultat de navigation peut empêcher l’agent de finaliser sa réponse.

La capacité d’historique plus limitée a produit des résultats particulièrement faibles pour certains modèles. Asana indique que le modèle C n’a renvoyé aucune réponse sur 18 exécutions dans cette condition. GPT-6.1 Sol n’a renvoyé que trois réponses.

Ces échecs ne prouvaient pas que les modèles manquaient de capacités générales de navigation. La capacité d’historique supérieure a changé le résultat. Les deux modèles ont répondu à chaque exécution après avoir reçu suffisamment d’espace pour conserver les éléments nécessaires.

Le résultat soutient un principe d’ingénierie plus général. La politique de contexte doit correspondre au modèle et à la tâche. Une limite universelle de tokens ne produira pas un comportement équivalent entre différents systèmes.

Les modèles peuvent consommer le contexte à des rythmes différents parce qu’ils génèrent des descriptions, des appels d’outils et des traces de raisonnement différents. Un agent peut atteindre un seuil d’élagage après un petit nombre d’actions. Un autre peut continuer beaucoup plus longtemps.

Asana a constaté que les modèles plus récents ou plus performants n’utilisaient pas automatiquement la capacité réduite plus efficacement. Le modèle C a commencé à tronquer l’historique bien plus tôt que le modèle A dans le flux de travail testé.

L’expérience a également montré que la mise en cache seule était insuffisante. Avec la capacité d’historique plus élevée, la mise en cache sans élagage par lots coûtait plus cher que l’absence de mise en cache pour trois modèles sur quatre.

Ce résultat semble contradictoire jusqu’à ce que l’on considère la structure des requêtes. Un cache offre une valeur limitée lorsque l’application réécrit constamment le contenu qu’elle souhaite réutiliser. Le système paie pour traiter un historique changeant sans obtenir suffisamment de futurs accès au cache.

La politique retenue par Asana alignait trois décisions. Elle mettait en cache l’historique, préservait une séquence uniquement enrichie par ajout pendant de plus longues périodes et offrait une capacité plus élevée avant que l’élagage ne devienne nécessaire.

Un suivi a soulevé une autre question. Asana a testé des configurations qui conservaient chaque capture d’écran au lieu de les élaguer. Certaines ont produit des coûts par appel plus faibles que la politique retenue pour cette tâche particulière.

L’entreprise n’y a pas vu la preuve que l’élagage devait disparaître. Les flux de travail plus longs peuvent dépasser les limites de contexte, tandis que certains fournisseurs facturent davantage les opérations de cache. Un agent qui dérive vers une navigation inutile a également besoin de limites strictes.

Asana recommande de fixer des plafonds sur le nombre d’étapes, les tokens et le coût total d’exécution. Ces limites empêchent un agent incorrect ou désorienté d’étendre son historique indéfiniment. La compaction, qui remplace l’ancien historique par un résumé plus court, constitue une autre option.

La compaction introduit son propre compromis. Elle réduit la taille du contexte, mais modifie le prompt antérieur, ce qui peut perturber la réutilisation du cache. Un résumé peut également omettre un détail qui devient important ultérieurement.

Les équipes ont besoin de traces en dehors du prompt actif pour cette raison. Asana a enregistré les requêtes, les traces et les résultats dans Command, sa plateforme de livraison logicielle. Les ingénieurs et des agents supplémentaires pouvaient ainsi examiner l’expérience complète.

Un enregistrement durable soutient également une base de connaissances consultable. L’agent actif ne reçoit que le contexte nécessaire à son étape en cours, tandis que les réviseurs conservent l’accès à l’ensemble de la piste de preuves.

Cette séparation aide les équipes à distinguer la mémoire du modèle de la mémoire organisationnelle. Le contexte de travail d’un agent doit rester limité. L’enregistrement de l’expérience doit rester suffisamment détaillé pour reproduire les décisions et examiner les échecs.

GPT-6 Astra a transformé le travail d’évaluation en tâche d’agent

Asana a utilisé un modèle pour améliorer le système et un autre pour exécuter le flux de travail de production optimisé.

GPT-6 Astra a travaillé dans Codex en tant qu’agent de recherche et d’ingénierie. GPT-6.1 Sol a servi comme l’un des modèles d’exécution de l’agent navigateur. Considérer ces rôles comme distincts évite une interprétation trompeuse des résultats.

Hidalgo a défini l’orientation de la recherche et sélectionné les changements proposés qui méritaient d’être testés. GPT-6 Astra a inspecté le code, instrumenté les requêtes, mené des essais préliminaires et identifié les variables influentes.

Le code existant n’avait pas été conçu pour des comparaisons contrôlées. Asana indique que l’agent Codex a refactorisé le système afin qu’un frontend et un backend partagés puissent prendre en charge plusieurs flux de travail expérimentaux en parallèle.

GPT-6 Astra a ensuite lancé l’étude, analysé les données d’utilisation et comparé les résultats. Des sessions de modèles distinctes ont examiné certaines parties du travail, tandis que des humains ont évalué les conclusions et approuvé les changements en production.

Asana estime que le projet aurait nécessité un ou deux mois de travail manuel. Avec le flux de travail Codex, l’enquête a pris environ une semaine.

Cette affirmation émane de l’entreprise plutôt que d’une évaluation indépendante. Elle décrit également un projet d’ingénierie mené par un dirigeant technique connaissant bien le système. Les autres équipes ne devraient pas présumer d’une réduction de délai identique.

Néanmoins, ce flux de travail illustre une évolution importante dans l’utilisation des agents de codage. L’agent ne s’est pas contenté d’implémenter une fonctionnalité à partir d’une spécification finalisée. Il a contribué à concevoir et à exécuter une enquête empirique.

L’enquête a produit des traces, des résultats expérimentaux, des tickets et des pull requests. Ces artefacts sont passés par Command avant que les changements n’atteignent la production de StackAI.

Ce processus compte davantage que l’affirmation selon laquelle un agent IA a effectué l’essentiel du travail mécanique. Sans enregistrements stables, les réviseurs ne peuvent pas déterminer de manière fiable quelle configuration a été exécutée, pourquoi elle a échoué ou si une amélioration signalée a résisté aux modifications du code.

L’étude d’Asana indique que les humains ont défini l’objectif et les normes d’évaluation. Ils ont également examiné les conclusions. L’agent de codage a accru le volume d’expérimentations que l’équipe pouvait exécuter entre ces décisions.

Hidalgo a décrit une routine consistant à fixer un objectif avant de se coucher et à examiner les résultats le lendemain matin. Ce schéma asynchrone transforme le temps d’exécution de l’agent en ressource d’ingénierie.

Il déplace aussi le goulot d’étranglement. Lorsque les expériences deviennent faciles à générer, les humains doivent consacrer davantage de temps à sélectionner des questions valides, vérifier les mesures et écarter les conclusions trompeuses.

Le risque est celui du bruit expérimental automatisé. Un agent peut produire de nombreuses exécutions sans générer de preuves solides. Les tests répétés restent vulnérables à la conception des benchmarks, aux variations cachées des tâches et aux erreurs de notation.

Asana a réduit une partie de ce risque en utilisant une tâche fixe et une réponse de référence préparée indépendamment. L’entreprise a également enregistré les compteurs d’utilisation propres au fournisseur, plutôt que d’estimer la consommation de tokens à partir de la longueur du texte.

L’entreprise n’a effectué que trois répétitions pour la plupart des configurations. Asana précise explicitement que l’étude révèle des tendances générales, et non des différences fiables de quelques points de pourcentage.

Cette réserve est importante. Les comparaisons de 76x et 5x sont suffisamment importantes pour justifier l’attention, mais elles combinent des changements d’architecture et de modèle. Elles n’isolent pas un avantage universel pour GPT-6.1 Sol.

Les résultats internes d’Asana montrent que le modèle B s’est lui aussi nettement amélioré après avoir reçu le flux de travail optimisé. L’architecture représentait une grande partie du gain avant que GPT-6.1 Sol ne réduise davantage les coûts.

Ce que l’affirmation de 76x n’établit pas

Les résultats publiés constituent des preuves d’ingénierie convaincantes, mais ils ne forment pas un benchmark neutre du marché des agents de navigation.

L’étude a utilisé une tâche structurée sur un catalogue public de livres. Chaque exécution suivait le même objectif et collectait le même ensemble de champs. La navigation réelle en entreprise implique souvent une authentification, des mises en page changeantes, des instructions ambiguës et la récupération après des boîtes de dialogue inattendues.

Un flux de travail qui excelle dans l’extraction répétitive pourrait se comporter différemment dans les achats, le support, la conformité ou les opérations internes. Ces tâches peuvent exiger du discernement entre plusieurs systèmes plutôt qu’une collecte répétée sur des pages similaires.

Le test de l’agent de navigation d’Asana a également comparé GPT-6.1 Sol à trois modèles anonymisés. Les lecteurs ne peuvent pas inspecter les paramètres propres aux fournisseurs ni déterminer comment chaque alternative se comporterait après une optimisation indépendante.

Asana indique que les modèles B, C et GPT-6.1 Sol présentaient des tarifs standard comparables pendant l’étude. Le modèle A était présenté comme une alternative moins coûteuse. L’article public ne révèle pas leurs noms.

Cet anonymat empêche le résultat de devenir un classement clair des modèles. Il protège également l’étude contre une dérive vers des comparaisons de fournisseurs qui ne seraient pas étayées par un nombre suffisant d’essais.

Le principal titre compare le flux de travail optimisé de GPT-6.1 Sol à la configuration de production initiale sur le modèle B. Deux variables ont changé simultanément : le modèle et l’architecture de l’agent.

Une comparaison plus ciblée a révélé une réduction des coûts par quatre lorsque la nouvelle politique était appliquée au sein de GPT-6.1 Sol. L’écart restant provenait de la comparaison entre ce système optimisé et l’ancienne référence de production.

Cela n’affaiblit pas le résultat. Cela en modifie la conclusion. L’étude plaide pour la combinaison de modèles performants et d’une architecture tenant compte du contexte, plutôt que pour considérer un changement de modèle comme la solution complète.

L’amélioration du temps d’exécution par cinq s’accompagne de réserves similaires. Certaines exécutions initiales du modèle B ont atteint une limite d’étapes avant d’être terminées. Leur durée mesurée représente donc une borne inférieure pour la tâche complète.

La qualité d’exécution nécessite également une observation continue. Asana rapporte que toutes les exécutions dans les meilleures conditions ont trouvé les faits requis et produit des réponses correctes. Les documents publics n’incluent pas les charges de travail des clients ni les taux d’erreur à long terme.

La réplication indépendante reste limitée, car l’étude complète dépend de l’implémentation et des traces d’Asana. L’entreprise a partagé ses méthodes et une étude plus complète, mais les équipes externes ont toujours besoin de leurs propres suites de tâches.

L’acquisition de StackAI par l’entreprise crée également un intérêt commercial dans ce résultat. Asana a finalisé l’acquisition de StackAI en mai 2026 afin d’étendre les flux de travail d’agents intersystèmes.

OpenAI a un intérêt similaire à montrer comment GPT-6 Astra et GPT-6.1 Sol prennent en charge les agents d’entreprise. Ces deux sources primaires fournissent des détails techniques précieux, mais aucune ne représente un audit indépendant du secteur.

Les conditions opérationnelles peuvent également modifier le résultat. La disponibilité du cache a une durée de vie limitée. Des clients concurrents peuvent avoir des historiques différents, et un contexte personnalisé peut réduire la quantité de contenu partagé.

Les exigences de confidentialité peuvent limiter le contenu qui entre dans le contexte du modèle. Les équipes de sécurité ont également besoin de contrôles pour les captures d’écran, les identifiants, les dossiers clients et les informations sensibles collectées durant la navigation.

La mise en cache ne supprime pas ces obligations. Elle modifie les comportements de calcul et de facturation, mais pas le besoin de gouvernance des données. Les équipes ont toujours besoin de politiques de conservation, de contrôles d’accès, de pistes d’audit et de mécanismes de gestion des défaillances.

La bonne conclusion est donc conditionnelle. Asana a identifié une optimisation à forte valeur pour un agent de navigation spécifique et l’a mise en production. Les autres équipes devraient considérer le mécanisme comme une hypothèse testable.

Le prochain test portera sur les performances dans les flux de travail réels des clients

Les trois prochains signaux indiqueront si le résultat d’Asana devient un modèle opérationnel réutilisable ou demeure une solide étude de cas interne.

Le premier signal est une couverture d’évaluation plus large. Asana affirme développer des outils permettant aux clients et aux équipes internes de comparer le coût, le temps d’exécution et la qualité des réponses lors de la configuration d’agents.

Ces évaluations doivent inclure des tâches allant au-delà de l’extraction structurée de catalogues. Des suites de tests utiles devraient intégrer des sites web changeants, des applications authentifiées, des échecs partiels, des parcours de navigation longs et des instructions dont les points d’arrêt sont ambigus.

Si la même politique d’historique améliore ces flux de travail, l’argument en faveur d’une optimisation guidée par l’architecture devient plus solide. Si les gains diminuent, la configuration choisie par Asana pourrait être étroitement liée à l’extraction répétitive.

Le deuxième signal est la preuve issue de l’adoption en production. Asana a déjà déployé les changements de navigation dans StackAI, mais n’a pas publié de résultats agrégés pour les clients.

Le taux d’achèvement devrait compter davantage que le coût par appel. Une requête moins chère offre peu de valeur si les clients doivent relancer des tâches ou corriger manuellement des résultats incomplets.

Les équipes devraient également suivre la part des entrées servies depuis le cache, la durée médiane des tâches, les échecs dus aux limites d’étapes et les taux d’intervention humaine. Ces mesures indiquent si la conception optimisée résiste à un trafic de production variable.

Le troisième signal réside dans la réaction des fournisseurs de modèles concurrents et des plateformes d’agents. La mise en cache des prompts est devenue une fonctionnalité produit, mais l’architecture applicative détermine si les développeurs peuvent en bénéficier.

Les fournisseurs peuvent rivaliser grâce à une conservation du cache plus longue, de meilleurs diagnostics, des tarifs plus bas pour les entrées mises en cache et des données d’utilisation plus claires. Les frameworks d’agents peuvent exposer des politiques d’historique sans contraindre chaque client à développer une instrumentation sur mesure.

OpenAI présente GPT-6.1 Sol comme un modèle adapté à un travail agentique performant, à un coût opérationnel inférieur à celui de GPT-6 Astra. L’étude d’Asana offre à ce positionnement un exemple d’application concret.

Toutefois, la pression concurrentielle la plus forte pèse sur les équipes de logiciels d’agents. Les clients s’attendront de plus en plus à ce que les plateformes optimisent automatiquement le coût total des tâches, plutôt que de n’exposer qu’un sélecteur de modèles.

Une plateforme mature devrait recommander des limites de contexte en fonction du comportement observé. Elle devrait identifier les modifications qui brisent le cache, comparer les politiques et avertir lorsque l’élagage amène l’agent à revisiter des pages antérieures.

Elle devrait également conserver suffisamment de preuves externes pour que les humains puissent auditer le résultat. Un agent de navigation a besoin d’une mémoire de travail limitée, tandis que l’organisation a besoin d’un registre opérationnel complet.

Asana prévoit d’intégrer des tests similaires dans son système d’évaluation. L’entreprise utilise également GPT-6 Astra dans Codex pour naviguer dans les fonctionnalités du produit, essayer différentes entrées et signaler des bugs aux réviseurs humains.

Cette extension élargit le récit au-delà d’un seul agent de navigation. Asana teste si des agents d’ingénierie peuvent évaluer en continu d’autres agents et fonctionnalités de produit.

L’opportunité est claire. L’expérimentation automatisée peut évaluer davantage de configurations qu’une petite équipe d’ingénierie ne pourrait en tester manuellement. Elle peut également raccourcir le chemin entre l’analyse des traces et des changements de code examinés.

La contrainte est tout aussi claire. L’attention humaine devient la ressource rare lorsque les agents peuvent générer continuellement des expériences, des conclusions et des correctifs. Les équipes doivent décider quels résultats méritent confiance et exposition en production.

Pour les développeurs, l’action immédiate consiste à mesurer des tâches complètes plutôt que des appels isolés. Enregistrez les ratios d’accès au cache, la qualité d’achèvement, le temps d’exécution, les nouvelles tentatives et le travail de correction humain dans des conditions réalistes.

Pour les acheteurs d’entreprise, demandez aux fournisseurs comment leurs agents gèrent des historiques croissants. Le seul nom d’un modèle ne révèle pas si le système environnant préserve un contexte utile ou paie à répétition pour le traiter.

Pour les travailleurs du savoir, ce changement promet une automatisation de navigation plus rapide et plus performante. Sa valeur dépendra de la capacité des agents à conserver les faits nécessaires sans exposer de données sensibles ni dériver au fil d’étapes superflues.

Le résultat de l’agent de navigation d’Asana plaide de manière convaincante pour que la conception du contexte accompagne désormais la sélection du modèle dans chaque évaluation d’agent. La prochaine question est de savoir si cette leçon tient dans les flux de travail désordonnés que les clients souhaitent réellement automatiser.