My Hermes Agent Setup
Why Hermes
Hermes is designed from the ground up to work beyond individual sessions. It runs persistently, carries memory forward, turns successful procedures into reusable skills, schedules unattended work, and delegates tasks to subagents. That makes it useful as a personal assistant that coordinates work rather than simply answering one prompt at a time.
Hermes vs. OpenClaw
Both Hermes and OpenClaw are self-hosted, multi-channel agents with support for different model providers. I chose Hermes because its core emphasis is the learning loop: persistent memory, reusable skills, and skill improvement across sessions. OpenClaw places more emphasis on its messaging gateway, channel plugins, and connected-device ecosystem; those are valuable, but less central to how I want to use the agent.
OpenRouter usage
On OpenRouter, Hermes currently ranks first among coding agents by token volume.
Recent results
| Rank | Coding agent | Tokens today |
|---|---|---|
| 1 | Hermes Agent | 995B |
| 2 | Kilo Code | 262B |
| 3 | Claude Code | 196B |
| 4 | OpenClaw | 165B |
| 5 | Cline | 102B |
Source: OpenRouter Coding Agents Rankings, captured July 12, 2026.
Architecture
Hermes is the agent runtime at the center of my AI setup. It runs continuously on a self-hosted box and connects conversations, tools, memory, scheduled jobs, and external services. It can be any always-on machine, such as a Mac mini, a Raspberry Pi, a pod, a cloud VM, etc.
Components
The core setup separates agent execution, message delivery, and long-term memory into three distinct layers.
- Hermes Agent
- Reasons, calls tools, edits files, runs commands, and coordinates workflows.
- Hermes Gateway
- Turns incoming messages into agent sessions.
- Honcho and Obsidian
- Provide two complementary memory layers: one agent-native and one human-native.
Hermes Gateway
I control Hermes mostly through a private WhatsApp conversation with myself, monitored by the Hermes Gateway. ; The gateway supports more than 20 messaging services, including Telegram, Discord, Slack, Signal, email, SMS, and Microsoft Teams.
I already used this same whtasapp thread to save interesting things I found. With Hermes watching it, those messages can be indexed in my knowledge base and retrieved as context later.
The agent loop
Each request moves through a simple loop that adds context, invokes a model, and repeats tool use until Hermes can return a final response.
Context and memory
Context is where personalization happens. Hermes combines the current conversation with its personality, user profile, durable memory, available skills, tool descriptions, and relevant past sessions. Local session history maintains continuity within day-to-day conversations, while Obsidian and Honcho cover two different kinds of long-term context.
Obsidian: External memory in MD format easy to read and edit a knowledge base that Hermes Agent knows it can grab at any time
Obsidian holds the material I want to read, organize, and edit myself: saved links, research, project notes, summaries, and connections between ideas. Because the vault is made of Markdown files, Hermes can search and update it with normal file tools while the knowledge remains portable and easy to audit. Is basically a folder structure with mark-up files inside obsidian is just the interfase that can be anything.
Honcho: agent-native memory
Honcho gives Hermes persistent memory across sessions. It builds a model of my preferences, goals, communication style, and recurring patterns from previous conversations. Hermes can retrieve relevant conclusions through semantic search and inject session context when responding, so useful personal context does not have to be restated in every conversation. I am still learning how honcho works It seems a bit magicall still. Honcho is self-hosted for me.
Scheduled work
Hermes cron jobs turn a prompt into unattended recurring work. A job can use a standard cron expression or a natural-language schedule and can include specific skills and a delivery target.
The scheduler is part of the Hermes Gateway. While the gateway is running, it checks for due jobs every 60 seconds. Each due job starts in a fresh agent session, loads any attached skills, runs its prompt to completion, and delivers the final response to its configured chat or local output. Hermes then records the result and calculates the next run time.
Job definitions are stored in ~/.hermes/cron/jobs.json. Reports from individual runs are saved under ~/.hermes/cron/output/{job_id}/{timestamp}.md. This lets the same agent handle both conversations and unattended recurring work without carrying unrelated conversation history into a scheduled run.