Une nouvelle étude de Harvard et Perplexity, "How AI Agents Reshape Knowledge Work: Autonomy, Efficiency, and Scope" (Jeremy Yang de Harvard avec Kate Zyskowski, Noah Yonack et Jerry Ma de Perplexity, arXiv 2606.07489), fait quelque chose que le discours sur les agents skip la plupart du temps : ça mesure, à partir de données de production, combien de temps les agents roulent vraiment de façon autonome. Le numéro headline c'est 26 minutes de temps d'exécution machine par session pour Perplexity Computer, l'orchestrateur agentic, contre 33 secondes pour Perplexity Search, le moteur de réponse conversationnel, un gap de 48x. Les médianes sont plus serrées mais racontent la même histoire, 9 minutes contre 14 secondes, un gap de 40x. La valeur ici c'est pas le compte de minutes spécifique, c'est que la mesure vient des mêmes users qui hit deux produits sur la même fenêtre de 90 jours (27 février au 27 mai 2026), matchés en 10 000 paires de sessions avec cosine similarity au-dessus de 0,99, donc la comparaison isole la différence agentic-versus-conversational plutôt que de la confondre avec qui demande ou ce sur quoi ils demandent. Les sessions Computer étaient gated sur l'invocation réelle des "do" tools, exécution de code, actions de browser, écritures de fichier, connector calls, donc les 26 minutes c'est du travail machine, pas du user think-time.

La méthodologie c'est la partie que les builders devraient prendre au sérieux, parce que c'est un template pour mesurer tes propres agents honnêtement. La plupart des claims d'autonomie d'agent sont des vendor demos : un seul run impressionnant, une session de 35 heures cherry-pickée, un benchmark designé pour être passé. Cette étude à la place prend le counterfactual au sérieux. Elle estime qu'un professionnel utilisant Search seul a besoin de 269 minutes par tâche, pendant que Computer-plus-humain a besoin de 36 minutes, un saving de 87% de temps et 94% de coût, et ensuite elle nomme le breakeven honnêtement : un professionnel qui peut compléter toutes les étapes manuelles en moins de 20 minutes ne bénéficie pas, parce que l'overhead de l'agent ne vaut pas la peine en dessous de ce seuil. C'est un framing utile et inhabituellement candide, l'agent gagne sur les tâches assez longues pour amortir son coût de setup et d'oversight, et perd sur les courtes, ce qui est exactement le calcul qu'un builder devrait rouler avant d'agentifier un workflow. Le signal de qualité pointe dans la même direction : les sessions Computer ont montré un taux de dissatisfaction de 1,3% contre 2,9% pour Search, une réduction de 55%, donc les runs autonomes plus longs n'achetaient pas de la vitesse au coût de la correctness en agrégat.

Le finding qui ouvre une question plus large que le benchmark c'est à propos du scope, et c'est la partie qui vaut de s'asseoir avec. Quand les users avaient un agent disponible, ils ne faisaient pas juste le même travail plus vite, ils tentaient du travail différent. 76% des queries agentic ont atteint une cognition Bloom d'ordre supérieur (analyser, évaluer, créer) contre 55% pour le conversationnel, et 59% ont traversé des frontières occupationnelles contre 50%, voulant dire que le monde atteignait au-delà de leur propre domaine dans des tâches qu'ils ne tenteraient pas normalement. C'est l'effet de second ordre que le numéro de 26 minutes undersell. L'autonomie ne fait pas que compresser le temps qu'une tâche connue prend, ça change l'ensemble des tâches qu'une personne considère worth starting, parce que le coût de tenter quelque chose d'ambitieux ou en dehors de ton expertise drop quand un agent peut porter les 26 minutes d'exécution. La courbe d'adoption en dessous c'est steep, les queries Computer cumulatives ont grossi à 84x leur total de première semaine à travers la fenêtre d'étude, donc le changement de comportement c'est pas un artefact de lab, c'est ce que le monde a fait quand la capability était vraiment dans leurs mains. Ça reframe toute la conversation agent-autonomy de "combien de temps ça peut rouler" à "qu'est-ce que l'autonomie pas chère fait à la shape du travail que le monde choisit," et cette deuxième question c'est celle avec la plus longue traîne.

Lundi matin, si tu décides si agentifier un workflow : le breakeven sous-20-minutes c'est le numéro à internaliser, les agents gagnent leur overhead sur les tâches long-horizon multi-step et perdent sur les lookups rapides, donc cible les premières et laisse les dernières comme des plain calls. Si tu mesures tes propres agents : ce paper c'est une méthodologie à copier, matche les sessions agentic et conversationnelles des mêmes users, gate sur l'invocation réelle de tool, mesure le temps d'exécution machine plutôt que le wall-clock ou les vendor demos, et estime le coût counterfactual du chemin human-only, parce que c'est ce qui transforme "notre agent est impressionnant" en "notre agent sauve X minutes au-dessus d'un seuil de Y minutes." Si tu tracks les threads agent-runtime, c'est le floor empirique sous l'axe persistence-in-time qu'on a watché les vendors asserter (les runs autonomes de 35 heures, les tâches schedulées always-on), maintenant grounded dans ce que les users de production ont vraiment eu, des dizaines de minutes par session, pas des heures, mais assez pour changer quelles tâches ils tentaient. Et si tu penses au-delà de la build sheet, le finding de scope c'est celui à garder : la conséquence intéressante des agents autonomes peut ne pas être le travail qu'ils font, mais le travail plus ambitieux que le monde commence à tenter une fois que le coût d'exécution de l'ambition tombe.