[🛠] AI Orchestration #3: J’ai testé l’AI Orchestrator en ne lui donnant qu’un objectif dans Telegram

✨ Résumé de GPT-5.6 Sol

Le récit d’une demande limitée au résultat dans Telegram, sans chemin de projet ni Agent imposé, puis des obstacles corrigés un à un jusqu’au retour du PDF et du XLSX.

Objectifs en langage naturel dans Telegram et découverte automatique du projet

Je voulais pouvoir dire « produis ce résultat » dans Telegram, puis laisser l’AI Orchestrator trouver le projet, répartir le travail, corriger les livrables défectueux et renvoyer les fichiers. S’il se contentait d’appeler Codex une fois et de transmettre une réponse, il y avait peu d’intérêt à construire un Orchestrator.

Le premier obstacle concernait les permissions. Même dans le Cell de chaque employé, les restrictions globales de Codex rendaient difficile la découverte de projets hors du Workspace ouvert au démarrage. J’ai retiré cette limite pour les projets appartenant au même utilisateur macOS, tout en conservant une approbation juste avant les actions ayant un impact externe, comme le push, le déploiement ou l’envoi de messages.

Récupération des réponses et pièces jointes par Topic avec une CLI Telethon

J’ai créé une CLI basée sur Telethon pour envoyer des commandes au Bot de l’AI Orchestrator et recevoir ses réponses et pièces jointes. Les identifiants et la Session utilisateur sont restés hors du dépôt, tandis que chaque Topic de projet servait d’unité de travail.

La première CLI pouvait se terminer avec succès après avoir simplement envoyé le message. La commande paraissait réussie même si la réponse finale du Bot ou le fichier n’arrivait jamais.

J’ai remplacé le critère de fin du processus local par la réception réelle d’une réponse et d’une pièce jointe dans Telegram. Même lorsque j’envoyais simultanément des tâches à différents Topics, chaque OpenClaw Session conservait son contexte séparé et renvoyait le résultat au Topic d’origine.

Répartition des rôles entre OpenClaw Session et l’exécution parallèle de Codex

Les tâches courtes créées directement par OpenClaw perdaient des événements de fin, tandis que les native sub-agents de Codex récupéraient de façon fiable les résultats parallèles. Une structure capable de finir le travail sans récupérer son état final ne pouvait pas servir de base d’exécution à l’Orchestrator.

Le Task Flow d’OpenClaw seul permettait difficilement de rattacher l’exécution et l’état final des tâches enfants à un registre de référence unique. J’ai donc cessé d’en faire l’unique source de vérité : OpenClaw gère Telegram, les Topics, les Sessions et la Memory ; Codex gère la découverte des projets, la décomposition du travail, l’exécution parallèle, l’intégration et la revalidation.

Diffusion de l’état d’avancement dans Telegram

Sans message pendant une tâche longue, impossible de savoir si elle s’était arrêtée. Afficher directement les commandes internes transformait Telegram en vidage de terminal. Pendant l’exécution, je mettais à jour au maximum quatre lignes d’état en coréen, puis je supprimais ce message lorsque le résultat final arrivait.

Telegram suffisait désormais pour distinguer la recherche de documents de la production du livrable.

Sélection automatique des Agent, Skill et Tool avec revalidation des livrables

Une fois les fonctions individuelles reliées, j’ai volontairement testé l’usage le plus contraignant. J’ai joué le rôle du décideur final, confié à Codex celui de CEO par intérim et transmis uniquement le résultat attendu à l’AI Orchestrator. Je n’ai indiqué ni chemin de projet, ni modèle, ni Agent, ni Skill, ni Tool, ni ordre d’exécution.

L’AI Orchestrator a trouvé le projet concerné, choisi les Skills et Tools nécessaires, puis exécuté en parallèle des native sub-agents de Codex chargés de la planification, de la technique et de la validation. Il a réparti les rôles sans que je lui fournisse le chemin ou la méthode.

Le PDF et le XLSX retournés n’étaient pas corrects du premier coup. J’ai rendu le PDF de nouveau avec une police TTF, car une police TTC avait cassé le texte coréen. Pour le XLSX, j’ai corrigé l’affichage des dates et la structure des colonnes, puis vérifié de nouveau les formules et l’affichage de toutes les feuilles.

Vingt-deux minutes et six secondes après la demande, le PDF du brief de décision CEO Pilot et le XLSX de gestion d’exécution sur deux semaines sont revenus dans le Topic Telegram d’origine. Les SHA-256 des fichiers retéléchargés depuis Telegram correspondaient aux originaux générés. Il ne s’agissait pas seulement d’un message annonçant la fin : les fichiers réels avaient fait l’aller-retour.

Validation E2E mono-utilisateur et lacune d’isolation multi-utilisateur

Le flux E2E mono-utilisateur est allé jusqu’au bout, mais 22 minutes restaient trop longues pour de petites tâches quotidiennes. Le même Agent qui avait créé les livrables les avait aussi vérifiés ; je ne pouvais donc pas parler de vérification indépendante. Je n’avais pas non plus testé un controller qui gère tous les états des tâches enfants dans un Task Graph unique et ne confirme la fin qu’une seule fois, ni l’isolation des Sessions entre employés.

Le prochain dogfooding devra d’abord vérifier que les Sessions de deux employés ne se mélangent jamais. Ensuite, il faudra identifier le principal goulot d’étranglement du flux de 22 minutes. Ces deux conditions doivent être remplies avant de passer d’un dogfooding personnel à un système utilisé collectivement par les employés.