Hermes Agent: Is It the Ideal RAG App? Architecture Lessons for Engineers

TL;DR

• Hermes Agent is an open-source, self-hosted agent harness from Nous Research. As of July 2026, it ships as a Python runtime with CLI, messaging gateway, cron, ACP/IDE integration, 70+ tools, and a background learning loop (on by default; optionally gated with memory.write_approval / skills.write_approval, both default false) that can turn successful work into reusable skills.
• It is not the ideal RAG app in the classic sense. Hermes is closer to a long-running agent harness with layered recall: bounded curated memory, FTS5 session search, optional hybrid document search (qmd), wiki-style knowledge bases, and pluggable external memory providers. That is broader than “embed documents, retrieve top-k, answer.”
• What makes it strong: sessions treated as infrastructure (SQLite + FTS5 + lineage), prompt tiers optimized for caching, tool registration separated from tool exposure, progressive skill loading, consent-aware memory writes, and a gateway that turns one agent into a multi-channel assistant.
• What to borrow for your own apps: tiered system prompts, frozen vs on-demand context, hybrid retrieval only when needed, auditable procedural memory, explicit write-approval gates, and compression that creates session lineage instead of rewriting history.
• Versus OpenClaw, n8n, Agno/AgentOS, and CrewAI: Hermes is closest to OpenClaw as a personal agent harness, but centers the Python agent runtime and auditable skill learning; the others optimize for gateway control planes, workflow automation, productized agent APIs, or multi-agent crews respectively.
• Token posture: Hermes pays a small fixed per-turn memory/skills-index cost, then favors on-demand recall (session_search is FTS5-only). Background review and compression add extra LLM calls OpenClaw-style harnesses may not make by default — there is no apples-to-apples public benchmark, so compare architectures, not slogans.
• What to watch: child-run orchestration is still maturing (per third-party harness reviews), background learning is on by default but needs governance, and document RAG quality still depends on your ingestion stack — Hermes gives you hooks and patterns, not a turnkey enterprise knowledge product.

Should you evaluate Hermes?

Part 2 of this series shows how the harness maps to WhatsApp support with human handoff.

What You Will Learn Here

• What Hermes Agent is, and how it differs from a chat wrapper or a vector-only RAG stack
• Whether Hermes qualifies as an “ideal RAG app,” and what question you should ask instead
• How the internal architecture is laid out: agent loop, prompt assembly, memory, sessions, skills, gateway
• How Hermes compares with OpenClaw, n8n, Agno/AgentOS, and CrewAI — and a quick decision flow
• Concrete patterns you can reuse in your own AI apps, with examples and ASCII diagrams
• Honest limitations and where to look next if you need production document RAG

This article is for engineers building agentic products. It is Part 1 of the Hermes Agent series. Part 2 covers WhatsApp support wiring; Part 3 covers scheduled cron ops; Part 4 covers internal support copilots. For chunking, reranking, and RAG eval gates, see RAG Apps in Practice and Graph RAG Apps: A Production Deep Dive.

What Is Hermes Agent?

Hermes Agent is an open-source agent runtime published by Nous Research under the MIT license. The project describes itself as “the agent that grows with you” — meaning it is designed to accumulate durable workflow knowledge across sessions, not reset to zero after every chat.

At a high level, Hermes is four things at once:

1. An agent loop — AIAgent in run_agent.py handles provider selection, prompt construction, parallel tool dispatch, retries, fallback models, compression, and persistence.
2. A memory and recall system — bounded MEMORY.md / USER.md snapshots, SQLite session history with FTS5 search, optional external memory providers, and skills as procedural memory.
3. A deployment surface — CLI, API server, messaging gateway across 20 platform adapters (per Hermes architecture docs, July 2026), cron jobs, and ACP integration for VS Code / Zed / JetBrains.
4. A learning substrate — background review after turns can persist compact facts and patch skills, with optional human approval gates.

User / Cron / Gateway / IDE
            |
            v
      +-------------+
      |   AIAgent   |  provider adapters, tool loop, compression
      +------+------+
             |
   +---------+---------+------------------+
   |         |         |                  |
   v         v         v                  v
Prompt    Tools    Sessions           Skills/Memory
Builder   Registry  SQLite+FTS5       files + plugins

Hermes is not primarily a hosted document-QA product. You can absolutely use it for knowledge work — via qmd hybrid search, the bundled LLM Wiki skill, external memory providers, or MCP tools — but its core bet is different: make the agent itself compound over time.

Is Hermes the Ideal RAG App?

Short answer: no, and that is the wrong comparison.

A classic production RAG app optimizes a repeatable pipeline:

Corpus -> chunk/index -> retrieve -> rerank -> grounded answer -> eval gates

Hermes optimizes a personal or team agent harness:

Goal -> plan/act/observe loop -> layered recall -> procedural skills -> durable sessions

Editorial judgment: In this author’s view, Hermes is a strong open-source reference for long-lived agent infrastructure. It is not a drop-in replacement for a serious document RAG platform with ingestion pipelines, citation contracts, and retrieval eval suites. The better framing is:

Is Hermes a strong example of how to combine recall, tools, sessions, and procedural memory in one agent app?

On that question, yes.

Picking quickly

Need a personal agent across Telegram + CLI + IDE?
  -> Hermes or OpenClaw

Need SaaS trigger -> transform -> approve -> notify?
  -> n8n (+ maybe an agent step inside)

Need a customer-facing agent API with RBAC and traces?
  -> Agno / AgentOS

Need researcher + writer + reviewer as separate agents?
  -> CrewAI Flow + Crew

The full comparison matrix below adds nuance; use this flow for a first-pass product decision.

Key Features and How They Solve Common Agent Problems

1. Tiered prompt assembly

Problem: agents bloat system prompts, break provider prefix caching, and mix stable identity with volatile facts.

Hermes approach: the cached system prompt is assembled in three ordered tiers:

1. Stable — identity (SOUL.md), tool guidance, skills index, environment/platform hints
2. Context — project files like .hermes.md, AGENTS.md, CLAUDE.md, .cursorrules
3. Volatile — frozen MEMORY.md / USER.md snapshots, external memory-provider block, timestamp/session metadata

This keeps cache-friendly prefixes stable while still injecting repo rules and user facts. Mid-session memory writes hit disk immediately but do not mutate the frozen prompt until rebuild — usually a new session or compression event.

2. Bounded curated memory + on-demand session search

Problem: “always inject everything” does not scale; “store everything in vectors” is expensive and fuzzy.

Hermes approach: split recall by access pattern.

The docs are explicit: memory is for critical always-on facts; session search is for historical recall. That is a useful product split many teams blur together.

3. Skills as procedural memory

Problem: agents repeat the same multi-step workflows from scratch every session.

Hermes approach: skills are markdown workflows compatible with the agentskills.io open standard. The prompt carries a compact skills index; the model loads a skill with skill_view(name) only when needed. After complex work, the background review can create or patch skills — with optional staging via skills.write_approval.

This is closer to procedural RAG than document RAG: retrieve a playbook, not a paragraph.

4. Sessions as infrastructure

Problem: treating chat transcripts as throwaway strings makes cross-channel agents fragile.

Hermes approach: ~/.hermes/state.db stores sessions, full message history, FTS5 indexes (including trigram search for CJK/substrings), token metadata, and parent-child lineage when compression splits a session. CLI, Telegram, Discord, cron, and IDE surfaces can attach to the same session plane.

5. Context compression with lineage, not amnesia

Problem: naive trimming deletes evidence; full summarization without lineage makes debugging impossible.

Hermes approach: when context crosses thresholds, the built-in ContextCompressor prunes verbose old tool results (Phase 1), determines compression boundaries (Phase 2), may summarize middle turns with an auxiliary model (Phase 3), then reassembles the message list (Phase 4). It protects the first three messages and a recent tail (default 20 messages or a token budget), then creates a continuation session linked via parent_session_id. You get a chain of sessions instead of one rewritten transcript.

6. Tool registration != tool exposure

Problem: huge tool schemas hurt model performance and safety.

Hermes approach: tools self-register in a central registry at import time, but a separate toolset layer decides what the model actually sees per platform, profile, or delegated run. You can install broadly and expose narrowly.

7. Gateway + cron + profiles

Problem: agents trapped in a laptop terminal do not match how people work.

Hermes approach:

• Gateway routes 20 messaging platform adapters through shared session logic, authorization, slash commands, and hooks.
• Cron runs first-class agent jobs with attached skills and delivery targets.
• Profiles (hermes -p <name>) isolate config, memory, sessions, and gateway state for separate agents on one machine.

8. Optional hybrid document retrieval

Problem: personal notes and docs still need semantic + keyword retrieval.

Hermes approach: document retrieval is optional and pluggable:

• qmd skill — local hybrid search with BM25, vectors, and LLM reranking; exposes MCP tools
• LLM Wiki skill — Karpathy-style interlinked markdown knowledge base with SCHEMA.md, index.md, and raw source layers
• External memory providers — Honcho, Mem0, Hindsight, OpenViking, Supermemory, and others

So Hermes can do RAG-like work, but as skills and plugins around the harness, not as the sole identity of the system.

Internal Architecture

End-to-end request flow

                ENTRY POINTS
 +----------+  +----------+  +------+  +--------+
 | CLI/TUI  |  | Gateway  |  | Cron |  | ACP/IDE|
 +----+-----+  +-----+----+  +---+--+  +---+----+
      |              |           |         |
      +--------------+-----------+---------+
                     |
                     v
            +------------------+
            |     AIAgent      |
            |  run_agent.py    |
            +--------+---------+
                     |
      +--------------+--------------+
      |              |              |
      v              v              v
 prompt_builder  runtime_provider  model_tools
 (3-tier prompt) (18+ providers)   (tool dispatch)
      |              |              |
      v              v              v
 memory snapshot  API mode pick   parallel tools
 skills index     retry/fallback  terminal/browser/MCP
 context files    compression     file/web/vision
                     |
                     v
              +-------------+
              | SessionDB   |
              | SQLite FTS5 |
              +-------------+

Prompt and recall stack

SYSTEM PROMPT (cached)
├── stable
│   ├── SOUL.md identity
│   ├── enabled-tool guidance
│   └── skills index (names only)
├── context
│   ├── optional system_message override
│   └── one project context file (.hermes.md > AGENTS.md > CLAUDE.md > .cursorrules)
└── volatile
    ├── MEMORY.md snapshot
    ├── USER.md snapshot
    ├── external memory provider block
    └── timestamp / session / model metadata

TURN-TIME RECALL (on demand)
├── skill_view("workflow-name")
├── session_search("deployment rollback")
├── qmd query / MCP retrieval tools
└── wiki reads via llm-wiki skill

Knowledge layers compared to classic RAG

Classic document RAG:
  Source docs -> chunker -> embeddings -> vector DB -> retriever -> answer

Hermes layered recall:
  Always-on facts        -> MEMORY.md / USER.md
  Past conversations     -> session_search (FTS5)
  Procedures             -> skills (progressive disclosure)
  Large personal corpus  -> qmd / wiki / external memory provider
  Repo instructions      -> AGENTS.md / .hermes.md / progressive subdirectory hints

That layered model is the architectural reason Hermes feels broader than a RAG demo.

Product Decisions That Make It a Good Agent App

1. Files you can inspect beat opaque memory blobs

Hermes stores durable state as markdown and SQLite you can diff, back up, and grep — and optionally track in git. Skills, memory, pending approvals, and wiki pages are inspectable artifacts. For teams worried about “what did the agent learn?”, that matters.

2. Consent-aware learning is built in

Self-improvement is configurable, not invisible. Background review runs after turns by default and can write memory or patch skills unless you gate it. The docs expose:

• memory.write_approval and skills.write_approval for staged writes
• /memory pending, /skills pending, approve/reject flows
• display.memory_notifications to control how chatty background review is
• auxiliary.background_review to run review on a cheaper model

That is a more governance-aware stance than many agent demos: learning is a feature you can audit, not an uncontrolled side effect.

3. Prompt caching is a first-class design constraint

Hermes separates cached system prompt state from ephemeral per-turn overlays. Identity and skills index stay stable; volatile memory is still structured; compression triggers explicit rebuilds. If you have ever watched Anthropic/OpenAI prefix caching melt because one line in the system prompt changed every turn, this design is the lesson.

4. One core runtime, many surfaces

AIAgent serves CLI, gateway, cron, batch, API server, and ACP. Platform differences live in entry points, not forked agent logic. That matches Hermes’s stated “platform-agnostic core” design principle.

5. Loose coupling through registries

Tools, plugins, memory providers, context engines, terminal backends, and browser backends all use registry patterns with availability checks. Optional subsystems do not become hard compile-time dependencies.

6. Security treated as prompt-input hygiene

Context files and memory entries are scanned for injection and exfiltration patterns before entering the system prompt. Project rules are powerful — and therefore dangerous — so Hermes sanitizes them instead of blindly trusting repo content.

Capability Inventory (Quick Reference)

Hermes is unusually complete as a self-hosted agent harness. The official architecture docs describe a single Python runtime with many subsystems already wired together — not a minimal SDK you must assemble yourself. The feature narratives above explain why; this section is a lookup table.

Runtime and orchestration

Memory, skills, and recall

Surfaces and operations

HERMES OUT OF THE BOX
+---------------------------+---------------------------+
| Runtime core              | Surfaces                  |
| - agent loop              | - CLI / TUI               |
| - 70+ tools               | - 20-channel gateway      |
| - compression + caching   | - cron                    |
| - provider failover       | - ACP / IDE               |
+---------------------------+---------------------------+
| Recall layers             | Governance                |
| - bounded memory files    | - write_approval gates    |
| - FTS5 session search     | - dangerous-cmd approval  |
| - skills (on demand)      | - prompt-injection scan   |
| - optional memory plugins | - profile isolation       |
+---------------------------+---------------------------+

Editorial judgment: If your product needs a personal or team agent that compounds across sessions on infrastructure you control, Hermes’s built-in surface area is the main reason to evaluate it. If your product is a multi-tenant SaaS API with RBAC and workflow checkpoints, Agno/AgentOS or LangGraph may still be a better starting point.

Hermes vs OpenClaw, n8n, Agno/AgentOS, and CrewAI

These tools often appear in the same conversation, but they optimize different layers. The useful question is not “which is best?” It is which layer should own state, routing, memory, and execution for your use case.

Layer map

                    PERSONAL AGENT HARNESS
  Hermes  <------------------------------->  OpenClaw
     \                                         /
      \   WORKFLOW / CONTROL PLANE            /
       +-------- n8n -------------------------+
       |                                      |
       |   PRODUCTIZED AGENT RUNTIME          |
       +---- Agno / AgentOS ------------------+
       |                                      |
       |   MULTI-AGENT ORCHESTRATION          |
       +---- CrewAI (Flows + Crews) ----------+

Comparison matrix (July 2026)

Hermes vs OpenClaw — the closest peer

OpenClaw and Hermes are the most direct comparison. Both are open-source, self-hosted, model-agnostic personal agent harnesses with gateway, cron, skills, and markdown memory.

When Hermes is the better default (editorial): you want a Python runtime, bounded always-on memory, FTS5 session recall, and auditable agent-authored skills.

When OpenClaw is the better default (editorial): you want a mature gateway control plane, ClawHub’s skill marketplace, and hybrid memory search over a growing markdown corpus without hard character caps.

Both projects can coexist. They are model-agnostic and solve overlapping but not identical boundaries.

Hermes vs n8n

n8n is a workflow automation platform: triggers, integrations, branching, retries, and human approval nodes on a canvas. It can call LLMs and agent nodes, but it is not trying to be a single persistent assistant with procedural memory.

See also: Autonomous Workflows in Practice.

Hermes vs Agno / AgentOS

Agno with AgentOS is a production Python agent runtime built on FastAPI. It is closer to “ship an agent product API” than “run my personal assistant.”

Editorial judgment: Choose Hermes for a compounding assistant runtime you operate for yourself or a small team. Choose Agno/AgentOS when you are building a customer-facing agent backend with API docs, auth, schedules, and observability as product requirements.

See also: Agno/AgentOS + FastAPI vs LangChain/LangGraph + FastAPI.

Hermes vs CrewAI

CrewAI orchestrates teams of specialized agents through Flows (event-driven control) and Crews (collaborative task execution). It is a multi-agent framework, not a single persistent assistant shell.

Editorial judgment: CrewAI wins when the problem is role specialization and task orchestration. Hermes wins when the problem is one agent that should remember you, your repos, and your workflows across months.

Picking quickly (full matrix context)

See the decision flow near the top of this article. The matrix above adds layer-by-layer detail for architects who need more than a first-pass triage.

Does Hermes Consume More Tokens Than Alternatives?

Short answer: there is no published apples-to-apples benchmark across Hermes, OpenClaw, n8n, Agno, and CrewAI. Token use depends on your model, enabled toolsets, memory contents, retrieval habits, and how chatty the agent is. What we can compare honestly is architectural token posture.

Fixed per-turn overhead (Hermes)

Hermes pays a predictable baseline every session:

OpenClaw also loads MEMORY.md at the start of DM sessions and can maintain larger daily memory logs. Because Hermes enforces hard character caps on always-on MEMORY.md/USER.md, its baseline prompt injection is more bounded than OpenClaw’s workspace model, which can truncate injected MEMORY.md when it exceeds bootstrap budget but still accumulate large on-disk corpora.

On-demand recall: where Hermes saves tokens

Hermes’s docs draw an explicit line:

OpenClaw’s default memory_search returns snippet text (capped ~700 chars per OpenClaw memory-search defaults) from chunked markdown with hybrid vector + keyword search — also on demand, but typically embedding-backed on the retrieval path.

Editorial judgment: Hermes is designed to avoid dragging all history into every turn. OpenClaw is designed to make workspace memory searchable without a hard cap on what can accumulate on disk. Neither approach is free; they spend tokens in different places.

Hidden token costs where Hermes can spend more

Hermes features that add LLM calls beyond the main chat turn:

1. Background review — post-turn replay/digest that can write memory or patch skills. Configurable to a cheaper model via auxiliary.background_review.
2. Context compression — auxiliary summarization when prompts cross the 50% threshold (default). Phase 1 also prunes old tool outputs without an LLM call.
3. Tool-heavy turns — verbose terminal/file tool output lands in context until pruned or compressed. This is common to all agent harnesses, not Hermes-specific.
4. Multi-iteration agent loops — default 90 max turns (agent.max_turns in Agent Loop docs). Any harness that lets the model loop can burn tokens fast.

OpenClaw has its own costs: memory_search embeddings, larger injected memory files, /compact summarization, and multi-agent routing — but Hermes’s background review + dual compression stack is a distinctive extra line item to budget for.

Prompt caching: where Hermes can spend less

On Anthropic models, Hermes implements explicit prompt caching with the system_and_3 strategy. Official docs claim up to ~75% input-token savings on multi-turn conversations when prefix caching hits. The stable/volatile prompt tiering exists partly to preserve cache-friendly prefixes.

That benefit is provider-specific. It does not automatically mean Hermes is cheaper than OpenClaw on OpenAI-only stacks.

Practical token checklist

[ ] Measure baseline system prompt size (memory + skills index + context files)
[ ] Track tool output volume per turn (terminal/file tools dominate)
[ ] Count auxiliary calls (background review + compression summaries)
[ ] Compare on-demand recall cost (FTS5 only vs embedding search snippets)
[ ] Enable write_approval if bad memory entries bloat MEMORY.md
[ ] Scope toolsets per surface — fewer exposed tools = smaller schemas
[ ] Use auxiliary.background_review with a cheaper model if review quality holds

Bottom line on tokens

Hermes is not inherently token-hungry, but it is not token-minimal either. Its design trades:

• bounded always-on memory (lower fixed cost than unbounded workspace memory)
• FTS5 session recall without LLM calls (cheaper historical lookup than summarize-and-inject patterns)
• extra auxiliary calls for learning and compression (costs OpenClaw may incur differently via /compact and memory indexing)

If token cost is your primary constraint, run both candidates on the same scripted task list with /usage (OpenClaw) and Hermes’s CLI token bar, then compare total tokens per successful task — not marketing claims.

Implementation Patterns You Can Reuse

Pattern A: Split always-on facts from searchable history

If you are building your own agent app, copy the Hermes split:

# Pseudocode inspired by Hermes memory/session design

class AgentRecall:
    def build_system_prompt(self) -> str:
        return "\n".join([
            self.identity_block(),
            self.compact_user_profile(max_chars=1400),
            self.compact_working_memory(max_chars=2200),
            self.skills_index_only(),  # not full skill bodies
        ])

    async def on_turn(self, user_message: str) -> list[dict]:
        context = []
        if self.looks_like_history_question(user_message):
            context.extend(await self.session_search(user_message, limit=8))
        if self.looks_like_doc_question(user_message):
            context.extend(await self.hybrid_retrieve(user_message, limit=6))
        return context

Why it works: fixed per-turn cost stays bounded, while deep recall remains available on demand.

Pattern B: Progressive skill loading

Do not stuff every workflow into the system prompt. Ship an index plus a load_skill(name) tool.

System prompt:
  - skill: deploy-staging
  - skill: incident-triage
  - skill: code-review

On match:
  load_skill("deploy-staging") -> inject full SKILL.md body for this turn chain only

This is how Hermes keeps token use sane while still supporting a large skills catalog.

Pattern C: Compression creates lineage

When summarizing old context, do not overwrite the canonical transcript. Instead:

Session A (full history)
   |
   | context threshold reached
   v
summary S generated by auxiliary model
   |
   v
Session B(parent=A, seed=S)  # new session id, preserved lineage

That gives you debuggability and cross-session analytics later.

Pattern D: Staged self-modification

If your agent can update memory or tools, add a staging layer:

background review -> proposed memory/skill change
                  -> pending queue
                  -> human approve/reject
                  -> commit to durable store

Hermes uses this pattern because autonomous learning without audit trails breaks trust quickly.

Pattern E: Hybrid retrieval as an optional tool, not the whole app

For note/doc search, Hermes documents qmd modes that mirror good production practice:

Expose these as tools the agent calls when needed, rather than retrieving on every turn by default.

Pattern F: Repo-native instructions

Hermes reads AGENTS.md, .hermes.md, and compatible files from the working tree. If you maintain agent instructions beside code, the agent picks them up without a separate admin UI. Progressive subdirectory discovery means monorepo rules can appear when the agent enters a package.

What a Hermes-Inspired App Checklist Looks Like

Use this if you are designing your own agent product:

[ ] Agent loop with explicit tool dispatch and iteration budget
[ ] Stable / context / volatile prompt tiers
[ ] Bounded always-on memory plus searchable session history
[ ] Procedural memory as on-demand skills or playbooks
[ ] Compression with lineage, not silent transcript loss
[ ] Tool registry separate from per-surface tool exposure
[ ] Write-approval path for self-modifying state
[ ] Hybrid retrieval only for document-heavy questions
[ ] Cross-channel session routing if users will not live in one UI
[ ] Eval hooks for memory pollution, retrieval miss, and skill regressions

The last item is where Hermes stops and your product work begins. The harness gives you architecture; you still own quality gates.

Where Hermes Is Not the Answer

Be explicit about the gaps:

1. Enterprise document RAG — Hermes does not replace ingestion pipelines, chunk strategy design, citation contracts, ACL-aware retrieval, or RAG eval dashboards. See RAG Apps in Practice.
2. Durable child-run orchestration — delegate_task exists, but independent long-lived child runs with external steering are still emerging (per Arize’s harness review from June 2026). Complex fan-out/fan-in orchestration may need an external control plane.
3. Managed SaaS convenience — Hermes is self-hosted. You own upgrades, secrets, backups, model routing, and abuse prevention on messaging surfaces.
4. Guaranteed learning quality — background review can stage bad memories or overfit noisy workflows. Approval gates help, but evals are still your responsibility.
5. Graph-native reasoning — relationship-heavy corpora may still need Graph RAG or a knowledge-graph memory provider rather than markdown plus FTS5.

Bottom Line

Hermes Agent is, in this author’s view, one of the more capable open-source agent harnesses available as of July 2026 (editorial judgment — not a benchmarked ranking). It is not the ideal RAG app — it is something more interesting for builders: a reference architecture for long-lived agents that combine tools, sessions, procedural skills, and layered recall.

The lesson is not “rip out your vector database and install Hermes.” The lesson is:

• treat sessions as infrastructure
• separate always-on facts from searchable history
• load procedures progressively
• make self-modification auditable
• keep prompt prefixes stable
• bolt document retrieval on as a tool, not as the entire product identity

If you are building an agent app rather than a document search product, Hermes is worth studying closely — especially the docs on prompt assembly, session storage, memory providers, and skills.

Sources

Primary sources consulted on July 3, 2026:

1. Nous Research — Hermes Agent GitHub repository — project scope, MIT license, feature overview, release cadence. github.com/NousResearch/hermes-agent
2. Hermes Agent documentation — Architecture — system map, subsystems, design principles, directory layout. hermes-agent.nousresearch.com/docs/developer-guide/architecture
3. Hermes Agent documentation — Agent Loop Internals — AIAgent responsibilities, API modes, iteration budgets. hermes-agent.nousresearch.com/docs/developer-guide/agent-loop
4. Hermes Agent documentation — Prompt Assembly — stable/context/volatile tiers, SOUL.md, context file priority, caching boundaries. hermes-agent.nousresearch.com/docs/developer-guide/prompt-assembly
5. Hermes Agent documentation — Persistent Memory — MEMORY.md, USER.md, session search comparison, write approval, background review. hermes-agent.nousresearch.com/docs/user-guide/features/memory
6. Hermes Agent documentation — Session Storage — SQLite schema, FTS5, lineage, contention handling. hermes-agent.nousresearch.com/docs/developer-guide/session-storage
7. Hermes Agent documentation — Skills System — progressive disclosure, /learn, write approval, agentskills.io compatibility. hermes-agent.nousresearch.com/docs/user-guide/features/skills
8. Hermes Agent documentation — Memory Providers — Honcho, Mem0, Hindsight, OpenViking, Supermemory, and others. hermes-agent.nousresearch.com/docs/user-guide/features/memory-providers
9. Hermes Agent documentation — qmd optional skill — local hybrid retrieval modes (BM25, vector, rerank) and MCP integration. hermes-agent.nousresearch.com/docs/user-guide/skills/optional/research/research-qmd
10. Hermes Agent documentation — LLM Wiki bundled skill — three-layer wiki architecture tagged as rag-alternative. hermes-agent.nousresearch.com/docs/user-guide/skills/bundled/research/research-llm-wiki
11. Hermes Agent documentation — Context Compression and Caching — dual compressor, pruning, lineage, Anthropic system_and_3 caching. hermes-agent.nousresearch.com/docs/developer-guide/context-compression-and-caching
12. Hermes Agent documentation — Tools Runtime — registry vs toolset exposure, dispatch flow. hermes-agent.nousresearch.com/docs/developer-guide/tools-runtime
13. Hermes Agent documentation — CLI Interface — token bar, compression defaults, session resume. hermes-agent.nousresearch.com/docs/user-guide/cli
14. OpenClaw documentation — Architecture — gateway control plane, WebSocket clients/nodes. docs.openclaw.ai/concepts/architecture
15. OpenClaw documentation — Memory — markdown workspace memory, hybrid search, optional qmd backend. docs.openclaw.ai/concepts/memory
16. OpenClaw GitHub repository — memory-search defaults — chunk and snippet sizing for memory_search. github.com/openclaw/openclaw/blob/main/src/agents/memory-search.ts
17. OpenClaw GitHub repository — gateway, skills, workspace model. github.com/openclaw/openclaw
18. CrewAI documentation — Introduction — Flows + Crews model. docs.crewai.com/en/introduction
19. Agno documentation — AgentOS — FastAPI-native runtime. docs.agno.com
20. n8n integrations — integration count for comparison matrix. n8n.io/integrations
21. agentskills.io — open skill format used by Hermes. agentskills.io

Strong secondary analysis:

22. Arize AI — How Hermes implements an open source agent harness architecture (June 1, 2026) — independent architecture review using a nine-part harness model; useful for subsystem boundaries and remaining orchestration gaps. arize.com/blog/how-hermes-implements-open-source-agent-harness-architecture

Related internal articles:

23. RAG Apps in Practice
24. Graph RAG Apps: A Production Deep Dive
25. Autonomous Workflows in Practice
26. Agno/AgentOS + FastAPI vs LangChain/LangGraph + FastAPI
27. Part 2: WhatsApp agent with Cloud API, Chatwoot, Hermes, and OpenAI