Nous Research a livré un dashboard web pour son Hermes Agent open-source qui réduit ce qui était une suite de commandes CLI en un seul flow guidé pour bâtir un agent isolé. Tu roules hermes dashboard, ça ouvre à une adresse loopback dans ton navigateur, et par défaut ça reste bound à localhost donc rien quitte la machine. L'installation est une seule ligne, pip install hermes-agent avec l'extra web. C'est une petite release en surface, une porte d'entrée plus accueillante, mais la chose autour de laquelle ça met une forme propre est la partie qui vaut le coup d'œil : le profil d'agent.
Un profil se remplit à travers cinq groupes. L'identité vient en premier, et le nom est pas cosmétique : il devient un alias shell, donc un profil appelé coder répond à coder chat. Ensuite modèle et provider, sélectionnables depuis Nous Portal, OpenRouter, NVIDIA, OpenAI, ou n'importe quel endpoint OpenAI-compatible ; un ensemble de skills intégrées activables ; des catalogues de skills externes installés depuis un Skills Hub par identifiant ; et des serveurs MCP, ajoutés soit par URL pour les serveurs HTTP soit par commande locale pour les serveurs stdio, avec un catalogue approuvé par Nous qui offre des installs en un clic. Chaque profil vit dans son propre répertoire home contenant un config.yaml pour les réglages de modèle et MCP, un .env pour les clés, un SOUL.md pour la personnalité, et de la mémoire, des sessions, des skills, des cron jobs et une base de state séparés. L'isolation est le design : un agent de code et un agent de recherche roulent indépendamment et partagent jamais de state.
Pour la compétition de runtime qu'on track, c'est le côté Hermes de l'agent qui se rend ownable. Le dashboard et le CLI éditent les mêmes fichiers, donc le GUI est la porte d'entrée à basse friction et le CLI reste scriptable, mais la contribution durable c'est le format en dessous : un agent réduit à un répertoire nommé et portable d'identité, modèle, outils, mémoire, et un fichier soul, que tu roules sur ton propre loopback avec tes propres clés. C'est la posture own-the-weights, own-the-runtime rendue concrète, le bout opposé du spectre par rapport aux plateformes d'agent enterprise hébergées. Les limites honnêtes sont énoncées : y'a pas de sandboxing de filesystem sur le backend local, et changer les skills ou les serveurs MCP demande de redémarrer la session ou le gateway.
Ça s'assoit où deux de nos fils se croisent. Un, c'est la spécialisation de subagent, le move loin d'un seul généraliste vers des agents purpose-built ; un profil c'est exactement ça, un agent de code avec un MCP filesystem et des skills Git, un agent de recherche avec du web-extract et des findings isolés, un ops bot avec des canaux de messagerie et des rapports cron. L'autre, c'est la question de ce qu'un agent est même, et ici le format prend position en mettant SOUL.md à côté de config.yaml : il traite l'identité et la personnalité d'un agent comme un fichier first-class, éditable, à côté de son modèle et de ses outils, avec sa propre mémoire et son state qui persistent. T'as pas besoin de lire quelque chose de grandiose là-dedans pour remarquer que c'est un repère concret planté dans le sol, un agent comme une chose avec un nom, un fichier soul, et une mémoire qui survit à la session. Pour les builders qui roulent plus qu'un agent spécialisé, la version pratique est plus simple encore : un profil-comme-répertoire avec du MCP et du state par-agent bat un tas de scripts shell, et le dashboard fait que le premier prend une minute au lieu d'un après-midi.