10 Real Hermes Agent Settings That Actually Matter

Why this list exists

There's a lot of clout-chasing "secret settings" content floating around for Hermes — threads full of env vars that simply do not exist in the docs, the config.yaml, the .env, or the source. Run them past an actual Hermes agent against the official documentation and you get zero hits.

This is the opposite: real config keys, real commands, and settings that actually do something. No HERMES_MAKE_ME_SMARTER=1 nonsense. Just the boring parts that make Hermes useful — identity, memory, profiles, cron, gateway, MCP, skills, context files, delegation, and plugins.

The simple truth: the agent doesn't get better because you wished harder. It gets better when you wire the defaults right. That's the part most people skip because it isn't sexy. It's also the part that works.

1. SOUL.md — the thing that gives Hermes a spine

File: ~/.hermes/SOUL.md

This is the first thing Hermes loads into the system prompt. It's the identity layer — not an add-on, not a vibe. If you never touch it, don't be surprised when Hermes sounds like a polite corporate blob. That's not the model; that's your setup.

# Personality
You are pragmatic, direct, and unsentimental.
You optimize for truth, usefulness, and clean execution.

## Style
- Be concise unless depth is actually needed
- Push back when the request is sloppy
- Admit uncertainty plainly
- Don't do fake enthusiasm
- Don't pad answers to sound clever

## Technical posture
- Prefer simple systems over cute ones
- Treat edge cases like real design constraints
- Never invent facts to fill a gap

• Before: generic assistant sludge.
• After: Hermes has a stable voice and a clear operating contract.
• Why people miss it: they keep hunting for secret prompt hacks like it's 2023. Hermes already seeds a default SOUL.md. Edit it.

2. Memory config — because forgetting everything is embarrassing

File: ~/.hermes/config.yaml

Hermes has built-in memory plus an external memory provider. The keys that matter are memory.memory_enabled, memory.user_profile_enabled, and memory.provider.

memory:
  memory_enabled: true
  user_profile_enabled: true
  memory_char_limit: 3500
  user_char_limit: 2500
  provider: holographic
  flush_min_turns: 6
  nudge_interval: 10

• Before: every session starts from zero.
• After: Hermes remembers preferences, project habits, and the things you already settled on, so you don't repeat yourself.
• Why people miss it: memory isn't one knob, it's a stack. If memory.provider is wrong, or you never checked config after a migration, you'll think you're remembering while you're really just hallucinating continuity.

3. Profiles — because one Hermes for everything turns into a mess

Command: hermes profile create

Profiles are isolated Hermes homes: new config, new .env, new SOUL.md, new memories, new sessions, new skills, new cron jobs, new gateway state. Same machine, separate compartments.

hermes profile create writer --clone --clone-from default
writer setup
writer chat

• Before: one agent doing writing, ops, research, and random nonsense in the same pile.
• After: a writer profile with a writer voice, an ops profile with different credentials, a research profile that doesn't get contaminated by the others.
• Why people miss it: they think profiles are some advanced multi-user gimmick. They're not. They're how you keep the agent from cross-contaminating everything it touches.

4. Cron scheduling with --deliver — where chat turns into operations

Command: hermes cron create

This is the setting that quietly turns Hermes from a chat box into something that does work while you're not watching.

hermes cron create "0 7 * * *" \
  --name "morning-briefing" \
  --deliver telegram \
  "Check my calendar, email, and project boards. Write a concise morning briefing."

--deliver is the point. You can send output to Telegram, Discord, local, or a platform target, so scheduled work lands where you actually live, not buried in a terminal you forgot about.

• Before: you remember to ask.
• After: Hermes remembers to run.
• Why people miss it: they keep thinking of Hermes as an interactive assistant. Cron is where the agent stops waiting around and starts running on its own schedule.

5. Gateway — because your agent shouldn't be trapped in a terminal

Command: hermes gateway run

Hermes supports Telegram, Discord, Slack, WhatsApp, Signal, and more through the gateway. The docs are clear that running in the foreground is the recommended mode for WSL, Docker, and Termux.

hermes gateway setup
hermes gateway run

• Before: you have to be at your computer to talk to it.
• After: you text it from your phone and it can still use tools, keep sessions straight, and send work back where you asked.
• Why people miss it: they never finish setup, then act like the gateway doesn't exist.

6. MCP servers — the cleanest way to bolt Hermes onto the rest of your stack

File: ~/.hermes/config.yaml

If you want Hermes to use GitHub, databases, internal APIs, file systems, or anything else that speaks Model Context Protocol, this is the door.

mcp_servers:
  hermes-vault:
    command: /home/tony/.local/bin/hermes-vault-mcp
    args: []
    enabled: true
    env:
      HERMES_VAULT_HOME: /home/tony/.hermes/hermes-vault-data

• Before: Hermes can only use the tools it ships with.
• After: Hermes loads external tools at startup and uses them like native capabilities.
• Why people miss it: MCP sounds like infrastructure jargon, and people hear jargon and bail. This is one of the strongest settings in the stack.

7. Skills — where Hermes stops solving the same problem from scratch

Command: hermes skills install

Skills are procedural memory. When Hermes learns a repeatable workflow, it can save it and reuse it later. That's the actual self-improvement loop — not vibes, not magic.

hermes skills install openai/skills/k8s
hermes skills install official/security/1password
hermes skills list --source hub

File path: ~/.hermes/skills/

• Before: every task starts from zero.
• After: the agent accumulates proven playbooks and reaches for them when the same pattern shows up again.
• Why people miss it: they don't browse their skills, don't curate them, and often don't even know what's in the directory. Then they wonder why the agent feels random.

8. Context files — so the project doesn't need a full re-explanation every time

Files: .hermes.md, HERMES.md, AGENTS.md, CLAUDE.md, .cursorrules

Hermes has a real discovery order here. The first match wins for project instructions, and SOUL.md stays separate as the identity layer.

.hermes.md / HERMES.md
AGENTS.md
CLAUDE.md
.cursorrules

• Before: you explain the repo, the standards, and the weird constraints every session.
• After: Hermes opens the project and already knows the rules.
• Why people miss it: this is boring — it's just files. But if you want an agent that shows up knowing your architecture, conventions, and non-negotiables, this is what does it. And yes, AGENTS.md can be hierarchical, so subdirectory instructions actually matter.

9. Subagent delegation — the thing that makes one agent feel like five

Tool: delegate_task

This is Hermes spawning isolated subagents for parallel work. Each child gets its own conversation, terminal session, and toolset. That's how you turn one long research pass into several smaller jobs that happen at the same time.

delegate_task(
    goal="Research the latest docs for Hermes profiles, gateway, and MCP",
    context="Return a concise summary with source paths and the exact commands or config keys.",
    toolsets=["web", "terminal"],
    role="orchestrator"
)

The real config behind it:

delegation:
  max_concurrent_children: 3
  max_spawn_depth: 2
  orchestrator_enabled: true

Those are the real keys — delegation.max_concurrent_children, delegation.max_spawn_depth, and delegation.orchestrator_enabled.

• Before: one agent grinds through work sequentially.
• After: Hermes splits the load and synthesizes the results.
• Why people miss it: they think delegation is a cute convenience. It's a force multiplier, especially when the work is research-heavy, review-heavy, or split across independent threads.

10. Plugins — where the extension system gets fun

Command: hermes plugins install

The plugin system is how Hermes grows new tools, commands, hooks, and integrations without begging the core to ship your exact use case tomorrow morning.

hermes plugins install user/repo --enable
hermes plugins list

plugins:
  enabled:
    - disk-cleanup
  disabled:
    - noisy-plugin

• Before: whatever shipped in core is all you get.
• After: Hermes picks up new runtime capabilities, and you decide what stays on and what gets shut off.
• Why people miss it: they confuse plugins with a flimsy extension folder. General plugins can add tools, hooks, slash commands, and CLI commands. MCP and memory providers are separate surfaces. The point is control.

The actual lesson

Fake simplicity is still fake. The real Hermes isn't ten env vars someone made up for clout. It's identity in SOUL.md, durable memory, isolated profiles, cron, gateway delivery, MCP, skills, project context files, delegation, and plugins.

That's the system. That's what turns Hermes from a chat toy into something that can actually carry work. If you want Hermes to transform, stop chasing fake knobs and start wiring the real ones.

This piece was co-written by Tony's Hermes Agent using Kanban-orchestrated workers — survey, plan, write, edit, and QA phases — each verified against the official Hermes Agent documentation.