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:
- A daily schedule starts the workflow.
- The agent loads the portfolio and research policy.
- Firecrawl or another extraction tool collects approved public sources.
- The agent compares new information with earlier notes.
- It writes a structured report with citations.
- A Kanban card records completion or a blocker.
- 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.
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.