CtrlK
| Hermes Agent | |
|---|---|
| Developer | Nous Research |
| Repository | NousResearch/hermes-agent |
| Initial repository creation | July 22, 2025 |
| First tagged public release | March 12, 2026 (v0.2.0) |
| License | MIT |
| Primary implementation | Python, with TypeScript and shell components |
| Minimum Python version | 3.11 |
| Supported host environments | Linux, macOS, WSL2, Android via Termux |
| Interfaces | CLI, TUI, messaging gateway, ACP integration, MCP server |
| Website | https://hermes-agent.nousresearch.com/ |
Hermes Agent is an open-source AI agent platform developed by Nous Research. Official project materials describe it as a long-running agent runtime that combines a terminal interface, tool use, persistent memory, scheduled jobs, browser automation, and messaging integrations in one system. The project is MIT licensed, requires Python 3.11 or newer, and is distributed primarily through a one-line installer and a public GitHub repository.[^1][^2][^5][^6][^18]
Although it is built by the same lab that publishes the Hermes model family, Hermes Agent is not itself a standalone large language model. The documentation presents it as an orchestration layer that can run on multiple providers and endpoints, including Nous Portal, OpenRouter, OpenAI, Anthropic, AWS Bedrock, Hugging Face, DeepSeek Direct, xAI, and GitHub Copilot. It can also expose its own messaging capabilities to outside clients through Model Context Protocol support.[^2][^6][^15][^17]
GitHub metadata shows that the NousResearch/hermes-agent repository was created on July 22, 2025.[^3] The public release history on GitHub begins with v2026.3.12, labeled "Hermes Agent v0.2.0", published on March 12, 2026. By April 16, 2026, the release feed had reached v2026.4.16, labeled "Hermes Agent v0.10.0".[^4]
The rapid release cadence in March and April 2026 coincided with expansion of the project's documentation, installer, provider list, terminal backends, messaging surfaces, and memory-related features.[^2][^4][^5][^18]
The official architecture guide describes Hermes Agent as a platform with multiple entry points feeding a common AIAgent core. The documented entry points include a CLI, a messaging gateway, ACP integration for editors, a batch runner, an API server, and a Python library interface. Session state is stored in SQLite with FTS5 full-text search, while tool discovery is centralized in a registry-based tool system.[^17]
| Subsystem | Role in the documented architecture |
|---|---|
AIAgent core | Handles prompt construction, provider resolution, tool execution, retries, compression, and persistence.[^17] |
| CLI and TUI | Provide an interactive terminal-first interface with multiline editing, slash commands, resume support, and streaming tool output.[^7][^17] |
| Messaging gateway | Routes messages from connected platforms through per-chat sessions, runs the cron scheduler, and delivers responses back through adapters.[^8][^17] |
| Session storage | Uses SQLite and FTS5 for session history, lineage tracking, and recall.[^9][^17] |
| Tool system | Organizes built-in capabilities into tool categories and toolsets, with separate execution backends for terminal, browser, web, memory, and orchestration tasks.[^11][^17] |
| Integrations layer | Connects to external systems through ACP, MCP, provider APIs, and platform adapters.[^15][^17] |
Hermes Agent's CLI documentation emphasizes that the command-line interface is a full terminal UI rather than a browser interface. It supports interactive chat, model selection, toolset selection, resumable sessions, worktree-based parallel runs, voice input shortcuts, and a separate --tui mode for a more graphical terminal experience.[^7]
Official documentation groups Hermes Agent's capabilities around memory, tooling, orchestration, messaging, and interoperability.[^2][^11]
| Capability area | Details documented by the project |
|---|---|
| Persistent memory | Built-in memory is split between MEMORY.md for environment and workflow facts, and USER.md for user preferences. The default character limits are 2,200 and 1,375 respectively, and both are injected into the system prompt as a frozen snapshot at session start.[^9] |
| Session recall | Past CLI and messaging sessions are stored in ~/.hermes/state.db and searchable through session_search, using FTS5 plus summarization for cross-session recall.[^9][^17] |
| External memory providers | The memory provider guide lists eight optional provider plugins: Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, and Supermemory. These run alongside the built-in memory rather than replacing it.[^9][^10] |
| Skills system | The docs and README describe skills as reusable instruction modules compatible with the agentskills.io standard. Skills can be loaded on demand or attached to scheduled jobs.[^2][^18] |
| Tool execution | Built-in tool categories include web search and extraction, terminal and file operations, browser automation, vision and media, memory, scheduling, and outbound messaging.[^11] |
| Terminal backends | The terminal tool supports local, Docker, SSH, Singularity, Modal, and Daytona backends, with container hardening for isolated environments.[^11] |
| Browser automation | The browser guide documents cloud backends such as Browserbase, Browser Use, and Firecrawl, plus local Chrome/CDP and local Chromium workflows. Pages are represented as accessibility trees for LLM-friendly interaction.[^12] |
| Subagent delegation | The delegate_task tool spawns isolated child agents with their own sessions and terminal contexts. The delegation guide says batch mode runs up to three subagents in parallel, and only each child's final summary is returned to the parent context.[^13] |
| Programmatic tool calling | The execute_code tool runs Python scripts that call Hermes tools through a Unix domain socket RPC layer. The docs say this is available on Linux and macOS, and is intended for multi-step workflows that would otherwise require many separate tool calls.[^14] |
| Scheduled tasks | Cron jobs can be one-shot or recurring, can attach skills, and can deliver results back to chats, files, or platform targets.[^8][^15] |
A defining feature of Hermes Agent is its messaging gateway. According to the messaging guide, the gateway is a single background process that connects to configured platforms, manages sessions, runs cron jobs, and delivers voice messages when voice features are enabled.[^8] The same guide lists Telegram, Discord, Slack, WhatsApp, Signal, SMS, email, Home Assistant, Mattermost, Matrix, DingTalk, Feishu/Lark, WeCom, Weixin, BlueBubbles, and QQ among supported surfaces as of April 2026.[^8][^17]
The messaging system supports slash commands for session reset, model changes, approvals, rollback, background tasks, and usage inspection. Background prompts run in isolated sessions and report results back to the originating chat when they finish.[^8] The cron system extends this automation model by allowing tasks to be scheduled in natural language or cron syntax, with optional skill loading before execution.[^15]
Hermes Agent is designed to work with external model providers and external tool servers.
The quickstart guide documents provider setup flows for Nous Portal, OpenAI Codex, Anthropic, OpenRouter, AWS Bedrock, DeepSeek Direct, GitHub Copilot, Google Gemini, xAI, Hugging Face, and several regional or specialized providers.[^6] The project pyproject.toml also lists optional extras for messaging, voice, MCP, ACP, Modal, Daytona, Bedrock, and other integrations.[^5]
The MCP guide describes two related roles. First, Hermes can act as an MCP client, connecting to local stdio servers and remote HTTP servers, discovering their tools automatically, and exposing them to the agent with namespaced tool identifiers. Second, Hermes can run as an MCP server itself, allowing outside clients to access Hermes-managed messaging channels and approval workflows.[^15]
The official security guide describes Hermes Agent as using a seven-layer defense-in-depth model. Those layers cover user authorization, dangerous command approval, container isolation, MCP credential filtering, context-file scanning for prompt injection, cross-session isolation, and input sanitization for terminal backends.[^16]
The command approval system supports three documented modes: manual, smart, and off. The same page also documents a session-level "YOLO" mode that bypasses dangerous-command prompts entirely. The project explicitly warns that this mode should be used only in trusted environments.[^16]
On messaging platforms, the default security posture is deny-by-default for unknown users unless the deployment is configured with allowlists or DM pairing. For containerized execution, the tools guide documents hardening controls such as dropped Linux capabilities, namespace isolation, PID limits, and read-only root filesystems for Docker-based runs.[^11][^16]
Official project materials consistently position Hermes Agent as a self-hostable, long-running agent platform rather than as a chatbot wrapper around a single API.[^1][^2][^18] That positioning is visible in several design choices:
| Design choice | What it suggests |
|---|---|
| Multiple entry points, one core agent | The project is intended to run in terminals, editors, background services, and external integrations, not just in a chat window.[^17] |
| Memory plus session search | The project is optimized for continuity across sessions rather than stateless prompt-response interaction.[^9] |
| Built-in scheduler and gateway | Hermes is meant to continue operating after a single conversation ends.[^8][^15] |
| Multiple execution backends | The agent can be run locally, in containers, on remote servers, or on cloud execution backends depending on the deployment model.[^11] |
| Provider-agnostic model setup | The system is designed to switch among many external model providers instead of depending on one fixed model family.[^6] |
The documented installation path is curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash, followed by provider and tool configuration through hermes model, hermes tools, or hermes setup.[^6][^18] Official quickstart material says the primary supported host environments are Linux, macOS, WSL2, and Android via Termux, while native Windows users are directed to WSL2.[^6][^18]
The source repository is public on GitHub under the MIT license.[^3][^5]