We turned Hermes into a small AI operating system, not by fine-tuning a model, but by installing the agent, wiring it to tools and knowledge, then training its behavior through memory, skills, corrections, and repeatable workflows. The result is a project system that can remember context, retrieve evidence, and publish safely.
What we actually built
The public story is simple: I wanted an agent that could help run Sieon Labs projects, not just answer one-off prompts. The practical story is more interesting. Hermes became the coordination layer between my terminal, my Second Brain, a publishing pipeline, and WordPress. That matters because most agents fail at the same boundary. They can write a good answer in one session, but they do not carry enough operational context into the next one.
Hermes is a good fit for this because the project is designed as a self-improving AI agent rather than a narrow coding assistant. The official docs describe Hermes as an agent with persistent memory, skills, messaging surfaces, cron jobs, delegation, web tools, MCP support, and multiple runtime surfaces like CLI, desktop, dashboard, and messaging gateways Hermes Agent documentation. Those are not cosmetic features. They are the pieces you need when the agent is expected to operate across days instead of across one chat window.
The important distinction is that this was not model training. I did not fine-tune the underlying LLM on my conversations. I trained the system around the model. In practice, that means the agent learned through three layers: compact profile memory for stable preferences, procedural skills for repeatable workflows, and a Second Brain retrieval layer for project evidence.
Our Second Brain design keeps Markdown files as the source of truth and treats SQLite as a rebuildable projection for search [Hermes Memory Layer Specification](sb://01_Projects/Hermes/Architecture/Hermes Memory Layer Specification.md#chunk-0). That architecture is boring in the best way. If the index breaks, it can be rebuilt. If the agent changes, the notes still exist. If the model provider changes, the project memory is still readable by a human.
The long-term design is also intentionally not “Second Brain equals Context Engine.” The architecture notes define Second Brain as one retrieval provider under a future Hermes Context Engine, alongside session history, local memory, project files, skills, and future graph sources [Hermes Next-Generation Architecture](sb://01_Projects/Hermes/Architecture/Hermes Next-Generation Architecture.md#chunk-0). That separation keeps retrieval from becoming planner logic, and it keeps the agent from confusing stored evidence with executable decisions.
Installation
The install path is intentionally unglamorous. On Linux, macOS, WSL2, and Termux, the official command is the shell installer from the Hermes docs:
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
After installation, the fastest path to a usable agent is the setup wizard. The docs recommend hermes setup --portal as the quickest route because one OAuth flow can cover model access and the bundled Tool Gateway tools Hermes Agent documentation.
hermes setup --portal
hermes doctor
hermes
That is enough for a local CLI agent, but the project version needed more than a local shell. I wanted Hermes to run as an always-available AI OS layer, so the deployment model moved toward a VPS-hosted runtime. The CLI remains the working surface, but the same system can be exposed through messaging, scheduled jobs, and tool-backed workflows. Hermes supports many of those surfaces out of the box, including terminal, desktop, dashboard, Telegram, Discord, Slack, WhatsApp, Signal, Matrix, Teams, Email, SMS, and MCP integrations Hermes Agent documentation.
The install was only the first step. The real setup work was deciding what Hermes should be allowed to know and what it should be allowed to change. For this project, I split the system into read paths and write paths. Search and retrieval could be enabled early. Production writes needed to stay gated until the memory and upload paths were boring enough to trust.
That safety split shaped the rest of the deployment.
Connecting knowledge
The architecture is easier to understand as two loops. The top loop is the runtime path: a user talks to Hermes, Hermes calls tools, and the Second Brain retrieval plane returns grounded context. The bottom loop is the training path: corrections, memories, skills, and Forge drafts become durable artifacts the next session can reuse.
Hermes as an AI OS: user surfaces call the Hermes runtime, Hermes reaches the Second Brain through MCP, and durable training artifacts flow back into memory, skills, and Forge drafts.
The core retrieval path is:
Hermes
→ Second Brain MCP
→ Search and Context API
→ SQLite index
→ corpus files
The audit notes describe this as a deliberate boundary. Hermes talks to the Second Brain through MCP, and the MCP server calls an HTTP Search/Context API. It does not directly open SQLite or mutate corpus files [Hermes Architecture Audit](sb://01_Projects/Hermes/Architecture/Hermes Architecture Audit 2026-07-10.md#chunk-0). That is an important design choice because it keeps the agent-facing tool boundary thin and testable.
The SQLite database is not the knowledge base. It is the search projection. The project files remain the durable source of truth, while the index can be regenerated from the corpus [Hermes Memory Layer Specification](sb://01_Projects/Hermes/Architecture/Hermes Memory Layer Specification.md#chunk-0). That is the same reason I prefer Markdown for long-lived project memory. It is less magical, easier to diff, easier to back up, and easier to inspect when an agent makes a bad call.
At the time of this build, the Second Brain integration was intentionally in a read-only phase. The audit recorded that search, context, and reasoning were available, while memory writes, plan creation, and reflection persistence were blocked by a read-only guard [Hermes Architecture Audit](sb://01_Projects/Hermes/Architecture/Hermes Architecture Audit 2026-07-10.md#chunk-0). That made the system useful without giving it a write blast radius too early.
This is the pattern I would recommend for any serious agent deployment. Do not start by giving the agent permission to edit everything. Start by giving it reliable read access, citations, status checks, and clear failure modes. Once retrieval is stable, then add write APIs with dry runs, confirmation tokens, idempotency, and audit trails.
Training the agent
When I say “training Hermes,” I mean operational training, not gradient descent. The model behind Hermes may change from session to session, but the system around it keeps learning.
The first layer is persistent memory. Hermes stores compact agent and user memory in two files, MEMORY.md and USER.md, under ~/.hermes/memories/ Hermes persistent memory docs. These memories are injected into the system prompt as a frozen snapshot at the start of a session Hermes persistent memory docs. That frozen snapshot behavior is a trade-off. New memories are written immediately, but they do not change the active prompt mid-session. The benefit is prompt-cache stability and predictable behavior.
The second layer is skills. Hermes skills are on-demand knowledge documents stored under ~/.hermes/skills/ Hermes skills system docs. They follow progressive disclosure, which means the agent does not need to load every procedure on every turn Hermes skills system docs. It loads the relevant skill when the task calls for it.
That is the difference between memory and skills. Memory is for compact durable facts, like preferences, environment conventions, and recurring corrections. Skills are for procedures, like how to publish a Forge article, how to review a GitHub PR, or how to troubleshoot a Hermes Docker deployment.
In this project, the publishing workflow became a skill-backed process. The agent knows that new Sieon Labs posts should be saved through Forge, kept as WordPress drafts, previewed before publication, and never published without explicit instruction. That procedure belongs in a skill because it is a workflow, not a fact.
The third layer is the Second Brain memory model. The internal design separates project memory, decisions, meetings, blog memory, learning notes, and agent execution lessons as Markdown categories in the Second Brain [Hermes Memory Layer Specification](sb://01_Projects/Hermes/Architecture/Hermes Memory Layer Specification.md#chunk-6). That gives Hermes a place to ground project-specific answers without stuffing everything into the small prompt memory budget.
A practical example: if I correct Hermes about the WordPress migration architecture, that correction should become a compact memory if it will affect future decisions. If Hermes discovers a multi-step publishing procedure, that should become a skill. If we write an architecture decision, that should live in Second Brain with citations. Each layer has a job.
Publishing and operations
The publishing side uses Forge as the canonical content engine. The architecture audit records Forge as storing canonical articles under /opt/data/forge and publishing to WordPress through a REST adapter [Hermes Architecture Audit, Forge deployment](sb://01_Projects/Hermes/Architecture/Hermes Architecture Audit 2026-07-10.md#chunk-2). That means WordPress is the rendering target, not the source of truth for drafts.
This matters because WordPress infrastructure changed during the project. The public WordPress site moved to Hostinger Managed WordPress, while the VPS remained dedicated to Hermes as the AI OS host [Hermes Architecture Audit, WordPress-to-Hostinger Decision](sb://01_Projects/Hermes/Architecture/Hermes Architecture Audit 2026-07-10.md#chunk-4). That separation reduced coupling. The agent runtime and the public website no longer had to share the same Docker stack.
The resulting flow is simple:
Hermes session
→ Forge canonical markdown
→ WordPress REST API
→ draft preview
→ human review
→ publish only on explicit command
That last line is not bureaucracy. It is the safety model. An agent can draft, revise, and check a preview, but publication remains a deliberate action. This is especially important when the content is about the system itself, because the article can accidentally leak infrastructure details if the workflow does not force review.
For this Projects post, I kept private details out of the article. No application passwords, no IP addresses, no raw host paths that reveal more than the reader needs. The useful public lesson is the architecture pattern, not the secrets of the deployment.
Lessons from the build
The first lesson is that agent “training” is mostly systems design. If you rely on the model to remember everything, the system will drift. If you split knowledge across memory, skills, session search, and a cited corpus, the system becomes easier to correct.
The second lesson is that read-only comes first. It is tempting to build the write path immediately because writes feel like autonomy. In practice, reliable retrieval is the foundation. The agent needs to know what is true before it should be allowed to change anything.
The third lesson is that MCP is still useful even when services are close together. In our architecture, MCP is not where the business logic lives. It is the stable tool boundary between Hermes and the Second Brain API [Hermes Architecture Audit](sb://01_Projects/Hermes/Architecture/Hermes Architecture Audit 2026-07-10.md#chunk-0). That makes it useful for multi-agent access, testing, and future deployment changes.
The fourth lesson is that publishing needs its own guardrails. A technical blog run by an agent should not be a direct “prompt to publish” pipeline. It should be a canonical draft store, a WordPress adapter, a preview step, and explicit publish intent.
If I were rebuilding this from zero, I would keep the same order: install Hermes, configure providers and tools, connect read-only knowledge, add memory and skills, build the publishing workflow, then enable writes only after the diagnostics and rollback paths are proven.
FAQ
Is this model fine-tuning?
No. This is operational training around the model. Hermes keeps compact persistent memory in MEMORY.md and USER.md Hermes persistent memory docs, loads procedural skills from ~/.hermes/skills/ Hermes skills system docs, and retrieves project evidence from Second Brain. The underlying model can change without losing those system-level habits.
Do I need a VPS to use Hermes?
No. Hermes can run locally through the CLI, desktop, or dashboard, and the docs describe a direct installer for local machines Hermes Agent documentation. A VPS makes sense when you want the agent to be available from messaging platforms, scheduled jobs, or long-running project workflows.
What is the difference between memory and skills?
Memory stores compact durable facts and preferences, while skills store reusable procedures. The memory docs describe bounded persistent memory files injected at session start Hermes persistent memory docs. The skills docs describe on-demand skill documents that the agent loads when a task needs a procedure Hermes skills system docs.
Why keep MCP in the architecture?
MCP gives Hermes a stable tool boundary. In our deployment, the Second Brain MCP server stays thin and calls the Search/Context API rather than embedding retrieval logic in the tool wrapper [Hermes Architecture Audit](sb://01_Projects/Hermes/Architecture/Hermes Architecture Audit 2026-07-10.md#chunk-0). That keeps the architecture easier to test, replace, and extend.