ClawdyHuang Research · v2026.4.30 · May 2026

Hermes Agent
Architecture Deep Analysis

A first-principles forensic breakdown of the self-improving AI agent — tracing the prompt construction lineage, agentic loop evolution, and the three major subsystems introduced in v2026.4.30.

#curator #kanban #guardrails #prompt-builder #gateway #self-improvement

Architecture Overview

Hermes Agent is a self-improving AI agent operating system. It runs a re-entrant agentic loop that assembles context from multiple sources, invokes an LLM, executes tool calls, observes results, and recursively abstracts successful workflows into reusable skills. The v2026.4.30 release represents the most significant architectural expansion since the initial launch — introducing background curation, task orchestration, and tool safety guardrails.

853
New Commits
6.9K
Core Lines Added
10.2K
Docs Lines Added
flowchart TB
    subgraph PA["Prompt Assembly"]
        SOUL["SOUL.md (Identity Core)"]
        SKILL["Skill Index (FTS5 + LRU)"]
        PROJ["Project Context (.hermes.md)"]
        KANBAN["Kanban Protocol"]
        GUARD["Guardrails"]
    end

    subgraph AL["Agentic Loop"]
        LOOP["AIAgent.run()"]
        LLM["LLM Inference"]
        TOOLS["Tool Execution (40+)"]
        OBSERVE["Observation"]
    end

    subgraph NEW["v2026.4.30 Subsystems"]
        CURATOR["Curator (Background)"]
        KANBAN_DB["Kanban Board (SQLite)"]
        GOALS["Persistent Goals"]
    end

    SOUL --> LOOP
    SKILL --> LOOP
    PROJ --> LOOP
    KANBAN --> LOOP
    GUARD --> TOOLS
    LOOP --> LLM
    LLM --> TOOLS
    TOOLS --> OBSERVE
    OBSERVE --> LOOP
    LOOP -.-> CURATOR
    LOOP -.-> KANBAN_DB
    LOOP -.-> GOALS

    style CURATOR fill:#0a2a1a,stroke:#00FF88,stroke-width:2px
    style KANBAN_DB fill:#0a2a1a,stroke:#00FF88,stroke-width:2px
    style GOALS fill:#0a2a1a,stroke:#00FF88,stroke-width:2px
    style GUARD fill:#1a0a2a,stroke:#FF00FF,stroke-width:2px
    style LOOP fill:#0a1a2a,stroke:#00FFFF,stroke-width:2px
  

Curator NEW

Background Skill Maintenance Orchestrator

The Curator is an auxiliary-model background process that periodically reviews agent-created skills and maintains the collection. It's the first true "meta-agent" — a second AIAgent fork that runs independently to curate the primary agent's skill corpus.

Core Principle: The main agent creates skills during its session. The Curator reviews them when idle — classifying, consolidating, archiving — ensuring the skill index stays clean without interrupting the user's workflow.

Lifecycle Management

stateDiagram-v2
    [*] --> Active: Agent creates
    Active --> Stale: 30 days unused
    Stale --> Archived: 90 days unused
    Active --> Pinned: User pins
    Pinned --> Active: User unpins
    Archived --> Active: User recovers
    state Stale {
        [*] --> ReviewNeeded
        ReviewNeeded --> Consolidate
        ReviewNeeded --> Patch
    }
      

Runtime Binding

  • Interval: 7 days (configurable)
  • Min Idle: 2 hours after last user message
  • Stale After: 30 days unused
  • Archive After: 90 days unused
  • Guard: Only touches agent-created skills
  • Bypass: Pinned skills exempt from auto-transitions
New File: agent/curator.py (1,674 lines)
State File: ~/.hermes/skills/.curator_state
Key Functions: maybe_run_curator(), _spawn_review_agent(), auto_transition_lifecycle()

The Curator never auto-deletes — only archives. Archive is recoverable. It uses a separate auxiliary LLM client so it never touches the main session's prompt cache or token budget. This is a safety-first design.

Kanban Board NEW

Multi-Agent Task Orchestration System

The Kanban system is a full task management and multi-agent orchestration layer built on SQLite. It enables persistent, cross-session task delegation where the AI agent acts as both worker and dispatcher — spawning specialist sub-agents for decomposed work items.

sequenceDiagram
    participant U as User
    participant GW as Gateway
    participant AG as Main Agent
    participant KB as Kanban DB
    participant W1 as Worker A
    participant W2 as Worker B

    U->>GW: Create task
    GW->>AG: Dispatch
    AG->>KB: kanban_create()
    AG->>KB: Create child tasks

    Note over AG: Orchestration complete

    KB->>W1: Spawn worker (task=t1)
    W1->>KB: kanban_show() (Orient)
    W1->>KB: kanban_heartbeat()
    W1->>KB: kanban_complete(summary)

    KB->>W2: Spawn worker (depends on t1)
    W2->>KB: kanban_show() (Reads handoff)
    W2->>KB: kanban_complete(summary)

    AG->>U: Results summary
  

15-Verb CLI Surface

createshowlistupdate
deleteassignmovecomment
blockunblockstartcomplete
cancelarchivestats

Worker Lifecycle

1. Orient -> kanban_show()
2. Work -> $KANBAN_WORKSPACE
3. Heartbeat -> kanban_heartbeat()
4. Block -> kanban_block()
5. Complete -> kanban_complete()
New Files: hermes_cli/kanban.py (1,701 lines) + hermes_cli/kanban_db.py (3,326 lines)
Multi-Board: One install supports many kanbans (per-project isolation)
Orchestrator Mode: Planner profiles decompose goals into child tasks

Tool Guardrails NEW

Side-Effect-Free Safety Controller

A pure observation layer that classifies every tool call as idempotent (read-only) or mutating, tracks per-turn tool call patterns, and returns decisions that the runtime can use for warning guidance, synthetic tool results, or controlled turn halts.

Idempotent (Safe)

  • read_file
  • search_files
  • web_search
  • web_extract
  • session_search
  • browser_snapshot
  • browser_console
  • browser_get_images

Mutating (Guarded)

  • terminal
  • execute_code
  • write_file
  • patch
  • memory
  • skill_manage
  • cronjob
  • delegate_task
  • send_message
  • process
Design Philosophy: The guardrail controller is intentionally side-effect free. It tracks observations and returns decisions — the runtime owns enforcement. This separation means guardrails can be tested in complete isolation.
New File: agent/tool_guardrails.py (455 lines)
Key Classes: ToolCallTracker, GuardrailDecision, GuardrailController

Persistent Goals NEW

Cross-Turn Goal Persistence (Ralph Loop)

The /goal command introduces persistent cross-turn goals — objectives that survive across sessions and automatically re-inject into the agent's context on each new turn.

flowchart LR
    A["Goal: Deploy SaaS MVP"] --> B["Goal Store (~/.hermes/goals/)"]
    B --> C["Session 1: Research"]
    C --> D["Session 2: Build (auto-injected)"]
    D --> E["Session 3: Ship (auto-injected)"]
    E --> F["Goal: Complete (MVP deployed)"]

    style B fill:#0a1a2a,stroke:#00FFFF
    style F fill:#0a2a1a,stroke:#00FF88
  
New Files: hermes_cli/goals.py (535 lines)
Commands: /goal create, list, show, update, complete, cancel

Prompt Construction Engine

Updated v2026.4.30 Prompt Assembly Pipeline

flowchart TD
    A["Static Identity (SOUL.md)"] --> E["Assembled Prompt"]
    B["Skill Index (FTS5 + LRU Cache)"] --> E
    C["Project Context (.hermes.md)"] --> E
    D["Platform Hints (Telegram/Discord)"] --> E
    F["Session Context (Current Chat)"] --> E
    G["Memory Injection (Profile + Notes)"] --> E
    H["NEW: Kanban Guidance (Task Protocol)"] --> E
    I["NEW: Goal Injection (Cross-Turn)"] --> E
    E --> J["LLM"]

    style H fill:#0a2a1a,stroke:#00FF88,stroke-width:2px
    style I fill:#0a2a1a,stroke:#00FF88,stroke-width:2px
    style E fill:#0a1a2a,stroke:#00FFFF,stroke-width:2px
  

Kanban Guidance Block NEW

When a worker agent is spawned for a Kanban task, a dedicated KANBAN_GUIDANCE block (64 lines) is injected into the system prompt with the complete 6-step worker lifecycle protocol.

# Kanban task execution protocol
1. Orient -> kanban_show()
2. Work -> $HERMES_KANBAN_WORKSPACE
3. Heartbeat -> kanban_heartbeat()
4. Block -> kanban_block() if stuck
5. Complete -> kanban_complete(summary, metadata)
6. Spawn follow-up; don't scope-creep

Context Compression UPDATED

The "Smart-Tail" compression algorithm now handles timeout fallbacks and non-string tool content more robustly. When the summary model fails, it retries on the main model before giving up. Non-string tool results are skipped during deduplication.

Gateway & Multi-Platform Layer

Platform Registry NEW

A centralized platform registration system managing connected messaging platforms (Telegram, Discord, Slack, iMessage, Signal, Feishu, Teams) with per-platform rate limiting and auth gating.

New File: gateway/platform_registry.py (212 lines)
Rate Limiting: Signal rate limiter (369 lines)

Telegram Topics UPDATED

Multi-session DM mode via /topic command. Users can run multiple independent agent sessions within a single Telegram chat. Supports /topic create, switch, off, and auth-gated access.

Dashboard NEW

The hermes dashboard web UI can now be launched as a side-process via HERMES_DASHBOARD=1. In Docker containers, it backgrounds alongside the gateway on port 9119.

Env Var: HERMES_DASHBOARD=1
Port: 9119 (configurable)
Output: Prefixed with [dashboard]

v2026.4.30 Release Delta

What changed since the previous analysis

Previous (c3e3a9c)
Core Agent
· Single-session agentic loop
· Skill creation -> manual review
· No task orchestration
· Basic tool safety
· 40+ tools, single profile

Gateway
· Single-chat DM mode
· Basic platform routing
· No dashboard side-process
v2026.4.30 (b816fd4)
Core Agent
· Curator: Background skill maintenance
· Kanban: Multi-agent task orchestration
· Goals: Cross-turn persistence
· Guardrails: Safety observation layer
· Worker profiles + orchestrator mode

Gateway
· Platform Registry
· Telegram /topic multi-session
· Dashboard side-process
· Rate limiting per platform

Code Impact

37
Files Changed (core)
+6,897
Lines Added (core)
20
New Core Files
1,674
Curator (new)
5,027
Kanban (new)
535
Goals (new)

Agentic Loop Deep Dive

The Self-Improving Flywheel

flowchart TD
    A["User Message or Cron Trigger"] --> B["Prompt Assembly (SOUL + Skills + Context)"]
    B --> C["LLM Call (Multi-Provider Routing)"]
    C --> D{"Response Type"}
    D -->|"Tool Call"| E["Guardrails Check (Idempotent vs Mutating)"]
    E --> F["Execute Tool (40+ Tools)"]
    F --> G["Observe Result"]
    G --> B
    D -->|"Text Response"| H["Deliver to User"]
    G -.-> I{"5+ Tool Calls?"}
    I -.->|"Yes"| J["Skill Abstraction (skill_manage create)"]
    J -.-> K["Curator Review (Background, Idle)"]
    K -.-> L["Skill Index (FTS5 Database)"]

    style E fill:#1a0a2a,stroke:#FF00FF,stroke-width:2px
    style J fill:#0a2a1a,stroke:#00FF88,stroke-width:2px
    style K fill:#0a2a1a,stroke:#00FF88,stroke-width:3px
  

Deployment Architecture

flowchart TB
    TUI["TUI (hermes chat)"] --> LOOP
    GW["Gateway (REST API)"] --> LOOP
    CRON["Cron (Scheduled)"] --> LOOP
    KANBAN_CLI["Kanban CLI"] --> SQLITE
    GOAL_CLI["Goals CLI"] --> SQLITE
    LOOP["Agentic Loop (AIAgent.run())"] --> CURATOR_DAEMON
    LOOP --> LLM_M
    CURATOR_DAEMON["Curator (Idle-Triggered)"] --> AUX
    LOOP --> LOCAL
    LOOP --> DOCKER
    LOOP --> SSH
    LOOP --> MODAL
    LOOP --> SQLITE
    SQLITE["SQLite (kanban.db, fts5_skills.db, goals/)"]
    LLM_M["LLM (OpenAI/Anthropic/Gemini/OpenRouter)"]
    AUX["Auxiliary LLM (Curator/Summarizer)"]
    LOCAL["Local Shell"]
    DOCKER["Docker (Hardened)"]
    SSH["SSH Remote"]
    MODAL["Modal (Serverless GPU)"]

    style CURATOR_DAEMON fill:#0a2a1a,stroke:#00FF88,stroke-width:2px
    style SQLITE fill:#2a2a0a,stroke:#FFD700
    style LOOP fill:#0a1a2a,stroke:#00FFFF,stroke-width:2px
  

Four-Tier Memory Architecture

The agent maintains four distinct memory tiers, each with a different lifetime and retrieval mechanism:

1. Working Memory

Current turn context window. LLM's native context. Compressed via Smart-Tail when exceeding budget. Lifetime: single inference call.

2. Episodic Memory

FTS5 full-text search across all past session transcripts. Retrieved via session_search(). Lifetime: persistent across all sessions.

3. Semantic Memory

Compact facts in ~/.hermes/memory/ — user profile, environment facts, conventions. Injected into every turn. Lifetime: permanent.

4. Procedural Memory

Skills — reusable workflows as SKILL.md files. Created by agent, reviewed by Curator. FTS5-indexed for lazy loading. Lifetime: curated.

Architectural Warning Signs

Growing Complexity Surface