Hermes Agent by Nous Research: Architecture, Skills, and Security Explained

Nous Research’s Hermes Agent has crossed 213,000 GitHub stars with a pitch that stands out even in a crowded field of coding agents: it doesn’t just execute tasks, it learns from them. The README calls it “the only agent with a built-in learning loop.” That’s a strong claim. Here’s what the repo actually shows.

The core loop: skills as procedural memory

The mechanism behind the learning claim is a skill system. After a task that involves five or more tool calls, the agent writes a reusable skill document describing how it solved the problem. The next time a similar task comes up, it pulls that skill instead of re-deriving the approach from scratch.

What makes this more than a static cache is the self-improvement step. Skills get patched during use when the agent finds them outdated, incomplete, or wrong. A separate component called the Autonomous Curator runs on a schedule to review the accumulated skill library: it scores skills, merges overlapping ones, archives stale entries, and protects a set of pinned skills from being touched. As of v0.12.0 this runs automatically; recent releases added archive, prune, and list-archived commands plus the option to trigger it manually and synchronously.

This is a genuinely different design from a coding agent that starts fresh every session. Whether it constitutes “learning” in a strict sense is a fair question, since the skill documents are closer to accumulated procedural notes than to weight updates. But as a mechanism for compounding task-specific knowledge across sessions, it’s a real architectural choice, not a marketing gloss.

Memory and cross-session recall

Separately from skills, Hermes maintains conversational memory using FTS5 (SQLite’s full-text search) across all past sessions, with LLM summarization layered on top for cross-session recall. It also integrates Honcho, an open-source dialectic user-modeling library, to build a persistent model of the user across sessions rather than just replaying raw transcript search.

One detail worth flagging for anyone running this against untrusted input: recalled memory is treated as a potential attack surface. Recent releases narrowed what gets pulled into context by default and added scanning of recalled memory at load time, part of a broader defense described below.

Provider-agnostic by design

The agent core, AIAgent in run_agent.py, sits behind an abstracted transport layer. Concrete transport implementations (AnthropicTransport, ChatCompletionsTransport, ResponsesApiTransport, BedrockTransport) each handle message format conversion, tool schema conversion, and response normalization for their respective API shapes. Switching models is a single command, hermes model, with no code changes required. The repo documents 300+ models reachable this way when routed through Nous Portal, alongside direct support for OpenRouter, OpenAI, and self-hosted endpoints.

This matters architecturally because it means the learning loop, the skill system, and the memory layer are all provider-independent. The agent’s “intelligence” (in the self-improvement sense) lives in the orchestration layer, not tied to a specific model backend.

Where it runs

Hermes ships with six execution backends: local, Docker, SSH, Singularity, Modal, and Daytona. The last two are notable because they offer serverless persistence, meaning the agent’s environment hibernates when idle and wakes on demand, so a long-running agent doesn’t need to keep a VM warm around the clock between tasks. The project’s own framing is that this is meant to run on infrastructure as small as a $5 VPS, not just a developer’s laptop, and that it stays reachable over messaging platforms (Telegram, Discord, Slack, WhatsApp, Signal) even while the actual work executes elsewhere.

Delegation is handled through subagents for parallel workstreams, and a scripting path lets Python call tools directly over RPC, which the maintainers describe as collapsing multi-step pipelines into “zero-context-cost turns,” since the orchestration doesn’t have to round-trip through the model’s context window for every intermediate step.

Security posture: prompt injection is a named threat model

This is one of the more concrete engineering signals in the repo. Recent releases added what the changelog calls “promptware defense,” explicitly citing prompt-injection research on what’s termed the “Brainworm / Promptware Kill Chain.” The implementation adds around 15 new detection patterns in a single threat-pattern module, scans recalled memory at load time, and adds delimiter markers to tool results specifically so that a malicious file or remote service can’t impersonate the agent’s own system content.

Alongside this, Hermes added Bitwarden Secrets Manager integration so credentials for different providers don’t have to sit in plaintext in a local .env file. Instead, a single bootstrap token retrieves per-provider secrets on demand.

Taken together, these are the kinds of defenses you’d expect from a team that has actually had to deal with agents ingesting untrusted tool output and remote content in production, not defenses bolted on for a security audit checklist.

What “self-improving” doesn’t mean here

To be precise about the scope of the claim: this is not reinforcement learning happening inside a running agent session. The RL and fine-tuning side of the Nous Research stack lives in separate projects. hermes-agent-self-evolution uses DSPy and GEPA (a prompt-optimization method presented as an ICLR 2026 Oral) to evolve skills and prompts offline, then opens a pull request against the main repo with the improved variant. Atropos is Nous’s separate RL environments framework for collecting and evaluating LLM trajectories, and the main repo includes trajectory compression tooling aimed at generating training data for future tool-calling models.

So the “grows with you” framing in the README is accurate in the sense that skills and memory compound during use. It is not accurate in the sense of the model’s own weights updating in real time. That distinction matters if you’re evaluating this for a production use case versus taking the marketing copy at face value.

The takeaway

The interesting engineering story in Hermes Agent isn’t any single feature, it’s the combination: a procedural memory system that self-curates, a provider-agnostic core that keeps the orchestration layer decoupled from any one model vendor, and a security model that treats the agent’s own context window as something that needs defending from the tools and memories it relies on. Most “self-improving agent” claims in this space are thin. This one has a specific, inspectable mechanism behind it, even if the phrase oversells what’s happening at the model level.


Sources: