How to Use Hermes Better Than Most People: Architecture, Project Isolation, and Scalable Workflows

A best-practices guide to VPS deployment, model selection, memory, progressive skills, profiles, delegation, and real automation.

Most Hermes setups become messy for a predictable reason: installation, memory, project files, skills, credentials, and automated jobs are allowed to accumulate without an architecture. The agent may still respond, but nobody can explain which files are authoritative or which profile owns a workflow.

A scalable setup begins with isolation and explicit structure. The system should make it easy to answer: Where does Hermes run? Which model handles this task? What does the agent know? Which skill is active? Where are project files stored? What is scheduled? Who approves the result?

Choose local or VPS deployment based on availability

Local deployment provides direct access and is suitable for experimentation. A VPS is better when Hermes must stay online, receive Telegram messages, and run cron jobs continuously.

The server should use key-based SSH access, current packages, a restricted firewall, and a non-public gateway where possible. Record the installation and configuration so the instance can be rebuilt.

Before adding tools, verify that Hermes survives a reboot and that backups capture its important state.

Understand model roles

The primary model handles the main agent loop, but every task does not need the same model. A strong reasoning model may handle planning and synthesis. Cheaper models can handle routine classification. Specialized tools may handle search or extraction without a model at all.

Model selection affects tool reliability, cost, and context capacity. Test important skills with the exact model assigned to them. A workflow that succeeds with one provider may fail after a switch.

Keep provider credentials outside repositories and maintain a known fallback.

Learn the operational commands

Hermes provides commands for sessions, models, schedules, skills, and system status. Use the installed version’s help rather than relying on an old tutorial.

The key habit is inspection. List jobs before creating a new one. Check active sessions before assuming context. Inspect the current model before comparing output quality. Read logs after a tool failure.

Commands are useful because they expose state. An operator should not depend entirely on conversational claims about what the system is doing.

Design memory as an architecture

Memory should be divided by purpose:

• identity describes how the agent behaves;
• user memory stores stable preferences and facts;
• project memory stores decisions and current state;
• session history records the conversation;
• skills store procedures;
• artifacts store outputs and evidence.

Do not place all information in one large memory file. It wastes context and creates conflicts. Durable project facts belong with the project. Global user memory should remain small.

Review memory periodically. Stale instructions are more dangerous than missing trivia because they influence later tasks with false confidence.

Use progressive disclosure in skills

Progressive disclosure means showing the agent only the instructions needed for the current task. A top-level skill explains when it applies and points to deeper references or scripts as needed.

This keeps the initial context small and reduces distraction. A research skill might load source-evaluation rules only when research begins, then load a specific report template only when drafting.

Skills should reuse scripts and templates rather than embedding huge blocks of text. They should include verification steps and clear failure messages. A skill is successful only when another session can use it without the original author’s hidden knowledge.

Isolate projects in the file system

Each project should have its own directory containing context, inputs, outputs, and task-specific notes. Shared skills can live in a common location, but project data should not be mixed.

A simple structure might include:

• context/ for briefs and constraints;
• inputs/ for source material;
• work/ for intermediate files;
• outputs/ for approved deliverables;
• logs/ for run records.

The agent should receive the project path explicitly. File tools should be restricted to the intended workspace when possible.

Isolation improves security and prevents one client’s information from appearing in another client’s output.

Profiles are roles; delegation is a task relationship

A profile defines a durable operating identity with its own tools, model, and memory. Delegation assigns a specific task to another agent or subagent.

Use a profile when the role recurs: researcher, developer, client operator, or financial analyst. Use delegation when a bounded task can be completed independently and returned to the coordinating agent.

Do not create a permanent profile for every small task. Do not delegate work that depends heavily on constantly changing shared context. Choose the mechanism that keeps ownership clearest.

Build workflows around evidence

A real workflow begins with a trigger and ends with a verifiable artifact. Consider a stock-research agent:

1. A daily schedule starts the workflow.
2. The agent loads the portfolio and research policy.
3. Firecrawl or another extraction tool collects approved public sources.
4. The agent compares new information with earlier notes.
5. It writes a structured report with citations.
6. A Kanban card records completion or a blocker.
7. The report is delivered for human review.

The agent should not execute trades merely because it produced research. Analysis and financial action require separate permissions and risk controls.

Combine Kanban and cron jobs

Cron jobs create recurring work, while Kanban exposes status. A schedule can create or update a card at the beginning of a run. The card moves to waiting for approval when the artifact is ready and to complete only after acceptance.

Failed runs should create a visible blocked state with the error and log location. Silent failure is unacceptable for an always-on system.

This pattern works for daily reports, content research, system monitoring, and client deliverables.

Integrate tools narrowly

Firecrawl and similar tools can collect web content for research. Give the agent a defined source list, crawl limit, and storage location. Respect robots rules, service terms, and copyright.

Every integration should have a clear purpose. Do not install tools simply because they are available. More tools increase context, credentials, updates, and possible failure modes.

Test one read-only function before enabling action functions. Record exact errors in the project log.

An operator’s checklist

Before considering the setup mature, confirm:

• Hermes restarts and remains reachable.
• Backups can be restored.
• Secrets are outside repositories.
• Global memory is short and reviewed.
• Projects use separate directories.
• Skills load information progressively.
• Profiles have distinct roles and permissions.
• Delegated tasks have output contracts.
• Cron jobs have time zones, limits, and delivery paths.
• Kanban or another dashboard exposes failures and approvals.
• Important outputs contain evidence and citations.
• High-risk actions remain under human control.

Better use means less hidden complexity

The best Hermes operator is not the person with the most agents or integrations. It is the person who can inspect the system, explain each workflow, recover from failure, and know which information influenced an output.

Architecture creates that clarity. Memory is separated from procedure. Projects are isolated. Skills reveal information progressively. Profiles define durable roles. Delegation remains bounded. Schedules produce visible evidence.

With these practices, Hermes can scale across research, clients, operations, and automation without becoming an unmaintainable collection of prompts and credentials.

Hands-on lab: Isolate a research profile and project workspace

Outcome: A named profile starts in one explicit project directory and produces a cited report only inside that workspace.

Time: 15–25 minutes.

Risk: Medium. A profile separates Hermes state, but terminal.cwd is only a starting directory and does not enforce a filesystem sandbox.

Before you start

Use a configured default profile and a non-sensitive research question. The –clone option copies the current profile’s config, .env, SOUL.md, and skills, so review whether those credentials are appropriate for this new role.

Place information at the narrowest useful memory layer:

Layer	Put here	Promote only when	Keep out
Static profile memory (USER.md / MEMORY.md)	Stable preferences, environment facts, and conventions that should influence most sessions in this profile.	The fact has been verified, remains useful across sessions, and is short enough to review.	Secrets, temporary task status, raw transcripts, and project-specific clutter.
Daily or project notes	Ordinary Markdown under the project’s context/, logs/, or outputs/; these files are user-managed and are not automatically injected as built-in memory.	A decision or state belongs to this project, needs provenance, or may change during the work.	Unattributed claims and the only copy of a credential or critical backup.
External memory provider	Reviewed knowledge that needs retrieval across many sessions beyond the bounded built-in files; one provider can be active and it remains additive to built-in memory.	The recall benefit justifies the provider’s cost, retention, and privacy boundary, and correction or deletion has been tested.	Indiscriminate sensitive-data dumps and facts that should stay inside one project.

Use a simple promotion rule: capture evidence in the project first, promote it to static or external memory only after it proves durable and broadly reusable, and remove or correct it when its source changes.

mkdir -p "$HOME/hermes-projects/source-grounded-research/context"
mkdir -p "$HOME/hermes-projects/source-grounded-research/inputs"
mkdir -p "$HOME/hermes-projects/source-grounded-research/outputs"
mkdir -p "$HOME/hermes-projects/source-grounded-research/logs"

cat > "$HOME/hermes-projects/source-grounded-research/context/brief.md" <<'EOF'
# Research brief
Question: Which Hermes cron controls should a new operator test first?
Required output: outputs/report.md
Evidence rule: cite official Hermes documentation URLs for every operational claim.
Boundary: do not publish, send messages, or modify files outside this project.
EOF

Build it

Create the role, bind its default working directory, and run one bounded non-interactive task under that profile.

hermes profile create research-lab \
  --clone \
  --description "Reads approved sources and writes cited research artifacts."

hermes -p research-lab config set terminal.cwd "$HOME/hermes-projects/source-grounded-research"

hermes profile show research-lab
hermes -p research-lab doctor

hermes -p research-lab chat -q "Read context/brief.md and complete it. Write only outputs/report.md. Include a Sources section and an Uncertainties section. Stop and report a blocker if an official source cannot support a claim."

Verify it

Inspect both the profile configuration and the artifact; do not rely only on the agent’s completion message.

hermes -p research-lab config show | rg -n "terminal|cwd"
test -s "$HOME/hermes-projects/source-grounded-research/outputs/report.md"
rg -n "Sources|Uncertainties|https://hermes-agent.nousresearch.com/docs/" "$HOME/hermes-projects/source-grounded-research/outputs/report.md"

Success means research-lab reports the intended cwd and the report stays inside outputs with official citations.

If it fails

• If profile creation reports that the name exists, inspect it with hermes profile show research-lab rather than deleting it blindly.
• If tools start elsewhere, set terminal.cwd again with an absolute path and start a new session.
• If the report lacks citations, tighten the completion prompt and treat the current artifact as a failed draft.
• If you need enforced file isolation, switch to an appropriate sandboxed terminal backend or container; a profile and cwd alone are not security controls.

Safety, privacy, and cost

Profiles separate config, sessions, memory, skills, cron jobs, and gateway state, but they run with the same operating-system user’s file access on the local backend. Do not treat a profile as tenant isolation. Clone only credentials the role needs, keep client projects in separate directories, use read-only sources first, and review model/tool cost under the profile before scheduling the workflow.

Official references

• Profiles
• Security

---

Source video: How to use Hermes Agent better than 99% of people, Nemanja Mirkovic. Adapted and reorganized from the full transcript; promotional material was removed.