Nous Research ने अपने open-source Hermes Agent के लिए एक web dashboard शिप किया जो पहले CLI commands की एक श्रृंखला वाली चीज़ को एक isolated agent बनाने के एक guided flow में सिकोड़ देता है। तुम hermes dashboard चलाते हो, यह तुम्हारे browser में एक loopback पते पर खुलता है, और default रूप से localhost से bound रहता है तो कुछ भी मशीन से बाहर नहीं जाता। Installation एक ही line है, pip install hermes-agent web extra के साथ। ऊपर से यह एक छोटा release है, एक ज्यादा अनुकूल प्रवेश-द्वार, पर जिस चीज़ को यह एक साफ आकार देता है वही देखने लायक है: agent profile।

एक profile पांच समूहों में भरा जाता है। पहचान पहले आती है, और नाम सजावटी नहीं है: यह एक shell alias बन जाता है, तो coder नाम का एक profile coder chat को जवाब देता है। फिर model और provider, जो Nous Portal, OpenRouter, NVIDIA, OpenAI, या किसी भी OpenAI-compatible endpoint से चुने जा सकते हैं; toggle होने वाली built-in skills का एक सेट; Skills Hub से identifier द्वारा install किए गए बाहरी skill catalogs; और MCP servers, जो HTTP servers के लिए URL से या stdio servers के लिए local command से जोड़े जाते हैं, एक Nous-अनुमोदित catalog के साथ जो one-click installs देता है। हर profile अपने खुद के home directory में रहता है जिसमें model और MCP settings के लिए एक config.yaml, keys के लिए एक .env, personality के लिए एक SOUL.md, और अलग memory, sessions, skills, cron jobs और एक state database होता है। Isolation ही design है: एक coding agent और एक research agent स्वतंत्र रूप से चलते हैं और कभी state साझा नहीं करते।

जिस runtime प्रतिस्पर्धा को हम track कर रहे हैं, उसके लिए यह agent का Hermes पक्ष है जो खुद को ownable बना रहा है। dashboard और CLI एक ही files संपादित करते हैं, तो GUI कम-घर्षण प्रवेश-द्वार है और CLI scriptable बना रहता है, पर टिकाऊ योगदान नीचे का format है: एक agent को पहचान, model, tools, memory, और एक soul file वाली एक नामित, portable directory में सिकोड़ा गया, जिसे तुम अपनी keys के साथ अपने loopback पर चलाते हो। यह own-the-weights, own-the-runtime रुख का ठोस रूप है, hosted enterprise agent platforms से spectrum के विपरीत छोर पर। ईमानदार सीमाएं बताई गई हैं: local backend पर कोई filesystem sandboxing नहीं, और skills या MCP servers बदलने के लिए session या gateway को restart करना पड़ता है।

यह वहां बैठता है जहां हमारे दो धागे मिलते हैं। एक है subagent specialization, यानी एक अकेले generalist से purpose-built agents की ओर बढ़ना; एक profile बिल्कुल यही है, filesystem MCP और Git skills वाला एक coding agent, web-extract और isolated findings वाला एक research agent, messaging channels और cron reports वाला एक ops bot। दूसरा यह सवाल है कि agent है ही क्या, और यहां format एक रुख लेता है, SOUL.md को config.yaml के बगल में रखकर: यह एक agent की पहचान और personality को एक first-class, संपादन-योग्य file मानता है, उसके model और उसके tools के साथ-साथ, अपनी memory और state के साथ जो टिकते हैं। इसमें कुछ भव्य पढ़ने की ज़रूरत नहीं यह देखने के लिए कि यह ज़मीन में गाड़ा एक ठोस खूंटा है, एक agent एक ऐसी चीज़ के रूप में जिसका एक नाम, एक soul file, और एक memory है जो session से बच जाती है। एक से ज्यादा specialized agent चलाने वाले builders के लिए, व्यावहारिक संस्करण और भी सरल है: per-agent MCP और state वाला एक profile-as-directory shell scripts के ढेर को हरा देता है, और dashboard पहले वाले को एक दोपहर के बजाय एक मिनट में करवा देता है।