Agentlas OS : un hub d'agents spécialisés, un orchestrateur jetable par tâche
Agent OS: keep specialist agents in a hub, spin up a temporary orchestrator per task. Local-first, works with any model.
En bref
- De quoi s’agit-il ?
- Agentlas OS installe une couche de commandes dans l'outil LLM que vous utilisez déjà, garde les agents créés dans un espace privé et assemble une équipe temporaire au moment de la tâche. Voici ce que le dépôt décrit, et ce qu'il laisse dans l'ombre.
- À qui s’adresse-t-il ?
- Agentlas OS convient à un ingénieur qui travaille déjà dans Claude Code, Codex, Gemini CLI, Cursor ou Ollama et qui veut réutiliser des agents d'une session à l'autre sans les rattacher à un seul modèle. Il ne convient pas à qui cherche un moteur d'orchestration déterministe et testable en CI, ni à qui refuse qu'un bloc de routage soit écrit dans le fichier d'instructions global de son hôte.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 3 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème visé : des agents qui survivent à la session qui les a vus naître
Un agent écrit à la main dans un projet disparaît avec le projet. Un agent généré à la volée dans une conversation disparaît avec la conversation. Agentlas OS prend le contre-pied : le README présente l'agent comme un actif, pas comme un programme, et insiste sur le fait qu'un agent créé n'est lié ni à un espace de travail de modèle ni à une machine. La cible est donc l'ingénieur qui accumule des spécialistes (un pour la revue de code, un pour la recherche, un pour une chaîne de build) et qui veut les retrouver ailleurs, sur un autre hôte pris en charge, après une simple connexion. Le second problème est la composition : au lieu de faire grossir un agent unique jusqu'à l'illisibilité, le projet propose de garder les spécialistes dans un hub et de monter un orchestrateur temporaire pour la tâche du moment. Le README résume la promesse par une formule : « Build it or borrow it. The agents you create stay yours. »
Deux surfaces distinctes : Agent Cloud privé et Agentlas Hub public
La documentation sépare nettement ce qui est à vous et ce qui est emprunté. Agent Cloud est décrit comme privé et rattaché au propriétaire (owner-scoped) : c'est là qu'un agent est enregistré pour être restauré plus tard sur un Desktop connecté au même compte. Agentlas Hub est public : c'est le catalogue dans lequel on emprunte des spécialistes déjà écrits. Cette séparation a une conséquence pratique que le README ne développe pas : emprunter un agent public et enregistrer le vôtre ne relèvent pas du même régime de confiance, et rien dans le matériel fourni ne décrit de processus de revue, de signature ou de versionnage des agents du Hub. Le paquet généré, lui, passe par une séquence explicite : classification de la demande, entretien (interview) et porte de recherche, génération, puis vérification, avant de demander si l'agent reste uniquement sur la machine ou part dans Agent Cloud. Cette dernière question est posée à l'utilisateur, ce qui suggère que le choix local ou cloud n'est pas déduit automatiquement.
Le mécanisme d'installation : un script lu avant d'être exécuté
Le README ne demande pas de faire confiance à une commande opaque. Il fournit un texte à coller dans le LLM courant, texte rédigé pour que le modèle aille d'abord lire le script d'installation, puis rende compte de ce qu'il fait. Le script visé est scripts/install-all-runtimes.sh, récupéré depuis raw.githubusercontent.com sur la branche main. D'après ce texte, il télécharge une archive de release depuis les GitHub Releases du même dépôt et n'écrit que sous ~/.agentlas, ~/.local/bin, ainsi que dans les répertoires de plugins et d'adaptateurs de commandes propres à l'hôte, par exemple ~/.claude pour Claude Code. La commande d'installation effective est :
curl -fsSL https://raw.githubusercontent.com/agentlas-ai/Agentlas-OS/main/scripts/install-all-runtimes.sh | HEPHAESTUS_INSTALL_GLOBAL_ROUTER=1 bash
La variable HEPHAESTUS_INSTALL_GLOBAL_ROUTER=1 ajoute un bloc de routage dans le fichier d'instructions global de l'hôte, par exemple ~/.claude/CLAUDE.md. Le README précise que ce bloc n'est pas secret, qu'on peut le relire et le citer, et qu'on peut l'omettre en retirant la variable pour l'ajouter plus tard avec hephaestus global install. Windows passe par Git Bash, macOS par Terminal, avec l'installation des Command Line Tools au premier appel de curl ou git. Après installation, il faut fermer puis rouvrir l'outil LLM pour que les nouvelles commandes soient prises en compte.
Le routeur global est la décision à prendre, pas un détail d'installation
C'est le point le plus intéressant du dispositif et celui que la documentation traite le plus légèrement. Poser HEPHAESTUS_INSTALL_GLOBAL_ROUTER=1 revient à écrire dans le fichier d'instructions global de l'hôte une règle qui autorise des tâches substantielles à être dotées en personnel depuis le réseau d'agents d'Agentlas. Autrement dit, une partie du choix d'orchestration sort de votre dépôt et de votre configuration de projet pour aller dans un fichier qui s'applique à tout ce que fait l'hôte. Le README présente cela comme réversible et lisible, ce qui est exact, mais il ne dit pas comment le bloc se comporte en cas de conflit avec des instructions déjà présentes dans ce même fichier, ni comment le désactiver proprement une fois posé. Pour un poste de travail personnel, le compromis est faible. Sur une machine partagée ou dans un environnement où le fichier d'instructions global est versionné, la question mérite d'être tranchée avant de lancer la commande, pas après.
Hôtes pris en charge et portée réelle de « works with any model »
Le badge du README énumère Claude Code, Codex, Gemini CLI, Antigravity, Cursor, DeepSeek, GLM et Ollama. Le projet se décrit comme local-first et fonctionnant avec n'importe quel modèle. Il faut lire cette affirmation pour ce qu'elle est : l'installation écrit des adaptateurs de commandes dans les répertoires propres à chaque hôte, ce qui suppose un travail d'adaptation par hôte, et le README reconnaît lui-même l'existence d'une « command surface » équivalente selon l'hôte, avec la commande /agentlas build comme exemple pour l'un d'eux. La portabilité annoncée concerne donc les agents que vous créez, pas une interface unique identique partout. Le moteur sous-jacent est nommé : Hephaestus, présenté comme open-source. Le dépôt est en Python, sous licence Apache-2.0, branche par défaut main, et les releases récentes s'enchaînent à un rythme serré : v1.2.42, v1.2.43 et v1.2.44 sur moins de deux jours en septembre 2026.
Ce que le dépôt ne permet pas de vérifier
Aucune des affirmations ci-dessus ne vient d'une exécution. Le matériel fourni ne contient pas de fichier de configuration d'exemple, pas de schéma d'API, pas de description du format de paquet d'un agent, et pas de spécification du protocole d'orchestration. Le topic a2a suggère un rapprochement avec les protocoles agent-à-agent, mais rien dans le README ne décrit l'implémentation. Le texte d'installation mentionne un « verification output » produit par le script pour l'hôte concerné : c'est précisément ce qu'il faut lire avant de conclure quoi que ce soit sur le bon fonctionnement. La cadence des versions, à trois publications en deux jours, indique un projet en mouvement rapide ; elle ne dit rien de la stabilité de l'interface de commandes entre deux versions. Si vous épinglez Agentlas OS dans un environnement reproductible, prévoyez de vérifier ce point vous-même, car le dépôt ne publie pas de politique de compatibilité visible dans les éléments fournis.
Face à un framework multi-agents écrit à la main
L'alternative la plus directe n'est pas un autre produit : c'est un graphe d'agents écrit dans votre propre base de code, avec des appels de modèle explicites et un état sérialisé. La différence d'approche est nette. Un graphe maison est déterministe, testable en intégration continue, et son coût en jetons est lisible dans le diff. Agentlas OS mise sur l'inverse : un orchestrateur créé pour la tâche, des spécialistes empruntés à un catalogue, et une installation qui se fait par un script shell plutôt que par un gestionnaire de paquets Python. Le gain est le temps de mise en route et la réutilisation d'agents entre machines. Le prix est la prévisibilité : vous ne composez plus le graphe, vous décrivez une intention et laissez la classification et le routage décider. Pour une chaîne de traitement qui doit produire le même résultat à chaque exécution, ce n'est pas le bon outil. Pour un poste d'exploration où l'on veut essayer un spécialiste sans l'écrire, l'échange est favorable.
Coût de maintenance, licence et ce qu'il reste à trancher
Apache-2.0 est permissive : usage commercial, modification et redistribution sont autorisés, avec conservation des mentions de licence et du fichier NOTICE le cas échéant, et une clause de brevets explicite. Ce paragraphe n'est pas un avis juridique ; si vous redistribuez un paquet modifié, faites relire les mentions par qui de droit. Le coût de maintenance réel tient à trois choses. L'installation écrit hors du dépôt, dans ~/.agentlas et ~/.local/bin, donc une mise à jour n'est pas un simple git pull. Le bloc de routage global vit dans un fichier que le projet ne possède pas, ce qui rend sa désinstallation dépendante de l'hôte. Et la cadence des releases impose de suivre les changements d'interface de commandes si vous scriptez autour d'elles. Le README indique que hephaestus global install permet d'ajouter le routeur après coup : c'est le seul levier de configuration nommé dans le matériel fourni, et c'est aussi le premier endroit où regarder si le comportement de routage vous surprend.
Conclusion éditoriale
Agentlas OS convient à un ingénieur qui travaille déjà dans Claude Code, Codex, Gemini CLI, Cursor ou Ollama et qui veut réutiliser des agents d'une session à l'autre sans les rattacher à un seul modèle. Il ne convient pas à qui cherche un moteur d'orchestration déterministe et testable en CI, ni à qui refuse qu'un bloc de routage soit écrit dans le fichier d'instructions global de son hôte. Avant d'adopter, lisez scripts/install-all-runtimes.sh en entier, vérifiez la liste exacte des chemins qu'il écrit, puis décidez si vous lancez la commande avec ou sans HEPHAESTUS_INSTALL_GLOBAL_ROUTER=1.
Notes de la communauté