Hermes Agent Profiles: My Four Specialist AI Agents

One agent can do many jobs. Separate profiles make sure every job has an owner.

When I first installed Hermes, I used the default profile for everything.

That was the right way to start. I was learning the system, setting up Telegram, testing memory, and checking whether the agent could operate files and tools on my VPS. Creating an organization chart before the first useful prompt would have been pure over-engineering.

Then the default profile became responsible for groceries, reminders, web research, coding, and public writing.

It could attempt all of them. That was the problem.

A coding session filled its context with repositories, build commands, and debugging decisions. A household session needed food inventory and expiry dates. A content session needed my voice guide and publication workflow. Research needed primary sources and citations.

The model was capable, but the ownership was unclear.

That is when I moved from one general profile to four specialist Hermes Agent profiles:

• assistant
• researcher
• coder
• content

A Hermes profile is a separate agent home with its own identity, configuration, memory, sessions, skills, scheduled jobs, model settings, credentials, and gateway state. The profiles run on the same Hermes installation, but they do not have to think, remember, or operate like the same agent.

This separation changed how the whole system works.

A Hermes profile is more than a different prompt

It is tempting to think of profiles as personas.

One prompt says, “You are a coder.” Another says, “You are a researcher.” Same agent underneath, different costume.

Hermes profiles go further. Each profile gets a separate HERMES_HOME. That directory contains its own:

• config.yaml
• .env
• SOUL.md
• memories/ (MEMORY.md, USER.md)
• sessions
• skills
• cron jobs
• logs
• state database (state.db)
• gateway state

The SOUL.md defines the role and operating rules. config.yaml controls the model, tools, terminal behavior, memory provider, and other settings. Sessions and memory stay inside the profile instead of blending into one history.

Agent behavior comes from more than the current prompt.

The model also sees its system instructions, persistent memory, available tools, project context, conversation history, and working directory. When those belong to five unrelated jobs, the model spends part of every task deciding which version of itself to be.

Profiles remove that ambiguity.

My content profile does not need pantry history. My assistant does not need a TypeScript repository’s build failures. My researcher should not remember an editorial preference as if it were evidence. My coder should not publish a post because it happened to help generate one.

The role is smaller, so the decisions become cleaner.

Why I stopped using one agent for everything

The first issue was context contamination.

A long coding session leaves useful technical context behind. That context becomes noise when the next request is a grocery reminder. The same thing happens in reverse: household details do not help a coding model inspect a failing test suite.

The second issue was memory ownership.

Hermes memory is profile-scoped by design. That gives every agent a smaller set of durable facts to maintain. The assistant can remember how I handle everyday operations. The content agent can remember where drafts live and how approval works. The coder can remember repository conventions and verification rules.

The third issue was tool ownership.

A researcher needs web access and citation discipline. A coder needs terminal, file editing, testing, and code-review workflows. A content agent needs access to Content Forge and my writing context. Giving every profile every tool creates more ways to do the wrong work in the wrong place.

The fourth issue was accountability.

When one agent researches, implements, verifies, writes the announcement, and declares success, its own assumptions survive every stage. A specialist handoff introduces a useful boundary. Research produces sources. Coding produces a diff and test output. Content produces a draft. I can inspect each artifact before the next role uses it.

The split is not about making the agents look like a company. It is about knowing who owns the next decision.

The four specialist profiles in my setup

This is the current division of work:

The contract matters more than the profile name.

Each profile has an explicit does, does not, and how it operates section in SOUL.md. That prevents the soft version of role separation where every agent is “specialized” until a task crosses its path.

The assistant owns everyday operations

The assistant profile handles the small work that otherwise gets scattered across notes and chat messages:

• Food inventory and expiry-driven recipe suggestions
• Reminders and errands
• Shopping and household lists
• Quick capture of contacts, ideas, and opportunities
• Straightforward notes across personal and company contexts

It updates the real source of truth. Food state belongs in my Household Manager database, not in a memory sentence that may become stale. A reminder belongs in the scheduler. A content idea belongs in the correct backlog.

The assistant is intentionally brief. It should complete a small operational action, not turn every grocery update into a strategy session.

It also has a hard boundary: substantial research, public writing, and code belong elsewhere.

The researcher owns evidence

The researcher profile starts from sources.

Its job is to investigate a question, separate facts from interpretation, and leave behind something another profile can use. That usually means:

• Direct links
• Dates
• Claim-by-claim findings
• Conflicting evidence
• Confidence or caveats
• A recommendation only after the evidence

The researcher does not polish the final blog. That sounds inefficient until you see the alternative: a writing agent finds a convenient source, starts shaping the narrative, and quietly stops looking for evidence that complicates it.

My researcher is allowed to be skeptical and boring. The content profile can make the result readable later.

The coder owns delivery and verification

The coder profile owns repository work:

• Inspecting the existing codebase
• Implementing the smallest safe change
• Running tests, type checks, linters, builds, and smoke checks
• Reviewing diffs
• Reporting real output instead of claiming that something “should work”

This is also the profile that manages specialist coding CLIs.

I often use Claude Code from the terminal, but I do not hand it an open-ended request and disappear. The coder profile acts as the manager around the process. It chooses the repository, scopes the task, starts the authenticated CLI, monitors it, inspects the changes, and runs independent verification after Claude Code exits.

A simplified version looks like this:

claude -p \
  "Fix the confirmed issue, keep the change scoped, and run the relevant tests." \
  --allowedTools "Read,Edit,Write,Bash(npm run *),Bash(git diff *),Bash(git status *)" \
  --max-turns 10

The --allowedTools flag controls which tools Claude Code can run without prompting for user confirmation in headless mode. A separate --tools flag restricts which tools are available to the model at all. In practice I use --allowedTools to scope what runs unattended and leave --tools at its default unless a task should have no terminal access.

The command is only one part of the workflow. The profile provides the boundary around it:

1. Set the correct working directory.
2. Give Claude Code a bounded task.
3. Limit the tools where practical.
4. Capture the exit status and output.
5. Review the resulting diff.
6. Run the repository’s own verification commands.
7. Report what actually passed and what remains uncertain.

Claude Code supplies a strong coding harness. The Hermes coder profile owns the delivery contract.

I use the same pattern when Codex CLI is a better fit. The external coding agent can change; the profile’s responsibility does not.

The content profile owns my public voice

The content profile works from /home/hermes/projects/content-forge.

Before writing anything public in my name, it reads the relevant files from /home/hermes/projects/personal-context: my global style guide, blog or LinkedIn rules, company context when needed, and one or two real examples.

Its responsibilities include:

• Blog drafts
• LinkedIn posts and carousels
• Hooks, titles, edits, and repurposing
• Content backlog and lifecycle support

It does not decide whether research is true because the paragraph sounds good. It does not edit production code. It does not publish externally without my approval.

That last boundary matters. A profile can prepare a publishable artifact, but publication is still a human decision.

The profiles work together through artifacts, not telepathy

Hermes profiles do not automatically share built-in memory or sessions. That is a feature.

If every profile read and wrote the same memory store, the separation would disappear. Hermes explicitly warns against pointing two active agents at the same profile because both can write memory and then load each other’s changes into future sessions.

My profiles collaborate through explicit handoffs:

$$\text{research note} \longrightarrow \text{implementation brief} \longrightarrow \text{code and test output} \longrightarrow \text{content draft}$$

Not every task uses the whole chain.

If I need a reminder, I go directly to assistant. If I need a source check, I use researcher. If a repository is broken, I use coder. If I have the facts and need a post, I use content.

For mixed work, the artifact moves instead of the conversation history.

A practical content flow looks like this:

1. I give the topic and constraints to the researcher.
2. The researcher saves a cited Markdown report.
3. The content profile reads that report plus my voice files.
4. The content profile writes a draft in Content Forge.
5. I review it before anything becomes ready to post.

A technical flow can start with a captured idea, move through research, and end with the coder launching Claude Code against a specific repository. If the result becomes worth sharing, the content profile receives the verified facts and turns them into a public explanation.

I still do much of the routing myself. Obvious tasks go straight to the specialist through Telegram, Hermes Desktop, or the CLI. That is faster than asking a manager agent to classify every grocery item and typo.

The system can become more automated later. Hermes has delegation for isolated child work and Kanban for durable cross-profile queues. I do not need that machinery for every request. Clear ownership and file-based handoffs already solve most of the problem.

Shared context without shared memory

Separate memory means the profiles need another way to agree on durable facts.

My answer is shared source-of-truth repositories.

• personal-context contains the compact instructions every profile may need: who I am, where things live, how I write, company context, workflows, and pointers to deeper sources. Each profile reads only the slice relevant to its role.
• content-forge is the production workspace for drafts and rendered content.
• My Obsidian vault keeps approved content and deeper knowledge. Drafts do not move there until I approve them.

The split:

• Profile memory holds small, role-specific preferences and pointers.
• Shared repositories hold reviewable context and work artifacts.
• Source systems hold operational truth, such as household inventory or repository code.

This avoids two bad outcomes. I do not duplicate the same biography and company context into four memory stores. I also do not merge all four agents into one shared memory that nobody owns.

The profiles share the map. They keep separate working memory.

Profiles let me choose models per responsibility

Profiles also separate model configuration.

At the time of writing, my profile defaults look like this:

This is a snapshot, not a permanent architecture.

The content profile is a good example of why separation helps. Much of its daily work is editing, formatting, structure, and applying an existing voice guide. Luna can handle a lot of that work. The coder gets a stronger default because ambiguous debugging and repository changes carry more risk.

My assistant is still on Sol today. That may be more model than many of its tasks need, and it is one of the defaults I can optimize later. The profile split lets me make that change without touching the coder or content agent.

The role should survive the model change.

If I replace Luna with Terra, or switch the researcher to a different provider, the profile still has the same job, memory, skills, and handoff contract.

Separate gateways make the profiles reachable

A profile can run its own gateway process and messaging credentials. That means I can keep separate Telegram entry points for different roles instead of sending every message into one chat and hoping the agent classifies it correctly. Hermes documents the operational choices in its multi-profile gateway guide.

Hermes supports two operating patterns:

1. One gateway process per profile (standalone): Each profile runs its own independent background gateway daemon with its own Telegram bot token or Discord app credentials.
2. One multiplexing gateway (centralized): A single master gateway process routes inbound messages to different profiles based on URL paths, bots, or channel routing.

The multiplexing pattern is strictly opt-in. You must explicitly enable it on the default profile’s configuration:

hermes config set gateway.multiplex_profiles true

When multiplexing is active, it changes how Hermes behaves under the hood:

• The default profile acts as the single gateway supervisor for all configured profiles.
• Secondary profiles cannot start their own standalone gateway processes (preventing duplicate bot polling or socket bind collisions).
• HTTP webhook endpoints use profile-scoped URL prefixes (e.g., /p/<profile>/webhook).
• Inbound messages route dynamically to the appropriate profile’s session based on bot tokens or route rules defined in the central configuration.

I personally run standalone gateways for my primary profiles because I prefer visible, hard-isolated entry points: each specialist has its own Telegram bot with distinct profile-scoped memory and tools.

Standalone gateways do add operational overhead: multiple systemd services or processes to supervise and separate API tokens to manage. Hermes includes token-conflict protection because two active gateways must not poll the same Telegram bot token simultaneously.

That overhead is justified only when the roles are genuinely different. I would not create one profile per repository or temporary project; a profile is for a stable responsibility that deserves its own memory, credentials, and operating rules.

Profiles are boundaries, not sandboxes

A Hermes profile isolates Hermes state. It does not automatically isolate the filesystem.

On the local terminal backend, the profiles normally run as the same Linux user. They can access the files that user can access. External tools such as git, ssh, gh, Claude Code, and Codex also use the normal operating-system home by default, so their CLI credentials can remain available across profiles.

The profile’s terminal.cwd controls where commands start. It is separate from HERMES_HOME.

For example, my content profile starts in:

/home/hermes/projects/content-forge

The coder often starts from the repository selected for the task. The assistant has its own workspace but reaches the Household Manager source of truth when food state changes.

SOUL.md tells an agent what it should do. It is not a filesystem permission system.

If I need hard isolation, I need a container, restricted terminal backend, separate OS user, or another sandboxing mechanism. Profiles solve identity and state separation. They do not replace host security.

Creating and operating a profile

A basic specialist profile takes a few commands:

hermes profile create researcher \
  --description "Primary-source research and cited briefs"
researcher setup
researcher chat

The --description flag is more than a display label. Hermes uses it for orchestration and Kanban routing: when a parent agent dispatches a subtask, it inspects profile descriptions to decide which specialist handles it.

Hermes automatically creates a shell command alias for the profile (a wrapper around hermes -p <profile>). These commands are equivalent ways to target it:

researcher doctor
hermes -p researcher doctor

The daily profile management commands I use most often:

hermes profile list              # List all profiles and their active status
hermes profile show researcher   # Inspect configuration, models, and paths for a profile
hermes profile use content       # Switch default active profile in current shell

For profile lifecycle and environment mobility, Hermes also provides:

hermes profile rename coder dev-lead   # Rename an existing profile
hermes profile export researcher       # Bundle config, SOUL, and skills into a portable archive
hermes profile import ./researcher.tar.gz # Restore or replicate a specialist profile on another machine

After creating a profile, I configure four things before trusting it with real work:

1. Role: write a narrow SOUL.md with responsibilities and exclusions.
2. Model and tools: choose enough capability for the job without enabling everything by default.
3. Workspace: set terminal.cwd to a predictable location when the role has a stable production home.
4. Source of truth: tell the profile where durable data belongs and what it must never keep only in memory.

The exclusions take the most thought.

“You are a coding agent” is vague. “You implement and verify code; you do not own priorities, deep research, public writing, or personal operations” is much harder to misread.

The trade-offs of a multi-profile Hermes setup

Profiles fixed context mixing, but they introduced new maintenance.

Every profile has settings to review. Skills can drift. A model change may need to be applied more than once. Separate gateways need monitoring. Handoffs can fail if one profile saves a report somewhere the next profile does not know to look.

There is also a temptation to create more agents whenever a task feels difficult.

That usually makes the system worse. A new profile needs a stable responsibility, a source of truth, a clear output, and a reason its memory must remain separate. Without those, it is another name in a profile list.

My four-profile split works because the boundaries map to work I already do:

• Operate everyday life
• Find evidence
• Deliver code
• Publish ideas

I can explain each role in one sentence. I can tell when it has finished. I know where its output belongs.

That is enough structure to be useful without turning my VPS into a fictional corporation.

The setup I would build again

I would still start with the default profile.

One agent is the fastest way to learn Hermes. Connect a model, test tools, add Telegram, and discover which tasks you actually repeat. Specialization before repetition creates empty roles and maintenance work.

I would split a new profile only when three conditions are true:

1. The responsibility repeats.
2. It needs different context, memory, tools, or verification rules.
3. Its output has a clear owner and destination.

That is how my default setup became four specialists.

The assistant keeps small operations moving. The researcher protects the evidence. The coder owns working software and can manage Claude Code from the terminal. The content profile protects my voice and publication process.

They work on the same machine and can use the same repositories, but they do not carry the same identity or memory.

That is the value of Hermes Agent profiles: one installation, several focused agents, and a clear answer to who should do the work.

The Hermes Journey Series:

• Part 1: My Hermes Journey: Running a Self-Hosted Agent on Hetzner VPS
• Part 2: Controlling Hermes via Telegram: Remote Setup & Security
• Part 3: Adding Voice Notes to Hermes Through Telegram
• Part 4: Hermes Agent Profiles: My Four Specialist AI Agents (You are here)