A Hermes Agent profile is a home directory. Each one carries its own config.yaml, .env, SOUL.md, memory store, session logs, skills folder, cron jobs, and state database, all kept apart from the profiles sitting next to it. The unit is the directory, not the chat window, and that is what makes running a coding agent and a research agent on the same machine actually coherent.
Nous Research shipped a Profile Builder this week that turns that directory abstraction into a guided browser form. The Web Dashboard, launched with hermes dashboard and bound to http://127.0.0.1:9119 on loopback by default, walks a user through five setting groups in one flow: identity, model and provider, built-in skills, optional Skills Hub installs, and MCP servers. The dashboard writes to the same files the CLI commands edit, so the form and the command line are interchangeable entry points to the same profile directory, as documented in the official Profiles guide.
The identity field is the one with the most leverage. A profile named coder exposes a coder chat command, a coder setup command, a coder gateway start command, and so on, with the profile name becoming a CLI prefix for every command in that agent's world. Token-locks prevent two profiles from sharing a gateway bot token by accident, which is what lets the same host run several agents at once. Personality does not live in the form. It lives in SOUL.md, which sits in the profile directory and is loaded separately, so the builder is plumbing, not character.
The five groups map to the five questions the CLI used to answer one at a time. Identity captures the name and a short description. Model and provider expose Nous Portal, OpenRouter, NVIDIA, OpenAI, and custom OpenAI-compatible endpoints. Built-in skills are the SKILL.md files shipped with the project, each carrying a name, description, and procedure. The agent reads the short descriptions cheaply and pulls the full procedure only when a task needs it, so adding many skills does not bloat every request. Skills Hub adds community skills with a click. MCP servers attach as either HTTP servers via URL with headers, or stdio servers via local command, with the mcp_servers block in config.yaml keyed by server name, as documented in the Web Dashboard documentation.
The prerequisite install is pip install 'hermes-agent[web,pty]', or hermes-agent[all] for the full extras tuple. The base install ships without the HTTP stack or the PTY helper, which is why the dashboard will not start until the right extras are pulled in. The MarkTechPost walkthrough calls the install hermes-agent[web], but the official Web Dashboard docs list both the web and pty extras, since the pty extra powers the embedded Chat tab in the same dashboard.
Two scope limits matter. First, the dashboard binds to loopback only, so nothing leaves the host unless a user passes --insecure and configures an auth provider, which the docs note fails closed by default. Second, the profile is not a sandbox. It is an isolated home directory, but the local backend does not restrict filesystem access inside that directory, so a profile can still read or write anywhere the host user can. Skill and MCP changes also only take effect on the next session or after a gateway restart, which the builder surfaces but cannot paper over.
Nous Research describes Hermes Agent as an "open-source, self-improving agent" that runs on the CLI, a desktop app, and messaging platforms, with per-profile gateway processes to keep tokens separate. That framing is the project's own positioning, not an independent assessment, and should be read as marketing language rather than capability claim. The release this week is a tooling release: a guided form for assembling an existing abstraction, not a new abstraction and not a new model. MarkTechPost's interactive explainer is labeled by the publisher as a demo simulation rather than the live product, so the running UI is best judged from the official docs and the hermes-agent repository itself.
The watch items are small but concrete. A non-loopback bind story that does not require --insecure would change the deployment shape, and a sandbox mode scoped to the profile directory would change the trust story. Neither is in the current release. Until then, the Profile Builder is a UX layer over the existing CLI inputs, and the profile-as-isolated-home-directory idea is the actual story the builder is exposing.