OpenAI déploie une exécution en environnement “sandbox” pour aider les entreprises à automatiser des workflows tout en gardant un contrôle maîtrisé des risques.
Jusqu’ici, faire passer des systèmes du prototype à la production posait des compromis : les frameworks indépendants du modèle apportaient de la flexibilité, mais exploitaient mal les capacités des modèles les plus avancés. Les SDK liés au fournisseur restaient plus proches du modèle, mais offraient souvent une visibilité insuffisante sur le “contrôle” du système.
Les API d’agents managés ont aussi simplifié le déploiement, tout en limitant fortement où ces systèmes pouvaient s’exécuter et comment ils accédaient aux données sensibles. Pour répondre à cela, OpenAI met à jour le Agents SDK avec une infrastructure standardisée : un “harness” natif adapté au modèle et une exécution en sandbox.
Cette approche améliore la fiabilité, notamment quand des tâches nécessitent la coordination entre plusieurs systèmes. Oscar Health illustre ce gain d’efficacité sur des données non structurées.
Le groupe de santé a testé la nouvelle infrastructure pour automatiser un processus lié aux dossiers cliniques, que les solutions précédentes géraient de façon trop peu fiable. L’objectif était d’extraire des métadonnées correctes tout en comprenant précisément les limites de chaque séquence de soins dans des documents médicaux complexes. En automatisant cette tâche, l’établissement peut analyser plus rapidement les historiques des patients, accélérer la coordination des soins et améliorer l’expérience globale.
Rachael Burns, Staff Engineer et AI Tech Lead chez Oscar Health, explique : « Le Agents SDK mis à jour a rendu notre automatisation de workflow clinique directement exploitable en production. La vraie différence, ce n’était pas seulement d’extraire les bonnes métadonnées, mais aussi de bien comprendre les frontières de chaque rencontre dans des dossiers longs et complexes. »
OpenAI renforce les workflows grâce à un “harness” natif
Pour déployer de tels systèmes, les équipes doivent gérer la synchronisation des bases vectorielles, réduire le risque d’hallucinations et optimiser un calcul coûteux. Sans cadre standard, elles finissent souvent par construire des connecteurs sur mesure difficiles à maintenir.
Le “harness” natif réduit ces frictions : gestion configurable de la mémoire, orchestration compatible avec les sandbox, et outils de type “filesystem” (inspirés de Codex). Les développeurs peuvent aussi intégrer des primitives standardisées, comme l’usage d’outils via MCP, des instructions via AGENTS.md et des modifications de fichiers via apply_patch.
En plus, des mécanismes de “progressive disclosure” (via skills) et l’exécution de code via un outil de shell permettent d’enchaîner des étapes complexes de manière plus structurée. L’objectif est de limiter le temps consacré à l’infrastructure de base afin de se concentrer sur la logique métier.
Pour intégrer un programme autonome dans un système existant, il faut un routage précis. Quand l’agent manipule des données non structurées, il dépend fortement de mécanismes de récupération (retrieval) pour obtenir le contexte utile.
Le SDK introduit donc une abstraction de Manifest : elle standardise la description de l’espace de travail (montage de fichiers locaux, dossiers de sortie). Les environnements peuvent être reliés à des stockages d’entreprise (AWS S3, Azure Blob Storage, Google Cloud Storage, Cloudflare R2), afin que l’agent sache où trouver les entrées et où écrire les sorties durant l’exécution.
Cette prévisibilité évite que le système interroge des “data lakes” non filtrés : il reste limité à des fenêtres de contexte validées. Les équipes de gouvernance peuvent ensuite suivre la provenance de chaque décision automatisée, depuis les prototypes jusqu’au déploiement en production.
Sécurité : exécution en sandbox et séparation des couches
Le SDK supporte nativement l’exécution en sandbox : les programmes tournent dans des environnements contrôlés, avec les fichiers et dépendances nécessaires. Les équipes n’ont plus besoin de construire manuellement toute la couche d’exécution : elles peuvent utiliser des sandboxes construites sur mesure ou des options intégrées, selon les fournisseurs pris en charge (notamment Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, Vercel).
La réduction du risque est centrale : tout système qui lit des données externes ou exécute du code généré doit être considéré comme exposé à des attaques par prompt-injection et à des tentatives d’exfiltration.
OpenAI répond à cela en séparant le “contrôle” (control harness) du calcul (compute). Les identifiants restent isolés, donc hors des environnements où s’exécute le code généré. Ainsi, une commande malveillante injectée ne peut pas accéder au plan de contrôle ni voler des clés API sensibles, ce qui limite les mouvements latéraux au sein du réseau de l’entreprise.
Cette séparation aide aussi à limiter les coûts : si une tâche échoue en cours de route (timeouts réseau, crash de conteneur, limites d’API), l’agent peut reprendre sans repartir de zéro. Grâce à des mécanismes de snapshotting et rehydration, l’état peut être restauré dans un environnement neuf et la tâche reprendre depuis le dernier point de contrôle.
Pour passer à l’échelle, l’architecture permet d’allouer dynamiquement des ressources : lancer une ou plusieurs sandboxes selon la charge, isoler des sous-agents et paralléliser des exécutions dans plusieurs conteneurs.
Ces nouveautés sont disponibles via l’API, avec une tarification standard basée sur les tokens et l’usage des outils (sans accords de procurement spécifiques). Le déploiement commence avec Python ; le support TypeScript est prévu pour une prochaine version.
OpenAI prévoit aussi d’ajouter d’autres fonctions, comme le “code mode” et des sous-agents, pour Python et TypeScript, et d’étendre l’écosystème (nouveaux fournisseurs de sandbox, méthodes plus faciles pour brancher le SDK aux systèmes internes).
