Building a Loop Where Discord Messages Automatically Land in Your Wiki — hermes-discord Story

A loop where ideas thrown from your phone pile up in the second wiki, built with a single ops repo

Why I Started This

Sound familiar? You’re on the subway and something pops into your head. Not sure if it’s an idea or a note, but you want to hold onto it. You pull out your phone, open Obsidian, dig through folders, come up with a title… and by the time you’re done, the context has evaporated.

I wanted to eliminate that friction. Why I chose Discord is covered in a previous post — it’s already an app I open several times a day. What if talking to it there meant that message went straight into the wiki?

After confirming that hermes-agent, an LLM agent framework, officially supports the Discord gateway (I was initially wrong about this — I thought it didn’t support Discord, then confirmed it later), I got to work.

The Design Decision: An Ops Repo

The hermes-discord repo I built has an unusual character. There’s no app source code. It’s an ops repo that wraps the upstream hermes-agent Docker image. All it contains is a Dockerfile, a docker-compose.yml, environment variable management scripts, and documentation.

The reason is simple: I had no intention of modifying hermes itself. All I wanted to manage was “how to deploy it” and “how to connect the second vault.”

The core structure comes down to three things:

• Where it runs: [[집서버-앱-공존-구성|24/7 on the dev server (hong)]]. The local machine is for git management only. The bot needs to stay alive even when the MacBook lid is closed.
• Token constraint: One Discord bot token means one gateway connection. Running it on both local and server simultaneously means the same bot responds twice, or the sessions collide. There must be exactly one instance.
• second connection: The second repo is cloned at ~/hermes-discord/workspace/second, and the hermes container mounts that directory directly. This lets hermes read and write wiki files directly.

Deployment Flow: One Line of Git

Change a config locally, run git push. On the server, it’s git pull && docker compose up -d. Both commands live in a single deploy.sh script.

At first I thought “maybe I should be able to run it locally too,” so I set up the full local run configuration — then realized the server was already running fine and local was only ever going to be for git. So I tore it all out. 4.92GB image, docker-compose.override.yml, local .env… set it all up and cleaned it all up. Simple is better.

The Config Trap: Two Hours Down the Drain

This was the most painful part of the whole build. It happened while connecting the Tavily search backend.

The default search backend was a “DDGS” fallback, and the search quality was terrible. I decided to switch to Tavily. Following the official hermes docs, I typed:

hermes config set tool_search.search_default_limit 8

config check passed. I restarted. The setting appeared to apply. But the actual behavior was different.

Later, when I opened the config file directly, I found that what I’d entered had been created as a fake top-level key, completely different from the correct key (tools.tool_search.search_default_limit). config check only validates parsing — it doesn’t verify whether the value is at the right path.

The correct commands are:

hermes config set tools.tool_search.backend_id tavily
hermes config set tools.tool_search.search_default_limit 8

Use a short path and you get an ignored fake key at the top level. Always use the full path.

The “Oh, This Actually Works” Moment

I threw an idea at the bot in Discord. A file actually got created in the second wiki.

That was the moment a plain Discord message turned into a wiki page. No friction. Send one message from your phone, and the next time you open your laptop, the organized content is sitting there in Obsidian.

Sure, the quality and depth of knowledge digestion is a separate problem. But the fact that the “chat → wiki” loop itself works was proof that the friction removal I’d originally imagined was actually possible.

Two-Way Sync for the second Vault

There was one more thing to solve. The second wiki gets updated from multiple directions: local Obsidian, Claude Code sessions, and the hermes bot itself writing files. In that setup, if hermes tries to push its edits from the server and remote is ahead, there’s a conflict.

When I checked the server’s second repo, it was exactly that situation. Stuck since June 5th, with a pile of dirty uncommitted work. The cron set to --ff-only just silently skips when there’s a conflict risk.

In a repo where everyone is writing from both directions, git pull --ff-only is wrong — git pull --rebase --autostash is the right call. It puts hermes’s unpushed commits on top of remote. That way the nightly push goes out as a clean fast-forward.

How the Loop Runs Now

The automation currently running on the server looks like this:

• Every 20 minutes: rebase pull to sync the second repo to latest
• 10 PM: collect hermes session logs into raw/
• hermes bot: connected to the Discord gateway 24/7

I modify code locally and push. I chat in Discord from my phone. The server handles the rest.

The loop I originally imagined is actually running. An idea comes up, I open Discord. The wiki fills itself in.

← Prev: I Built a Discord Bot Because I Hated Watching Ideas Disappear on My Phone · Next →: How to Run Two AI Agents Side by Side Background: second Wiki Design Decisions · Deep dive: Second Brain Automation Method · See also: Agent Context and Second Brain Integration