Hermes Agent Profiles: How to Isolate Work, Personal, and Bot Agents

Hermes Agent profiles are the clean way to run separate agents without mixing memory, secrets, skills, sessions, or gateway bots. If you use Hermes for work, personal automation, a Telegram bot, and a risky test project, do not cram everything into one ~/.hermes directory. Create profiles and give each context its own boundary.

When you should create a profile#

Create a Hermes profile whenever the boundary matters more than convenience. Good examples:

• Work vs personal: keep company credentials, repositories, calendars, and memory separate from personal automations.
• One profile per client: prevent one client skill or AGENTS.md convention from leaking into another engagement.
• One profile per public bot: a Telegram community bot should not have the same secrets as your private assistant; use a dedicated profile with its own token and gateway. See the Telegram integration and Telegram setup guide.
• Testing dangerous tools: try new MCP servers, plugins, browser automation, or terminal backends in a disposable profile before enabling them in your main agent.
• Different model/provider budgets: keep an expensive coding profile on a frontier model while a lightweight monitoring profile uses a cheaper provider.

Do not use profiles as cosmetic labels. Use them when memory, tools, tokens, or operational risk should be isolated.

What a Hermes profile isolates#

A profile is a full Hermes home directory with its own durable state. In practice, that means:

• config.yaml for model, tool, gateway, terminal, memory, and display settings.
• .env for profile-specific API keys and platform tokens.
• skills/ for reusable procedures loaded only by that profile.
• sessions/ for transcript history and resume/continue behavior.
• memory files and provider settings for persistent memory.
• gateway state for platform adapters such as Telegram, Discord, Slack, Email, and Webhooks.

That isolation is why profiles are better than prompt instructions for secret scoping. If a token exists in one shared environment, the shared agent can use it. If a token exists only in a profile-specific .env, other profiles do not get it.

Copy-paste setup: work and personal profiles#

Create two profiles:

hermes profile create work
hermes profile create personal

Show where each profile stores config and secrets:

hermes -p work config path
hermes -p work config env-path
hermes -p personal config path
hermes -p personal config env-path

Run a one-off command in the work profile:

hermes -p work chat -q "Summarize the open PRs in this repository"

Make one profile your default:

hermes profile use personal
hermes chat -q "What profile am I using?"

List profiles when you forget what exists:

hermes profile list

The -p flag is the safest habit for automation because scripts, cron jobs, and launch services should not depend on whichever profile happened to be sticky in your shell.

Profile pattern for a Telegram or Discord bot#

A messaging bot should normally get its own profile. That is especially important for a public or semi-public bot, because the profile boundary controls which secrets, tools, skills, and memory the bot can reach.

Recommended pattern:

1. Create the profile.
2. Put only the bot token and required provider keys in that profile's .env.
3. Enable only the toolsets the bot needs.
4. Configure the gateway inside that profile.
5. Start or install the gateway for that profile.

Example:

hermes profile create telegrambot
hermes -p telegrambot config env-path
hermes -p telegrambot gateway setup
hermes -p telegrambot gateway run

For a team bot, add only the skills you want that bot to use. The custom skills guide explains how skills are stored and structured. If you are migrating existing instructions, the Claude Code skills migration guide shows how to convert them into Hermes-compatible procedures.

Profile pattern for model and provider experiments#

Profiles also make model testing less chaotic. Instead of constantly changing your main config, create an experiment profile and point it at a different provider:

hermes profile create localtest
hermes -p localtest model
hermes -p localtest chat -q "Run a small coding task and explain tool usage"

This keeps your main sessions, memory, and cost assumptions stable while you test local models, OpenRouter routing, Nous Portal OAuth, or other providers. For agent behavior comparisons, pair this with Hermes Agent vs Claude Code or the Hermes CLI reference page so the test is about workflow, not just raw model output.

How to move or clone a profile#

Use export/import when you need a portable backup or a second machine:

hermes profile export work
hermes profile import work.tar.gz

Use clone commands when you want a profile that starts from an existing setup but can diverge afterward:

hermes profile create client-acme --clone work

After cloning, immediately inspect the new .env and remove secrets that do not belong in the new context. Clone convenience should not become secret sprawl.

Common mistakes#

Mistake 1: using one profile for every bot#

This is convenient until one bot can access another bot's secrets or memory. Use separate profiles for different trust levels.

Mistake 2: copying the entire default .env#

Copy only required keys. A read-only community bot probably does not need GitHub, Stripe, production database, and browser automation credentials.

Mistake 3: relying on the sticky profile in scripts#

Automation should be explicit:

hermes -p reporting cron list
hermes -p reporting chat -q "Generate today's report"

Mistake 4: treating profiles as permission sandboxes#

Profiles isolate files and configuration, but they are not a replacement for least-privilege API tokens, OS permissions, or a hardened server. For internet-facing deployments, combine profiles with Hermes security hardening.

FAQ#

Are Hermes profiles the same as sessions?#

No. A session is one conversation history inside a Hermes home. A profile is an isolated Hermes home with its own sessions, memory, config, skills, and secrets.

Can two profiles share one skill?#

Yes, but copy it intentionally or install it separately. If a skill contains project-specific assumptions, keep it profile-specific.

Can one Telegram bot switch between profiles?#

Do not design it that way. Give each trust boundary its own bot token and profile. It is clearer operationally and safer for secrets.

Should I migrate everything from OpenClaw into one Hermes profile?#

Usually no. Start clean, then cherry-pick the secrets and skills you actually want. A blank Hermes profile is the easiest way to avoid importing old clutter.

Which profile should I use for FlyHermes?#

If you want a hosted path instead of managing profiles, gateways, and uptime yourself, FlyHermes is the natural commercial route. Use local profiles when you want direct control over a self-hosted Hermes installation.

Recent support signal: profiles are the clean boundary for messy installs#

Recent threads about copying Hermes between Linux machines, model-switch resets, memory failures, and gateway confusion all point to the same operational lesson: do not mix every project, provider, bot, and experiment into one shared profile.

Use separate profiles for production gateways, local experiments, high-risk MCP servers, and team/customer workflows. If the profile matrix starts to feel like infrastructure work, compare that self-managed path with FlyHermes, especially for always-on business workflows.