Hermes: an agent stack with actual engineering discipline behind it
Built on Hermes Agent (Nous Research's open-source agent framework), running GBrain and the skillify workflow — both from Garry Tan's GBrain/GStack ecosystem — as the memory and skill layer. I integrated and deployed this stack as a persistent personal AI system and operate it as daily-use infrastructure on an Azure VM. It started as an experiment. It's now close to a digital representative of me. This is a writeup of how I integrated it, the skills I've built on top, and the decisions behind it.
Integrated, deployed, and operated by me · custom skills built on top
At a glance
- type
- Technical write-up
- framework
- Hermes Agent · Nous Research
- memory
- GBrain · GBrain/GStack
- skill layer
- skillify · GBrain/GStack
- gateway
- Discord
- deployment
- Azure VM
- workflow
- constitution → spec → validation
- status
- Running for months
The problem
Hermes started as a pet project — I wanted to figure out what a persistent, always-available second brain could actually do for me. No fixed spec, just curiosity. Over time, the use case sharpened: I use Claude and Claude Code/Codex for hard technical work, but Hermes has gradually taken over everything else — my personal life, scheduled checks, and open-ended tasks like "research this and produce a document." It replaced Claude, ChatGPT, and Gemini for that whole category of work, one task at a time, because it remembers context those tools don't.
Architecture
- Agent framework — Hermes Agent: Nous Research's open-source agent framework. I chose, integrated, deployed, and operate it; I did not create the underlying framework.
- Memory layer — GBrain: A markdown-first knowledge graph backed by PGLite from Garry Tan's GBrain/GStack ecosystem. I run it as Hermes's memory layer, so every session builds on the last instead of starting from zero.
- Skill layer — skillify: The existing GBrain/GStack mechanism for turning one-off fixes into permanent, tested skills. I use it to build and maintain the specific skills that run in my Hermes deployment.
- Gateway — Discord: Discord is the interface layer — always open, multi-device, and it turns Hermes into something I can just talk to instead of a tool I have to open.
- Model routing: The routing history is a straightforward cost/performance curve: started on DeepSeek V4-Pro, moved to V4-Flash purely for cost. Tested GPT-5.4 mini next, chasing a better cost/performance tradeoff. Currently running 5.6 Luna: across 350 million input tokens and 1.5 million output tokens, the deployment has cost about US$20 total so far. I re-evaluate the model behind Hermes the way I'd re-evaluate any infrastructure dependency — against observed cost and performance, not habit.
What I actually did
- Chose this specific stack (Hermes Agent + GBrain + skillify) over building or using something else
- Deployed and operate it on an Azure VM as daily-use infrastructure
- Built a growing library of custom skills on top (Minecraft VM admin, outreach-scout, etc.)
- Own the model-routing judgment calls: DeepSeek V4-Pro → V4-Flash (cost) → GPT-5.4 mini (cost/performance) → 5.6 Luna (current, best performance-to-cost)
- Apply my own SDD (constitution/spec/validation) discipline to how I build and ship skills on top of the stack
Engineering discipline: SDD
Before I ship a custom skill or configuration change on top of the stack, I apply my own constitution → spec → validation triplet — a deliberate constraint against letting an agent with memory and tool access drift or regress silently, which is worse than not having the agent at all.
How guardrails actually get built
skillify is the existing mechanism in Garry Tan's GBrain/GStack ecosystem for turning one-off fixes into permanent, tested skills. My contribution is the specific skills I write with it: I test manually first, then use skillify to encode what works. The clearest example is the Minecraft VM administration skill. At first, Hermes was improvising shell commands from scratch every time, which is unreliable. After enough manual testing, I built that skill on top of the stack, so now Hermes calls known, tested scripts against the VM instead of generating commands live.
What it's actually used for
- Persistent, cross-session memory for personal context (the original "second brain" use case)
- Scheduled checks and routine personal-life tasks
- Open-ended research tasks — "look into X and produce a document"
- VM/infra administration via skillified command sets (e.g. the Minecraft server)
- A structured job-search outreach skill (outreach-scout) with a defined send target and a strict time-budget rule, so infra tinkering doesn't crowd out actual output
Quality bar (and what's next)
Every skill built on this stack — the Minecraft VM admin skill, outreach-scout, and everything since — goes through skillify's full checklist before it ships: a SKILL.md spec, unit tests, integration tests, LLM evals, a resolver trigger eval, and an end-to-end smoke test. That checklist, combined with the SDD constitution/spec/validation process I run on top of it, is what makes "reliable enough to depend on daily" more than a claim.
The next step is formalizing cross-skill regression checks when the underlying model changes. Per-skill evals catch regressions within each skill; a single pass that re-validates the whole library would make the next model migration safer and faster.
Why this matters beyond "cool personal project"
Most of what gets labeled "AI Engineering" in production right now isn't training models from scratch. It is knowing which existing infrastructure to adopt and integrate well, building a reliable skill layer on top of it, making deliberate model-selection calls under cost/performance constraints, and applying enough process discipline that changes don't silently break things. Hermes demonstrates that work: I chose and integrated the stack, operate it for a real daily workload, built the custom skill layer on top, and made three deliberate model migrations — I did not build the underlying agent framework from scratch.