312 actions, deux requêtes : Droid 1.0 repense le fonctionnement des agents IA

Factory fait évoluer Droid avec l'exécution programmable des outils, réduisant les requêtes, les coûts et les délais sur les tâches complexes.

Déplacer 151 tickets dans Linear, vérifier chaque modification et exécuter 312 appels d'outils : une opération qui nécessitait jusqu'à 36 requêtes au modèle peut désormais être réalisée en seulement deux. Cette démonstration résume l'évolution de Droid 1.0, le nouvel environnement d'exécution agentique développé par Factory. Plutôt que d'améliorer le modèle d'intelligence artificielle lui-même, l'entreprise intervient sur la manière dont celui-ci organise et exécute ses actions. Une approche destinée aux projets logiciels complexes, où les interactions successives avec les outils peuvent rapidement multiplier les coûts et les délais. Des centaines d'actions dans une seule requête

L'évolution majeure repose sur le Programmatic Tool Calling (PTC), désormais utilisé par défaut avec plusieurs modèles compatibles. Dans un fonctionnement classique, un agent sollicite ses outils successivement, récupère leurs réponses, puis interroge à nouveau le modèle pour déterminer l'étape suivante. Chaque interaction enrichit l'historique de la conversation et augmente les informations à traiter.

Le nouveau mode Script de Droid modifie cette organisation. Le modèle écrit un programme JavaScript capable d'orchestrer plusieurs centaines d'appels d'outils au cours d'une même exécution. Les opérations peuvent s'enchaîner, être conditionnées aux résultats précédents ou fonctionner simultanément lorsqu'elles sont indépendantes. Les données intermédiaires restent dans le programme, tandis que le modèle ne récupère que les informations nécessaires à la poursuite de son travail. Le code s'exécute dans un environnement isolé, sans accès direct aux fichiers, au réseau ou au système en dehors des outils autorisés.

Dans l'exemple des 151 tickets Linear, les 312 appels restent nécessaires pour déplacer et contrôler les éléments. Ce sont les échanges avec le modèle qui diminuent : Factory estime qu'une exécution classique aurait mobilisé environ 3,1 millions de tokens en entrée, contre 61 000 avec Script. Ces chiffres proviennent d'une comparaison interne dans laquelle le scénario traditionnel est modélisé, et non d'une mesure directe de deux exécutions identiques.

La même méthode a permis d'inspecter 5 384 tâches d'intégration continue réparties sur 547 exécutions. Grâce à 550 appels d'outils, l'agent a identifié 41 échecs tout en ne transmettant au modèle qu'un résumé de cinq valeurs. Moins de 0,1 % des résultats bruts ont ainsi intégré son contexte de travail. Des performances comparées à Codex et Claude Code

Les évaluations réalisées sur Terminal-Bench 4 permettent à Factory de mesurer les différences entre Droid et plusieurs environnements concurrents, notamment Codex, Claude Code, Cursor, Devin et OpenCode. Les essais ont été effectués du 23 au 28 octobre 2026, avec les mêmes modèles et trois répétitions par tâche.

Avec GPT-6.1 Sol, Droid atteint un taux de réussite de 57,6 %, contre 54 % pour Codex, pour un coût inférieur de 12 % sur les tâches comparées. Avec Claude Opus 5.5, il obtient 65,2 % et un coût moyen de 4,73 dollars par tâche réussie. Selon les résultats publiés par Factory, les économies peuvent atteindre 24 % face à certains environnements concurrents.

La rapidité présente toutefois des différences selon les configurations. Sur Claude Opus 5.5, Droid réalise les tâches réussies 26 % plus rapidement que Claude Code et utilise 17 % de tokens en moins. Avec GPT-6.1 Sol, il consomme 12 % de tokens en moins que Codex, mais nécessite 10 % de temps supplémentaire. Ces mesures concernent les tâches réussies par les deux environnements comparés, selon le protocole de Factory, et ne constituent pas une évaluation indépendante de leurs performances générales. Une usine à agents pour améliorer les agents

Derrière ces évolutions se trouve une infrastructure interne baptisée Agent Factory. Elle automatise une partie du travail d'optimisation de Droid en analysant les échecs rencontrés lors des benchmarks et les difficultés observées dans les sessions réelles. Des agents identifient les problèmes récurrents, proposent des modifications et les soumettent à des expérimentations contrôlées sur différentes familles de modèles.

Les ingénieurs conservent la décision finale sur les changements intégrés au produit. Cette méthode permet notamment d'adapter les instructions, les descriptions des outils et les mécanismes d'exécution sans dépendre d'un fournisseur unique. Droid peut ainsi fonctionner avec plusieurs modèles propriétaires ou à poids ouverts, tandis que Factory Router sélectionne automatiquement une configuration en fonction des besoins.

D'autres optimisations concernent la gestion du contexte. Entre les versions 0.170.0 et 0.250.0, les instructions et informations initiales transmises au modèle sont passées de 20 887 à 13 055 tokens, soit une réduction de 37 %. Les outils rarement utilisés sont désormais chargés à la demande, et la conservation du cache limite le retraitement des informations déjà transmises. Factory indique que 98 % des tokens d'entrée d'une requête typique sont lus depuis le cache, sur la base de sa télémétrie de production. Un agent indépendant du modèle qui l'anime

L'amélioration porte également sur l'expérience d'utilisation. Entre les versions d'août et d'octobre, le temps médian nécessaire pour afficher l'interface est passé de 1 839 à 488 millisecondes. Le démarrage d'une session, la gestion de plusieurs agents simultanés et la fermeture de l'application ont également fait l'objet d'optimisations.

Droid 1.0 est accessible sur macOS et Windows, ainsi que depuis une interface en terminal. Les développeurs peuvent aussi intégrer ses capacités dans leurs applications grâce au Droid SDK, qui permet notamment de gérer des sessions, de suivre leur exécution et de connecter des outils via le Model Context Protocol.

Cette évolution illustre une distinction importante dans le développement des agents IA : les capacités du modèle et l'efficacité du système qui l'exploite ne progressent pas nécessairement au