Quand j’ai commencé à poser argentic-mw, j’ai fait ce que tout ingénieur fait avant d’écrire une ligne : regarder ce qui existait. J’ai installé OpenClaw, j’ai lu la doc d’Hermes Agent, j’ai fouillé les dépôts, j’ai fait tourner des scénarios à la main. Les deux projets sont impressionnants et massivement adoptés, et je comprends pourquoi : OpenClaw revendique près de 384 000 étoiles sur GitHub, Hermes Agent tourne autour de 218 000, et l’un comme l’autre promettent un assistant personnel qui décide, agit et apprend sans intervention. C’est séduisant sur le papier et ça l’est encore à l’usage pour un certain nombre de cas. Pour argentic-mw, ça a coincé presque immédiatement, et pas pour des raisons de qualité de modèle.

Ce qui a coincé, c’est la philosophie de contrôle. J’avais besoin d’envoyer un mail de veille chaque matin à une heure précise, de répondre à un ticket Zendesk selon des règles métier éditables, de comparer des statistiques web contre des sites de référence. Aucune de ces tâches ne demandait à un LLM de choisir la prochaine action. Elle demandait à un LLM de classer, de résumer, de rédiger un brouillon, le tout à l’intérieur d’un plan fixé par du code. La philosophie supervisée, vue dans le manifeste du premier article, suppose précisément que le code pilote et que le LLM produit du contenu aux points d’extension. Les plateformes full-LLM supposent l’inverse, et c’est un mismatch qui ne se règle pas en configurant mieux.

Reste que “build ou buy” est une fausse alternative binaire. Il y a au moins trois axes : adopter un agent full-LLM tout-en-un, construire sur un framework d’orchestration, ou bâtir un socle sur-mesure. Le propos de cet article est de donner un cadre pour choisir, pas de plaider pour l’un d’eux.

Le cadre : six critères de décision

Pour comparer des approches qui n’ont pas le même but, il faut un terrain commun. J’en utilise six, choisis parce qu’ils séparent les agents supervisés des autres plutôt que parce qu’ils flattent une approche. Aucun n’est suffisant seul, et aucun ne classe les options de manière tranchée : ils dessinent un profil.

Le déterminisme est le premier, et c’est le plus structurant. La question est simple : qui contrôle le flow d’exécution, le code ou le LLM ? Dans un agent supervisé, l’ordre des Steps est écrit en code et ne dépend pas d’une décision de modèle. Dans un agent full-LLM, le modèle choisit la prochaine action à chaque itération. Un framework comme LangGraph laisse les deux ouvertes, puisqu’on peut écrire un graphe déterministe ou y déléguer des branches au modèle. Le critère n’est pas “déterministe ou pas”, il est “où la décision du flow vit-elle, et peut-on la lire dans le code ?”.

L’auditabilité est le deuxième. Peut-on retracer et rejouer chaque décision d’un run ? Un agent supervisé trace chaque Step, horodate ses entrées et ses sorties, et persiste ces traces pour qu’un humain puisse les examiner des mois plus tard. Un agent full-LLM produit des décisions probabilistes qui ne se rejouent pas à l’identique, et dont le cheminement est reconstruit après coup. La question concrète est : pour une décision datée, puis-je retrouver les entrées, le raisonnement et la sortie, et re-exécuter le run ? La réponse sépare nettement les approches.

Le coût token est le troisième. Un agent full-LLM fonctionne en boucle : chaque itération consomme des tokens d’entrée et de sortie, et la longueur du contexte grossit au fur et à mesure. La consommation n’est pas bornée par construction, elle dépend du nombre d’itérations et de la verbosité du modèle. Un agent supervisé appelle le LLM à des points d’extension fixes, avec un prompt borné et un schéma de sortie strict. La facture se calcule par Step et se cappe par run. Le critère est : la consommation est-elle une propriété architecturale ou un paramètre non maîtrisé ?

Le multi-tenant est le quatrième, et il est souvent sous-estimé. Plusieurs équipes peuvent-elles configurer des instances du même agent avec des paramètres, des prompts, des modèles et des destinataires différents, sans redéployer le code ? Un agent supervisé distingue un type d’agent (la définition du pipeline) d’une instance (sa configuration), ce qui permet de déployer une veille pour l’équipe commerciale et une veille pour l’équipe ingénierie sans toucher au code. Les plateformes full-LLM raisonnent généralement en agent personnel, pas en instance configurable.

Le contrôle des prompts est le cinquième. Les prompts sont-ils éditables sans redéploiement, versionnés, et séparés du code ? Dans un agent supervisé, chaque LLM Step porte sa propre configuration (modèle, limites de consommation, prompt système) stockée en base, modifiable via le control plane. Côté full-LLM, le prompt est souvent imbriqué avec la logique d’orchestration et les fichiers d’instruction du système, et le modifier sans casser le comportement suppose une compréhension fine du runtime.

Le lock-in est le sixième. Quelle est la dépendance à un runtime, une licence, un écosystème ? Une plateforme full-LLM lie l’agent à son runtime, ses skills, son registre. Un framework lie le code à ses abstractions, mais reste du code qu’on possède. Un socle sur-mesure lie à son propre code, qu’on maintient. Le critère est : si je veux partir demain, qu’est-ce que j’emporte, et qu’est-ce que je dois réécrire ?

Le tableau ci-dessous projette les approches sur deux des critères, le déterminisme et le coût de boot, parce qu’ils suffisent à visualiser le profil de chaque famille. Les autres critères se lisent en complément dans les sections suivantes.

quadrantChart
    title Déterminisme vs Coût de boot
    x-axis "Coût de boot faible" --> "Coût de boot élevé"
    y-axis "Déterminisme faible" --> "Déterminisme élevé"
    "OpenClaw": [0.15, 0.1]
    "Hermes Agent": [0.2, 0.15]
    "Dify": [0.3, 0.4]
    "CrewAI": [0.45, 0.5]
    "LangGraph": [0.55, 0.7]
    "argentic-mw": [0.8, 0.9]

Le quadrant se lit simplement : en haut à gauche, on démarre vite mais on perd le contrôle du flow ; en bas à droite, on gagne en déterminisme mais on paie en coût de boot. Aucune approche n’occupe le coin haut-droit, et c’est l’observation qui structure la suite : on ne gagne pas en déterminisme sans investir dans le socle, et on ne démarre pas instantanément avec un socle complet.

Axe A vs sur-mesure : agent full-LLM contre socle déterministe

Appliquons le cadre à OpenClaw et Hermes Agent, qui sont les incarnations les plus visibles de l’axe “agent full-LLM tout-en-un”. OpenClaw, né d’une série de renommages fin 2025 et début 2026 (Clawdbot, puis Moltbot, puis OpenClaw), est un assistant personnel dont l’interface principale est une messagerie et dont le modèle d’extension repose sur des skills injectés en runtime. Hermes Agent, porté par Nous Research, partage la même famille philosophique : auto-amélioration, mémoire cross-session, sous-agents parallèles, gateway multi-plateformes. Tous deux sont sous license MIT et actifs, mais n’incarnent pas la philosophie supervisée.

Sur le déterminisme, ils plient dès la première question. Le flow d’exécution est piloté par le LLM, qui choisit la prochaine action à chaque itération. Le code est à la marge, le LLM est au centre, et l’ordre des actions n’est pas lisible dans un fichier. Pour un agent personnel qui apprend les préférences d’un utilisateur, c’est à propos. Pour un pipeline métier planifié qui doit produire le même comportement chaque matin, c’est un défaut structurel qu’aucun réglage de prompt ne corrige.

Sur l’auditabilité, le même écart se mesure. Un run d’OpenClaw produit une trajectoire probabiliste dont le cheminement se reconstruit après coup, mais ne se rejoue pas à l’identique. Pour un usage personnel, l’approximation suffit. Pour un audit réglementaire qui demande, pour une décision datée, de retrouver les entrées et le raisonnement, elle ne tient pas.

Sur le coût token, la boucle ouverte est un fait d’architecture, pas un défaut de configuration. Chaque itération consomme, le contexte grossit, et la longueur d’un run dépend d’un état terminal que le modèle doit décider d’atteindre. Sur un cron qui tourne toutes les heures, la facture devient un paramètre non maîtrisé, sauf à capper artificiellement par des garde-fous externes. argentic-mw, à l’inverse, appelle le LLM à des points d’extension fixes avec des limites de consommation par Step : la facture se prévoit au Step près, et le même pipeline exécuté aujourd’hui et dans six mois consomme le même ordre de grandeur de tokens.

Sur le contrôle des prompts, OpenClaw et Hermes Agent reposent sur des fichiers d’instruction (SOUL.md, AGENTS.md, TOOLS.md) et des skills injectés, dont la modification suppose une compréhension fine du runtime et de l’écosystème. argentic-mw sépare la configuration d’un LLM Step (modèle, limites, prompt) du code du pipeline, et la stocke en base pour qu’elle soit éditable via le control plane sans redéploiement. La différence n’est pas cosmétique : elle décide qui peut modifier le comportement sans toucher au code.

Les incidents sécurité documentés ne sont pas théoriques et méritent qu’on les cite. La recherche publiée par Cisco AI Security a mis en évidence des vecteurs de prompt injection et d’exfiltration de données via des skills tiers sur OpenClaw. Un mainteneur du projet a lui-même déclaré que l’outil était trop dangereux pour un utilisateur qui ne sait pas lancer une ligne de commande. Le gouvernement chinois a interdit OpenClaw aux banques, entreprises d’État et agences en mars 2026. Aucun de ces signaux n’est anecdotique, et tous pointent vers la même cause : un agent qui décide seul de ses actions est, par construction, un agent qu’on ne peut pas contraindre a priori. La surface d’attaque s’élargit à chaque skill, parce que chaque skill est une capacité potentiellement détournable, et aucun garde-fou ne vit dans le code autour du modèle.

argentic-mw appliqué au même cadre ne gagne pas partout, et c’est important de le dire. Sur le déterminisme, l’auditabilité, le coût token et le contrôle des prompts, la philosophie supervisée tient, parce qu’elle a été pensée pour ces propriétés. Sur le multi-tenant, la distinction entre type et instance permet de déployer plusieurs configurations du même agent sans redéploiement, ce qui est précisément le cas d’usage d’une plateforme interne multi-équipes. Sur le lock-in, le Socle est du code qu’on possède, ce qui est à la fois une liberté et une charge.

La charge est réelle et je ne la cache pas. argentic-mw a un coût de boot élevé, parce qu’il faut écrire le Socle, le scheduler, le tracing, le cache de replay, le control plane, la gestion des secrets. Il n’a pas de démarrage instantané, pas de registre de skills, pas de gateway messagerie clé-en-main. L’investissement se paye en semaines d’ingénierie de plateforme, et il n’a de sens que si les pipelines visés sont récurrents, planifiés et soumis à des exigences d’audit.

Verdict partiel, et c’est tout l’objet du cadre : pour les agents supervisés, l’axe A est un mismatch philosophique, pas un défaut de qualité. OpenClaw et Hermes Agent ne sont pas des mauvais outils, ils sont des outils conçus pour un autre besoin, et le cadre permet de le lire sans parti pris. Pour un agent personnel autonome ou un usage expérimental où l’on accepte le non-déterminisme, ils restent un choix cohérent. Pour un pipeline métier planifié en production, ils répondent à la mauvaise question.

Et la voie intermédiaire ? les frameworks d’orchestration

Reste un troisième axe, que la recherche appelle le “achète un socle pour bâtir” : les frameworks et plateformes sur lesquels on construit soi-même des agents. LangGraph, CrewAI, Dify, et le couple AutoGen devenu Microsoft Agent Framework, ne sont pas des produits-utilisateurs autonomes, ce sont des outils d’orchestration. La question est de savoir si l’un d’eux délivre assez de socle métier pour qu’on n’ait pas à le reconstruire par-dessus.

LangGraph est le plus proche de la philosophie supervisée. C’est un orchestrateur bas-niveau qui autorise un graphe déterministe, de la durable execution avec reprise après crash, du human-in-the-loop, et une observabilité via LangSmith. Le graphe est explicite, ce qui répond à la question du déterminisme si on l’écrit ainsi. L’écart se mesure sur le reste du cadre : LangGraph ne fournit pas de socle métier clé-en-main. Les traces normalisées, le cache de replay, la file de validation humaine, la distinction type-instance, la rule table, tout cela est à construire par-dessus. L’observabilité est par ailleurs biaisée vers LangSmith, ce qui ajoute une dépendance à l’écosystème LangChain. Le coût de boot est réduit sur l’orchestration, mais le socle supervisé reste à écrire.

CrewAI propose deux primitives. Les Crews sont des agents autonomes en role-playing, ce qui est un anti-pattern pour du supervisé, puisque le flow revient au modèle. Les Flows rapprochent du déterminisme événementiel, mais sans sémantique d’audit ou de replay native, et sans multi-tenant configurable par construction. CrewAI AMP, la couche commerciale, ajoute un control plane et de la télémétrie, mais reste orientée autonomie plutôt que pipeline planifié. La distance avec argentic-mw se mesure sur l’auditabilité et le multi-tenant, pas sur la capacité à orchestrer.

Dify est le plus “buy” du lot, au sens où il offre un boot rapide et une UI collaborative de workflows, un Prompt IDE, du RAG, des agents Function Calling et ReAct, et une couche LLMOps. C’est séduisant pour un prototype ou un déploiement interne qui accepte un déterminisme partiel, puisque le “workflow” reste très LLM-centré. Deux précisions s’imposent. Dify n’est pas sous licence Apache 2.0 pure : c’est la Dify OSS License modifiée, avec des restrictions commerciales, ce qui n’est pas neutre pour un déploiement entreprise. Et Dify n’a pas de modèle d’agent supervisé natif : pas de traces horodatées normalisées, pas de replay, pas de file de validation humaine, pas de distinction type-instance. Le lock-in plateforme est réel.

AutoGen mérite une mention honnête : il est en maintenance mode depuis la version 0.7.5 de septembre 2025, et son successeur est Microsoft Agent Framework (MAF) 1.0, orienté orchestration multi-agent enterprise. Le nommer comme choix d’avenir serait inexact, et MAF reste orienté autonomie et fleet d’agents plutôt que pipeline supervisé. La maturité de MAF sur les propriétés spécifiques aux agents supervisés reste à vérifier.

Verdict de la voie intermédiaire : elle réduit le coût de boot, parfois significativement, mais elle ne délivre pas le déterminisme et l’auditabilité natifs des agents supervisés. Le graphe de LangGraph est déterministe si on l’écrit ainsi, mais le socle métier reste à construire, et on finit par reconstruire par-dessus ce que la philosophie supervisée exige : traces, replay, validation, multi-instance. Le framework n’économise que la couche d’orchestration, qui n’est pas la plus coûteuse ni la plus discriminante. C’est un choix viable pour démarrer vite, pas un substitut au socle.

Quand build, quand buy

Le cadre ne plaide pas pour une réponse unique, et ce serait malhonnête. Buy si ton besoin est un agent personnel autonome qui apprend les préférences d’un utilisateur, ou un prototype rapide où l’on accepte le non-déterminisme pour aller vite. OpenClaw et Hermes Agent répondent au premier cas, Dify au second, et ils ont leur public légitime. Build si tu as des pipelines métier planifiés avec des exigences d’audit, de contrôle, de coût borné et de multi-instance configurable. argentic-mw est une réponse à cette famille, pas à toutes.

Le cadre est réutilisable : applique-le à ton contexte, à tes contraintes réglementaires, à ton volume, à ton équipe. Les six critères ne classent pas les options dans un ordre universel, ils dessinent un profil à comparer au tien. Une équipe qui démarre un prototype sans contrainte d’audit n’a pas besoin du socle supervisé, et le construire serait un investissement mal placé. Une équipe qui touche des données clients, des communications externes et un cron en production n’a pas le choix du non-déterminisme, et l’acheter serait un risque mal mesuré.

Le troisième article refermera la boucle sur l’implémentation : comment argentic-mw exécute concrètement ses trois agents, du Socle commun aux pipelines métier, avec le détail des Steps, des garde-fous et du scheduler (voir Du manifeste au code : comment argentic-mw exécute ses agents). La philosophie supervisée vue dans le manifeste y rencontrera le code qui la met en pratique.