Hermes Agent: ¿Es la app RAG ideal? Lecciones de arquitectura para ingenieros

Resumen

• Hermes Agent es un harness de agentes de código abierto y autohospedado de Nous Research. Hasta julio de 2026, se distribuye como un runtime de Python con CLI, gateway de mensajería, cron, integración ACP/IDE, más de 70 herramientas y un ciclo de aprendizaje en segundo plano (activado por defecto; opcionalmente sujeto a aprobación mediante memory.write_approval / skills.write_approval, ambos con valor predeterminado false) que puede convertir el trabajo exitoso en skills reutilizables.
• No es la app RAG ideal en el sentido clásico. Hermes se parece más a un harness de agentes de larga duración con recuperación en capas: memoria curada y acotada, búsqueda de sesiones con FTS5, búsqueda híbrida opcional de documentos (qmd), bases de conocimiento tipo wiki y proveedores externos de memoria intercambiables. Es algo más amplio que «generar embeddings de documentos, recuperar los top-k y responder».
• Sus puntos fuertes: sesiones tratadas como infraestructura (SQLite + FTS5 + linaje), niveles de prompt optimizados para caché, registro de herramientas separado de su exposición, carga progresiva de skills, escrituras de memoria que consideran el consentimiento y un gateway que convierte un agente en un asistente multicanal.
• Qué puedes adoptar en tus propias apps: prompts de sistema por niveles, contexto congelado frente a contexto bajo demanda, recuperación híbrida solo cuando se necesite, memoria procedimental auditable, controles explícitos de aprobación de escritura y compresión que crea linaje de sesiones en lugar de reescribir el historial.
• Frente a OpenClaw, n8n, Agno/AgentOS y CrewAI: Hermes se acerca más a OpenClaw como harness de agentes personales, pero se centra en el runtime de agentes de Python y el aprendizaje auditable de skills; los demás se enfocan, respectivamente, en planos de control de gateway, automatización de workflows, APIs de agentes listas para integrarse en productos o equipos multiagente.
• Enfoque sobre tokens: Hermes asume un pequeño costo fijo de memoria e índice de skills por turno y después favorece la recuperación bajo demanda (session_search usa solo FTS5). La revisión en segundo plano y la compresión agregan llamadas adicionales al LLM que los harnesses al estilo de OpenClaw podrían no hacer por defecto. No hay un benchmark público con una comparación equivalente, así que compara arquitecturas, no eslóganes.
• Aspectos a vigilar: la orquestación de ejecuciones hijas aún está madurando (según reseñas independientes de harnesses), el aprendizaje en segundo plano está activado por defecto pero necesita gobernanza, y la calidad del RAG documental sigue dependiendo de tu stack de ingestión. Hermes ofrece hooks y patrones, no un producto empresarial de conocimiento listo para usar.

¿Deberías evaluar Hermes?

La Parte 2 de esta serie muestra cómo aplicar el harness a soporte por WhatsApp con transferencia a una persona.

Qué aprenderás aquí

• Qué es Hermes Agent y en qué se diferencia de un wrapper de chat o un stack RAG basado solo en vectores
• Si Hermes califica como una «app RAG ideal» y qué pregunta deberías hacerte en su lugar
• Cómo se organiza su arquitectura interna: ciclo del agente, ensamblaje del prompt, memoria, sesiones, skills y gateway
• Cómo se compara Hermes con OpenClaw, n8n, Agno/AgentOS y CrewAI, además de un flujo rápido de decisión
• Patrones concretos que puedes reutilizar en tus propias apps de IA, con ejemplos y diagramas ASCII
• Limitaciones expuestas con franqueza y dónde buscar después si necesitas RAG documental para producción

Este artículo está dirigido a ingenieros que crean productos basados en agentes. Es la Parte 1 de la serie sobre Hermes Agent. La Parte 2 cubre la integración de soporte por WhatsApp; la Parte 3, las operaciones programadas con cron; y la Parte 4, los copilotos internos de soporte. Para chunking, reranking y controles de evaluación de RAG, consulta Apps RAG en la práctica y Apps de Graph RAG: análisis profundo para producción.

¿Qué es Hermes Agent?

Hermes Agent es un runtime de agentes de código abierto publicado por Nous Research bajo la licencia MIT. El proyecto se describe como «el agente que crece contigo»: está diseñado para acumular conocimiento duradero sobre workflows entre sesiones, en lugar de empezar desde cero después de cada chat.

A grandes rasgos, Hermes es cuatro cosas a la vez:

1. Un ciclo de agente: AIAgent en run_agent.py maneja la selección de proveedores, la construcción del prompt, el despacho paralelo de herramientas, los reintentos, los modelos alternativos, la compresión y la persistencia.
2. Un sistema de memoria y recuperación: snapshots acotados de MEMORY.md / USER.md, historial de sesiones en SQLite con búsqueda FTS5, proveedores externos de memoria opcionales y skills como memoria procedimental.
3. Una superficie de despliegue: CLI, servidor API, gateway de mensajería con 20 adaptadores de plataforma (según la documentación de arquitectura de Hermes, julio de 2026), tareas cron e integración ACP para VS Code / Zed / JetBrains.
4. Una base para el aprendizaje: la revisión en segundo plano después de los turnos puede guardar hechos concisos y actualizar skills, con controles opcionales de aprobación humana.

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 no es principalmente un producto alojado de preguntas y respuestas sobre documentos. Sin duda puedes usarlo para trabajo con conocimiento mediante la búsqueda híbrida de qmd, la skill LLM Wiki incluida, proveedores externos de memoria o herramientas MCP, pero su apuesta central es distinta: hacer que el propio agente acumule capacidades con el tiempo.

¿Es Hermes la app RAG ideal?

Respuesta corta: no, y esa no es la comparación adecuada.

Una app RAG clásica para producción optimiza un pipeline repetible:

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

Hermes optimiza un harness de agentes personal o para equipos:

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

Valoración editorial: En opinión de este autor, Hermes es una sólida referencia de código abierto para infraestructura de agentes de larga duración. No es un reemplazo directo para una plataforma RAG documental robusta con pipelines de ingestión, contratos de citas y suites de evaluación de recuperación. Es mejor plantearlo así:

¿Es Hermes un buen ejemplo de cómo combinar recuperación, herramientas, sesiones y memoria procedimental en una sola app de agentes?

A esa pregunta, la respuesta es sí.

Elección rápida

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

La matriz comparativa completa que aparece más adelante añade matices; usa este flujo para una primera decisión de producto.

Funciones clave y cómo resuelven problemas comunes de los agentes

1. Ensamblaje del prompt por niveles

Problema: los agentes sobrecargan los prompts de sistema, invalidan la caché de prefijos del proveedor y mezclan una identidad estable con hechos volátiles.

Enfoque de Hermes: el prompt de sistema almacenado en caché se ensambla en tres niveles ordenados:

1. Estable: identidad (SOUL.md), orientación para herramientas, índice de skills e indicaciones sobre el entorno y la plataforma
2. Contexto: archivos del proyecto como .hermes.md, AGENTS.md, CLAUDE.md, .cursorrules
3. Volátil: snapshots congelados de MEMORY.md / USER.md, bloque del proveedor externo de memoria y metadatos de fecha, hora y sesión

Esto mantiene estables los prefijos favorables para la caché y, al mismo tiempo, incorpora reglas del repositorio y datos del usuario. Las escrituras de memoria durante una sesión se guardan de inmediato en disco, pero no modifican el prompt congelado hasta que se reconstruye, normalmente al iniciar una sesión nueva o durante un evento de compresión.

2. Memoria curada y acotada + búsqueda de sesiones bajo demanda

Problema: «inyectar siempre todo» no escala; «guardar todo en vectores» es costoso y poco preciso.

Enfoque de Hermes: separar la recuperación según el patrón de acceso.

La documentación es explícita: la memoria es para hechos críticos que siempre deben estar presentes; la búsqueda de sesiones es para recuperar el historial. Es una distinción útil de producto que muchos equipos no mantienen clara.

3. Skills como memoria procedimental

Problema: los agentes repiten los mismos workflows de varios pasos desde cero en cada sesión.

Enfoque de Hermes: las skills son workflows en markdown compatibles con el estándar abierto de agentskills.io. El prompt contiene un índice compacto de skills; el modelo carga una skill con skill_view(name) solo cuando la necesita. Después de un trabajo complejo, la revisión en segundo plano puede crear o actualizar skills, con una etapa opcional de aprobación mediante skills.write_approval.

Esto se parece más al RAG procedimental que al RAG documental: recupera un playbook, no un párrafo.

4. Sesiones como infraestructura

Problema: tratar las transcripciones de chat como cadenas de texto desechables hace que los agentes multicanal sean frágiles.

Enfoque de Hermes: ~/.hermes/state.db almacena sesiones, el historial completo de mensajes, índices FTS5 (incluida la búsqueda por trigramas para CJK/subcadenas), metadatos de tokens y linaje entre sesiones padre e hija cuando la compresión divide una sesión. Las interfaces de CLI, Telegram, Discord, cron e IDE pueden conectarse al mismo plano de sesiones.

5. Compresión de contexto con linaje, no amnesia

Problema: los recortes ingenuos eliminan evidencia; resumir todo sin conservar el linaje hace imposible la depuración.

Enfoque de Hermes: cuando el contexto supera ciertos umbrales, el ContextCompressor integrado recorta los resultados antiguos y extensos de herramientas (Fase 1), determina los límites de compresión (Fase 2), puede resumir los turnos intermedios con un modelo auxiliar (Fase 3) y luego vuelve a ensamblar la lista de mensajes (Fase 4). Protege los primeros tres mensajes y una parte reciente del historial (por defecto, 20 mensajes o un presupuesto de tokens), y después crea una sesión de continuación vinculada mediante parent_session_id. Obtienes una cadena de sesiones en lugar de una transcripción reescrita.

6. Registro de herramientas != exposición de herramientas

Problema: los esquemas de herramientas demasiado grandes perjudican el rendimiento y la seguridad del modelo.

Enfoque de Hermes: las herramientas se registran automáticamente en un registro central al importarse, pero una capa separada de conjuntos de herramientas decide qué ve realmente el modelo según la plataforma, el perfil o la ejecución delegada. Puedes instalar muchas herramientas y exponer solo unas pocas.

7. Gateway + cron + perfiles

Problema: los agentes confinados a la terminal de una laptop no se ajustan a la forma en que trabaja la gente.

Enfoque de Hermes:

• Gateway enruta 20 adaptadores de plataformas de mensajería mediante lógica compartida de sesiones, autorización, comandos de barra y hooks.
• Cron ejecuta tareas de agentes como componente nativo, con skills asociadas y destinos de entrega.
• Perfiles (hermes -p <name>) aíslan la configuración, la memoria, las sesiones y el estado del gateway para agentes separados en una misma máquina.

8. Recuperación híbrida opcional de documentos

Problema: las notas y los documentos personales también necesitan recuperación semántica y por palabras clave.

Enfoque de Hermes: la recuperación de documentos es opcional y admite componentes intercambiables:

• Skill qmd: búsqueda híbrida local con BM25, vectores y reranking con LLM; expone herramientas MCP
• Skill LLM Wiki: base de conocimiento en markdown con enlaces cruzados al estilo de Karpathy, con SCHEMA.md, index.md y capas de fuentes originales
• Proveedores externos de memoria: Honcho, Mem0, Hindsight, OpenViking, Supermemory y otros

Así que Hermes puede realizar trabajo similar a RAG, pero mediante skills y plugins alrededor del harness, no como la única identidad del sistema.

Arquitectura interna

Flujo de solicitud de extremo a extremo

                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 |
              +-------------+

Stack de prompt y recuperación

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

Capas de conocimiento comparadas con el RAG clásico

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

Ese modelo en capas explica, desde la arquitectura, por qué Hermes se siente más amplio que una demo de RAG.

Decisiones de producto que lo convierten en una buena app de agentes

1. Los archivos inspeccionables superan a los bloques opacos de memoria

Hermes almacena el estado duradero en markdown y SQLite, formatos que puedes comparar con diff, respaldar y buscar con grep; también puedes versionarlos en git. Las skills, la memoria, las aprobaciones pendientes y las páginas wiki son artefactos inspeccionables. Eso importa a los equipos que se preguntan «¿qué aprendió el agente?».

2. El aprendizaje que considera el consentimiento está integrado

La mejora autónoma es configurable, no invisible. La revisión en segundo plano se ejecuta después de los turnos por defecto y puede escribir en la memoria o actualizar skills, salvo que establezcas controles de aprobación. La documentación expone:

• memory.write_approval y skills.write_approval para escrituras pendientes de aprobación
• /memory pending, /skills pending y flujos para aprobar o rechazar
• display.memory_notifications para controlar la frecuencia de los avisos de la revisión en segundo plano
• auxiliary.background_review para ejecutar la revisión con un modelo más económico

Es una postura que considera más la gobernanza que muchas demos de agentes: el aprendizaje es una función que puedes auditar, no un efecto secundario descontrolado.

3. La caché de prompts es una restricción de diseño fundamental

Hermes separa el estado del prompt de sistema almacenado en caché de las capas efímeras de cada turno. La identidad y el índice de skills permanecen estables; la memoria volátil sigue estructurada; la compresión desencadena reconstrucciones explícitas. Si alguna vez viste cómo dejaba de funcionar la caché de prefijos de Anthropic/OpenAI porque una línea del prompt de sistema cambiaba en cada turno, este diseño ofrece una lección.

4. Un runtime central, muchas interfaces

AIAgent da servicio a la CLI, el gateway, cron, el procesamiento por lotes, el servidor API y ACP. Las diferencias entre plataformas viven en los puntos de entrada, no en lógica de agente bifurcada. Esto coincide con el principio de diseño declarado por Hermes de un «núcleo independiente de la plataforma».

5. Acoplamiento flexible mediante registros

Las herramientas, los plugins, los proveedores de memoria, los motores de contexto, los backends de terminal y los backends de navegador usan patrones de registro con verificaciones de disponibilidad. Los subsistemas opcionales no se convierten en dependencias obligatorias en tiempo de compilación.

6. La seguridad como higiene de las entradas del prompt

Los archivos de contexto y las entradas de memoria se analizan para detectar patrones de inyección y exfiltración antes de entrar al prompt de sistema. Las reglas de proyecto son poderosas y, por tanto, peligrosas, así que Hermes las sanitiza en lugar de confiar ciegamente en el contenido del repositorio.

Inventario de capacidades (referencia rápida)

Hermes es inusualmente completo como harness de agentes autohospedado. La documentación oficial de arquitectura describe un único runtime de Python con muchos subsistemas ya integrados, no un SDK mínimo que debas ensamblar por tu cuenta. Las descripciones anteriores explican por qué; esta sección sirve como tabla de consulta.

Runtime y orquestación

Memoria, skills y recuperación

Interfaces y operaciones

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       |
+---------------------------+---------------------------+

Valoración editorial: Si tu producto necesita un agente personal o para un equipo que acumule conocimiento entre sesiones en infraestructura que controlas, la amplitud de las capacidades integradas de Hermes es la razón principal para evaluarlo. Si tu producto es una API SaaS multi-tenant con RBAC y checkpoints de workflows, Agno/AgentOS o LangGraph pueden seguir siendo un mejor punto de partida.

Hermes frente a OpenClaw, n8n, Agno/AgentOS y CrewAI

Estas herramientas suelen aparecer en la misma conversación, pero optimizan capas diferentes. La pregunta útil no es «¿cuál es mejor?», sino qué capa debe encargarse del estado, el enrutamiento, la memoria y la ejecución para tu caso de uso.

Mapa de capas

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

Matriz comparativa (julio de 2026)

Hermes frente a OpenClaw: el competidor más cercano

OpenClaw y Hermes son la comparación más directa. Ambos son harnesses de agentes personales de código abierto, autohospedados e independientes del modelo, con gateway, cron, skills y memoria en markdown.

Cuándo Hermes es la mejor opción por defecto (valoración editorial): quieres un runtime de Python, memoria siempre activa y acotada, recuperación de sesiones con FTS5 y skills auditables creadas por el agente.

Cuándo OpenClaw es la mejor opción por defecto (valoración editorial): quieres un plano de control de gateway maduro, el marketplace de skills de ClawHub y búsqueda híbrida de memoria sobre un corpus creciente de markdown sin límites estrictos de caracteres.

Ambos proyectos pueden coexistir. Son independientes del modelo y resuelven problemas que se superponen, aunque no son idénticos.

Hermes frente a n8n

n8n es una plataforma de automatización de workflows: triggers, integraciones, ramificaciones, reintentos y nodos de aprobación humana en un canvas. Puede llamar a LLM y nodos de agentes, pero no busca ser un único asistente persistente con memoria procedimental.

Consulta también: Workflows autónomos en la práctica.

Hermes frente a Agno / AgentOS

Agno con AgentOS es un runtime de agentes en Python para producción construido sobre FastAPI. Se acerca más a «entregar una API de producto de agentes» que a «ejecutar mi asistente personal».

Valoración editorial: Elige Hermes para un runtime de asistente que acumula capacidades y que administras para ti o para un equipo pequeño. Elige Agno/AgentOS cuando estés construyendo un backend de agentes para clientes con documentación de API, autenticación, programación y observabilidad como requisitos de producto.

Consulta también: Agno/AgentOS + FastAPI frente a LangChain/LangGraph + FastAPI.

Hermes frente a CrewAI

CrewAI orquesta equipos de agentes especializados mediante Flows (control basado en eventos) y Crews (ejecución colaborativa de tareas). Es un framework multiagente, no la interfaz de un único asistente persistente.

Valoración editorial: CrewAI gana cuando el problema es la especialización por roles y la orquestación de tareas. Hermes gana cuando el problema es un agente que debe recordarte a ti, tus repositorios y tus workflows durante meses.

Elección rápida (contexto de la matriz completa)

Consulta el flujo de decisión cerca del inicio de este artículo. La matriz anterior añade detalles capa por capa para arquitectos que necesitan algo más que una primera evaluación.

¿Consume Hermes más tokens que las alternativas?

Respuesta corta: no hay un benchmark publicado con una comparación equivalente entre Hermes, OpenClaw, n8n, Agno y CrewAI. El uso de tokens depende de tu modelo, los conjuntos de herramientas habilitados, el contenido de la memoria, los hábitos de recuperación y cuán verboso sea el agente. Lo que sí podemos comparar con honestidad es el enfoque arquitectónico sobre tokens.

Sobrecarga fija por turno (Hermes)

Hermes asume un costo base predecible en cada sesión:

OpenClaw también carga MEMORY.md al inicio de las sesiones de mensajes directos y puede mantener registros diarios de memoria más grandes. Como Hermes aplica límites estrictos de caracteres a los archivos MEMORY.md/USER.md siempre activos, su inyección base en el prompt está más acotada que la del modelo de workspace de OpenClaw, que puede truncar el MEMORY.md inyectado cuando supera el presupuesto de bootstrap, pero aun así acumular corpus grandes en disco.

Recuperación bajo demanda: dónde ahorra tokens Hermes

La documentación de Hermes establece una distinción explícita:

El memory_search predeterminado de OpenClaw devuelve fragmentos de texto (limitados a ~700 caracteres según los valores predeterminados de memory-search de OpenClaw) de markdown dividido en chunks, con búsqueda híbrida vectorial + palabras clave. También funciona bajo demanda, pero normalmente usa embeddings en el proceso de recuperación.

Valoración editorial: Hermes está diseñado para evitar arrastrar todo el historial a cada turno. OpenClaw está diseñado para permitir búsquedas en la memoria del workspace sin un límite estricto sobre lo que puede acumularse en disco. Ninguno de los dos enfoques es gratis; consumen tokens en puntos distintos.

Costos ocultos de tokens donde Hermes puede gastar más

Funciones de Hermes que agregan llamadas al LLM más allá del turno principal de chat:

1. Revisión en segundo plano: reproducción o resumen posterior al turno que puede escribir memoria o actualizar skills. Puede configurarse con un modelo más económico mediante auxiliary.background_review.
2. Compresión de contexto: resumen auxiliar cuando los prompts superan el umbral del 50% (por defecto). La Fase 1 también recorta resultados antiguos de herramientas sin llamar al LLM.
3. Turnos con muchas herramientas: las salidas extensas de herramientas de terminal o archivos entran al contexto hasta que se recortan o comprimen. Esto es común a todos los harnesses de agentes, no es específico de Hermes.
4. Ciclos de agente con múltiples iteraciones: máximo predeterminado de 90 turnos (agent.max_turns en la documentación de Agent Loop). Cualquier harness que permita al modelo iterar puede consumir tokens rápidamente.

OpenClaw tiene sus propios costos: embeddings de memory_search, archivos de memoria inyectados más grandes, resúmenes con /compact y enrutamiento multiagente. Sin embargo, la combinación de revisión en segundo plano + compresión doble de Hermes es una partida adicional particular que debes incluir en el presupuesto.

Caché de prompts: dónde puede gastar menos Hermes

En modelos de Anthropic, Hermes implementa caché de prompts explícita con la estrategia system_and_3. La documentación oficial afirma que puede ahorrar hasta ~75% de tokens de entrada en conversaciones de varios turnos cuando se aprovecha la caché de prefijos. La organización del prompt en niveles estables y volátiles existe, en parte, para conservar prefijos favorables para la caché.

Ese beneficio depende del proveedor. No significa automáticamente que Hermes sea más económico que OpenClaw en stacks que usan solo OpenAI.

Lista práctica para revisar tokens

[ ] 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

Conclusión sobre los tokens

Hermes no consume necesariamente muchos tokens, pero tampoco minimiza su consumo al máximo. Su diseño combina:

• memoria siempre activa y acotada (menor costo fijo que una memoria de workspace sin límites)
• recuperación de sesiones con FTS5 sin llamadas al LLM (búsqueda histórica más económica que los patrones de resumir e inyectar)
• llamadas auxiliares adicionales para aprendizaje y compresión (costos en los que OpenClaw puede incurrir de otra forma mediante /compact y la indexación de memoria)

Si el costo de tokens es tu restricción principal, ejecuta ambos candidatos con la misma lista de tareas predefinidas usando /usage (OpenClaw) y la barra de tokens de la CLI de Hermes. Después compara los tokens totales por tarea exitosa, no las afirmaciones de marketing.

Patrones de implementación que puedes reutilizar

Patrón A: separar los hechos siempre activos del historial consultable

Si estás creando tu propia app de agentes, copia la separación de Hermes:

# 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

Por qué funciona: el costo fijo por turno se mantiene acotado, mientras que la recuperación detallada sigue disponible bajo demanda.

Patrón B: carga progresiva de skills

No metas todos los workflows en el prompt de sistema. Ofrece un índice y una herramienta load_skill(name).

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

Así es como Hermes mantiene razonable el uso de tokens y, al mismo tiempo, admite un catálogo amplio de skills.

Patrón C: la compresión crea linaje

Al resumir contexto antiguo, no sobrescribas la transcripción canónica. En su lugar:

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

Esto te permite depurar y analizar las sesiones en conjunto más adelante.

Patrón D: automodificación con aprobación previa

Si tu agente puede actualizar la memoria o las herramientas, agrega una capa de aprobación previa:

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

Hermes usa este patrón porque el aprendizaje autónomo sin trazabilidad erosiona rápidamente la confianza.

Patrón E: recuperación híbrida como herramienta opcional, no como toda la app

Para buscar en notas y documentos, Hermes documenta modos de qmd que reflejan buenas prácticas de producción:

Expón estas opciones como herramientas que el agente llama cuando las necesita, en lugar de recuperar información por defecto en cada turno.

Patrón F: instrucciones nativas del repositorio

Hermes lee AGENTS.md, .hermes.md y archivos compatibles del árbol de trabajo. Si mantienes instrucciones para agentes junto al código, el agente las incorpora sin una interfaz de administración separada. El descubrimiento progresivo de subdirectorios permite que las reglas de un monorepo aparezcan cuando el agente entra a un paquete.

Cómo sería una lista de verificación para una app inspirada en Hermes

Úsala si estás diseñando tu propio producto de agentes:

[ ] 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

El último punto es donde termina Hermes y empieza tu trabajo de producto. El harness te da la arquitectura; tú sigues siendo responsable de los controles de calidad.

Dónde Hermes no es la respuesta

Seamos explícitos sobre las brechas:

1. RAG documental empresarial: Hermes no reemplaza los pipelines de ingestión, el diseño de estrategias de chunking, los contratos de citas, la recuperación que considera ACL ni los dashboards de evaluación de RAG. Consulta Apps RAG en la práctica.
2. Orquestación duradera de ejecuciones hijas: delegate_task existe, pero las ejecuciones hijas independientes y de larga duración con control externo todavía están surgiendo (según la reseña de harnesses de Arize de junio de 2026). La orquestación compleja de fan-out/fan-in puede necesitar un plano de control externo.
3. Comodidad de un SaaS administrado: Hermes es autohospedado. Tú te encargas de las actualizaciones, los secretos, los respaldos, el enrutamiento de modelos y la prevención de abuso en las interfaces de mensajería.
4. Calidad garantizada del aprendizaje: la revisión en segundo plano puede dejar memorias incorrectas pendientes de aprobación o sobreajustarse a workflows con ruido. Los controles de aprobación ayudan, pero las evaluaciones siguen siendo tu responsabilidad.
5. Razonamiento nativo de grafos: los corpus con muchas relaciones pueden seguir necesitando Graph RAG o un proveedor de memoria basado en grafos de conocimiento en lugar de markdown más FTS5.

Conclusión

Hermes Agent es, en opinión de este autor, uno de los harnesses de agentes de código abierto más completos disponibles hasta julio de 2026 (valoración editorial, no una clasificación basada en benchmarks). No es la app RAG ideal: para quienes construyen productos, es algo más interesante, una arquitectura de referencia para agentes de larga duración que combinan herramientas, sesiones, skills procedimentales y recuperación en capas.

La lección no es «elimina tu base de datos vectorial e instala Hermes». La lección es:

• tratar las sesiones como infraestructura
• separar los hechos siempre activos del historial consultable
• cargar los procedimientos de forma progresiva
• hacer auditable la automodificación
• mantener estables los prefijos del prompt
• incorporar la recuperación de documentos como una herramienta, no como la identidad completa del producto

Si estás creando una app de agentes en lugar de un producto de búsqueda documental, vale la pena estudiar Hermes de cerca, en especial la documentación sobre ensamblaje de prompts, almacenamiento de sesiones, proveedores de memoria y skills.

Fuentes

Fuentes primarias consultadas el 3 de julio de 2026:

1. Nous Research — repositorio de Hermes Agent en GitHub: alcance del proyecto, licencia MIT, descripción general de funciones y cadencia de versiones. github.com/NousResearch/hermes-agent
2. Documentación de Hermes Agent — Architecture: mapa del sistema, subsistemas, principios de diseño y estructura de directorios. hermes-agent.nousresearch.com/docs/developer-guide/architecture
3. Documentación de Hermes Agent — Agent Loop Internals: responsabilidades de AIAgent, modos de API y presupuestos de iteraciones. hermes-agent.nousresearch.com/docs/developer-guide/agent-loop
4. Documentación de Hermes Agent — Prompt Assembly: niveles estable/contexto/volátil, SOUL.md, prioridad de archivos de contexto y límites de caché. hermes-agent.nousresearch.com/docs/developer-guide/prompt-assembly
5. Documentación de Hermes Agent — Persistent Memory: MEMORY.md, USER.md, comparación con la búsqueda de sesiones, aprobación de escritura y revisión en segundo plano. hermes-agent.nousresearch.com/docs/user-guide/features/memory
6. Documentación de Hermes Agent — Session Storage: esquema SQLite, FTS5, linaje y manejo de contención. hermes-agent.nousresearch.com/docs/developer-guide/session-storage
7. Documentación de Hermes Agent — Skills System: divulgación progresiva, /learn, aprobación de escritura y compatibilidad con agentskills.io. hermes-agent.nousresearch.com/docs/user-guide/features/skills
8. Documentación de Hermes Agent — Memory Providers: Honcho, Mem0, Hindsight, OpenViking, Supermemory y otros. hermes-agent.nousresearch.com/docs/user-guide/features/memory-providers
9. Documentación de Hermes Agent — skill opcional qmd: modos de recuperación híbrida local (BM25, vector, rerank) e integración MCP. hermes-agent.nousresearch.com/docs/user-guide/skills/optional/research/research-qmd
10. Documentación de Hermes Agent — skill incluida LLM Wiki: arquitectura wiki de tres capas etiquetada como rag-alternative. hermes-agent.nousresearch.com/docs/user-guide/skills/bundled/research/research-llm-wiki
11. Documentación de Hermes Agent — Context Compression and Caching: compresor doble, recorte, linaje y caché de Anthropic system_and_3. hermes-agent.nousresearch.com/docs/developer-guide/context-compression-and-caching
12. Documentación de Hermes Agent — Tools Runtime: registro frente a exposición de conjuntos de herramientas y flujo de despacho. hermes-agent.nousresearch.com/docs/developer-guide/tools-runtime
13. Documentación de Hermes Agent — CLI Interface: barra de tokens, valores predeterminados de compresión y reanudación de sesiones. hermes-agent.nousresearch.com/docs/user-guide/cli
14. Documentación de OpenClaw — Architecture: plano de control del gateway, clientes/nodos WebSocket. docs.openclaw.ai/concepts/architecture
15. Documentación de OpenClaw — Memory: memoria de workspace en markdown, búsqueda híbrida y backend qmd opcional. docs.openclaw.ai/concepts/memory
16. Repositorio de OpenClaw en GitHub — valores predeterminados de memory-search: tamaños de chunks y fragmentos para memory_search. github.com/openclaw/openclaw/blob/main/src/agents/memory-search.ts
17. Repositorio de OpenClaw en GitHub: gateway, skills y modelo de workspace. github.com/openclaw/openclaw
18. Documentación de CrewAI — Introduction: modelo de Flows + Crews. docs.crewai.com/en/introduction
19. Documentación de Agno — AgentOS: runtime nativo de FastAPI. docs.agno.com
20. Integraciones de n8n: cantidad de integraciones para la matriz comparativa. n8n.io/integrations
21. agentskills.io: formato abierto de skills utilizado por Hermes. agentskills.io

Análisis secundario destacado:

22. Arize AI — Cómo implementa Hermes una arquitectura de harness de agentes de código abierto (1 de junio de 2026): revisión independiente de arquitectura mediante un modelo de harness de nueve partes; útil para entender los límites de los subsistemas y las brechas de orquestación que aún existen. arize.com/blog/how-hermes-implements-open-source-agent-harness-architecture

Artículos internos relacionados:

23. Apps RAG en la práctica
24. Apps de Graph RAG: análisis profundo para producción
25. Workflows autónomos en la práctica
26. Agno/AgentOS + FastAPI frente a LangChain/LangGraph + FastAPI
27. Parte 2: agente de WhatsApp con Cloud API, Chatwoot, Hermes y OpenAI