Agent stack build plans · № 3 · part 3

Architecture

Everything below is a named Hermes feature except two boxes — those are marked, because pretending conventions are features is how plans like this rot.

Cron scheduler — built in jobs live in ~/.hermes/cron/ · created in natural language via the cronjob tool · managed with hermes cron list/run/pause/resume/status

↓ fires 07:15 daily

Agent run — the /research-intern briefing skill a skill you create at ~/.hermes/skills/research/research-intern/SKILL.md; the cron job’s instruction just invokes it

↓ gathers via tools

Web toolsmetered web_search / web_extract (Firecrawl) and x_search, all through the paid Nous Portal tool gateway — every call is billed

Scraper skills self-written via skill_manage, gated by skills.write_approval — SKILL.md + scripts/ per awkward source; run through execute_code/terminal

↓ scripts execute in

Docker terminal backend — the sandbox hardened container: all capabilities dropped, no-new-privileges, 256-process limit, 512 MB tmpfs /tmp. Not optional here — see the honesty note below

↓ checked against memory

session_search full-text (SQLite FTS5) over past conversations in ~/.hermes/state.db

reports/ archiveyou build this a directory of dated markdown reports the intern greps before writing — a convention this plan defines, not a Hermes feature

↓ writes report, then delivers via

Messaging gateway — hermes gateway background daemon (systemd/launchd installable); delivery to Telegram here, but cron can deliver to any supported platform

The memory, honestly

“A memory archive of past reports” sounds like one feature. In Hermes it is three layers, and only two exist out of the box:

MEMORY.md is an index card, not an archive. Hermes’s pinned memory file (~/.hermes/memories/MEMORY.md) is capped at 2,200 characters — roughly one screen. Use it for standing facts (“beat: solid-state batteries; owner reads FT but has no API access; skip oxide-vs-sulfide explainers”), never for coverage history. Anyone who tells you Hermes has built-in vector-store memory is wrong as of July 2026.
session_search is the recall layer. Keyword full-text search over every past conversation. Good for “have I discussed QuantumScape’s pilot line?”; it is FTS, so a story reworded beyond keyword overlap can slip past it.
The reports/ directory is the archive — and it’s yours. One file per day, stable section headings, grep before writing. This is the layer that makes “never repeats itself” true, and it costs you one mkdir and one paragraph in the briefing. If you outgrow grep, Hermes supports external memory-provider plugins (Mem0, Honcho and others) — bolt one on later; don’t start there.

The sandbox, honestly

Hermes’s execute_code tool runs Python that can call the agent’s tools over RPC — ideal for scraper scripts. But it is not inherently sandboxed: on the default local terminal backend that Python runs as your user, on your machine. Since this plan has an agent writing and running its own code against arbitrary web content unattended at 7 a.m., pairing it with the docker backend (one of six backends: local, docker, ssh, singularity, modal, daytona) is the load-bearing decision, not a nicety. The docs’ own framing: the container is the security boundary. Keep skills.write_approval on so new and edited scraper skills wait for you, and leave approvals in smart or manual mode — details on the setup page.

What’s deliberately absent

RSS — not built in. If a feed matters, the intern writes a small fetch script as a skillyou build this — or you wire an external RSS service to Hermes’s webhook gateway. Either way it’s explicit, not assumed.
Browser automation — Portal’s Browser Use tools (browser_navigate etc.) exist but stay out of the daily loop: slower, costlier, and a cloud browser clicking around unattended is exactly the surface area this plan avoids. Reserve them for one-off investigations you supervise.