Hermes Agent: a local, open agent built around skills

I’ve spent this year building around one idea: that an agent’s skills should be first-class, versioned artifacts, not instructions buried in a system prompt. It is the thread running through my Enterprise Context Layer, where team workflows live as small SKILL.md files loaded only when a task matches. So when I looked at Nous Research’s Hermes Agent, it was the skills system I went to first. It productizes the same shape I have been hand-rolling, and it does the two other things I care about most: it runs locally and it does not lock you to one model.

What this is

Hermes Agent is open source under the MIT license, released earlier this year, and Nous describes it as “the agent that grows with you.” You install it with one command and start it with one command. There is a desktop app for macOS, Windows, and Linux (or a terminal install if you prefer).

The reach is the part that surprised me. A single gateway process connects the agent to Telegram, Discord, Slack, WhatsApp, Signal, email, and the CLI, with shared memory across ALL of them. Ask it something in Slack, follow up from your terminal, and it remembers. It also carries persistent memory across sessions, so it searches its own past conversations rather than starting cold every time.

The skills system, which is the point

A skill in Hermes is a SKILL.md file: markdown with YAML frontmatter naming the skill, a description, a version, and optional platform restrictions, with room for reference docs, templates, and helper scripts alongside it. They live in ~/.hermes/skills/ and follow the open standard at agentskills.io. If you have written a Claude skill, or one of my ECL skills, this will look familiar.

Three things stand out:

Triggering is explicit and cheap. You invoke a skill as a slash command, /skill-name, and you can stack up to five in one message. Skills also surface through ordinary conversation. The progressive-disclosure design means a skill costs almost nothing in tokens until it is actually needed.
It writes its own skills. After a complex workflow, the agent can capture what it did as a new skill through its skill_manage tool. There is a /learn command that points at a directory, a docs URL, or a described procedure and authors a standards-compliant skill without you hand-writing the SKILL.md. This is procedural memory: solve a hard problem once, then keep the solution.
Skills are shareable, with a gate. There is a Skills Hub for official, community, and custom sources, and hub skills are scanned for data exfiltration, prompt injection, and destructive patterns before they land. Agent-written skills can be held behind a skills.write_approval gate so a human signs off before anything commits.

Hermes ships with a broad default library out of the box, which is what makes it usable on day one rather than a framework you have to furnish yourself.

Local and model-agnostic by design

This is where it lines up with what I keep arguing for. All data stays on your machine! No telemetry, no tracking, no cloud lock-in. And the model is yours to choose: point it at Nous’s own Portal, OpenRouter, OpenAI, or your own endpoint, and switch with hermes model, no code changes. Execution is sandboxed across several backends, from a plain local process to Docker, SSH, Singularity, and Modal, so you can run it on a small VPS or inside a hardened container.

That combination, local data plus swappable models plus skills as portable files, is the same posture I described in own the model, not the API. You are not renting a capability from a provider who can change the terms, as you own the pieces.

What I’d be careful about

The self-improving loop is the headline feature and the thing I would watch most closely. An agent that writes its own skills is an agent that can encode a wrong solution as confidently as a right one, and then reuse it. In anything serious I would keep the write-approval gate on and treat agent-authored skills like code: reviewed, versioned, and owned by a person. The hub’s security scanning is good to have, but installing a community skill is still running someone else’s instructions, so the same caution applies.

It is also new. The version numbers are low, and the paid Portal tiers are convenient but beside the point if sovereignty is important. Keep it self-hosted, keep it on the local backend, skip the hub for sensitive work, and you have an agent that fits an air-gapped or regulated environment far better than most.

The larger thing Hermes signals is convergence. Claude’s, PI’s and CODEX’s skills, the lean skills patterns I have been using, and now a full agent built on the same SKILL.md shape are all arriving at the same answer: a skill is a small, described, loadable document, and that is turning into a standard worth building on. That is the part I am most glad to see.

If you are weighing a local, model-agnostic agent for a regulated or air-gapped environment, that is the kind of build I do. Get in touch.