Codex comme plateforme : développez avec le harnais d’agent open source

La plupart des gens connaissent Codex à travers l’App, l’interface en ligne de commande ou l’extension IDE. Ces interfaces sont importantes, mais elles ne représentent que quelques-unes des façons d’utiliser le même système sous-jacent.

Le harnais open source de Codex fait fonctionner toutes ces interfaces. Il aide les modèles à recueillir du contexte, à raisonner sur les tâches, à utiliser des outils, à respecter les limites configurées, à demander une approbation et à faire avancer le travail.

Cela ouvre de nouvelles possibilités aux développeurs. Au lieu de demander à chaque équipe de transférer son travail dans un assistant de programmation généraliste, vous pouvez intégrer l’agent à un logiciel conçu autour de son activité réelle : un workflow d’ingénierie, un tableau de bord opérationnel, une investigation de sécurité, une console de support client ou une application interne destinée à une équipe spécialisée.

La boucle de l’agent est la partie réutilisable

Un agent performant ne se résume pas à un prompt et à une réponse du modèle. Il doit pouvoir comprendre une tâche, conserver le contexte dans la durée, examiner les informations pertinentes, appeler des outils, rendre compte de sa progression, gérer les échecs, demander une approbation humaine si nécessaire et produire un résultat utile.

Le harnais est le système d’exécution qui encadre l’ensemble.

La conception du harnais peut changer sensiblement les résultats : sur ARC-AGI-3, la conservation du raisonnement et le compactage du contexte ont fait passer le score de GPT-5.6 Sol de 13,3 % à 38,3 %, tout en divisant par six le nombre de tokens de sortie.

Nous avons conçu le harnais de Codex pour gérer l’état de la conversation, transmettre le déroulement de l’exécution en continu, utiliser des outils, appliquer les politiques configurées de bac à sable et d’approbation, et poursuivre le travail d’un tour à l’autre. Avec Codex app-server, nous rendons ces capacités accessibles via un protocole client documenté : les applications peuvent créer des fils de discussion, lancer des tours, recevoir des événements et traiter les demandes d’approbation.

Si vous développez un logiciel qui a besoin d’un agent, vous pouvez partir de Codex au lieu de créer un nouvel environnement d’exécution, puis décider de ce que l’application qui l’intègre doit prendre en charge.

Un harnais open source que les développeurs peuvent examiner et adapter

Le harnais étant open source, vous pouvez examiner la couche entre votre application et le modèle, comprendre son comportement et adapter l’intégration à votre produit.

Les développeurs gardent ainsi la maîtrise des éléments qui permettent d’adapter l’agent à leur produit :

• L’interface. Une équipe peut conserver ses tableaux de bord, éditeurs, files d’attente, cartes, fiches et circuits d’approbation existants, au lieu de faire passer chaque interaction par une fenêtre de discussion générique.

• Le contexte et les outils. Une application peut donner accès aux systèmes, documents, données et actions utiles à un workflow particulier, y compris à ses propres services MCP.

• Les limites opérationnelles. L’application hôte peut décider où un agent s’exécute, à quels fichiers ou outils il a accès, quelles actions nécessitent une approbation, comment son travail est suivi et comment les résultats sont réintégrés au système de référence.

Nous publions Codex CLI, app-server et le SDK Codex officiel sous forme de composants open source. Notre guide des composants open source présente les composants disponibles et indique où les trouver.

La couche open source comprend le harnais et les interfaces d’intégration ; l’accès aux modèles et les services managés restent distincts.

Choisissez la bonne couche d’intégration

Développer avec Codex ne nécessite pas la même intégration pour tous les cas d’usage.

• Pour un script, un job de CI ou une tâche ponctuelle en arrière-plan, codex exec peut exécuter un workflow d’agent au périmètre délimité et renvoyer une sortie structurée.

• Pour le code applicatif qui doit lancer ou reprendre des tâches Codex, ou en recevoir le déroulement en continu, le SDK Codex officiel fournit une interface de programmation directe.

Pour un exemple exécutable, consultez la documentation du SDK Codex.

Utilisez Codex app-server lorsque l’agent fait partie du produit lui-même. Il permet à votre application de se connecter à un processus Codex local, de garder les conversations ouvertes, de transmettre les événements en continu, d’interrompre le travail, de rendre des outils accessibles et de répondre aux demandes d’approbation. Le SDK simplifie les workflows programmatiques courants ; app-server donne aux équipes produit un contrôle direct sur le cycle de vie et l’expérience utilisateur.

Concevez votre logiciel autour du workflow

La possibilité la plus intéressante n’est pas de reproduire l’application Codex avec un autre logo, mais de créer un logiciel qui reflète la façon dont une personne ou une équipe travaille déjà :

Un analyste de sécurité peut avoir besoin d’une file d’investigations à traiter, des alertes récentes, de la liste des services concernés et d’une étape d’approbation avant d’ouvrir un ticket de remédiation. Un ingénieur support peut avoir besoin de l’historique du compte, des journaux du produit, de la documentation interne et d’un brouillon de réponse. Une équipe produit peut souhaiter disposer d’un tableau de tâches où le passage d’un ticket à l’état prêt déclenche un workflow d’implémentation au périmètre défini.

Dans chaque exemple, l’interface joue un rôle important dans l’expérience. Elle indique à l’agent ce que l’utilisateur consulte, lui fournit les bons outils et offre à l’utilisateur un espace pour examiner la suite des opérations.

Exemple : Relay

Nous avons créé Relay comme exemple d’application de gestion des opérations reposant sur Codex app-server. Elle place un agent à côté d’un tableau de bord d’expéditions fictif, le connecte à des outils MCP propres à l’application et exige une approbation humaine avant de réserver à nouveau le transport d’une expédition.

L’utilisateur ne commence pas par rédiger un prompt de zéro. Il sélectionne une expédition et clique sur une action telle que Comparer les solutions de rattrapage. L’application fournit le contexte pertinent, Codex récupère les dernières données opérationnelles de démonstration, l’agent explique les options disponibles et toute écriture ayant des conséquences importantes nécessite une approbation.

Codex peut alors utiliser les outils MCP de l’application pour récupérer les données à jour avant de recommander une action ou, après approbation, de l’exécuter. Lorsqu’un outil modifie la fiche sous-jacente, l’application actualise sa vue métier. Le harnais gère la boucle de l’agent, l’état de la conversation, la transmission de l’activité en continu et les interactions avec les outils ; le produit conserve la maîtrise de son tableau de bord, de ses fiches et de ses contrôles.

Relay utilise des données fictives préchargées, mais ce schéma d’intégration est général. Il pourrait aussi servir à la réponse aux incidents, à la gestion des comptes, aux workflows de recherche ou à d’autres applications où un agent doit intervenir au sein d’une expérience produit existante.

Ce que les développeurs créent

Ce schéma se retrouve déjà dans des réalisations publiques :

• GitHub et JetBrains

  intègrent Codex aux workflows existants dans les IDE.

• Cisco

  utilise le SDK Codex dans App Builder, au sein de Cisco Cloud Control.

• Thrive Holdings et Crete

  utilisent Codex dans un workflow de préparation des déclarations fiscales qui intègre les retours des professionnels. Leur projet pilote a traité 7 000 déclarations et réduit le temps de préparation d’environ un tiers.

Ces exemples ne se limitent pas à l’ingénierie : le même schéma s’applique aux équipes support qui examinent les problèmes des clients, aux équipes opérationnelles qui coordonnent les workflows, aux équipes de sécurité qui trient les incidents, aux équipes commerciales qui se renseignent sur les comptes clients et aux équipes marketing qui élaborent des campagnes. Dans chaque cas, l’application fournit le contexte, les outils et les mécanismes d’approbation, tandis que Codex fait fonctionner la boucle de l’agent sous-jacente.

Créez au-delà des usages évidents

Pour de nombreuses activités, le contexte essentiel se trouve dans un tableau de bord, une chronologie, une carte, un document ou une fiche du système. Ces vues ne sont pas là pour faire joli : c’est grâce à elles que les utilisateurs comprennent ce qui se passe, prennent des décisions et gardent le contrôle.

L’occasion à saisir n’est pas de remplacer ces interfaces par une fenêtre de discussion universelle, mais d’en étendre les capacités en leur ajoutant un agent capable de comprendre le travail, d’examiner le contexte pertinent, de proposer une prochaine étape et d’exécuter une action approuvée.

L’application Codex, la CLI et l’extension IDE montrent ce que le harnais peut faire. En le rendant open source, nous donnons aux développeurs les moyens d’examiner ces capacités, de les intégrer et de les adapter à leurs propres produits et workflows.

Si vous souhaitez développer avec le harnais de Codex, commencez par le dépôt open source de Codex, puis choisissez l’intégration adaptée à votre produit : codex exec pour les tâches non interactives, le SDK Codex pour les workflows d’agent programmatiques, ou Codex app-server pour les applications qui ont besoin de conversations persistantes, d’événements transmis en continu et d’une gestion des approbations.