320 lines
16 KiB
Markdown
320 lines
16 KiB
Markdown
# 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`
|
|
|
|
2. 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`
|
|
|
|
3. Current Timmy backlog and vision in Gitea
|
|
- `Timmy_Foundation/timmy-home#7` — Developer standards / modular purity / local-first / SOUL compliance
|
|
- http://143.198.27.163:3000/Timmy_Foundation/timmy-home/issues/7
|
|
- `Timmy_Foundation/timmy-home#15` — Introducing codex-agent to Timmy and the team
|
|
- http://143.198.27.163:3000/Timmy_Foundation/timmy-home/issues/15
|
|
- `Timmy_Foundation/timmy-home#20` — Hermes Agent v0.4.0 architecture spike and backlog alignment
|
|
- http://143.198.27.163:3000/Timmy_Foundation/timmy-home/issues/20
|
|
- `Timmy_Foundation/timmy-config#19` — Register MCP servers in config.yaml
|
|
- http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/19
|
|
- `Timmy_Foundation/timmy-config#20` — Rewire heartbeat_tick to invoke Hermes sessions for training telemetry
|
|
- http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/20
|
|
- `Timmy_Foundation/timmy-config#21` — Enable Hermes trajectory export for training pipeline
|
|
- http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/21
|
|
- `Timmy_Foundation/timmy-config#22` — Switch model default from Anthropic cloud to local Ollama (sovereignty)
|
|
- http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/22
|
|
- `Timmy_Foundation/the-nexus#551` — Morning briefing / compressed memory injection at startup
|
|
- http://143.198.27.163:3000/Timmy_Foundation/the-nexus/issues/551
|
|
- `Timmy_Foundation/the-nexus#610` — Shadow Context Manager / auto-generated brain dump for session continuity
|
|
- http://143.198.27.163:3000/Timmy_Foundation/the-nexus/issues/610
|
|
- `Timmy_Foundation/the-nexus#660` — Three-layer game architecture: Timmy → Reflex → Pilot
|
|
- http://143.198.27.163:3000/Timmy_Foundation/the-nexus/issues/660
|
|
|
|
4. 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:
|
|
|
|
- `4daad65` — `feat: 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.
|
|
|
|
- `26f8b79` — `fix(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.
|
|
|
|
- `c2c37ef` — `Show 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.
|
|
|
|
- `52ba940` — `feat(gateway): add reasoning hot reload`
|
|
This improves live operator control over gateway agents without requiring restart rituals.
|
|
|
|
- `7e52e8e` — `fix(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.
|
|
|
|
## Recommended actions
|
|
|
|
### 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
|
|
5. Build the Timmy-specific continuity layer on top of Hermes sessions and memory.
|
|
6. Clarify the exact difference between Hermes cron jobs and Timmy heartbeat continuity in implementation, not just theory.
|
|
7. Decide explicitly what remains unique to Timmy and what should remain upstream Hermes behavior.
|
|
|
|
### Strategic
|
|
8. Do not replace Hermes with OpenClaw.
|
|
9. Use OpenClaw only where it genuinely wins: sidecar gateway behaviors, additional channel patterns, or operator convenience.
|
|
10. 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
|
|
- `timmy-home#7` — http://143.198.27.163:3000/Timmy_Foundation/timmy-home/issues/7
|
|
- `timmy-home#15` — http://143.198.27.163:3000/Timmy_Foundation/timmy-home/issues/15
|
|
- `timmy-home#20` — http://143.198.27.163:3000/Timmy_Foundation/timmy-home/issues/20
|
|
- `timmy-config#19` — http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/19
|
|
- `timmy-config#20` — http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/20
|
|
- `timmy-config#21` — http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/21
|
|
- `timmy-config#22` — http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/22
|
|
- `the-nexus#551` — http://143.198.27.163:3000/Timmy_Foundation/the-nexus/issues/551
|
|
- `the-nexus#610` — http://143.198.27.163:3000/Timmy_Foundation/the-nexus/issues/610
|
|
- `the-nexus#660` — http://143.198.27.163:3000/Timmy_Foundation/the-nexus/issues/660
|