My Opinionated 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.

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 use a private Discord server as the control plane for Hermes. For each task, I create a thread in a channel and give it a descriptive title. The Hermes Gateway maps each thread to an isolated agent session. The hierarchy is server → channel → thread, with the session scoped at the thread level. The Discord adapter supplies rich routing metadata, including the server, channel, thread title, thread ID, and participant identity. Hermes builds a readable session title from that context, and Honcho derives a stable session ID from it. This makes concurrent tasks easy to find, resume, and keep separate while Honcho carries useful context between them. Discord handles text, images, and ordinary documents well, although generated archives still do not arrive as native attachments in my setup; that delivery path remains unresolved.

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 long-term memory

Honcho is Hermes's external memory provider. It stores completed turns, derives conclusions, and builds directional representations of both the user and AI peers. Before a model request, Hermes retrieves the prepared session summary, peer representations, peer cards, and dialectic synthesis from Honcho. It appends that recalled material to an API-only copy of the current user message, keeping the stored conversation free of injected context.

I self-host the Honcho API, datastore, queue, and background processing. How I Run Honcho for Hermes: Long-Term Memory and Personalities describes the architecture and operating model.

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.