IronBee construit un agent de navigateur qui se passe de LLM et vérifie la commande lui-même

La démonstration est courte et précise. D'après le billet publié par IronBee, Express s'est connecté, a ajouté un produit, a saisi une adresse et une carte, puis a attendu que la page de commande affiche COMPLETED : neuf actions, 6,7 secondes.

Le moteur de décision s'appelle Jev, un modèle de TypeSafe qui répond à des questions à choix multiples typées. IronBee assure qu'aucun LLM n'intervient dans la boucle. Chaque étape est un appel à Jev, qui renvoie l'option retenue, une probabilité pour chaque option et un score de confiance. Aucun texte n'est généré et aucune capture d'écran n'est lue. Une décision prend environ 300 ms depuis la Turquie, l'essentiel de ce temps étant le trajet vers le serveur. Le coût, voilà ce que l'entreprise met en avant. L'entrée est facturée 0,042 dollar par million de tokens et la sortie est gratuite. IronBee affirme que cela ramène un paiement entièrement rejoué, jugement et revue compris, à 0,00054 dollar. La réponse ne peut être qu'une clé prise dans la liste envoyée par le harnais, si bien que la sortie du modèle ne devient jamais un sélecteur, une coordonnée ou un script. Une exécution ne peut cliquer que sur ce qui était déjà à l'écran.

C'est un pari plus étroit que celui des agents pilotés par captures d'écran que d'autres livrent. Reste à voir si l'approche tient sur des pages qui n'offrent pas une liste numérotée propre de contrôles.

L'échec qui a vendu la conception

La vitesse est facile à filmer. L'exécution la plus instructive du billet est un paiement qui a mal tourné. La page affichait « Order placed successfully! » et l'API de commande renvoyait 200, mais la charge utile de cette réponse indiquait FAILED. L'agent d'IronBee a marqué l'exécution comme échouée en 7,57 secondes, sur 8 actions et 9 décisions. Il a pointé la réponse de l'API, puis la ligne de journal du backend : notification-service, Order #131 Could Not Be Processed, Reason: Insufficient inventory.

La page disait « Order placed successfully! ». L'API de commande répondait 200, mais la commande à l'intérieur indiquait FAILED.

Personne n'avait écrit d'assertion pour cela, précise le billet. L'étape de jugement est elle-même une question posée à Jev : l'objectif a-t-il tenu, et quelles preuves le soutiennent. Tous les chiffres du compte rendu viennent des propres exécutions d'IronBee entre le 21 septembre et le 1er octobre 2026. La première version a tourné le 24 septembre. Elle s'est connectée et a ajouté un produit au panier 3 fois sur 3, en 2,85 à 3,05 secondes.

Cette prudence compte, car l'essentiel de ce qui s'est publié cette semaine sur les agents de navigateur n'est pas un banc d'essai neutre. Une implémentation de référence de 400 lignes signée xhluca montre l'architecture inverse. Elle donne à Gemini 3.8 Flash des captures d'écran et les commandes du navigateur en 394 lignes de Python, dont une exécution enregistrée qui réserve un atelier et vérifie la confirmation. Les deux approches prétendent contrôler le résultat. Une seule paie à la capture d'écran.

La vérification est le thème de la semaine

Le même argument revient dans les outils de programmation. Dotpals, un compagnon de bureau open source pour Claude Code, Codex et Cursor, lit les résultats de tests dans la sortie des commandes plutôt que dans les dires de l'agent. Il renvoie l'agent au travail quand les tests échouent, et il repère aussi un test modifié juste pour le faire passer. Le texte d'Ian Maurer cite l'équipe OpenClaw supprimant environ 400 000 lignes de ses propres tests avec peu de changement dans la couverture. Il plaide pour des tests outside-in qui décrivent le comportement de l'utilisateur, plutôt qu'un tas croissant de tests unitaires. Threadnote a mené une petite étude appariée sur cinq dépôts publics. Elle rapporte 65,62 % de tokens de cycle en moins par achèvement vérifié et 46,14 % de temps en moins avec un transfert stocké, la vérification passant sur 5 tâches sur 5 contre 4 sur 5 avec les seuls fichiers. L'entreprise précise qu'il s'agit de sa propre étude, sur un seul modèle et sur la version 5.1.0-beta.2, et non d'une évaluation indépendante.

Sa formule sur le problème est directe : « Done » est une phrase qu'un agent peut produire, ce n'est pas un résultat de test.

La durabilité attire aussi l'attention. Pi Durable, cadre expérimental d'Arendelle publié avec Pi 1.0, enregistre des points de contrôle des conversations pour qu'un nouveau processus puisse les reprendre. Il ne rejoue un appel d'outil interrompu que si l'outil déclare le rejeu sans danger, car renvoyer un paiement deux fois n'équivaut pas à relancer une recherche. Ostoyae, un exécuteur de graphes pour agents de programmation, fait tourner chaque tâche dans son propre worktree git. Il ne compte le travail qu'une fois qu'une commande de contrôle passe sur une copie fraîche.

Pourquoi les entreprises calent

L'écart entre démonstrations et déploiements se mesure. Une enquête MIT Technology Review Insights auprès de 300 dirigeants des données et de la technologie constate qu'en moyenne, seuls environ 34 % des projets d'IA agentique des organisations atteignent la production. L'enquête a été réalisée par son pôle de contenus sur mesure, et non par sa rédaction. La fragmentation des données arrive en tête des obstacles cités à l'extension de l'accès des agents aux connaissances, à 55 %.

Du côté de la recherche, un article révisé le 1er octobre présente StructMemEval, un banc d'essai qui mesure si les agents organisent leur mémoire à long terme, et pas seulement s'ils rappellent des faits. Ses auteurs rapportent que les LLM augmentés par récupération échouent sur des tâches comme les registres de transactions et les listes de choses à faire. Ils ajoutent que les modèles récents ne reconnaissent pas toujours la structure requise sans invite.

Rien de tout cela ne fait d'un paiement en 6,7 secondes la partie difficile. Le billet d'IronBee consacre l'essentiel de sa longueur à ce qui a cassé. Sa thèse centrale est étroite : choisir dans une liste, contrôler le choix, et juger l'exécution sur des preuves plutôt que sur la bannière de succès de la page. C'est une promesse plus modeste qu'un agent qui lit le web, et plus facile à tester.