Les harnais allégés et les agents exécutant du code sont mieux adaptés aux tâches ouvertes, pour lesquelles une orchestration trop rigide peut limiter les performances du modèle.
L’exécution de code et le cloisonnement sont donc désormais des enjeux architecturaux fondamentaux pour les systèmes agentiques.
Le SDK Agents réduit la complexité et le volume de code nécessaires pour créer des agents exécutant du code, jusqu’à un facteur 6 lors de nos tests.
Pendant longtemps, les progrès des systèmes d’agents ont reposé sur l’amélioration de l’orchestration : meilleurs prompts, interfaces d’outils, gestion du contexte et flux de contrôle plus stricts. Mais à mesure que les agents de codage gagnent en capacités, cet équilibre commence à évoluer.
Dans de nombreux workflows ouverts, le goulet d’étranglement n’est plus la boucle de l’agent elle-même, mais la couche d’exécution : le bac à sable où le modèle écrit du code, exécute des commandes, examine les résultats et procède par itérations. À mesure que le raisonnement au niveau des tâches se déplace vers cet environnement, l’orchestration qui l’entoure doit se simplifier afin que le modèle puisse exprimer tout son potentiel.
C’est précisément cette évolution que permet la nouvelle version du SDK Agents. Lors de nos tests en accès anticipé, nous avons constaté qu’au lieu d’ajouter une couche supplémentaire de logique de framework, cette version rend la couche d’exécution plus modulaire et composable, afin que le reste du système demeure léger.
En ingénierie des harnais, la tendance consiste désormais à réduire le harnais à sa forme efficace minimale. À un niveau général, le harnais est le logiciel qui entoure le modèle : la couche qui gère le contexte, les outils, le flux de contrôle et les boucles de rétroaction afin que le modèle puisse travailler de façon fiable.
Ces dernières années, de nombreuses améliorations des performances des agents sont venues du renforcement de cette couche. De meilleurs outils, une mémoire et une récupération plus performantes, une décomposition plus explicite et une orchestration plus stricte ont souvent rendu les systèmes plus fiables et plus performants. Dans ce paradigme, progresser consistait principalement à intégrer davantage de logique métier dans le logiciel entourant le modèle.
Cette tendance s’atténue désormais, du moins pour une catégorie de tâches ouvertes. Un nombre croissant de projets et d’articles suggèrent que les performances ne s’améliorent pas toujours lorsque le harnais devient plus directif. Dans le codage assisté, les tâches de longue durée, l’utilisation du navigateur et les tâches à contexte long, le même schéma se répète : dès que le modèle est suffisamment intelligent, imposer une structure de tâche excessive dans le logiciel environnant peut devenir une contrainte plutôt qu’un avantage.
Le rôle du harnais évolue donc. Au lieu d’essayer d’anticiper la tâche au moyen d’une orchestration rigide, le harnais sert de plus en plus à fournir une surface d’exécution claire : un bac à sable dans lequel le modèle peut examiner l’état, exécuter du code, corriger les erreurs et adapter sa propre approche, tout en restant encadré par les interfaces et les mécanismes de protection du système. Cette évolution est proche de celle décrite par Andrej Karpathy dans Software Engineer 3.0 : une partie de la logique auparavant intégrée au logiciel remonte dans le « prompt ».
Cela ne signifie pas que les systèmes d’agents doivent supprimer toute structure. De nombreuses tâches bénéficient encore de workflows explicites, d’heuristiques et de garde-fous déterministes, surtout lorsqu’elles sont ciblées, traitées à grande échelle ou assorties d’un critère de réussite clair. Comme nous l’expliquions dans notre précédent article sur les heuristiques de conception des systèmes agentiques, une orchestration robuste demeure importante lorsqu’un flux logique fiable est à la fois possible et souhaitable.
Pour les tâches ouvertes, les priorités évoluent. L’enjeu consiste moins à concevoir des couches d’orchestration toujours plus élaborées qu’à créer des environnements d’exécution suffisamment simples, observables et modulaires pour que le modèle puisse y travailler efficacement.
Dès qu’un agent peut lire des fichiers, écrire du code, exécuter des commandes shell et lancer des tâches de longue durée, le défi d’ingénierie change. La difficulté ne se limite plus à l’optimisation des prompts ou au routage des outils. Le fait que l’agent opère désormais sur un système réel rend ces agents nettement plus puissants, mais aussi plus sensibles, car ils élargissent la surface de sûreté et de sécurité. Par exemple, un agent capable d’exécuter du code peut entreprendre des actions nuisibles si son environnement est mal isolé (voir le Sandbox Bench de l’AISI).
Le cloisonnement devient donc un enjeu critique dans les frameworks d’agents. Dans les systèmes antérieurs, l’exécution était souvent considérée comme un ajout : un outil greffé au harnais. Mais dès que l’exécution devient avec état, distante ou de longue durée, cette approche commence à montrer ses limites. La gestion du bac à sable lui-même, de son cycle de vie, de son état, de ses interfaces et de son articulation avec la boucle de l’agent devient rapidement un problème de conception de système à part entière. C’est l’une des raisons pour lesquelles un nombre croissant de fournisseurs proposent désormais des environnements gérés pour l’exécution de code, notamment l’API Container et l’outil shell d’OpenAI, Modal, Cloudflare, Daytona, E2B, etc.
Cette séparation est importante, car l’exécution de code exige une isolation plus forte et un contrôle plus strict de l’environnement d’exécution que le reste du harnais. En pratique, des agents exécutant du code et mal implémentés peuvent créer trois risques critiques pour l’entreprise : des dépenses de calcul incontrôlées, des actions destructrices sur les systèmes internes et l’exposition d’informations sensibles. Grâce à une conteneurisation, une isolation et des protections d’exécution adaptées, ces risques peuvent être ramenés à un niveau acceptable pour des déploiements réels.
On peut se représenter cela comme le fait de donner à l’agent son propre espace de travail hermétique plutôt que les clés de tout le bureau. Il peut toujours effectuer un travail utile dans cet espace, mais uniquement à l’intérieur de limites clairement définies. Vous pouvez plafonner ses ressources de calcul, limiter les systèmes et fichiers auxquels il peut accéder et contrôler les informations qui lui sont accessibles dès le départ.
Cela n’élimine pas entièrement le risque, mais transforme le problème d’« un agent en liberté dans votre infrastructure » en celui d’« un agent opérant dans un environnement contrôlé ». Si cette couche doit devenir un composant standard des systèmes d’agents, elle doit être prise en charge nativement par le framework. Le bac à sable devient ainsi une couche d’exécution modulaire dotée de primitives portables que les développeurs peuvent adopter rapidement, transférer entre fournisseurs et mettre à l’échelle sans remanier constamment la logique de l’agent.
Dès qu’un agent exécute du code, le bac à sable doit lui aussi être orchestré. Passer d’une preuve de concept locale à une exécution distante, à plusieurs backends ou à des sessions de longue durée augmente exponentiellement la charge opérationnelle. Il faut une méthode cohérente pour créer et arrêter les environnements, les suspendre et les reprendre, enregistrer des instantanés de leur état, se reconnecter ultérieurement et gérer l’ensemble chez différents fournisseurs.
Rien de tout cela n’est particulièrement prestigieux sur le plan conceptuel, mais c’est important en pratique. C’est précisément le type d’infrastructure qui devient pénible lorsque chaque équipe reconstruit de zéro un pipeline agentique, surtout s’il n’est pas intégré au framework d’agents…
C’est là qu’une meilleure prise en charge par le framework devient importante. Nous avons bénéficié d’un accès anticipé au nouveau SDK Agents d’OpenAI et l’avons utilisé pour créer nous-mêmes des agents cloisonnés. Ce qui nous a frappés, c’est le changement de priorité architecturale : le SDK traite l’exécution comme une couche de premier ordre plutôt que comme un outil périphérique. En pratique, cela permet de lancer un agent cloisonné, de prendre un instantané d’un bac à sable ou de reprendre l’exécution avec moins de code (environ 6 fois moins dans certains de nos tests), puis de changer de backend sans réécrire la logique environnante de l’agent.
Cette séparation plus nette des responsabilités permet au harnais de rester centré sur le raisonnement, le contexte et le workflow. La couche d’exécution peut se concentrer sur l’isolation, la portabilité et l’état d’exécution. Cette abstraction facilite la création d’agents de codage à la fois plus performants et plus évolutifs, capables de passer d’une exécution locale à une exécution distante, de prendre en charge des tâches plus longues et de changer de backend d’exécution sans imposer une refonte de l’ensemble du système.
À mesure que la logique des tâches passe du harnais au modèle, une partie de la complexité du système se déplace avec elle, vers la couche d’exécution. L’exécution de code et le cloisonnement sont désormais des enjeux architecturaux fondamentaux pour les systèmes agentiques, en particulier pour les tâches ouvertes et celles nécessitant beaucoup de codage. Il est désormais aussi important de concevoir le pipeline agentique que l’environnement dans lequel l’agent peut agir de manière sûre, fiable et durable.
C’est pourquoi les abstractions de haut niveau autour de l’exécution cloisonnée sont importantes. Le nouveau SDK Agents d’OpenAI va dans ce sens en traitant l’exécution comme une couche modulaire du système : portable entre les backends, avec état pour les tâches de longue durée et suffisamment simple à utiliser pour éviter de reconstruire la même infrastructure à chaque nouvelle configuration.
Plus généralement, la prochaine génération de frameworks d’agents se distinguera probablement moins par la quantité de logique d’orchestration ajoutée que par sa capacité à structurer les environnements d’exécution dont les agents dépendent de plus en plus.