Files
timmy-home/reports/notebooklm/2026-03-27-hermes-openclaw/hermes-agent-backlog-vision-report.md
2026-03-27 23:59:09 -04:00

16 KiB

Hermes Agent Research Report

Date: 2026-03-27 Audience: Alexander Whitestone / NotebookLM Subject: Hermes Agent release notes and git history, mapped against Timmy backlog and vision

Executive summary

Hermes Agent is already much closer to Timmy's desired operating system than the backlog wording makes it sound. The strongest overlaps are the messaging gateway, MCP, memory/session continuity, skills, delegation, Codex support, and migration paths from OpenClaw. The single most important caveat is version drift: Timmy backlog items often talk as if Hermes v0.4.0 capabilities are already local and proven, but the local sovereign branch I inspected is still anchored around the v0.2.0 release note plus a stream of newer post-release commits. That means several goals are directionally supported, but not all of them are locally landed in the exact form the backlog assumes.

The practical takeaway is simple: Hermes should still be treated as the center of gravity for Timmy. It already provides the majority of the platform surface Alexander wants. What remains is not a search for a totally different base system. It is a matter of tightening sovereignty defaults, verifying version assumptions, and deciding which pieces of OpenClaw should complement Hermes rather than replace it.

Scope and methodology

This report was built from four source classes:

  1. Local Hermes repo and docs
  • Local repo path: ~/worktrees/gemini-base-rockachopa-hermes-agent
  • Key files reviewed:
    • README.md
    • RELEASE_v0.2.0.md
    • docs/migration/openclaw.md
    • docs/honcho-integration-spec.md
    • docs/acp-setup.md
    • .plans/openai-api-server.md
    • AGENTS.md
  1. Recent local git history on the sovereign branch
  • Branch: sovereign
  • Recent head at audit time: 4daad65 feat: fallback chain with recovery — Groq, Kimi, local Ollama
  1. Current Timmy backlog and vision in Gitea
  1. Supporting code paths and tests referenced by the local branch

What Hermes already is, in platform terms

The current Hermes README still describes the right strategic shape for Timmy:

  • a self-improving agent shell
  • runs in CLI and messaging channels
  • supports many providers and custom endpoints
  • includes memory, session recall, skills, cron, delegation, and multiple terminal backends
  • is already explicitly aware of OpenClaw migration

That matters because it means Timmy is not searching for a greenfield platform. Hermes already covers the majority of the desired surface area:

  • messaging gateway
  • memory and session continuity
  • MCP
  • cron and automation
  • skills as procedural memory
  • delegation and subagents
  • Codex support
  • local or sovereign model routing

In plain language: Hermes is already the operating body. The Timmy work is mostly about making it more sovereign, more coherent, and more explicitly Timmy.

Release-note snapshot: what v0.2.0 proves

The v0.2.0 release note is the clearest stable anchor in the local tree.

File reviewed:

  • ~/worktrees/gemini-base-rockachopa-hermes-agent/RELEASE_v0.2.0.md

The release note shows that Hermes had already become, by March 12, 2026:

  • a multi-platform messaging gateway
  • an MCP-capable agent
  • a skills ecosystem with broad categories
  • a centralized provider router
  • an ACP server for editor integration
  • a worktree-aware coding agent
  • a checkpoint/rollback capable tool user
  • a tested, increasingly production-shaped platform

The features that matter most for Timmy's backlog are:

  1. Messaging gateway The release note confirms first-class support for Telegram, Discord, Slack, WhatsApp, Signal, Email, and Home Assistant. This directly supports Timmy's ambition to be reachable where Alexander lives, with one shared session and tool model.

  2. MCP The release note confirms native MCP with stdio and HTTP transports plus sampling support. This is directly aligned with timmy-config#19 and the later OpenClaw-related MCP work.

  3. Skills ecosystem Hermes is already built around skills as durable procedural memory. That matches the Timmy worldview far better than a monolithic "hardcode it in the core" posture.

  4. Codex The release note explicitly calls out OpenAI Codex support. This matters for timmy-home#15 and for Alexander's current preference to use Codex as a serious backend rather than as a side curiosity.

  5. OpenClaw migration The README and migration docs show that Hermes has already thought about OpenClaw as something to ingest, not just compete with. That is strategically important: Hermes sees OpenClaw as interoperable material.

Recent git history: the signals that matter now

Recent local branch history suggests Hermes is still evolving toward exactly the kinds of things Timmy cares about.

Important recent commits:

  • 4daad65feat: fallback chain with recovery — Groq, Kimi, local Ollama This is the strongest sovereignty-adjacent commit in the recent local history. It does not make local primary by itself, but it does make local/provider recovery materially more robust.

  • 26f8b79fix(setup): persist provider when switching model endpoints This is an operational maturity fix. It reduces the chance that the system silently drifts between backends or loses the intended provider when switching models.

  • c2c37efShow configured model and provider in status output This is a visibility fix, but visibility is sovereignty. If Alexander cannot immediately see which provider/model is active, the stack is too easy to lie to himself about.

  • 52ba940feat(gateway): add reasoning hot reload This improves live operator control over gateway agents without requiring restart rituals.

  • 7e52e8efix(gateway): bridge quick commands into GatewayConfig runtime This matters because quick commands are how a sovereign operator reduces friction and keeps recurring control actions cheap.

  • 5c9a842 and 50d6659 — MEDIA/send_message salvage work This reinforces messaging delivery correctness, which matters for any real multi-channel Timmy presence.

  • 1a85712 — telephony skill This extends the communications layer, though it is less sovereign than the core local-first vision.

The most important alignment with Timmy backlog and vision

1. Sovereignty and local-first routing

Backlog reference:

  • timmy-config#22

Hermes already supports:

  • custom endpoints
  • local/self-hosted inference
  • explicit provider routing
  • fallback chains

The gap is not capability. The gap is policy and default stance.

Hermes is already capable of sovereign routing. The remaining work is to make the default path actually reflect the sovereignty doctrine instead of leaving cloud-first behavior as the easy operational default.

This means #22 is not blocked by missing architecture. It is blocked by config, discipline, and verification.

2. MCP and tool surface

Backlog references:

  • timmy-config#19
  • OpenClaw-related MCP issues later in the stack

Hermes is already a real MCP client. That means Timmy's practical near-term move is not "wait for a new harness." It is "wire the actual MCP servers into the existing harness cleanly and prove the flow."

This is a place where Hermes already gives Timmy a serious advantage.

3. Session continuity, memory, and the 'brain dump' vision

Backlog references:

  • the-nexus#551
  • the-nexus#610

Hermes already has several strong ingredients:

  • session naming and search
  • memory persistence
  • Honcho-based user modeling
  • compression and resume patterns

But the exact Timmy vision of a compressed, auto-generated continuity injection for fresh sessions is still not fully identical to current Hermes behavior.

Important conclusion: Hermes is directionally aligned with the continuity vision, but the backlog still points to a real gap. The materials exist; the exact Timmy-specific continuity loop still needs to be made explicit.

4. Codex and coding-agent posture

Backlog reference:

  • timmy-home#15

Hermes already supports Codex and ACP/editor workflows. This means Codex is not an external bolt-on dream. It is already part of the platform story.

That reduces strategic risk. Alexander can use Codex as a routed capability inside a broader agent system rather than as a separate universe.

5. Delegation and the three-layer architecture

Backlog reference:

  • the-nexus#660

Hermes already has subagent delegation and isolated workstreams. That means the Timmy → Reflex → Pilot architecture is not alien to Hermes. It is just not fully realized in the exact three-layer form the game-agent architecture wants.

This is an important nuance:

  • Hermes already contains the primitives.
  • The Timmy stack still needs the opinionated architecture on top.

Where the backlog overstates current local reality

This is the most important caution in the whole report.

timmy-home#20 talks in the language of Hermes v0.4.0 and assumes a set of capabilities that are not all visible in the local sovereign checkout I inspected.

What I found locally:

  • clear v0.2.0 release note
  • recent post-release commits
  • plans for more, including OpenAI-compatible API server work
  • no local v0.4.0 release artifact in this checkout

Implication: Some backlog items are comparing themselves to a newer upstream idea of Hermes than the locally anchored Timmy branch actually proves.

That does not mean the backlog is wrong. It means Alexander should treat some items as:

  • sync/upgrade/verify tasks rather than
  • already-landed local facts

The biggest examples are:

  1. API server assumptions There is a plan file for an OpenAI-compatible API server. That is not the same as a hardened, local, already-adopted production surface in this checkout.

  2. MCP ergonomics The backlog language can imply a friendlier install flow than what I actually found in-tree. Current Hermes MCP is powerful, but config-driven and more manual than the backlog fantasy in a few places.

  3. Full continuity behavior Hermes has strong continuity ingredients, but the exact Timmy "brain dump" continuity mechanism is still an active vision item, not a fully-closed fact.

Where Hermes still falls short of the full Timmy vision

1. Nostr is not there in the same way

Hermes has broad messaging coverage, but not the exact Nostr/economic-peer layer Timmy wants.

2. Cron starts cold

Hermes cron is useful, but it still starts from a fresh context model. That means a lot of Timmy's continuity vision has to be made explicit if cron jobs are supposed to feel like one continuing mind rather than isolated tasks.

3. Multi-agent identity layering is incomplete

Hermes can delegate, but Timmy's deeper architecture wants more than generic delegation. It wants named cognitive layers with distinct roles and tight continuity.

4. Sovereignty still requires operator intent

Hermes can route locally. That does not mean it will do so unless Alexander or Timmy explicitly make that true. Sovereignty is possible; it is not yet automatically enforced by the system's defaults.

Strategic conclusion

Hermes should remain the center of gravity.

Why:

  • It already matches the broad shape of Timmy's desired system.
  • It already has gateway, skills, memory, delegation, Codex, and MCP.
  • It already has an import/migration posture toward OpenClaw.
  • It is more aligned with Timmy's training and self-improvement future than OpenClaw is.

The right mental model is:

  • Hermes is the body and the operational harness.
  • Timmy is the soul and the doctrine.
  • OpenClaw is a potentially useful sidecar or ingress layer, not the center of identity.

Immediate

  1. Treat timmy-config#22 as a config-and-verification priority, not a research problem.
  2. Treat timmy-config#19 as a high-leverage harness integration task.
  3. Treat timmy-home#15 as already directionally supported by Hermes.
  4. Audit which v0.4.0 assumptions are real in local Timmy branches versus only true upstream.

Near-term

  1. Build the Timmy-specific continuity layer on top of Hermes sessions and memory.
  2. Clarify the exact difference between Hermes cron jobs and Timmy heartbeat continuity in implementation, not just theory.
  3. Decide explicitly what remains unique to Timmy and what should remain upstream Hermes behavior.

Strategic

  1. Do not replace Hermes with OpenClaw.
  2. Use OpenClaw only where it genuinely wins: sidecar gateway behaviors, additional channel patterns, or operator convenience.
  3. Keep Timmy's long-term training/self-improvement loop grounded in Hermes-native state and artifacts.

Final verdict

Hermes is not a maybe. Hermes is already the strongest fit for Timmy's base runtime.

The real work now is not finding a better foundation. It is:

  • reducing version confusion
  • tightening sovereignty defaults
  • finishing continuity machinery
  • wiring the exact integrations Timmy wants
  • using OpenClaw surgically instead of romantically

Source appendix

Primary local files

  • ~/worktrees/gemini-base-rockachopa-hermes-agent/README.md
  • ~/worktrees/gemini-base-rockachopa-hermes-agent/RELEASE_v0.2.0.md
  • ~/worktrees/gemini-base-rockachopa-hermes-agent/docs/migration/openclaw.md
  • ~/worktrees/gemini-base-rockachopa-hermes-agent/docs/honcho-integration-spec.md
  • ~/worktrees/gemini-base-rockachopa-hermes-agent/docs/acp-setup.md
  • ~/worktrees/gemini-base-rockachopa-hermes-agent/.plans/openai-api-server.md

Key recent commits observed locally

  • 4daad65 feat: fallback chain with recovery — Groq, Kimi, local Ollama
  • 26f8b79 fix(setup): persist provider when switching model endpoints
  • c2c37ef Show configured model and provider in status output
  • 52ba940 feat(gateway): add reasoning hot reload
  • 7e52e8e fix(gateway): bridge quick commands into GatewayConfig runtime
  • 5c9a842 fix: complete send_message MEDIA delivery salvage
  • 1a85712 feat(skills): add optional telephony skill with Twilio, SMS, and AI calls

Backlog and vision references