HERMES Agent Workflow

help edit space_dashboard
Draft — This content has not been approved for publication.
ai generated
open_in_full page
fullscreen modal
edit edit
space_dashboard advanced

Verdict: [NON-HYPERON-SELF-IMPROVING-AGENT-WORKFLOW-TO-ABSORB]

HERMES (NousResearch/hermes-agent, MIT, Python) is “the self-improving AI agent built by Nous Research.” It is external augmentation technology: there is zero Hyperon / MeTTa / AtomSpace / PLN coupling anywhere in the source. Its value to Hyperon teams is the workflow pattern — a mature, code-backed agent loop with a closed learning loop, a clean tool-integration boundary, and a deployment story. Adopt the workflow; compile it into MeTTa-native structures; do not import the Python stack.

Name-coincidence guard: this HERMES is unrelated to the Magi HERMES (the L2/L3 cognitive-stack proposal on the Magi Archive, card 741). The shared name is a pure coincidence.

The absorb-this workflow (blueprint)

  1. Prompt-cache “narrow waist.” Keep the system prompt and tool schema byte-stable across a conversation so the provider prefix cache is reused; push all mutable material (recall, plugin context) to user-message / ephemeral paths or a cache-safe per-turn prologue. The repo states the rule plainly — “per-conversation prompt caching is sacred” — and enforces it in code (restore/replay the cached system prompt; apply Anthropic cache-control breakpoints).
  2. Skills as procedural memory. The agent creates, edits, and self-improves skills from experience (after a complex success, an error overcome, a user-corrected approach, or a non-trivial workflow discovery), stored as agentskills.io-compatible SKILL.md bundles. This is code-backed (a skill-manager tool + a background self-improvement review), not marketing.
  3. Pluggable cross-session memory. A memory-provider interface (initialize / prefetch / sync-turn / pre-compress / write-mirror / delegation-observation hooks) lets external memory backends plug in without binding one into the agent loop. Core memory writes are native; the headline “intelligence” (e.g. Honcho dialectic user-modeling, Hindsight consolidation) is integrated via external provider plugins, not native to core HERMES.
  4. MCP as a bidirectional tool boundary. HERMES is both an MCP client (connect to external servers over stdio/HTTP/SSE, discover + register their tools) and an MCP server (expose selected HERMES surfaces to external clients / editors). Late-connecting servers refresh the tool snapshot in a cache-safe prologue, preserving the prompt-cache contract.
  5. One multi-gateway process. A single gateway fronts Telegram / Discord / Slack / WhatsApp / Signal / CLI, with built-in cron for scheduled automations delivered to any platform.
  6. Subagents + offline trajectories. Live delegation spawns isolated child agents (single or parallel batch) with restricted toolsets; a batch runner generates training/research trajectories offline. RPC/scripted tool calls aim to “collapse multi-step pipelines into zero-context-cost turns.”
  7. Deploy anywhere. Six terminal backends — local, Docker, SSH, Singularity, Modal, Daytona — plus an Agent Client Protocol (ACP) adapter for editor interop. (Serverless “hibernate-on-idle” depends on the chosen backend, not a central abstraction.)

What is genuinely novel vs commodity

Novel / worth absorbing: the closed learning loop (skills-from-experience that self-improve), the prompt-cache narrow-waist discipline, and the bidirectional MCP boundary. Commodity: multi-gateway fronting, cron, and provider routing are table-stakes for modern agent frameworks.

NuNet adaptation — thin-image + MCP-delegation

nunet/hermes-agent-lite is a packaging fork, not a new architecture. Measured at the pins it is 7 commits ahead / 298 behind upstream (merge-base 5aec00f7); the entire lite-only delta is Dockerfile.lite + README + a CI job. It strips the heavy toolsets (Playwright/Chromium, ffmpeg, TTS, image-gen; ~1.5 GB → ~400 MB) and delegates them to dedicated MCP servers (e.g. playwright-mcp), keeping s6-overlay PID1, stage2-hook config seeding, skills-sync, MCP lazy-loading, and the provider registry identical to upstream. (Detail: the Dockerfile.lite comments still mention a slack extra, but the actual uv sync command installs only cli, mcp, and anthropic — Slack moves to MCP too.)

Augmentation angle for Hyperon teams

The thin-image + MCP-delegation pattern aligns directly with the team’s own MCP-server architecture (the Hyperon-wiki MCP and the planned Phase-4 agent MCP surface). A HERMES-style agent could curate an AtomSpace and run MeTTa tools through MCP, with skills serving as procedural memory over MeTTa workflows and the prompt-cache discipline keeping long sessions cheap. The boundary holds: absorb the loop and the MCP packaging, express them in MeTTa-native structures.

Comparative placement

  • vs the Claw family (mettaclaw / OmegaClaw, Hyperon-native): those run the reasoning/decision loop inside the Space via PeTTa/Prolog. HERMES is an external Python/LLM agent.
  • vs metta-motto: a prompt-gate layer to call LLMs from MeTTa. HERMES is a complete standalone agentic ecosystem (its own memory, gateway, deployment).
  • Same “LLM agent” space, different stacks — adopt-the-workflow-not-the-stack.

Provenance

Cross-Org Cognitive Repo Sweeps, SC-3 (Distributed Compute), Source 1. Pins: NousResearch/ (canonical) + nunet/ (adaptation). Three-model extraction (Codex citation-grade + Gemini synthesis + orchestrator spot-verification of all load-bearing cites at the pins), 2026-06-23. Boundary: CUDOS and NuNet distributed-compute/blockchain infrastructure are excluded as non-cognitive plumbing; nunet/misc-experiments/f1r3fly-node belongs to the SC-4 F1R3FLY sweep.

Verdict tags: [NON-HYPERON-SELF-IMPROVING-AGENT-WORKFLOW-TO-ABSORB] · [ZERO-HYPERON-COUPLING] · [SKILLS-CODE-BACKED-PROCEDURAL-MEMORY] · [MEMORY-CODE-BACKED-WITH-EXTERNAL-PROVIDER-INTEGRATION] · [MCP-CLIENT-AND-SERVER] · [PROMPT-CACHE-NARROW-WAIST-CODE-BACKED] · [THIN-IMAGE-MCP-DELEGATION-ADAPTATION]