Hi, I'm Lena. I had a question I kept putting off. I finally tried to answer it.

A few weeks ago, I was switching between two Hermes agents on the same machine — one I'd set up for personal experiments, the other tied to a small client project. They were sharing the same config directory by accident. I didn't notice at first. Then a session memory from the personal agent showed up in a conversation it shouldn't have. I paused for a long time after seeing that. The agents weren't actually separated. They just looked like they were.

That's when I started reading more carefully about what Hermes Agent profiles actually do — not the surface command, but what gets isolated and what doesn't. This is what I've pieced together so far. I don't think I have the full picture yet, but the pieces I do have feel worth writing down.

I'm writing this for the people who've moved past running a single agent and started running several. That moment when you realize you need more than one is also the moment most isolation problems start. The defaults that worked for one agent don't work for two, and they fail in quiet ways you don't notice until something has already crossed a boundary.

What Hermes profiles really isolate

A profile, as I now understand it, is a named scope that holds everything an agent instance needs to behave like itself: its config, memory, sessions, registered skills, gateway state, and environment variables. When you switch profiles, you're not just changing a setting — you're swapping the entire context the agent operates inside. That distinction matters more than I initially gave it credit for.

Config, memory, sessions, skills, gateway state, env

I went back and looked at this list more carefully, and the part that surprised me is how much state lives at this scope. If you've used environment variables in any serious CLI tool, the pattern feels familiar. Each profile carries its own:

Config — model selection, temperature, system prompt overrides, tool permissions
Memory — long-term context the agent has accumulated over time
Sessions — active conversation threads, including resumable ones
Skills — registered capabilities and their scoped credentials
Gateway state — routing rules, MCP server registrations, network policies
Env vars — API keys, endpoints, secrets

The thing I want to highlight: this is a security boundary, not just an organizational one. When OWASP describes how to harden agent architectures, isolating memory and context between sessions is one of the first defenses listed. Profiles are how Hermes implements that idea on a per-agent basis. I read that cheat sheet twice before this clicked for me.

I'm still not sure I fully understand how gateway state propagates across profiles in some edge cases — for instance, when two profiles register the same MCP server with different scopes. That's something I want to look at more. My current guess is that registration is per-profile but the underlying connection pool may not be, which would matter if you're doing anything stateful at the gateway layer. I haven't confirmed that. I'm leaving the question open.

Create and manage multiple profiles

When I first tried this, I overcomplicated it. The basic flow turned out to be simpler than I expected, but the conventions you build around it matter more than the commands themselves.

Naming, alias commands, switching, export and import

The convention I've settled on — and this is just my own habit, not a rule — is <context>-<role>: personal-research, work-coding, client-acme-prod. Naming matters more than I initially thought. When you have six profiles and you're tired, a profile called test2 is a future incident waiting to happen. I've made that mistake. The day you accidentally run a destructive command in test2 thinking it was the sandbox is the day you start naming profiles seriously.

Switching is meant to be a single command. Export and import let you move profiles between machines, which I tested once on a fresh laptop. The export bundle includes config but excludes raw secrets — you have to re-inject those on the receiving end. I think that's the right default, though it's also the part most likely to trip people up. A few people I've talked to expected secrets to migrate with the profile and were surprised when their imported agent failed to authenticate.

A small thing I noticed: aliasing common profile-switch commands at the shell level made this much less painful. If you're switching three or four times a day, friction adds up — and friction is what makes people skip the switch and reuse the wrong profile.

Real use cases for profiles

This is where I had to stop and think about who actually needs this. Not everyone running an agent needs profiles. But if any of these describe you, I think you do.

Personal vs work, coding vs research, prod vs test

The clearest case is personal vs work. Different memory, different skills, different credentials. You don't want your weekend side-project agent to have access to your employer's database, and you don't want your work agent remembering your grocery lists. The mental separation is also real — switching profiles is a small ritual that helps me change context, not just configuration.

The second case is coding vs research. A coding agent benefits from aggressive tool permissions — file writes, shell execution, repo access. A research agent doesn't need any of that, and giving it those permissions enlarges the attack surface for nothing. This is where the principle of least privilege becomes practical rather than abstract: each profile gets only the permissions it actually needs, and nothing more. I used to grant permissions broadly because it was easier. I don't anymore.

The third case is prod vs test, which is the one most people underestimate until something goes wrong. A test agent should never be one keystroke away from production credentials. Microsoft's guidance on agent governance frames this as project-level data isolation to prevent cross-contamination between agent contexts. Profiles are how that becomes enforceable on a single workstation, without spinning up separate VMs or containers for what should be a lightweight separation.

I had a fourth case start showing up recently that I didn't expect: stable vs experimental. A stable profile with tested skills and known-good configs, and an experimental profile where I try out new tools, prompt variations, or model swaps. The experimental profile breaks regularly. The stable one doesn't, because nothing is allowed to touch it casually. This separation has saved me more debugging time than I expected.

…not quite what I expected, but the more I work with profiles, the more they feel like the basic unit of safe agent operation, not an optional extra.

Common profile mistakes

I've made most of these. Some I noticed quickly. Others took weeks.

Sharing credentials across profiles. This is the most common one and the most dangerous. People create a separate profile but reuse the same API key across all of them. The profiles are isolated; the credentials are not. If one profile gets compromised, every profile that shares the key is compromised too. IBM's AI agent security tutorial is direct about this — over-permissioning and shared credentials are a primary failure mode for agent systems. The fix is unglamorous: separate keys per profile, scoped to the minimum each profile needs.

Wrong expectations about session continuity. Switching profiles ends the active session. Some people assume sessions follow them across profiles. They don't. If you need continuity, stay in one profile. If you need isolation, switch — and accept that you're starting a new conversation context. I've seen people fight this assumption for weeks before they internalize it.

Mixed tool configs. Loading the same skill into multiple profiles with different scopes. The skill behaves differently depending on which profile it's running under, which makes debugging genuinely confusing. I'd suggest treating skills as profile-scoped from the start, even if it means some duplication. Duplication is cheap. Debugging a skill that behaves inconsistently across profiles is not.

I might be reading too much into this last one, but it's caught me twice now, so I'm flagging it.

How profiles change deployment and governance decisions

This is the part I'm still working out, and I want to be honest that my understanding here is incomplete.

When profiles are taken seriously, they stop being a personal-organization tool and become a governance primitive. A team can require that production agent profiles use specific gateway configurations. An auditor can ask which profile generated a given action — and get a real answer instead of a shrug. This aligns with how NIST's AI Risk Management Framework treats accountability: every action should be traceable to a defined scope of authority. Profiles give you that scope without inventing one.

The 2025 NIST update on agentic AI goes further. The Cybersecurity AI Profile draft treats single-agent and multi-agent deployments as distinct risk categories, each with its own isolation requirements. Profiles are one concrete way to meet those requirements without standing up separate infrastructure for every agent. For small teams, that matters — most people don't have the budget or time to run isolated environments per agent, but they can run isolated profiles per agent.

I'm not ready to make strong claims about what this means for self-hosting setups or larger team deployments. I've only tested it at small scale, and I haven't run it long enough to see what fails at higher load. But the direction feels right: identity and isolation should live at the agent level, not the machine level. When that's true, agents become composable building blocks instead of monolithic processes that need to be trusted as a whole.

FAQ

Do profiles share any state at all?

The profile boundary is meant to be hard. The one place you'll see overlap is the underlying Hermes binary itself — same version, same global defaults — but everything stateful is profile-scoped, as far as I've observed.

Can I run two profiles simultaneously?

Yes, in separate terminal sessions. They don't interfere, as far as I've seen. I've run three at once for short stretches without obvious issues.

What's the safest default for a new profile?

Minimal permissions, no production credentials, no shared API keys. Add capabilities only when you actually need them. This is boring advice but it's the advice I wish I'd taken earlier.

Should every project get its own profile?

…I don't know. For small experiments, probably not. For anything touching production, real client data, or sensitive credentials, yes. The cost of creating a profile is low. The cost of not having one when you needed one is sometimes very high. That's where I'll leave it for now. I'll keep watching how this behaves as I add more profiles. Something's happening here in how agent infrastructure is starting to mature, and I don't fully see the shape of it yet.

👉 If you're still unclear how Hermes memory behaves across contexts, read:Hermes Agent Memory Limits & Tradeoffs Explained

👉 For a deeper look at avoiding hidden risks when extending agents with external tools:How to Use MCP Safely with Hermes Agent

👉 If you're running multiple agents across environments, this breakdown helps:Hermes Agent vs EvoMap: Memory Architecture Differences

👉 To understand how agent capabilities differ from stored knowledge (critical for profile design):Agent Skills vs GEP Assets: What Actually Persists

👉 And if you're thinking about long-term agent evolution beyond profiles:EvoSkills: Self-Evolving Agent Skills in Practice