agent-shell : piloter des agents ACP depuis un buffer Emacs natif

Le problème : chaque agent a son propre terminal

Les agents de codage en ligne de commande se multiplient et chacun arrive avec son propre client. Claude Agent, Codex, Gemini CLI, Goose, Grok Build, Cursor, Kimi Code CLI, Qwen Code et d'autres sont cités dans le README comme compatibles avec agent-shell. Sans couche commune, changer d'agent signifie changer d'outil, de raccourcis et de contexte. Le projet adresse ce point précis : offrir un seul buffer Emacs pour dialoguer avec n'importe quel agent qui implémente ACP, l'Agent Client Protocol. Le public visé est donc étroit mais cohérent : des développeurs déjà installés dans Emacs, qui veulent garder leurs habitudes d'édition, leurs buffers et leur configuration Lisp au moment de solliciter un agent. Le README précise que le projet est porté par une personne, Álvaro Ramírez, et qu'il sollicite un financement via GitHub Sponsors pour rendre la maintenance soutenable.

acp.el au milieu : qui parle à qui

agent-shell ne dialogue pas directement avec les agents. Le README indique que le paquet s'appuie sur acp.el, une bibliothèque séparée du même auteur, pour communiquer via ACP. La répartition est donc la suivante : agent-shell fournit l'interface Emacs (le buffer, la saisie, l'affichage des échanges), acp.el assure la couche de protocole, et l'agent tourne de son côté comme un processus externe. Le protocole lui-même est décrit sur agentclientprotocol.com, que le README référence, mais le contenu de cette spécification n'est pas reproduit dans le dépôt. Autrement dit, la documentation disponible explique l'architecture en couches et nomme les agents compatibles, sans détailler le format des messages ni le cycle de vie d'une session. Pour un lecteur qui veut comprendre le flux de données exact, il faudra consulter acp.el et la spécification ACP, pas le README d'agent-shell.

Installation : MELPA et une dépendance externe

Le README affiche le badge MELPA, ce qui situe la distribution du paquet sur ce dépôt. Le nom du paquet est agent-shell et le langage est Emacs Lisp. Le point à ne pas manquer : le paquet Emacs ne suffit pas. Puisque agent-shell s'appuie sur acp.el pour parler ACP, et que chaque agent cité est un outil en ligne de commande distinct, il faut aussi disposer de l'agent choisi sur sa machine et de son propre mécanisme d'authentification. Le README ne détaille ni les commandes d'installation de ces agents, ni les clés de configuration attendues côté Emacs. Il renvoie vers une série de billets de blog listés dans la section News, dont les titres couvrent les versions 0.5, 0.17, 0.25, 0.47, 0.55 et 0.63, et vers deux vidéos YouTube. C'est là, et non dans le README, que se trouvent vraisemblablement les exemples de configuration. Je ne peux pas citer de valeurs de configuration précises : le matériel fourni ne les contient pas.

Un écosystème de greffons plutôt qu'un noyau extensible

Le README liste une vingtaine de projets tiers construits autour d'agent-shell. La liste est instructive sur la philosophie du projet : le noyau reste mince et les besoins périphériques sont traités ailleurs. On y trouve des notifications (agent-shell-knockknock, agent-shell-notifications), un volet latéral (agent-shell-sidebar), la gestion de plusieurs sessions (agent-shell-manager, agent-shell-workspace, agent-shell-hq), des transcriptions Org (agent-shell-org-transcript), l'intégration Tramp (agent-shell-tramp), un backend Org Babel (ob-agent-shell), l'exécution d'agents dans des conteneurs Docker (agent-circus) et même un affichage d'équations LaTeX en SVG (agent-shell-math-renderer). Cette dispersion a un coût : chaque greffon est maintenu par un auteur différent, avec son propre rythme. Rien dans le README n'indique qu'ils sont testés ensemble ou suivis par le projet principal. Pour quelqu'un qui a besoin d'une fonction absente du noyau, la réponse se trouve probablement dans cette liste, mais elle vient avec une dépendance supplémentaire à évaluer séparément.

Ce que la documentation ne dit pas

Plusieurs questions restent sans réponse dans le matériel fourni. D'abord, aucune version publiée n'est listée : le champ des releases récentes est vide, alors que le README mentionne des numéros de version jusqu'à 0.63 dans les billets de blog. Ensuite, la compatibilité entre versions d'agents et versions d'agent-shell n'est pas documentée. Le protocole ACP évolue, les agents cités évoluent aussi, et rien n'indique comment les ruptures sont gérées. Enfin, le cas d'usage multi-agents simultanés n'est pas traité dans le README : plusieurs greffons tiers existent pour la gestion de sessions, ce qui suggère que ce n'est pas un besoin couvert nativement. Ce sont des zones grises, pas des défauts prouvés, mais elles comptent pour quiconque doit décider si l'outil tiendra dans le temps sur un poste de travail.

Face à un client d'agent fourni par l'éditeur

L'alternative la plus évidente est le client d'agent livré avec l'éditeur ou l'outil d'origine : l'interface officielle de Claude Agent, celle de Codex, ou le terminal de Gemini CLI. La différence d'approche est nette. Ces clients sont couplés à un seul fournisseur, mais ils suivent ses fonctionnalités au plus près et sont maintenus par l'équipe qui développe l'agent. agent-shell fait le pari inverse : une couche unique au-dessus d'agents interchangeables, au prix d'une dépendance à ACP et d'un décalage possible quand un agent ajoute une capacité qui n'a pas encore d'équivalent dans le protocole. Le choix se ramène donc à une question de coût de changement. Si vous n'utilisez qu'un seul agent et que son client officiel vous convient, agent-shell ajoute une couche sans bénéfice direct. Si vous alternez entre plusieurs agents, ou si vous voulez que vos sessions vivent dans Emacs à côté de votre code, l'abstraction devient utile. Il faut noter que le projet se présente explicitement comme financé par ses utilisateurs, ce qui est une donnée à intégrer dans l'évaluation de sa pérennité.

Licence GPL-3.0 et coût de maintenance

Le dépôt est publié sous GPL-3.0, un point qui n'est pas anodin pour un paquet Emacs Lisp. Cette licence est compatible avec la distribution sur MELPA et avec l'usage dans une configuration Emacs personnelle. Elle impose en revanche des obligations dès qu'on redistribue du code dérivé : toute œuvre dérivée distribuée doit rester sous la même licence. Je ne donne pas de conseil juridique ici, et le texte de la licence fait foi. Sur le coût de maintenance, le matériel disponible est limité. Le dépôt n'est pas archivé et le dernier push enregistré date du 8 septembre 2026, ce qui indique une activité, mais je ne peux rien affirmer sur le rythme des publications ni sur la politique de compatibilité. Le README lui-même indique que le projet cherche un financement pour rendre son entretien soutenable, ce qui est un signal direct sur la charge que représente la maintenance d'un paquet qui doit suivre l'évolution de plusieurs agents et d'un protocole.

Conclusion éditoriale

agent-shell s'adresse aux utilisateurs d'Emacs qui veulent garder leurs sessions d'agent dans un buffer, avec un choix d'agent non figé par l'éditeur. Ceux qui cherchent une interface graphique autonome ou qui refusent d'installer un CLI tiers par agent passeront leur chemin. Avant d'adopter, vérifiez deux choses concrètes : que votre agent figure dans la liste du README et qu'il expose bien une interface ACP, puis lisez les notes de version liées dans la section News, car la documentation du dépôt ne décrit pas le comportement du protocole lui-même.

Sources officielles

1. Issues
2. License: GPL-3.0
3. Project website
4. README
5. xenodium/agent-shell on GitHub