video youtu.be Watch ↗

Hermes Architecture EXPLAINED: Memory, Context & Gateways

TL;DR

A 40-minute whiteboard walkthrough (Hugging Face channel) of the full architecture of Hermes, a personal always-on agent in the OpenClaw family of "claws." The through-line: the agent core is a deliberately minimalist loop (user message → build context → LLM ↔︎ tools → response → memory update), and everything interesting lives in the systems wrapped around it — a context assembly made of a few markdown files (soul.md personality, user.md auto-learned user facts, memory.md arbitrary facts), Context Compression that summarizes message history past a configurable threshold (default 50% of the window, checked before each turn and on context-window errors, sized by a chars÷4 estimate before the first response and by provider usage fields after), an always-on Agent Gateway that multiplexes Telegram/Discord/email/SMS/WhatsApp into the agent and rebuilds context from scratch per inbound message (session identity = gateway name + platform session ID, history in SQLite, with a session manager that interrupts/steers/queues), a three-tier Layered Agent Memory (markdown always-in-context; SQLite full transcripts with a bare-text table for similarity search; optional external providers like mem0/SuperMemory/Honcho queried after the first response to anticipate follow-ups), and an Agent-Native Cron — the agent's own tick()-every-minute scheduler reading plain-JSON job definitions and delivering results to a designated "home" channel as a system action, not a tool call. The memory-update tail of every single turn is what the presenter credits for Hermes being an agent that "continuously learns the more you use it."

Concepts introduced

Context Compression — threshold-triggered summarization of message history: when, how it's measured (chars÷4 then provider usage), and a structured summary prompt as the quality lever.
Agent Gateway — the always-on multiplexer between messaging platforms and an agent core: per-channel transports, per-message context reconstruction, session identity, and a session manager for interrupt/steer/queue.
Layered Agent Memory — the three-tier memory architecture: always-in-context markdown, internal transcript DB, optional external memory providers with post-first-response recall.
Agent-Native Cron — the agent's own minute-tick scheduler with plain-file job definitions, per-run markdown outputs, and system-level (not tool-call) delivery to a home channel.

Held, not dropped — themes touched but not yet warranting a page (spin out on demand):

External-memory-provider landscape — mem0 vs SuperMemory vs Honcho mechanisms (similarity search vs full-history + LLM extraction vs enriched LLM queries) and a possible ranking; the video explicitly defers this to a dedicated video.
Pi/PyAgent architecture comparison — the presenter's prior video on Pi's architecture and its much more minimalist compression prompt; a pointer to another source, not developed here.
Docs–code drift — the cron-storage discrepancy (docs say SQLite, code reads jobs.json) instantiates a general "trust the code over the docs" epistemics theme; the instance is recorded on Agent-Native Cron, the general theme is held.
The "claw" category — Hermes/OpenClaw as a family of personal always-on agents; the video treats it as ambient vocabulary, not a defined concept.

Key claims

The video states Hermes' agent loop is minimalist and runs once per user message: build context → LLM ⇄ tools → response → memory update. observation → Agent Loop — a concrete instance of the Reason-Act-Observe skeleton already on that page.
A memory-update stage at the tail of every conversational turn — analyze the exchange, write anything worth remembering — is what makes an agent continuously learn from use. principle → Agent Loop, Self-Improving System, Layered Agent Memory — the in-loop, per-turn form of the persist-memory rule.
Compress message history at a threshold of the context window; default 50%, raised to 70–80% for smaller-window models. (best practice) — context: long-running chat agents; the threshold trades compression frequency against headroom → Context Compression.
Check compression at two moments: before each turn, and on a context-window error from the LLM. (best practice) — context: the error path is the safety net when estimation undershoots → Context Compression.
Estimate context size as characters÷4 before the first response; accumulate the provider's returned usage tokens afterward — a tokenizer pass is "too expensive" for a good-enough check. (best practice) — context: pre-send there is no ground-truth count; post-send the provider's own tokenizer numbers are free → Context Compression.
The video states Hermes' compression prompt is structured (goal, constraints, completed actions, active state, blockers, key decisions, resolved questions, relevant files, previous summaries) and treats the user's most recent unfulfilled request, captured verbatim, as the single most important field. observation → Context Compression — the summary-quality lever; explicitly richer than Pi's minimalist equivalent.
A gateway must rebuild context from scratch per inbound message, because messaging channels deliver single messages, not conversations. principle → Agent Gateway — the structural reason the gateway is more than a relay.
Session identity in a multi-channel gateway is composed of the gateway name plus the platform's session ID, keyed into a local SQLite history store. observation → Agent Gateway.
A session manager should mediate messages that arrive mid-task — interrupt, steer, or queue, chosen by how the user sends them. (best practice) — context: always-on agents reachable from chat apps, where users message faster than tasks finish → Agent Gateway.
Every third-party channel integration is configured independently (webhooks vs 1-second polls vs websockets) — there is no universal gateway. observation → Agent Gateway.
Agent memory layers into always-in-context markdown, an internal transcript DB, and optional external providers — each tier with different freshness, cost, and recall. principle → Layered Agent Memory.
The video states Hermes stores every session transcript in SQLite, including a bare-text table to make similarity search over past conversations easy. observation → Layered Agent Memory — the same SQLite-as-transcript-store seen in OpenClaw's read path (see How AI Agents Search Their Memory — Hybrid Retrieval, in Practice (OpenClaw)).
Query external memory after the first response, not before — answer first, then recall related history to anticipate the follow-up. (best practice) — context: external providers add latency and cost per query; deferring recall one turn keeps the first answer fast at the price of first-turn amnesia → Layered Agent Memory.
The video states external memory is off by default in Hermes and most people don't enable it, though the presenter recommends it — some supported providers are free. observation → Layered Agent Memory.
An agent's scheduler can be its own minute-tick loop, decoupled from the OS cron. observation → Agent-Native Cron.
The video states Hermes' docs say cron jobs live in SQLite, but its code reads them from .hermes/cron/jobs.json, with per-run markdown outputs under cron/output/<job-id>/. observation → Agent-Native Cron — a docs–code discrepancy the presenter found by inspection; flagged as the source's claim for a later grounding pass.
Scheduled-job results should be delivered by the system to a designated home channel, not by the agent calling a send-message tool. observation → Agent-Native Cron — the home channel is chosen per gateway at setup.

Why this builds on the existing graph

Dominant stance builds_on, with a strong secondary corroborates:

Builds on the loop spine: Agent Loop held the Reason-Act-Observe skeleton and the persist-memory-to-a-file rule; this source adds the conversational instantiation — memory update as a first-class stage of every turn — and four wraparound systems the graph had no pages for (Context Compression, Agent Gateway, Layered Agent Memory, Agent-Native Cron). Each new node attaches to existing concepts rather than floating free, which is what makes this builds_on rather than novel.
Builds on the memory material from the write/architecture side: How AI Agents Search Their Memory — Hybrid Retrieval, in Practice (OpenClaw) covered OpenClaw's read path (hybrid retrieval over a SQLite store); this video — on a sibling agent in the same "claw" family — supplies the surrounding architecture: what feeds that store, which markdown stays permanently in context, and where external providers slot in.
Corroborates AI Second Brain: soul.md / user.md / memory.md are another independently-built instance of "agent memory is just markdown files," here maintained by the agent itself. Also corroborates Agentic Simplicity in passing — the core loop is "very, very simple," kept deliberately close to minimalist agents like Pi and OpenCode, with the sophistication pushed to the edges.
Corroborates Self-Improving System's compounding thesis from the per-turn end: the memory-update tail is the smallest-grain version of "the system gets smarter the more you use it," automatic and in-loop rather than periodic and human-driven — a difference in mechanism worth keeping visible, so it was appended there as a claim rather than merged.

Illustrated walkthrough

Keyed by t=MM:SS, each kept frame fused with the transcript segment it fell in. Visual coverage is ok (max blind gap ~32 s, 90% grid-floor), so the whiteboard state is well sampled throughout.