Hermes Agent Features and Capability Limits

Direct answer

Hermes Agent's capabilities fall into five groups: a tool-using agent loop, a model and provider layer you choose, an extension layer (tools, skills, MCP servers, integrations), a persistence layer (memory, sessions, checkpoints), and interfaces (terminal, desktop, browser dashboard, messaging). Every capability below is listed with what it requires before it works and what it exposes when it does.

Checked against Hermes Agent v0.20.5 on August 25, 2026. Re-check when a release adds, renames, or removes a documented feature, or changes a platform limitation.

Hermes Agent capabilities at a glance

Read this table as a shortlist, not a feature brag. The prerequisite column is the part that decides whether a capability is available to you today.

Capability inventory with prerequisites and riskPrerequisite = what must already be true for the capability to work. Exposure = what the capability can reach or reveal when enabled. Owner = the page that carries the setup detail.

Capability	What it does	Prerequisite	Exposure
Agent loop with tools	Plans a task, calls tools, and iterates until the goal is met	A configured provider and a model with at least 64,000 tokens of context	Whatever the enabled toolsets can reach
Terminal and file tools	Runs commands, reads files, applies patches	A terminal backend; `local` by default	The filesystem and shell of whatever machine the backend points at
Web search and extraction	Searches and pulls page content into the task	A search backend; several require their own API key	Outbound network requests, with private addresses blocked by default
Browser automation	Drives a real browser to complete web tasks	A browser backend, local or hosted; roughly 2 GB RAM in a container	Any site the browser can reach, and any session it inherits
Memory and user profile	Carries bounded facts between sessions	Enabled by default; 2,200 and 1,375 character limits	Whatever the agent chose to write down about you and your environment
Skills	Loads procedure documents on demand and can author new ones	Skills directory; installs from the hub run a security scan first	Third-party instructions entering the agent's context
MCP servers	Connects external tool servers over stdio or HTTP	The server binary or endpoint, plus its credentials	Whatever that server is authorised to do
Scheduled tasks	Runs work on a cron schedule or natural-language timing	A running agent and a separate approval policy for headless runs	Unattended execution, so approvals cannot be answered interactively
Subagent delegation	Spawns child agents with isolated context and restricted toolsets	None beyond a working agent	Parallel tool use under the same credentials
Messaging gateway	Bridges chat platforms to the agent	Platform tokens and an explicit user allowlist	Inbound instructions from a chat platform

Source: Nous Research features overview, Tools and Toolsets, Memory, Skills, MCP, Security, and Docker documentation, checked 25 August 2026 against v0.20.5.

Core agent loop and planning

The loop is the product. Hermes Agent takes a goal, decides on a sequence of tool calls, executes them, and reads the results back into its own context before deciding what to do next. Three controls shape it:

Toolsets decide which tools the model can even see in a session.
Approval mode decides whether a command classified as dangerous runs, prompts, or is refused.
Budgets — iteration count and wall-clock limits — decide when a run stops on its own.

Two features exist because long loops fill context: automatic compression, which summarises older turns once the session crosses a configured share of the context window, and checkpoints, which snapshot the working directory before file changes so a bad run can be rolled back.

Model and provider capability summary

Hermes Agent does not ship a model. Capability therefore depends partly on the model you connect: tool calling, vision, and usable context length are properties of the provider path, not of Hermes Agent.

What is fixed regardless of provider:

A minimum of 64,000 tokens of context is required for agent use.
Auxiliary work — vision analysis, compression, title generation — can be routed to a cheaper secondary model.
Fallback providers can be listed so a failing primary model does not end the run.

Which provider path to pick, and how to connect it, is owned by the models and providers guide, linked at the end of this page.

Tool and integration capability summary

The documented built-in tools group into web (web_search, web_extract), terminal and files (terminal, process, read_file, patch), browser (browser_navigate, browser_snapshot, browser_vision), media (vision_analyze, image_generate, text_to_speech), orchestration (todo, clarify, execute_code, delegate_task), recall (memory, session_search), and automation (cronjob).

Those tools are bundled into toolsets — web, terminal, file, browser, memory, cronjob, delegation, safe and others — and toolsets are what you enable or disable per interface. The taxonomy, the connection patterns, and the permission scoping belong to tools and integrations.

Memory and skills

These are the two capabilities people most often expect to be magic, so the limits matter.

Memory is deliberately bounded: MEMORY.md for environment facts and USER.md for your profile, capped at 2,200 and 1,375 characters respectively. It is loaded as a snapshot at session start, so a memory written mid-run does not appear until the next session. It can be gated behind approval with memory.write_approval: true.
Skills are procedure documents with a SKILL.md front matter block, loaded on demand rather than held in context. The agent can author them, and that authoring can be gated with skills.write_approval: true and scanned with skills.guard_agent_created.

Neither is a database. Treat memory as a short curated note file and skills as reusable playbooks.

Browser and computer use

Browser automation runs through a backend — a local Chromium-family browser or a hosted service — and is the capability most likely to surprise you operationally. It inherits whatever the browser can reach, it is memory-hungry in containers, and a page it visits is untrusted input.

Because of that, browser work should be enabled deliberately rather than left on by default, and the controls that constrain it are covered under security controls.

Automation and messaging

Two capabilities let the agent act without you watching:

Scheduled tasks via the cronjob tool and the hermes cron command surface.
Messaging gateway, which connects chat platforms so a message becomes a task.

Both change the safety question rather than the capability question. Unattended runs have their own approval setting — approvals.cron_mode — because nobody is present to answer a prompt, and the gateway denies every user by default until an allowlist or pairing approval exists.

Desktop, CLI, and dashboard interfaces

All three drive the same runtime and share the same configuration directory.

CLI and TUI are what the installer gives you.
Hermes Desktop is a native application that launches and manages a backend, including a remote one.
The browser dashboard is served by Hermes Agent for managing a running deployment. It is not the same thing as a third-party web front end such as Open WebUI, which instead connects to Hermes Agent's OpenAI-compatible API server.

Applied Hermes publishes the browser dashboard guide after launch; the distinction is stated here so the names do not blur.

Deployment and security constraints

Capability is constrained by where the agent runs:

The terminal backend can be local, ssh, docker, singularity, modal, daytona, or vercel_sandbox. Container and cloud-sandbox backends are treated as the security boundary, and the dangerous-command check is skipped inside them.
Container resource limits (container_cpu, container_memory, container_disk) cap what a run can consume.
Requests to private network ranges and cloud metadata endpoints are blocked unless explicitly allowed.

Feature limits and version differences

Three limits are documented and worth planning around:

Native Windows. One feature is documented as unavailable natively — the dashboard's embedded terminal pane in /chat, which needs a POSIX PTY. Everything else, including the CLI, TUI, gateways, browser tool, dashboard, and cron, is documented as working. WSL2 is the documented route if you need that pane.
Docker installs. hermes update is not supported in a container; updating means running a new image.
Unsupported install methods. macOS on Intel, AUR, PyPI (pip install, uv tool install), and Homebrew are listed as unsupported.

Because features move between releases, treat any capability list — including this one — as dated. This page was checked against v0.20.5 on 25 August 2026.

Choose a capability by task

Extending what the agent can reach: tools and integrations.
Constraining what a capability is allowed to do: security controls.
Turning a capability into working output: get a first result.