What daily Hermes use actually looks like: the updater that interrupted the work

Published Oct 15, 2026 · Updated Oct 17, 2026

1. WORK Task → profile → relevant skill Retrieve the procedures for this job, not permission for another lane.
2. EXECUTE Selected model + bounded tools Local or cloud route; inspect, edit, test and read back.
3. UPDATE CHECK Install channel + active work Ask update semantics; inspect running work before a restart.
4. BRANCH Running / unknown → wait Verified quiet can proceed to the other gates; it is not by itself permission to update.

I have written about the local model machines and the content pipeline before giving Hermes its own story. That’s a gap in the build log. Hermes is part of the working environment, not just the API client hidden between the interesting screenshots.

The useful introduction isn’t a feature roundup. It’s what happened on October 13 and 14: my update wrapper interrupted the work it was supposed to keep healthy, an incident-preservation guard landed, and a test that looked green turned out to be testing the wrong expectation.

This is our operating layer around Hermes. These wrapper repairs are not claims that I authored fixes in upstream Hermes.

What I actually use it for

Hermes Agent supplies the agent environment: tools, profiles, skills, persistent sessions and a messaging gateway. In my setup, operational work and growth/content work have separate profiles. A profile provides working context; it is not, by itself, proof that a task finished or permission to cross into another job’s scope.

The tools do the unglamorous work: inspect source, read logs, make a bounded edit, run the test and check the result. Skills carry procedures that are worth retrieving when a task needs them. For update work that includes preserving active work and checking the actual runtime, rather than assuming a changed checkout updated every process.

There is a local-model side too. Retained Hermes usage records show GLM-5.3-Flash-EXL3 against a private endpoint during this period, including the named DGX provider route. Other retained records show cloud-backed models. The local lane is integrated; it is not the only engine in use.

That is narrower than saying every request went through the DGX pair. Session/model counters don’t establish that, and they certainly aren’t invoices. Some retained records span more than one day; they are not a daily token budget.

The practical arrangement looks like this:

October 13: “behind main” wasn’t the right question

Our safe-window updater had been looking at how far the checkout lagged upstream. But a branch can have new commits while the install’s selected release channel has nothing new to install.

The October 13 change made the wrapper ask hermes update --check whether that channel had an installable update. This install was deliberately following main. That is my operating choice, not a recommendation that everybody should track it.

The lesson is more general: ask the component that owns update semantics. A raw git distance is not the same thing as an available release for the selected channel.

The day’s log records an update exiting successfully and a smoke run reporting 57 passing tests. The same log warns that a desktop-serving process still held pre-update code and needed its owner’s relaunch. Both statements can be true. Updated source, passing smoke tests and every active interface running the new code are different claims.

Then the updater killed the work

The wrapper checked for active board workers. It did not initially check all running scheduled agent jobs.

A gateway restart interrupted scheduled work on October 13. The repair added a check of running execution records and their live Hermes processes. The recorded readback then said the update was being skipped because scheduled executions were running.

That fixed a real omission. It did not finish the problem.

On October 14 the same class of failure returned. The execution database could not be read, and the check treated that error as a count of zero. The updater interpreted “I cannot inspect the running jobs” as “there are no running jobs” and continued.

That’s the line that matters in this whole story. Missing evidence had been converted into permission.

The green test that deserves a correction

The October 13 ad-hoc verification explicitly passed a case whose expectation was that no database returned zero. It proved the behavior it asked for. The expectation was wrong for a kill-prevention gate.

The October 14 repair changed an unreadable execution database to an unknown result, and the decision layer now skips the update in that case. A retained regression receipt records failure against a reconstructed pre-fix implementation and success against the repaired one.

There is natural-operation evidence as well: later October 14 updater log entries say cron executions unknown (executions.db unreadable — fail closed) and skip the update. That’s the specific observed behavior, not a promise that no job can ever be interrupted again.

I don’t want to hide the earlier green check. It is more useful than a clean story: tests can faithfully enforce an unsafe assumption. You have to review what a pass means.

Don’t clean away the evidence you still need

Another October 13 change concerned retention, not model quality.

Older command-run directories could contain evidence for incidents that were still open. Archiving and pruning those directories made the records harder for the incident tools to reach. The new guard identifies unresolved incident run directories and holds their containing entries back from pruning. The accompanying tests distinguish a protected directory from a similarly named sibling.

This is not a claim that every old incident was recovered. It is a source-level prevention change. There is a recovery census, but a census of recoverable records isn’t a completed recovery.

It also has limits: the implementation treats a missing ledger as empty. I would not describe the retention system as universally fail-closed. That is exactly the kind of broader reassurance this week’s updater failure warns against.

A skipped send isn’t a successful delivery

October 14 also brought a small, practical change to the deals-email pre-slot sentinel. A legitimate skipped-no-deal state no longer raises an unexpected-status alarm when there is no staged campaign to verify.

That is a quieter monitor, not an email delivered. The distinction matters: a monitoring pass should describe the condition it checked, not borrow the business outcome’s vocabulary. The commit also adds an affiliate-link provenance pre-check; neither source change proves a later customer send.

The repeated pattern is the same as the updater: don’t turn one kind of evidence into a stronger kind of success.

The shared-resolution-file story follows a related trap: another helper can replace a genuine recovery record even after checking that no file exists. Its regression forces that ordering and checks the surviving bytes, rather than just accepting a clean exit.

What daily AI use buys me—and what it doesn’t

The useful part is having an agent environment that can work with the actual source, logs, tests and procedures rather than giving me a plausible answer about them. The local DGX route is part of that environment; cloud-backed routes are part of it too.

The limits are equally concrete:

• A profile boundary does not replace action-level authorization.
• A skill is procedural context, not proof that its instructions ran.
• A passing test can preserve the wrong expectation.
• An update can pass its smoke check while an older desktop process remains active.
• A retained usage counter cannot establish cost savings or fleet-wide model coverage.
• A closed incident and one good later log entry do not guarantee permanent unattended reliability.

I’m not attaching a dollar-savings figure or hours-saved estimate. The retained evidence here supports the repairs and the observed behavior, not that calculation.

Why didn’t this site have a Hermes article already? The earlier posts covered the model server and downstream pipelines without explaining enough of the working environment between them. This is the missing operator story: not “an agent can use tools,” but “here is the evidence it read, the assumption that failed, and the narrower claim I can defend after fixing it.”

Update — October 17, 2026: protect claims and all served profiles

The next repair belongs in this story, not in a new “Hermes is fixed” announcement. My local operating-wrapper commit b1b39a2, “Protect cron claims and all served profiles during safe updates,” closes more specific gaps in the earlier barrier.

The read-only probe now checks both claimed and running scheduled executions across the verified live gateway’s served-profile inventory and independently running named gateways. It checks execution-owner PID and native start-time identity rather than requiring a particular command-name substring. A live owner whose start time cannot be compared remains protected; a proved dead or reused PID does not require rewriting the execution ledger. Missing inventory, an unreadable profile database or an incomplete probe result blocks the lifecycle action rather than becoming zero activity.

The same active-work barrier is used by the normal update decision and the environment-repair restart path. That second path matters: protecting only the advertised updater leaves a different restart route able to interrupt the same work. The barrier also preserves board workers, an already running update and the existing owner-window check.

What was tested: the retained paired-run receipt shows five original failure cases failing against the preimage and the repaired suite passing 26 tests. Those cases cover claimed executions, agents without the old command substring, other served profiles, PID reuse, unreadable or partial evidence, and environment-repair deferral. A separate read-only probe through the installed Hermes Python runtime observed live claimed and running rows across the checked inventory. Installation, rollback and reinstallation were verified without updating software or restarting the gateway.

What happened naturally: the later October 17 receipt records the original scheduled updater appending skip: 4 kanban worker(s) running and exiting zero, with the gateway identity unchanged. The check did not manually fire the updater. That proves one natural active-work skip after installation. It does not prove a natural cron-only deferral, a completed software update, a restart under load or permanent updater reliability; the specific cron barrier has the separate probe and regression evidence above.

These are local wrapper changes, not an upstream Hermes release claim. The source, paired test logs, installation readback and natural-execution receipt are private operational evidence retained for editorial review, not public downloads. For the broader arrangement, see my AI setup; for why a saved configuration or old label isn’t current runtime proof, see the model-identity story.

References and evidence boundary

For the public product behavior, start with the Hermes repository, profiles documentation and official documentation. Those explain Hermes; they do not independently certify my setup.

The October 13–14 incidents in this article come from my retained local wrapper commits, incident receipts and updater logs. Those operational records are private, not public download links. The claims above deliberately stop short of exposing real computer identities, prompts, credentials, execution IDs or private endpoints. Public documentation should not be mistaken for public proof of a private deployment.