Nous Research Ships Hermes Agent Profile Builder: Identity, Model, Skills, and MCP Servers in One Dashboard Flow
Nous Research has shipped a Profile Builder for Hermes Agent.

Nous Research has shipped a Profile Builder for Hermes Agent. It lives inside the project’s local web dashboard. Standing up a distinct agent used to mean several CLI steps. The builder now walks you through one guided flow.
In that flow you define an agent’s identity. You pick a model and provider. You choose built-in and optional skills. You install skills from the hub. You attach MCP servers.
Hermes Agent is Nous Research’s open-source, self-improving agent. It runs on the CLI, a desktop app, and messaging platforms. Profiles were previously assembled mostly through terminal commands. The Profile Builder brings those pieces into a browser form.
A profile in Hermes is a separate home directory. Each profile holds its own config.yaml , .env , and SOUL.md . It also keeps separate memory, sessions, skills, cron jobs, and a state database.
Profiles let you run isolated agents on one machine. A coding agent and a research agent never share state. This is the unit the builder produces.
You launch the dashboard by running hermes dashboard . It opens at http://127.0.0.1:9119 in your browser. The default bind is loopback, so no data leaves localhost. The builder collects the same inputs the CLI profile commands accept. It then writes them into the profile’s files.
The builder gathers five groups of settings in one place:
Two of these terms deserve a short explanation.
Skills are SKILL.md files with a name, a description, and a procedure. The agent reads short descriptions cheaply. It loads a skill’s full content only when a task needs it. So adding many skills does not bloat every request.
MCP servers expose external tools through the Model Context Protocol. Hermes accepts HTTP servers via a URL. It also accepts stdio servers via a local command. A Nous-approved catalog offers one-click installs, prompting inline for any keys.
The builder does not replace the CLI. It mirrors it in a form. The table below maps each step to its command equivalent.
Both paths edit the same profile directory. The builder is the lower-friction entry point. The CLI remains the scriptable one.
In each case, the builder produces one isolated agent. You can run several without state collisions.
The builder edits files the CLI already reads. Model and provider land in the profile’s config.yaml . MCP servers populate the mcp_servers block in that file. API keys go to the profile’s .env .
Source: MarkTechPost