Hermes · what it actually runs

The previous post covered how the box is wired. This one covers what the agent spends its time on, written up from its own session records. Less glamorous than the benchmark numbers, but it's the reason the box is on.

Writing the journal

The benchmark posts and the per-box write-ups are drafted by the agent. I give it a task, it drives the model, pulls the stats, and writes the results up. The human pass is the review, not the typing.

Running the benchmarks

Each benchmark run is the same loop, end to end: bring up the container, wait for the model to be ready, fire the benchmark requests, read the client-side timing, cross-check it against the server metrics, and log the numbers. Same protocol every run after run, which is what keeps the numbers comparable across engines.

Research

When a run turns up something unexpected, the agent goes looking. Two containers handle it: a local web search (SearXNG) that returns candidate links, and a local fetcher (PinchTab) that pulls a page and hands back clean text. I call them like any other tool through the standard MCP interface, so there's no cloud search API in the loop and the traffic egresses through the same VPN as everything else.

Checking the rendered page

Some things can't be verified from the terminal. The agent drives a headless browser to look at the actual rendered page and measure layout, catching what a text-only check would miss. That's what the extra shared memory in the compose is for.

The other services

The box also runs a handful of small apps I built, all local, all on the same "SQLite and plain HTML, no framework" diet as this site. They get the same treatment: one repo each, a shared launcher that starts and watches them, and a health check that catches the ones that drift.

• A daily stock market report: a pipeline that builds a briefing overnight and serves it on a local dashboard.
• A few household PWAs: a baby tracker, a workout log, and an image gallery.
• Some glue services that expose the household services to the agent over the standard tool interface (MCP), so the models and the tools don't have to know about each other.

No cloud, no analytics, everything stays on the LAN.

Service ops

After a code change it restarts the affected service and runs a health check. It tracks what's running and which port belongs to what, so restarting one thing doesn't take down a sibling.

What keeps it useful

Three things turn a chat agent into something I leave running unattended:

• Memory that carries across sessions, backed by a local fact store: short standalone facts about the machines, the decisions, and the people involved, recalled when a message is about them. No cloud memory service, so nothing about the lab leaves the box.
• Skills, saved procedures it loads when a task matches, so it doesn't re-derive the same steps.
• Profiles, separate contexts per job, so one long task doesn't bleed into another.

It also runs on a schedule for the boring recurring stuff, so a daily report doesn't need me to think about it.

Where it stops being useful

It's not a substitute for judgement on anything that leaves the box. For anything public or hard to undo, the agent prepares it and a human approves it. That line is deliberate.