What moving the blog pipeline onto Hermes Bot profiles changed about how a post gets written and reviewed

The blog is long-standing, and the workflow behind it is new. I run that workflow as a small set of Hermes Bot profiles, one per stage. A profile is its own Hermes home directory, with its own config, memory, skills, sessions and scheduled jobs ¹. Bot Mode turns a profile into a named entry in a roster with a permanent chat, and each Bot can carry routines that fire on a schedule ². I split the work across a few of them, and the split changed how a post gets written and how it gets reviewed.

Scheduled runs start fresh, and I designed around that. A cron job runs in a new session with no memory of any chat, so its prompt has to carry everything the run needs ³. A stage that depended on remembering a conversation would break on the next run. Separate profiles also put the publish path out of reach of the profile that writes. The profile that drafts a post and the profile that ships one are never the same profile.

The queue

A post starts as a line in a topic file. A research Bot runs daily and keeps the list at five entries, and it marks a line time-sensitive for an actively exploited CVE, a fresh critical advisory in a lane I cover, a major incident with immediate defender impact, or a breaking change to the homelab stack. Career, certification and trend topics never carry the marker. The drafting Bot reads that file and takes the first line marked time-sensitive, wherever it sits in the list. That file is where my editing starts, and its order is the only order I set. The file is also the handoff between the two Bots. Both read and write the same directory, and neither needs the other’s memory to do its job.

The drafting stage

The drafting Bot is the only stage that writes a post file. It runs on a schedule: it drafts a line marked time-sensitive on any day, and when the queue holds no marked line it takes the first regular line on Monday and Thursday only. It researches the topic with web searches, loads the pages it plans to cite, and writes one Hugo file into a staging directory. Every claim that carries a specific has to trace to a page that run loaded, so a draft stands on its own sources and nothing else. Then the Bot posts the file into its own chat and stops. It cannot run the deploy script or touch the ledger that records what went live. The queue line stays in place until the post publishes, and the publish step removes it.

The review stage

A second profile reads the pending drafts and writes a review. It pulls the file from disk, checks the claims against sources it fetches itself, and posts a verdict with a list of must-fix items, each pinned to a line number in the draft. The drafting profile picks that list up on its next run and applies the items in place, then reads the file back to confirm each one landed. The two profiles do not share memory, so the reviewer writes the review into a journal file as a block, and the drafting profile reads it back. I expected that constraint to matter least, and it changed the review step the most. A review item tied to a line is hard to lose, and I can read the journal and see which items are still open. A must-fix that asks for something my sources do not support stops the pass there, and the run writes a note instead of guessing.

The editor

The roster holds one more role: an editor that can read the same drafts and send a revision request straight to the drafting Bot. That request is different from a scheduled review pass. The drafting Bot applies it on its next run, ahead of the scheduled work, without waiting for me to relay anything. The editor calls for revisions and holds the pipeline’s only publish path, which it uses only when a review reads clean on matching bytes.

The cost of the split

Every stage keeps its own memory, and most of the handoffs are files on disk: the queue, the draft, and the review block the reviewer leaves in its journal. That keeps each run reproducible, and it also means a vague review item produces nothing, because the drafting profile applies the fixes it can point at and will not infer what I meant. A run with no memory of yesterday’s chat cannot follow a preference I mentioned once, so I write preferences into the skills each run loads. That is more upfront work than one long conversation, and it is the price of a pipeline that keeps moving while I am away from it.

The last step

Publishing runs through the editor’s gate. That Bot runs the deploy script only when a review reads clean on matching bytes. The script validates the file, copies it to the web server, waits for the site to rebuild, checks that the live URL answers, and records the post in the ledger. Everything else stays with me: edits, rejections, removals, drafts the editor holds, and unpublishing.