Hermes 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
🎯 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
| Decision | Choice Made | Alternatives | Why 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/
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.
tools/
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.
hermes_cli/
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.
Communication
gateway/
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.
acp_adapter/
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.
Intelligence
plugins/
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.
environments/
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.
Automation
Navigation Guide
| Level | What You'll Find | When to Use |
|---|---|---|
| 0 — Project Hub (this page) | Project philosophy, design decisions, module map, data flows | Getting started, understanding the big picture |
| 1 — Module Overview | Design rationale, algorithm spotlight, narrated walkthrough, failure analysis | Understanding a module's purpose and design choices |
| 2 — Sub-Module Deep Dive | Annotated code walkthroughs, design rationale, edge cases, implementation details | Implementing, debugging, or extending code |
| Focus Pages | Algorithm traces, alternatives comparison, complexity analysis, failure recovery | Deep 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.