Hermes Agent v0.21.0 Pantheon: test cron continuity before you upgrade

Hermes Agent v0.21.0, tagged v2026.8.31 on August 31, 2026, is the Pantheon release. The practical change is not that a scheduled agent can talk more: it can carry a bounded trace of what it previously reported. That makes a monitor testable for duplicate suppression rather than merely impressive in a release note.

Bottom line: upgrade a disposable profile first. Test the exact workflow you depend on, with fake or approved non-production credentials. Do not use Bot Mode, profiles, or a peer connection as a substitute for network, tenant, approval, or secret isolation.

What we verified and what remains a vendor claim

The repository’s accompanying continuity packet checked the exact tagged source and intentionally did not spend or copy a production credential. The live gate remains unmeasured; that is the correct result when a safe model route is not available.

Capability	Evidence status	What it establishes
Exact version and tagged source	Observed	The isolated runtime reported v0.21.0 (2026.8.31) from tagged commit 29112bef.
Cron continuity	Source test passed; live three-run gate unmeasured	The tagged test proves prior output is injected into a continuity job. It does not prove your model will emit the required report/change/silence sequence.
Cron notepad	Source-inspected	The scheduler renders a durable per-job notepad into the prompt. A live persistence check still needs a safe model route.
hermes peer dm	Source test passed; live nonce roundtrip unmeasured	The tagged loopback test exercises HTTP auth and hidden canonical Bot Chat lookup. It does not prove reachability, model routing, or peer policy in your network.
Protected instruction-file writes	Source test passed	A write to AGENTS.md fails closed when no human approval callback exists. Keep human review enabled for real instruction, skill, and memory changes.
Desktop Bot Mode, MCP screen, and agent-driven browser	Vendor claims	The release notes describe these features. This guide did not test the desktop UI, so it includes no screenshot or independent usability claim.

The release also announces bundled Bot Mode, steerable subagents, a consolidated MCP surface, browser control, providers, and model catalog additions. Those are maintainer claims from the release notes, not an independent quality score. The release’s commit, issue, and contributor totals are change-history context, not evidence that your deployment is reliable.

The continuity gate that matters

Create the test source so it has only two meaningful states: initial and changed-once. Do not put timestamps, random IDs, or changing fetch metadata in it; a monitor compares exact source output.

Create the disposable job with --continuity and use a durable notepad key such as last-verified-state. Run it three times:

Run	Controlled source	Required result	Durable-state check
1	initial	Reports the initial state	Notepad is created or updated
2	changed-once	Reports exactly the one change	Notepad still contains the state from run 1 plus the update
3	changed-once again	Exactly [SILENT]	Notepad remains readable and no duplicate report is delivered

In v0.21.0, continuity adds the job’s most recent output to the next job prompt; it is not magic memory and it cannot decide whether your source is stable. The notepad is separate durable scratch state. Inspect both. A job can still repeat itself if the prompt is vague, the source churns, or the model ignores the supplied context.

A documented script-backed creation pattern is:

mkdir -p "$HERMES_HOME/scripts" /tmp/hermes-continuity-input
printf 'initial\n' > /tmp/hermes-continuity-input/state.txt
printf '#!/usr/bin/env python3\nfrom pathlib import Path\nprint(Path("/tmp/hermes-continuity-input/state.txt").read_text(), end="")\n' \
  > "$HERMES_HOME/scripts/continuity-source.py"

hermes cron create "every 1h" "Compare the supplied SCRIPT OUTPUT with your previous report. Update the durable notepad. If nothing changed, output exactly [SILENT]." \
  --script "$HERMES_HOME/scripts/continuity-source.py" \
  --continuity \
  --name "disposable-continuity-test" \
  --deliver local

Run the job once, replace only initial with changed-once in /tmp/hermes-continuity-input/state.txt, run it again, then run it a third time without changing the file. --script runs the stable source before each agent invocation and injects its stdout into the prompt; it does not itself suppress an unchanged run, so the third [SILENT] is the continuity result being tested. Remove the job, script, and temporary input after recording redacted evidence. Use the current cron documentation for your installed version before running it. Pin a deliberately approved non-production provider/model if the test must make an inference call. --no-agent is useful for simple script alerts, but it does not test model continuity.

Peer handoff: prove the nonce, not the label

hermes peer is a direct gateway-to-gateway path. The receiving side needs the API-server platform, a strong API_SERVER_KEY, a reachable URL, and a canonical Bot Chat. The peer key is a credential; keep it in the isolated profile’s credential store, never in a checked-in command log.

1. Create two fresh profiles with no copied skills, memory, messaging integrations, or production keys.
2. Run the receiving profile’s API-server gateway only on a controlled test network.
3. Register it from the sender using its generated test key.
4. Generate a unique nonce locally and send a short request through hermes peer dm.
5. Pass only when the returned canonical Bot Chat reply contains the exact nonce. Save a redacted transcript and the peer URL class, not the key.
6. Remove the peer registration, stop both gateways, delete both profiles, and verify that the profiles no longer appear in hermes profile list.

The Bot Mode documentation is clear about the boundary: a Bot is a profile with its own configuration, memory, skills, credentials, and history. That is useful separation, but it is not hostile-tenant security. Peers also add a network and credential boundary; protect it with loopback/LAN/VPN controls, a generated key, least-privilege profiles, and explicit delivery limits.

Security boundary: standing instructions stay human-controlled

The release says protected agent-instruction files now require write approval. Treat that as a guardrail against quiet persistence, not a reason to accept arbitrary prompts. Keep a human approval path for AGENTS.md, SOUL.md, skills, memory stores, and project rules. Test denial in a throwaway directory before relying on it.

Secret redaction reduces accidental disclosure, but redaction is not permission control. Do not place a real key in a test prompt merely to see whether it is hidden. Use generated fake values, scan sanitized logs for them, and discard the test state afterward.

Upgrade path and catches

1. Record hermes --version, your installed distribution, and the provider/model route in use.
2. Back up configuration through the supported Hermes mechanism; do not hand-copy a mixed production profile into a test directory.
3. Select or install the target version in an isolated profile/home. Confirm the tag and exact CLI help before using new flags.
4. Run the continuity gate, the peer nonce gate if you use inter-agent handoffs, and a protected-write denial check.
5. Check cron run history, delivery routing, model pins, approval behavior, and cleanup.
6. Only then reconnect a production profile or messaging integration.

Two catches are easy to miss. First, an unchanged monitor needs byte-stable input; timestamps turn every run into a change. Second, peer DMs are synchronous short exchanges. For a longer task, use the current documentation’s asynchronous peer-run workflow and its idempotency controls rather than holding a connection open indefinitely.

Sources and reproducible evidence

• Hermes Agent v0.21.0 release notes
• Hermes cron documentation
• Hermes Bot Mode documentation
• Repository continuity packet
• Prior Superbash Hermes v0.20.0 guide

The local packet records an exact tagged runtime and three focused source tests. Its live cron and peer results are deliberately unmeasured_blocked because no approved non-production inference credential was available. Do not turn that limitation into a pass claim.

Put this to work

Separate an implementation claim from a result you have reproduced in an isolated profile.

Try

Run a disposable three-turn monitor with a stable source: initial report, one change, then a silent unchanged run.

Prove it worked

Record the version, source state, each redacted output, durable notepad, peer nonce, and cleanup result before enabling production delivery.

Where it can pay

A documented upgrade and automation verification service is more useful than an untested release-note summary.

Keep in view

• Cron continuity can give each job its previous output and a durable notepad, making a monitor capable of suppressing repeats.
• `hermes peer dm` sends a bounded request to another API-server gateway's canonical Bot Chat and returns its reply.
• Protected instruction files require human approval for writes, including in automated or permissive workflows.

Learn the workflow: building Hermes automations →