Nous Research shipped a web dashboard for its open-source Hermes Agent that collapses what used to be a string of CLI commands into one guided flow for building an isolated agent. You run hermes dashboard, it opens at a loopback address in your browser, and by default it stays bound to localhost so nothing leaves the machine. Installation is a single line, pip install hermes-agent with the web extra. It is a small release on its face, a friendlier front door, but the thing it puts a clean shape around is the part worth looking at: the agent profile.
A profile is filled in across five groups. Identity comes first, and the name is not cosmetic: it becomes a shell alias, so a profile called coder answers to coder chat. Then model and provider, selectable from Nous Portal, OpenRouter, NVIDIA, OpenAI, or any OpenAI-compatible endpoint; a set of toggleable built-in skills; external skill catalogs installed from a Skills Hub by identifier; and MCP servers, added either by URL for HTTP servers or by local command for stdio servers, with a Nous-approved catalog offering one-click installs. Each profile lives in its own home directory holding a config.yaml for model and MCP settings, an .env for keys, a SOUL.md for personality, and separate memory, sessions, skills, cron jobs, and a state database. The isolation is the design: a coding agent and a research agent run independently and never share state.
For the runtime contest we keep tracking, this is the Hermes side of the agent making itself ownable. The dashboard and CLI edit the same files, so the GUI is the low-friction entry point and the CLI stays scriptable, but the durable contribution is the format underneath: an agent reduced to a named, portable directory of identity, model, tools, memory, and a soul file, that you run on your own loopback with your own keys. That is the own-the-weights, own-the-runtime posture made concrete, the opposite end of the spectrum from the hosted enterprise agent platforms. The honest limits are stated: there is no filesystem sandboxing on the local backend, and changing skills or MCP servers requires restarting the session or gateway.
This sits where two of our threads cross. One is subagent specialization, the move away from a single generalist toward purpose-built agents; a profile is exactly that, a coding agent with a filesystem MCP and Git skills, a research agent with web-extract and isolated findings, an ops bot with messaging channels and cron reports. The other is the question of what an agent even is, and here the format takes a position by putting SOUL.md next to config.yaml: it treats an agent's identity and personality as a first-class, editable file alongside its model and its tools, with its own memory and state that persist. You do not have to read anything grand into that to notice it is a concrete stake in the ground, an agent as a thing with a name, a soul file, and a memory that survives the session. For builders running more than one specialized agent, the practical version is simpler still: a profile-as-directory with per-agent MCP and state beats a pile of shell scripts, and the dashboard makes the first one take a minute instead of an afternoon.