OpenAI publie Symphony en open source : un SPEC.md pour l'orchestration d'agents de codage autonomes

Databricks publie Omnigent en open source : un orchestrateur d'agents IA qui unifie Claude Code, Codex et Pi

Databricks a publié Omnigent, un "meta-harness" open source placé au-dessus des agents IA existants comme Claude Code, Codex et Pi. Développé en collaboration avec Neon et distribué sous licence Apache 2.0, Omnigent ne remplace pas ces outils : il s'installe une couche au-dessus d'eux pour les orchestrer comme des pièces interchangeables d'un même système. Concrètement, un "harness" est l'enveloppe logicielle qui transforme un modèle de langage en agent capable d'agir. Omnigent standardise l'interface de ces harnesses, messages entrants, fichiers, flux de texte et appels d'outils sortants, pour qu'ils deviennent substituables sans réécriture de code. L'outil s'installe via deux alias CLI identiques, omnigent et omni, et lance au démarrage une interface web locale sur localhost:6767, synchronisée en temps réel avec le terminal et accessible depuis un téléphone. Pour les équipes d'ingénieurs qui jonglent déjà entre quatre ou cinq agents simultanément en copiant du texte entre des outils de code, des moteurs de recherche et Slack, Omnigent apporte trois capacités structurantes. La composition permet de combiner modèles et harnesses sans toucher au code : un simple changement d'une ligne suffit à basculer de Claude Code à Codex. Le contrôle introduit des politiques stateful, par exemple, mettre un agent en pause après chaque dépense de 100 dollars, ou exiger une validation humaine avant un git push si l'agent a installé un nouveau paquet npm. La collaboration permet de partager une session d'agent en direct par URL : les coéquipiers peuvent observer, commenter des fichiers, co-piloter ou bifurquer la conversation. Un sandbox système appelé Omnibox assure la sécurité sous-jacente, notamment en injectant les tokens GitHub uniquement via un proxy de sortie approuvé, sans les exposer à l'agent. Le projet embarque deux agents d'exemple révélateurs de la philosophie de l'outil. "Polly" est un orchestrateur multi-agents qui ne génère aucun code lui-même : il planifie, puis délègue en parallèle à des sous-agents dans des worktrees git distincts, avec une revue croisée assurée par un agent d'un fournisseur différent de celui qui a écrit le code. "Debby" est un partenaire de brainstorming à deux têtes, Claude et GPT, qui répond en parallèle à chaque question et peut déclencher un débat contradictoire entre les deux via la commande /debate. Ces exemples illustrent une tendance de fond : avec la multiplication des agents spécialisés, la compétition ne se joue plus seulement au niveau du modèle, mais à celui de l'orchestration. Omnigent positionne Databricks sur ce terrain en proposant une couche de gouvernance neutre, ouverte, et potentiellement universelle pour l'écosystème des agents de développement.

💬 Le truc qui m'a accroché, c'est pas la couche d'orchestration générique, c'est les politiques de contrôle : mettre un agent en pause après 100 dollars de dépenses, bloquer un git push si un nouveau paquet npm s'est glissé sans validation humaine, c'est le maillon qui manquait depuis qu'on jongle avec cinq agents en même temps. Databricks parie que la bataille se joue à la gouvernance plutôt qu'au modèle, et ce pari-là je le trouve solide. Apache 2.0, Neon dans la boucle, reste à voir si l'écosystème suit vraiment.

OpenAI publie en open source Euphony, un outil de visualisation web pour les données Harmony Chat et les sessions Codex

OpenAI a publié en open source Euphony, un outil de visualisation fonctionnant directement dans le navigateur, conçu pour transformer des données de conversation structurées en vues interactives lisibles. L'outil prend en charge deux formats propriétaires d'OpenAI : les conversations au format Harmony et les fichiers de session Codex au format JSONL. Euphony peut ingérer ces données de trois manières : en collant du JSON directement depuis le presse-papiers, en chargeant un fichier local, ou en pointant vers une URL publique, y compris des datasets hébergés sur Hugging Face. Une fois les données chargées, l'outil détecte automatiquement le format et rend une timeline de conversation navigable, avec un panneau d'inspection des métadonnées, un mode grille pour parcourir rapidement de grands datasets, un mode édition pour modifier le contenu JSONL dans le navigateur, et un filtrage basé sur JMESPath pour interroger les structures JSON complexes. Ce problème est concret pour quiconque travaille avec des agents IA multi-étapes : un agent Codex qui lit des fichiers, appelle des API, génère du code et révise ses propres sorties peut produire des centaines de lignes de JSON brut, où tokens bruts, chaînes décodées et métadonnées structurées s'entremêlent. Sans outillage dédié, retracer ce que le modèle faisait à chaque étape revient à reconstituer un puzzle sans image de référence. Euphony répond directement à ce besoin en rendant exploitable une richesse de données qui jusqu'ici restait enfouie dans des fichiers difficilement lisibles à l'œil nu. Pour les équipes d'évaluation et de fine-tuning, la possibilité d'inspecter des champs de métadonnées par conversation, scores, sources, labels, directement dans l'interface représente un gain de productivité significatif. Le contexte technique éclaire pourquoi cet outil était nécessaire. Le format Harmony, utilisé pour entraîner la série de modèles open-weight gpt-oss d'OpenAI, est structurellement plus riche qu'un format de chat standard : il supporte des sorties multi-canaux (raisonnement, appels d'outils, réponses normales dans une même conversation), des hiérarchies d'instructions basées sur les rôles (system, developer, user, assistant) et des namespaces d'outils nommés. Cette richesse est précieuse pour l'entraînement et l'évaluation, mais elle rend l'inspection manuelle particulièrement pénible. Euphony est disponible en deux modes : un mode purement frontend sans dépendance serveur, activé via la variable d'environnement VITEEUPHONYFRONTEND_ONLY=true, et un mode assisté par un serveur FastAPI local qui gère le chargement de datasets volumineux et le rendu Harmony côté backend. L'outil est également conçu pour être intégré comme composant web dans d'autres applications, ce qui ouvre la voie à une adoption dans des pipelines d'évaluation ou des interfaces internes d'équipes IA.

NVIDIA AI publie 'OpenShell' en open source : un environnement d'exécution sécurisé pour les agents IA autonomes

NVIDIA a mis en open source OpenShell, un environnement d'exécution sécurisé conçu pour les agents IA autonomes, publié sous licence Apache 2.0. Il offre un sandboxing au niveau noyau, un moteur de politiques granulaires (contrôle par binaire, endpoint et méthode API) avec journalisation complète, ainsi qu'un routage d'inférence privé pour éviter les fuites de données. OpenShell est agnostique aux frameworks — compatible avec Claude Code, Codex, LangChain et autres — et s'intègre comme une couche de sécurité sans réécriture du code agent.

RightNow AI publie AutoKernel : un framework open source qui applique une boucle d'agents autonomes à l'optimisation des kernels GPU pour les modèles PyTorch

RightNow AI a publié AutoKernel, un framework open-source qui automatise l'optimisation des kernels GPU pour n'importe quel modèle PyTorch. Le principe est simple : soumettre un modèle avant de dormir et retrouver au matin des kernels Triton plus rapides, sans avoir à maîtriser la programmation GPU de bas niveau. Le système repose sur une boucle agentique autonome : un agent LLM modifie un fichier kernel.py, un banc de test vérifie la correction puis mesure le débit, et le résultat détermine si la modification est conservée ou annulée via un git reset. Chaque itération dure environ 90 secondes, ce qui permet de réaliser 300 à 400 expériences lors d'une session de 10 heures. L'agent suit un manuel d'optimisation en six niveaux encodé dans un document de 909 lignes, couvrant le réglage des tailles de blocs, les patterns d'accès mémoire, les optimisations de calcul comme TF32, les techniques avancées comme split-K, et les stratégies spécifiques aux architectures Hopper et Ampere de NVIDIA. L'enjeu est considérable pour l'industrie du machine learning. Optimiser un kernel GPU de haute performance exige de raisonner simultanément sur l'intensité arithmétique, la coalescence mémoire, la pression sur les registres, la synchronisation au niveau warp et la sélection des instructions tensor core, un ensemble de compétences qui prend des années à acquérir. Un seul kernel de multiplication matricielle performant peut représenter plus de 200 lignes de code CUDA ou Triton avec des dizaines de paramètres interdépendants. La suite de benchmarks KernelBench, qui évalue les grands modèles de langage sur 250 problèmes de kernels GPU, a montré que même les meilleurs modèles n'égalaient la baseline PyTorch que dans moins de 20 % des cas en génération directe. AutoKernel répond précisément à ce déficit en rendant cette expertise accessible sans spécialiste humain, ce qui pourrait accélérer significativement le développement et le déploiement de modèles d'IA. L'approche s'inspire directement du projet autoresearch d'Andrej Karpathy, dans lequel une boucle keep/revert appliquée à du code d'entraînement LLM avait permis de découvrir 20 optimisations en 700 expériences sur deux jours avec un seul GPU. AutoKernel transpose cette logique à l'espace des kernels, en substituant la loss de validation par un benchmark de correction et de débit comme fonction d'évaluation. La traçabilité est assurée par git, les résultats étant stockés dans un fichier TSV lisible directement par l'agent. Ce type de framework illustre une tendance plus large où les tâches d'ingénierie hautement spécialisées deviennent des cibles pour l'automatisation agentique, réduisant la dépendance aux rares experts en optimisation GPU à mesure que les architectures de modèles continuent d'évoluer.

💬 L'idée de laisser tourner une boucle agentique toute la nuit pour sortir des kernels Triton optimisés au matin, c'est exactement ce qu'on attendait depuis qu'on a vu Karpathy faire la même chose sur du code d'entraînement. La partie vraiment bien foutue, c'est le mécanisme d'évaluation : un benchmark de correction avant tout, et le git reset si ça régresse, ce qui évite de passer des heures à débugger des "optimisations" qui cassent tout. Pour les équipes sans expert CUDA dans les jambes, c'est une vraie bouffée d'air.