Hermes Agent

The Self-Improving AI Agent

The self-improving AI agent — creates skills from experience, improves them during use, and runs anywhere. Features a closed learning loop, multi-platform messaging across 18+ platforms, 40+ tools, 6 terminal backends, cron scheduling, MCP integration, and support for 100+ LLM providers.

v0.9.0 · 677f1227 · Python · by Nous Research

Self-Improving Multi-Platform 100+ LLM Providers MIT License

870
Python Files
400K
Lines of Code
8
Modules
40+
Tools

🎯 Project Philosophy

Hermes Agent exists to close the gap between static tool-using agents and truly adaptive AI systems. Most agent frameworks treat tools as fixed capabilities — the developer defines them at build time, and the agent can only use what it was given. Hermes inverts this model with a closed learning loop: when the agent encounters a novel task, it can create a new skill from the experience, persist it to its skill library, and refine that skill on subsequent invocations. Over time, the agent literally gets better at its job without human intervention.

The architecture is guided by several core design principles. Composition over inheritance — modules are composed through registries, adapters, and plugin interfaces rather than deep class hierarchies. This makes it possible to swap memory backends, add platform adapters, or register new tools without modifying the core agent loop. Provider agnosticism — rather than coupling to a single LLM vendor, Hermes wraps 100+ providers behind a unified SDK interface so users can switch models with a single config change. Subprocess isolation — the gateway runs in a separate process from the agent, providing crash isolation and the ability to scale each component independently. Deployment flexibility — six terminal backends (local, Docker, SSH, Modal, Daytona, Singularity) mean the same agent definition runs on a laptop, a container, a remote server, or a serverless GPU — without code changes.

In the broader ecosystem, Hermes sits at the intersection of conversational AI and autonomous agents. It is not just a chatbot framework or a task runner — it is a platform for building agents that learn, communicate across any messaging platform, execute arbitrary tools in sandboxed environments, and schedule their own work. The priority ordering is correctness first, extensibility second, performance third.

🏗️ Design Decisions

DecisionChoice MadeAlternativesWhy This Approach
Learning loop Skill creation from experience with iterative refinement Static tool definitions; prompt-only memory; fine-tuning Enables self-improvement without retraining — skills are code artifacts the agent can inspect, test, and refine at runtime
Provider abstraction Unified SDK interface wrapping 100+ providers Vendor lock-in to OpenAI/Anthropic; per-provider adapters Any model works with a config change — users are never locked in, and new providers are added without touching agent logic
Gateway isolation Subprocess boundary between gateway and agent In-process event loop; microservice deployment Crash isolation (a gateway bug does not take down the agent), independent scaling, and clean separation of messaging concerns from reasoning
Terminal backends 6 pluggable environments (local, Docker, SSH, Modal, Daytona, Singularity) Local-only execution; single container runtime Run anywhere — same agent code works on a laptop for development, in Docker for CI, on Modal for serverless GPU, or via SSH for remote machines
Memory plugins Pluggable backend system with 8 implementations Single embedded store; external-only DB User choice — from lightweight holographic memory to production-grade Honcho/Supermemory, each with different trade-offs on latency, persistence, and capacity
Tool registry Dynamic registration via decorator pattern Hardcoded tool list; config-file discovery Extensible without core changes — new tools register themselves on import, and the skill system can add tools at runtime
Platform adapters Adapter pattern with common message protocol Per-platform bots; webhook-only integration 18+ platforms share the same session and delivery logic — adding a new platform means writing one adapter file, not a new bot

System Architecture

flowchart TD
  subgraph CoreEngine["Core Engine"]
    AGENT["agent/\nOrchestration + Memory + Skills"]
    TOOLS["tools/\n40+ Tool Implementations"]
    CLI["hermes_cli/\nTUI + Config + Profiles"]
  end

  subgraph Communication["Communication"]
    GATEWAY["gateway/\n18+ Platform Adapters"]
    ACP["acp_adapter/\nAgent Communication Protocol"]
  end

  subgraph Intelligence["Intelligence"]
    PLUGINS["plugins/\n8 Memory Backends"]
    ENVS["environments/\nRL Training + Benchmarks"]
  end

  subgraph Automation["Automation"]
    CRON["cron/\nScheduled Tasks"]
  end

  CLI -->|"user input to prompt builder"| AGENT
  AGENT -->|"dispatches via registry"| TOOLS
  AGENT -->|"persists context"| PLUGINS
  GATEWAY -->|"routes messages to sessions"| AGENT
  ACP -->|"inter-agent protocol"| AGENT
  CRON -->|"triggers scheduled runs"| AGENT
  CRON -->|"delivers results"| GATEWAY
  ENVS -->|"evaluation harness"| AGENT
  TOOLS -->|"environment execution"| ENVS
  GATEWAY -->|"exposes endpoints"| ACP

Core Engine

agent/

Core agent orchestration and reasoning loop

The brain of Hermes — manages context windows, builds prompts, routes to the right model, orchestrates tool calls, handles skill creation and improvement, and tracks pricing. Everything flows through the agent loop: receive input, build context, call LLM, execute tools, return results.

28 files~15K LOCContext + Memory + Skills

tools/

40+ tool implementations across 6 execution environments

The largest module — implements terminal commands, browser automation, file operations, vision, TTS, code execution, MCP integration, agent delegation, and skill management. Each tool registers itself via the dynamic registry. Execution backends span local, Docker, SSH, Modal, Daytona, and Singularity.

70 files~37K LOC6 Backends

hermes_cli/

CLI interface with TUI, config management, and skin engine

The user-facing shell — provides a rich terminal UI, interactive setup wizards, model switching, authentication, profile management, and a skin engine for visual customization. Translates user commands into agent loop invocations and streams responses back to the terminal.

50 files~25K LOCTUI + Config + Auth

Communication

gateway/

Multi-platform messaging gateway with 18+ adapters

Runs as a separate subprocess from the agent for crash isolation. Manages platform adapters (Telegram, Discord, Slack, WhatsApp, Signal, and more), session lifecycle, streaming delivery, message routing, and device pairing. Each adapter translates platform-specific events into a common message protocol.

40 files~15K LOC18+ Platforms

acp_adapter/

Agent Communication Protocol for inter-agent interop

Implements the ACP specification so Hermes agents can communicate with other ACP-compatible agents. Provides request/response routing, capability advertisement, and protocol negotiation. Compact module with a focused scope.

9 files~2K LOCInterop

Intelligence

plugins/

Plugin system with 8 memory backends

Pluggable memory and extension system. Includes backends for holographic memory, Honcho, Supermemory, and five others — each with different trade-offs on latency, persistence, and capacity. The plugin interface allows third-party extensions to hook into the agent lifecycle.

17 files~5K LOC8 Backends

environments/

RL training environments and benchmarks

Provides reinforcement learning training environments, benchmark suites, and tool call parsers for evaluating agent performance. Used both for development-time testing and for the self-improvement loop — agents can benchmark their own skills and identify areas for refinement.

20 files~8K LOCRL + Benchmarks

Automation

cron/

Scheduled task system with platform delivery

Lightweight cron-style scheduler that triggers agent runs on a schedule and delivers results to any configured platform via the gateway. Supports cron expressions, one-shot timers, and recurring tasks with configurable retry logic.

3 files~1K LOCScheduling

Navigation Guide

LevelWhat You'll FindWhen to Use
0 — Project Hub (this page)Project philosophy, design decisions, module map, data flowsGetting started, understanding the big picture
1 — Module OverviewDesign rationale, algorithm spotlight, narrated walkthrough, failure analysisUnderstanding a module's purpose and design choices
2 — Sub-Module Deep DiveAnnotated code walkthroughs, design rationale, edge cases, implementation detailsImplementing, debugging, or extending code
Focus PagesAlgorithm traces, alternatives comparison, complexity analysis, failure recoveryDeep understanding of a specific mechanism

🔗 Key Data Flows

How data moves through the system's major paths. Annotations explain why each hand-off occurs.

CLI Chat Flow

The primary interactive path — a user types a message in the terminal and receives a tool-augmented response.

sequenceDiagram
    participant User as User
    participant CLI as hermes_cli
    participant PB as PromptBuilder
    participant LLM as LLM Provider
    participant TR as ToolRegistry
    participant Tool as Tool
    participant Display as Display

    User->>CLI: input message
    Note over User,CLI: CLI captures input and manages session state
    CLI->>PB: build prompt with context + memory
    Note over CLI,PB: Context window management ensures token budget
    PB->>LLM: send prompt to selected model
    Note over PB,LLM: Provider abstraction routes to any of 100+ backends
    LLM->>TR: tool call request
    Note over LLM,TR: Registry resolves tool by name, validates args
    TR->>Tool: execute tool
    Note over TR,Tool: Subprocess isolation protects agent from tool crashes
    Tool-->>TR: tool result
    TR-->>LLM: inject result into context
    Note over TR,LLM: Multi-turn loop continues until LLM produces final answer
    LLM-->>CLI: final response
    CLI-->>Display: stream to TUI
    Note over CLI,Display: Skin engine formats output per user preferences

Gateway Message Flow

How messages from external platforms (Telegram, Discord, etc.) reach the agent and return.

sequenceDiagram
    participant Platform as Platform (Telegram/Discord/...)
    participant Adapter as Platform Adapter
    participant Session as SessionStore
    participant Agent as Agent Loop
    participant Stream as StreamConsumer
    participant Delivery as Delivery Router

    Platform->>Adapter: incoming message
    Note over Platform,Adapter: Adapter normalizes platform-specific format
    Adapter->>Session: resolve or create session
    Note over Adapter,Session: Session tracks conversation history per user per platform
    Session->>Agent: dispatch to agent loop
    Note over Session,Agent: Subprocess boundary - gateway and agent are isolated
    Agent->>Agent: reason + tool calls
    Agent-->>Stream: streaming tokens
    Note over Agent,Stream: Backpressure prevents overwhelming slow platforms
    Stream-->>Delivery: formatted chunks
    Delivery-->>Platform: deliver response
    Note over Delivery,Platform: Delivery router handles platform rate limits and retries

How agent/ & tools/ Connect

The boundary between the agent core and the tool system is the ToolRegistry — a dynamic dispatch table that decouples tool definitions from agent logic.

sequenceDiagram
    participant AgentLoop as Agent Loop
    participant Registry as ToolRegistry
    participant ToolDef as Tool Definition
    participant Backend as Execution Backend

    AgentLoop->>Registry: lookup tool by name
    Note over AgentLoop,Registry: Registry was populated at import time via decorators
    Registry->>ToolDef: resolve definition + schema
    Note over Registry,ToolDef: Schema validation catches bad args before execution
    ToolDef->>Backend: execute in selected environment
    Note over ToolDef,Backend: Backend chosen by config: local, Docker, SSH, Modal, etc.
    Backend-->>ToolDef: raw result
    ToolDef-->>Registry: formatted result
    Registry-->>AgentLoop: inject into context window
    Note over Registry,AgentLoop: Agent decides: call another tool or produce final answer
Key insight: The agent loop owns reasoning (everything above the registry boundary). The tools module owns execution (everything below). The registry acts as the contract — tools register themselves with a name, description, and JSON schema, and the agent dispatches by name without knowing implementation details. This means skills created at runtime register into the same registry as built-in tools, making self-improvement seamless.

Directory Map

Project source tree
hermes-agent/
├── agent/                     ← Core orchestration, context, memory, skills, pricing
├── tools/                     ← 40+ tool implementations, 6 execution backends
├── hermes_cli/                ← TUI interface, config, setup wizards, profiles, skins
├── gateway/                   ← Multi-platform messaging, 18+ adapters, sessions
├── acp_adapter/               ← Agent Communication Protocol adapter
├── plugins/                   ← Plugin system, 8 memory backends
├── environments/              ← RL training environments, benchmarks, parsers
├── cron/                      ← Scheduled task system
├── config/                    ← Default configuration files
├── tests/                     ← Test suites
├── docs/                      ← Documentation
├── pyproject.toml             ← Project metadata and dependencies
└── README.md                  ← Project overview

Build & Tech Stack

Language

Python 3.10+ — 870 files, ~400K lines. Type hints throughout, async/await for I/O-bound operations.

Build System

pyproject.toml with pip/Poetry. No compiled extensions — pure Python for maximum portability.

Key Dependencies

LiteLLM (100+ LLM providers), Rich (TUI), Pydantic (schemas), Docker SDK, Paramiko (SSH), websockets.

Execution Backends

Local subprocess, Docker containers, SSH tunnels, Modal serverless, Daytona workspaces, Singularity HPC containers.

Messaging Platforms

Telegram, Discord, Slack, WhatsApp, Signal, Matrix, IRC, and 10+ more via the adapter pattern in gateway/.

Testing

pytest with fixtures for each module. Environment tests use mocked backends. Gateway tests use simulated platform events.