Craig McLuckie, de Stacklok, estime que les agents de programmation ne devraient pas rester liés à l’appareil du développeur et à son processus interactif. Il présente le projet open source Mecatl comme un modèle d’architecture distribuée séparant la boucle de l’agent des clients, des environnements d’exécution, des outils et des services de soutien.
La valeur des agents de programmation ne se limite plus à une interface conversationnelle qui répond aux questions. Leur adoption pratique est liée à la possession d’outils performants, d’un dépôt et d’un système de fichiers partagés, d’agents secondaires et de compétences qui préservent ce que le système apprend des travaux précédents. Selon Craig McLuckie, de Stacklok, l’étape suivante consiste à transférer ces capacités de l’ordinateur du développeur vers des services à fonctionnement prolongé et des interfaces utilisées par des personnes qui pourraient ne jamais ouvrir un terminal.
Le problème est que la plupart des frameworks d’exécution d’agents actuels ont été conçus autour d’un modèle de bureau : un seul utilisateur, un seul appareil, un système de fichiers local et un processus interactif réunissant simultanément l’interface utilisateur, la boucle de l’agent, l’isolation, le magasin d’identifiants, l’hébergement des outils et la base de données de session. Ce modèle convient au développeur individuel, mais devient moins adapté lorsqu’une organisation doit exécuter des centaines de sessions, appliquer des politiques précises aux outils, reprendre une session après la défaillance d’un nœud ou passer d’un appareil à l’autre.
Séparer la boucle de l’agent du reste du système
McLuckie propose de construire ce qu’il appelle une « ceinture d’exécution cloud native » en tant qu’application distribuée dès le départ, plutôt que de placer un framework de bureau dans un simple conteneur. Le conteneur peut modifier le lieu d’exécution du processus, mais il ne dissocie pas les interdépendances entre ses composants. Chez Stacklok, le framework open source Mecatl a été mis à disposition à cette fin.
Dans Mecatl, le noyau prend en charge la boucle de l’agent, notamment l’inférence, la distribution des appels d’outils, les autorisations, les hooks et l’émission d’événements. Les autres éléments s’y connectent par l’intermédiaire d’interfaces claires :
- Des clients finaux et des API, dont une TUI appelée mecatui, des interfaces gRPC et HTTP/SSE, ainsi qu’un SDK en TypeScript.
- Des environnements d’exécution, des espaces de travail et des exécuteurs de commandes dans lesquels l’agent réalise ses tâches.
- Un écosystème d’outils comprenant les outils intégrés, les services MCP via HTTP en continu, les compétences et les intégrations propres aux applications.
- Des services de soutien pour gérer les fournisseurs de modèles, l’état des sessions, le journal des événements, l’identité et l’orchestration.
Qu’est-ce qui change concrètement ?
Cette séparation fait de la boucle de l’agent un composant pouvant être versionné, déployé et surveillé comme n’importe quel autre service. Elle peut être exécutée dans un terminal, en tant que service ou sur Kubernetes, sans remplacer la boucle elle-même. Dans le guide mecak8s, les workers peuvent être remplacés pendant l’exécution, tandis que les sessions persistantes sont conservées lors du déploiement d’une nouvelle version.
L’état de la session et le journal des événements sont stockés dans un stockage persistant selon un modèle d’orchestration reposant sur un seul écrivain. Si le worker tombe en panne, un worker de remplacement peut reprendre à partir de la dernière limite de tour enregistrée. Cela n’équivaut toutefois pas à une transaction distribuée : le processus en cours au moment de la défaillance n’est pas repris, et le travail effectué après la dernière sauvegarde réussie peut être perdu. Le projet décrit donc cette capacité comme une continuité au niveau des tours, et non comme une garantie de transaction distribuée complète.
Le catalogue explicite permet également de restreindre les outils, les compétences et les intégrations autorisés, avec des limites de privilèges, d’audit et d’environnement d’exécution. Comme le client ne possède ni le système de fichiers, ni les identifiants, ni l’état de la session, la même boucle peut servir un terminal, un service distant, une application intégrée ou un déploiement Kubernetes, et même relier une interface web, une intégration Slack et un éditeur collaboratif à la même session.
Les questions encore en suspens
La source souligne que Mecatl en est encore à un stade précoce et que la « ceinture cloud native » constitue davantage une orientation architecturale qu’une spécification achevée. L’une des principales questions consiste à déterminer l’identité de l’entité qui appelle un système externe : l’utilisateur, l’agent, la session, ou un agent secondaire à plusieurs niveaux ? Le projet propose un domaine de confiance SPIFFE qui lui est propre, avec l’encodage de la chaîne complète de délégation dans un JWT, afin que les systèmes récepteurs puissent prendre leur décision en fonction de la chaîne des identités.
Le projet étudie également des trajectoires d’outils allant au-delà de MCP, afin qu’un outil tel qu’un analyseur PDF puisse travailler directement sur le système de fichiers au lieu de faire passer toutes ses entrées et sorties par la fenêtre de contexte du modèle. L’idée d’une « preuve de contexte » apparaît également : émettre, signer, attribuer, distribuer le contexte assemblé et le soumettre à des politiques, comme n’importe quel artefact d’une chaîne d’approvisionnement logicielle.
Lecture éditoriale : l’importance de cette proposition ne réside pas dans le lancement d’une nouvelle interface, mais dans la redéfinition de l’agent comme service administrable plutôt que comme processus personnel à longue durée de vie. Toutefois, la source distingue clairement ce qui fonctionne actuellement dans Mecatl de ce qui est encore en phase de conception. En outre, la continuité actuelle n’empêche pas la perte du travail en cours et ne tranche pas encore le modèle d’identité ni le transfert direct de données entre les outils. L’adoption de ce modèle nécessite donc une évaluation pratique de la situation du déploiement, des limites de privilèges et des garanties relatives aux données avant de le considérer comme un remplacement prêt à l’emploi pour tous les frameworks d’agents locaux.