Building Hermes, Part 11: Hermes AI Operations System

Most people try AI agents as chat interfaces first. I wanted to see what happens when an agent becomes part of an operating workflow.

Hermes is my personal AI operations system: a VPS-hosted agent layer that connects messaging, scheduled automation, WordPress publishing, canonical content storage, Second Brain retrieval, and lightweight infrastructure monitoring. The goal is not to make a chatbot feel smarter. The goal is to make repeated AI work observable, recoverable, and useful enough to run every day.

This project is a working case study in agent infrastructure, not a mockup.

What I Built

Hermes runs as a personal AI operator across the tools I already use:

• iMessage and Slack for commands, updates, and cron delivery
• Forge for canonical article storage and publishing workflows
• WordPress for public Sieon Labs publishing
• Second Brain retrieval for grounded personal and project knowledge
• Cron jobs for recurring research, publishing, and monitoring
• Custom skills for reusable operational runbooks
• VPS watchdog scripts for process and resource health

The system lets me ask for one-off tasks, but the more interesting part is the durable loop: jobs run on schedule, outputs are verified, failures are turned into runbooks, and those runbooks improve later behavior.

Why I Built It

A lot of agent demos stop at tool calling. That is useful, but it is not enough for production-style work.

Real workflows need answers to less glamorous questions:

• Did the scheduled job actually run?
• Did it only say it succeeded, or did the external side effect happen?
• Was the WordPress post published under the right category?
• Did the generated image come from an external source, and was it credited?
• Did a browser process leak memory on the VPS?
• Can the agent remember how to fix the same class of failure next time?

I built Hermes around those questions. The project became a way to test how far an AI assistant can move from prompt-response interaction toward an operational system.

Architecture

At a high level, the system has five layers:

Layer	Role
Messaging	iMessage and Slack provide the command surface and delivery channel.
Agent core	Hermes coordinates tools, skills, memory, and task execution.
Automation	Cron jobs turn recurring tasks into durable scheduled workflows.
Knowledge and publishing	Second Brain, Forge, and WordPress provide retrieval, canonical content, and public output.
Operations	VPS watchdogs and QA runbooks verify that the system is healthy and that side effects happened.

The important part is the feedback loop. Hermes does not just generate text. It performs work, checks whether that work happened, reports failures, and stores the fix as reusable procedure.

Core Workflows

1. Publishing Pipeline

Sieon Labs articles start as canonical Markdown in Forge, then move to WordPress. A daily publishing job can draft, review, publish, and verify posts.

The workflow has several guardrails:

• three editorial review passes before publishing
• title review to avoid document-style headings
• WordPress category enforcement for Articles
• original image preference and source-credit rules for external images
• post-publish checks for rendering, links, status, and category
• fallback handling when WordPress taxonomy permissions block tag/category creation

This turned publishing from a single “write a post” prompt into a small production pipeline.

2. Second Brain Retrieval

For personal and project questions, Hermes retrieves from my indexed Second Brain before answering. This matters because project context changes over time, and generic model memory is not reliable enough for decisions about my own work.

The retrieval layer is especially important for projects like my Capstone work on clinical retrieval and my Hermes architecture notes. The rule is simple: if the answer depends on my notes, Hermes should search the notes first and cite the source internally.

3. Cron Observability

Scheduled tasks are only useful if they are observable. Hermes cron jobs now have runbooks for common failure modes:

• script path mismatches
• missing tools because of restrictive toolsets
• delivery failures across messaging platforms
• model/provider drift
• jobs that report success but fail to produce the external side effect

One concrete example was a watchdog job that failed because the cron scheduler looked for a script under /opt/data/scripts/, while the actual file lived under /opt/data/.hermes/scripts/. The fix was not just copying the file. The fix was turning that failure mode into a reusable cron repair procedure.

4. VPS Resource Watchdogs

Browser automation can leave behind orphaned Chrome or Chromium processes when a session crashes or times out. On a small VPS, that can quietly consume memory and degrade the whole agent.

I added a lightweight watchdog pattern:

• detect orphaned browser process groups
• report only when there is a real issue
• keep script-only cron jobs silent on success
• include enough process details to decide whether cleanup is safe
• verify the watchdog itself through cron status and manual runs

This is not glamorous, but it is the kind of operational detail that determines whether an AI agent can run continuously.

The Skill Layer

The most useful pattern has been turning failures into skills.

When something breaks twice, it should not remain a one-off fix. I created reusable runbooks for recurring operational areas:

• wordpress-publishing-qa
• cron-observability-and-repair
• second-brain-vps-bridge-runbook
• forge-wordpress-migration-recovery
• blog-editorial-self-review
• mcp-server-onboarding-and-filtering
• vps-resource-watchdog-runbook

This is where the system starts to feel less like prompting and more like engineering. The agent’s behavior improves because operational knowledge becomes explicit, versioned procedure.

What I Learned

Tool calls are not the hard part

The hard part is making tool calls safe, scoped, and verifiable. It is easy to ask an agent to update a post. It is harder to make sure the post is published, categorized correctly, rendered correctly, and free of uncredited external images.

Cron success is not business success

A scheduled job can finish with status ok while the real-world side effect is missing. For publishing, the actual source of truth is WordPress. For retrieval, it is the Second Brain index. For infrastructure, it is the live process table and logs.

Agent memory should become procedure

Not every lesson belongs in long-term memory. Some lessons should become skills: step-by-step operational procedures that future sessions can load when the same class of work appears.

Small operational failures are valuable

A broken script path, a missing category, or a bad image source is not just a nuisance. It is a chance to improve the system boundary. Each failure shows where the agent needs stronger checks.

Why This Matters for AI Engineering

This project maps directly to the kind of work production AI teams need:

• building agents that can use tools without losing control of state
• grounding answers in private project knowledge
• scheduling autonomous work with clear delivery semantics
• verifying side effects in external systems
• designing recovery paths when APIs or permissions fail
• creating observability around agent behavior
• converting repeated human corrections into reusable procedures

The result is a practical AI operations layer that handles real tasks across content, infrastructure, and knowledge management.

Current Status

Hermes is actively running in my personal workflow. It is not a finished product, and that is part of the point. The project is an ongoing testbed for agent reliability, retrieval, automation, and operations.

The next improvements are clear:

• create a sanitized GitHub README with example runbooks
• connect the project to my AI engineering portfolio
• add more systematic evaluation for retrieval and agent workflow reliability
• publish follow-up writeups about cron reliability, post-publish QA, and operating agents on small VPS instances

Summary

Hermes started as an assistant. It became a personal AI operations system.

The shift happened when I stopped asking only, “Can the model do this task?” and started asking, “Can this workflow run, verify itself, recover from failure, and teach the agent how to do better next time?”

That is the line between a demo and an AI engineering system.

References

1. Hermes Agent Documentation
2. Sieon Labs: Agent Traces Are the New Runtime Interface
3. Sieon Labs: MCP Isn’t Just Tool Calling Anymore