Hermes Agent: qué es, cómo funciona por dentro y dónde encaja
Nota para el equipo
Ficha de referencia de un producto concreto, para no tener que releer su documentación cada vez que sale en una conversación. No es una recomendación de adopción para ningún proyecto, y no compara Hermes con otros productos: la comparación con nuestro intento con deepagents está en la capa de gestión decide si el modelo sirve.
TL;DR
Hermes Agent es un agente de propósito general, open source (MIT), de Nous Research, en versión 0.20.x. Se instala en la máquina del usuario o en un servidor y se accede desde CLI o desde canales de mensajería.
Tres cosas definen su diseño:
- Separa herramientas (primitivas atómicas: ejecutar código, buscar, leer ficheros) de skills (procedimientos documentados en markdown que se apoyan en esas herramientas), y carga las skills por niveles en lugar de meterlas todas en el contexto.
- Se le atribuye fiabilidad alta en la elección de herramienta incluso con modelos open-weight pequeños, y el motivo declarado es de diseño de contexto, no de modelo. Es la parte reutilizable del producto, y la desarrollamos con nuestra propia evidencia en la capa de gestión decide si el modelo sirve.
- Es autónomo por diseño: ejecuta código, se programa tareas, lanza subagentes y genera sus propias skills. Eso define bien dónde encaja y dónde no.
Qué tipo de evidencia es esta
Todo lo de aquí sale de la documentación oficial y del repositorio: no lo hemos instalado ni ejecutado, no hay nada medido por nosotros. Además el proyecto es joven y de ritmo de cambio alto, así que cualquier detalle concreto (lista de backends, nombres de comandos, topes) hay que verificarlo contra la versión del día antes de decidir sobre él.
Skill
En Hermes, una skill no es una herramienta. Es un documento de procedimiento que le dice al modelo cómo resolver una clase de tarea con las herramientas que ya tiene. Nous lo llama memoria procedimental.
Qué es y de dónde viene
Hermes Agent lo publica Nous Research bajo licencia MIT. Se presenta como "el agente que crece contigo": un asistente persistente que aprende del uso, guarda lo aprendido y lo reutiliza en sesiones posteriores.
Conviene no confundirlo con la familia de modelos Hermes del mismo laboratorio. Son cosas distintas: Hermes 4 y sucesores son LLM, Hermes Agent es la aplicación que los orquesta. El agente funciona con modelos de terceros sin problema.
El proyecto cambia deprisa. Cualquier decisión de despliegue debería fijar versión y presupuestar el mantenimiento de las actualizaciones.
Modelo conceptual: herramientas, skills y carga por niveles
Herramientas
Hermes expone más de sesenta herramientas integradas. Son primitivas de bajo nivel: ejecución de código, búsqueda web, navegación, lectura y escritura de ficheros, visión, generación de imagen, texto a voz.
Una de ellas merece mención aparte. La llamada programática a herramientas mediante
execute_code permite que el modelo escriba un fragmento de código que encadena varias
operaciones, en lugar de hacer una llamada por operación. Un flujo de cinco pasos se resuelve
en una sola inferencia, lo que reduce tanto el coste como el número de puntos donde el modelo
puede equivocarse. Es el mismo enfoque que anotamos como
alternativa estructural al tool-calling JSON.
A través de MCP se pueden añadir herramientas externas, con lo que el catálogo no está limitado a lo que trae de fábrica.
Skills
El formato es un fichero SKILL.md con frontmatter YAML y cuerpo en markdown. El frontmatter
exige name, description y version, y admite platforms para restringir a un sistema
operativo concreto, metadata.hermes.tags para categorizar y metadata.hermes.config para
parámetros que el usuario puede ajustar.
El cuerpo sigue una estructura estable: When to Use, Procedure, Pitfalls y Verification. Esa forma no es decorativa: le da al modelo un criterio de activación, una secuencia de pasos, una lista de errores frecuentes y una forma de comprobar que el resultado es correcto.
Divulgación progresiva
El sistema carga las skills en tres niveles, y esto es central para entender su comportamiento:
| Nivel | Llamada | Qué devuelve | Coste aproximado |
|---|---|---|---|
| 0 | skills_list() |
Nombres, descripciones y categorías de todas las skills instaladas | ~3k tokens |
| 1 | skill_view(nombre) |
El SKILL.md completo |
Variable |
| 2 | skill_view(nombre, ruta) |
Un fichero de referencia concreto dentro de la skill | Variable |
El agente solo carga el contenido completo cuando la skill resulta relevante. El contexto contiene un procedimiento en cada momento, no el catálogo entero.
Invocación y bundles
Cada skill instalada queda disponible automáticamente como comando con barra. El usuario
escribe /nombre-skill desde la CLI o desde cualquier canal de mensajería. Se pueden
encadenar hasta cinco en un mismo mensaje, y el análisis se detiene en el primer elemento que
no sea una skill.
Existen además bundles: ficheros YAML que agrupan varias skills bajo un solo comando, útiles cuando ciertas tareas se benefician siempre de la misma combinación.
Skills Hub
Las skills son portables y compartibles. El proyecto mantiene un repositorio público en agentskills.io, compatible con el mismo formato, del que se pueden instalar skills contribuidas por la comunidad. Las implicaciones de eso están en cadena de suministro de skills.
Por qué se le atribuye fiabilidad con modelos pequeños
La observación de partida, según su documentación y los relatos de uso: con modelos open-weight de pocos parámetros (familias gemma, llama y qwen), la elección de herramienta en Hermes es acertada de forma consistente, mientras que un agente convencional falla con frecuencia al elegir entre varias herramientas y se salta pasos del procedimiento.
La explicación no es que Hermes enrute de forma determinista. Son tres mecanismos de diseño de contexto actuando a la vez:
| Mecanismo | Por qué ayuda a un modelo pequeño |
|---|---|
| Pocas herramientas y muy genéricas, con la ejecución de código como comodín | El modelo elige entre un puñado de primitivas, no entre decenas de esquemas |
| La skill trae una secuencia de pasos escrita por una persona | Estos modelos son mejores siguiendo un procedimiento explícito que construyendo uno |
| Divulgación progresiva | En el momento de decidir hay un procedimiento en contexto, no cuarenta; la atención no compite contra material irrelevante |
El argumento general —que con el modelo fijo lo que decide el resultado es la capa de gestión, no el prompt— es el mismo que desarrollamos, ahí sí con fallos medidos por nosotros, en la capa de gestión decide si el modelo sirve. Aquí no lo repetimos.
Ojo con cómo se mide ese acierto
Cuando la skill se invoca con /nombre-skill, la selección no la hace el modelo: la
hace la persona. En pruebas informales es fácil atribuir al agente un acierto que venía
dado por la invocación. Antes de leer "acierta con modelos pequeños" como una propiedad
del agente, conviene saber si el modelo tenía algo que elegir.
Esto es una precaución al interpretar las pruebas de Hermes, no una explicación de nuestros resultados con deepagents: no sabemos si lo que allí tenía que elegir el modelo era equiparable a una skill invocada, así que no damos por supuesto que sea el mismo escenario.
La lección transferible, con esa cautela puesta, es que el cuello de botella de fiabilidad en un agente con modelos modestos está en el diseño del contexto y no en el tamaño del modelo: reducir el número de opciones visibles, sustituir planificación por procedimiento y cargar solo lo relevante produce mejoras grandes sin cambiar de modelo.
Memoria, autonomía y auto-mejora
Memoria persistente y única. Hermes mantiene un hilo de memoria continuo, el mismo desde todos los canales: una conversación empezada en la CLI continúa en Telegram. Incluye búsqueda sobre sesiones anteriores con resumen mediante LLM, lo que permite recuperar contexto antiguo sin cargarlo entero.
Subagentes. El agente puede lanzar subagentes con contexto aislado para trabajos en paralelo, y recoger sus resultados.
Planificador integrado. Trae un cron con el que el usuario programa tareas en lenguaje natural: informes periódicos, resúmenes, vigilancia de algo. Se ejecutan sin nadie delante.
El bucle de auto-mejora. Es la característica de marca: el agente crea skills nuevas a partir de lo que ha tenido que resolver, las refina cuando vuelve a usarlas y acumula conocimiento procedimental por su cuenta. El conjunto de capacidades del sistema cambia con el uso, sin intervención humana. Esa propiedad es la que define su perfil de riesgo, y conviene tenerla presente al leer el apartado de gobernanza.
Dónde encaja esto en la discusión de memoria tipada
Los tres primeros bloques se corresponden con tipos de memoria distintos —MEMORY.md y
USER.md como snapshot semántico, la búsqueda de sesiones como memoria episódica, las
skills como memoria procedimental explícita—, que es justo la distinción que echábamos de
menos en deepagents en
el hueco más profundo: no hay memoria tipada.
Lo que no tiene documentado es una capa de entidades tipo grafo.
Modelos y proveedores
Hermes es agnóstico respecto al modelo. Integra Nous Portal, OpenRouter, OpenAI y endpoints
propios compatibles, y se cambia de modelo con hermes model sin tocar código ni
configuración de la aplicación.
El software es gratuito. Nous comercializa suscripciones (Plus, Super, Ultra) que aportan créditos mensuales para modelos y para las herramientas de web, visión y generación de imagen incluidas en el paquete.
Un endpoint compatible con la API de OpenAI sirve como destino, lo que permite anteponer un gateway propio como LiteLLM Proxy si se quiere control de acceso, enrutado o trazas centralizadas.
Canales de acceso
| Canal | Uso típico | Calidad de la identidad |
|---|---|---|
| CLI | Uso técnico, administración | La del sistema operativo |
| Slack, Discord | Equipos | Buena: identidad verificada por la plataforma, atada al espacio de trabajo |
| Telegram, WhatsApp, Signal | Uso personal, movilidad | Débil: número de teléfono o identificador de chat, sin MFA ni revocación |
| Correo | Notificación, peticiones asíncronas | Débil y suplantable |
Todos comparten el mismo hilo de memoria. Es la característica que hace cómodo el producto y también la que obliga a pensar en aislamiento cuando hay más de un usuario, porque lo que entra en memoria por un canal es legible desde cualquier otro.
La interfaz de terminal es completa: edición multilínea, autocompletado de comandos con barra y navegación de sesiones.
Formas de implantación
Requisitos e instalación
Funciona sobre macOS 12 o superior, Windows 10 y 11, y cualquier distribución de Linux.
En Linux, macOS y WSL2 se instala con un script de una línea. En Windows nativo, una orden de PowerShell instala además las dependencias: uv, Python 3.11, Node.js, ripgrep, ffmpeg y una versión portable de Git Bash. Para Android existe una vía manual documentada sobre Termux.
Tras instalar, hermes abre el chat interactivo y hermes setup lanza la configuración.
Backends de ejecución
Es la decisión de implantación más importante, porque determina dónde se ejecuta el código que escribe el agente y qué puede alcanzar.
| Backend | Dónde ejecuta | Aislamiento | Cuándo tiene sentido |
|---|---|---|---|
| Local | La propia máquina | Ninguno | Uso personal en un equipo de trabajo |
| Docker | Contenedor en la misma máquina o servidor | Bueno, configurable | Despliegue de equipo en infraestructura propia |
| SSH | Máquina remota | El de esa máquina | Trabajo sobre un servidor concreto |
| Singularity | Contenedor sin privilegios | Bueno | Entornos de cálculo científico y HPC |
| Modal | Servicio gestionado en la nube | Alto | Cargas puntuales con necesidad de GPU |
| Daytona | Entornos de desarrollo gestionados | Alto | Espacios de trabajo efímeros |
| Vercel Sandbox | Función aislada en la nube | Alto | Ejecución sin servidor propio |
La documentación del sitio web menciona cinco backends y la del repositorio siete. La lista de la tabla es la del repositorio, que es la más reciente.
Los tres últimos son servicios gestionados de terceros: el código y los datos que se procesen salen de la red propia. Es un factor decisivo cuando hay requisitos de soberanía del dato.
Topologías habituales
Personal. Instalación local en el portátil, backend local, acceso por CLI y por un canal de mensajería personal. Es el caso para el que está diseñado el producto.
Equipo pequeño. Instalación en un servidor propio, backend Docker, acceso por Slack o Discord. Memoria y skills compartidas. Requiere decidir el aislamiento entre usuarios, que no viene resuelto.
Contenedor por sesión. Un contenedor efímero por conversación, sin credenciales dentro y sin salida de red salvo al gateway de modelos. Es la topología que limita mejor el radio de daño, y también la que más trabajo de montaje exige.
Sin servidor. Backends Modal, Daytona o Vercel. Sin infraestructura que mantener, a cambio de sacar la ejecución fuera de la red propia.
Escenarios donde encaja bien
Asistente técnico personal persistente. Un profesional que trabaja con ficheros, repositorios y herramientas de línea de comandos, y quiere que el agente acumule contexto sobre sus proyectos a lo largo de meses. Es el caso de uso nativo.
Automatización de operaciones en un equipo pequeño y de confianza alta. Informes periódicos, vigilancia de sistemas, resúmenes, tareas repetitivas que hoy se hacen a mano. El cron integrado y los canales de mensajería lo hacen cómodo sin construir nada.
Prototipado y descubrimiento de capacidades. Cuando no se sabe qué debería automatizarse, tener un agente general al que la gente le pide cosas durante unas semanas produce un inventario de necesidades reales muy superior al de una sesión de pizarra. Para este uso su falta de gobernanza es irrelevante, porque el resultado esperado no es un sistema en producción sino una lista.
Entornos con modelos locales modestos. Por lo explicado más arriba, es una de las formas más rápidas de conseguir un agente utilizable sin acceso a modelos frontera.
Trabajo intensivo sobre ficheros y herramientas de línea de comandos. Conversión, análisis, generación y manipulación de material local, donde la ejecución de código es exactamente lo que se necesita.
Escenarios donde no encaja
Cuando se exige aprobación humana previa a toda acción. Hermes propone y ejecuta. Se le puede pedir confirmación por convención en el prompt, pero no hay una interrupción estructural del flujo antes de actuar. Un requisito de human-in-the-loop estricto choca de frente con su diseño.
Cuando el comportamiento debe ser un artefacto versionado. Un sistema cuyo repertorio de capacidades cambia solo, sin que exista un cambio registrado y revisable, es difícil de sostener ante una auditoría o ante requisitos de trazabilidad como los del Reglamento de IA europeo. Reproducir una ejecución de hace tres semanas exige saber qué skills existían entonces.
Cuando hay muchos usuarios con permisos distintos. No trae identidad corporativa ni autorización por usuario. La identidad de la mayoría de canales es débil, la memoria es común y las skills son visibles para todos. Construir multiusuario encima es trabajo considerable.
Cuando no se puede admitir ejecución de código arbitrario. Es la base de su funcionamiento. Cualquier persona con acceso al agente tiene, en la práctica, una consola en la máquina donde ejecuta, con las credenciales que haya allí, expresada en lenguaje natural.
Cuando el dato no puede salir de la infraestructura propia y se quiere usar la oferta gestionada. Se puede montar totalmente autoalojado con modelos locales y backend Docker, pero entonces se renuncia a buena parte de lo que hace cómodo el producto.
Seguridad y gobernanza de cualquier despliegue
Aplican con independencia del contexto.
Radio de daño de la ejecución. Lo determina el backend elegido y lo que ese entorno alcance: sistema de ficheros, red y credenciales presentes. Un contenedor efímero, sin secretos en el entorno y con salida de red denegada por defecto reduce el problema a algo manejable. El backend local en un servidor compartido no es un sandbox.
Identidad y autorización. No hay integración con proveedor de identidad corporativo. Si el despliegue es multiusuario, hay que anteponer una capa propia que autentique y traduzca a una identidad canónica, y que las acciones sensibles se ejecuten con la identidad de quien las pide y no con una cuenta de servicio común.
Contaminación de memoria. La memoria única entre canales significa que un canal poco fiable puede escribir contenido que después se lee en un contexto de confianza alta. Es una vía de inyección persistente. Segmentar la memoria por usuario o por ámbito es la mitigación.
Cadena de suministro de skills. Una skill del Hub es un procedimiento que el agente va a seguir. Instalar skills de terceros sin revisión equivale a ejecutar código de terceros. Conviene desactivar la instalación libre o pasar a lista de permitidos. Lo mismo aplica a servidores MCP externos.
Enrutado de modelos. Con OpenRouter o proveedores gestionados, el contenido de las conversaciones sale de la red. Anteponer un gateway propio y fijar proveedor y endpoint es la forma de controlarlo.
Reproducibilidad. Si las skills cambian solas, una ejecución pasada no se reproduce. Versionar el directorio de skills y registrar qué versión estaba activa en cada ejecución es la única forma de recuperar esa propiedad.
Ejecución desatendida. Las tareas programadas y los subagentes se ejecutan sin usuario delante. Necesitan una identidad de servicio propia, con permisos más estrechos que los de cualquier usuario, y un responsable asignado.
Licencia y coste
El código está publicado bajo licencia MIT, lo que permite uso comercial, modificación y redistribución sin restricciones relevantes. No hay coste de licencia.
El coste real de una implantación está en la infraestructura de modelos, en el trabajo de montaje del aislamiento y la identidad si el despliegue es multiusuario, y en el mantenimiento de las actualizaciones de un proyecto que cambia deprisa.
Qué nos llevamos
- La separación herramienta/skill es la idea aprovechable, y no depende de Hermes. Primitivas pocas y genéricas, más procedimientos escritos por personas y cargados solo cuando hacen falta. Eso se puede montar sobre cualquier harness.
- La divulgación progresiva es context engineering barato. Un índice de ~3k tokens y el procedimiento completo solo cuando se elige, en vez del catálogo entero en cada llamada.
- La autonomía y la gobernanza tiran en direcciones opuestas, y aquí el producto elige autonomía. Auto-mejora, cron y subagentes son lo que lo hace cómodo, y también lo que lo hace difícil de auditar. No es un defecto que se arregle configurando.
- El backend de ejecución es la decisión de despliegue. Determina el radio de daño y si el dato sale de la red propia. Lo demás se cambia después; esto, no tanto.
- La memoria única entre canales es una vía de inyección persistente. Es la cara mala de su mejor característica: lo que entra por el canal más débil se lee desde el más fiable.
- Antes de creerse un "funciona bien con modelos pequeños", mirar quién eligió. Con
invocación explícita por
/nombre-skill, parte del acierto no es del modelo.
Anexo: decisiones que hay que fijar antes de desplegarlo (la receta)
- Versión. Fijar una y presupuestar el trabajo de seguir las actualizaciones.
- Backend de ejecución. Elegir de la tabla y escribir qué alcanza ese entorno: ficheros, red y credenciales presentes.
- Modelo y ruta. Proveedor y endpoint fijados; gateway propio delante si se quiere control de acceso o trazas.
- Identidad. Qué canales se habilitan y, si hay más de un usuario, qué capa autentica y traduce a identidad canónica.
- Aislamiento de memoria. Compartida o segmentada por usuario o ámbito, decidido a propósito y no por defecto.
- Política de skills. Instalación libre desde el Hub, lista de permitidos o solo internas. Lo mismo para servidores MCP.
- Versionado de skills. Directorio bajo control de versiones y registro de qué versión estaba activa en cada ejecución, si se necesita reproducibilidad.
- Ejecución desatendida. Identidad de servicio propia para cron y subagentes, con permisos más estrechos, y un responsable asignado.