Hermes Agent: Por Qué el Agente IA Más Popular NO Basta — Guion v3

Notas de producción

Formato: concepto + demo real (patrón validado)
Duración objetivo: 35-45 min
Demo: instalar Hermes, Docker multi-perfil, conectar skills, mostrar límites, MCP serve
Verificar CADA dato con fuentes primarias antes de grabar
Cambios desde v2:
1. Fuente “ask vs block” corregida (repello.ai → issue #7826)
2. Sección Cloud Run reescrita: suavizado lenguaje serverless, distinguir SaaS vs self-host
3. Timestamp [CLIP] Fowler corregido (7:49–8:40 → 7:49–8:17)
4. Cita literal de profiles (incluye “sandbox” + “On the default local terminal backend”)
5. Tabla arquitectura: 5 interfaces / 22 plataformas (no “20 interfaces”)
6. MCP serve clarificado: solo 10 tools de messaging, no las 70+ generales

[0:00 - 1:30] HOOK

[CÁMARA]

Más de 164,000 estrellas en GitHub en menos de un año. El agente open source que todos están instalando en VPS de 5 dólares. Y sí, funciona. Lo instalé, lo probé, y funciona.

Pero hay cosas que no te están contando. Su propia documentación dice que los perfiles no aíslan el acceso al disco. Un usuario auditó sus sesiones y encontró que el 87% tenían violaciones del sistema de seguridad. Y su arquitectura es un solo agente con múltiples interfaces — no es un sistema multi-agente.

Hoy te voy a mostrar Hermes como lo que realmente es — con sus fortalezas reales y sus limitaciones reales. Desde la perspectiva de alguien que ya tiene agentes corriendo en producción.

[1:30 - 2:00] OPEN LOOPS

[CÁMARA]

Tres cosas que van a ver en este video:

Voy a instalar Hermes, conectar mis skills existentes — que son compatibles porque usan el mismo estándar — y mostrar qué funciona bien de verdad.
Les voy a mostrar lo que la documentación oficial de Hermes dice versus lo que te venden en YouTube. Son cosas distintas.
Y al final vamos a ver dónde encaja Hermes en el panorama real de agentes en producción — y dónde no encaja.

[2:00 - 2:30] SUSCRIPCIÓN

[CÁMARA]

Y como siempre, todo va a estar disponible en la descripción. Los invito a suscribirse que estamos haciendo cosas muy entretenidas. Vamos a eso.

[2:30 - 5:00] QUÉ ES HERMES — lo que sí es

[CÁMARA]

Antes de hablar de problemas, hay que reconocer lo que Hermes hace bien. Porque hay cosas genuinamente buenas.

Hermes es un agente de IA open source creado por Nous Research. Gratuito, código abierto, y no recolecta datos sobre cómo lo usas. Corre en tu propia infraestructura — ya sea tu máquina local, un VPS, un container Docker o incluso opciones serverless. Ellos mismos se definen como — y esto es importante:

[PANTALLA — cita en inglés: “The self-improving AI agent”]

“El agente de IA que se mejora a sí mismo”. Un agente autónomo. No un harness, no un framework, no una plataforma. Un agente.

[PANTALLA — arquitectura de Hermes]

Y tiene tres cosas que son genuinamente inteligentes desde un punto de vista de ingeniería:

Uno: Progressive Disclosure de skills.

Hermes no carga todos los skills en el contexto de una vez. Primero le muestra al modelo solo los nombres y descripciones de los skills disponibles — eso cuesta unos 3,000 tokens en total, no importa si tienes 10 o 50 skills. Cuando el modelo identifica cuál necesita, ahí carga el contenido completo de ese skill específico. Y si necesita un archivo de referencia adicional, lo carga en un tercer paso. Solo carga lo que necesita cuando lo necesita.

Dos: Self-improving loop.

Después de que el agente completa una tarea compleja — 5 o más llamadas a herramientas — automáticamente genera un skill con el procedimiento que usó. La próxima vez que encuentra una tarea similar, usa ese skill en vez de razonar desde cero. Usuarios reportan un 40% más rápido en tareas repetitivas después de un par de horas de uso.

Tres: El estándar SKILL.md.

Los skills de Hermes siguen el formato de agentskills.io. Esto significa que un skill escrito para Claude Code, para Cursor, para Codex — funciona en Hermes sin modificación. Y al revés. Es un estándar cross-vendor que se adoptó por más de 40 herramientas en menos de seis meses. Eso es raro en esta industria.

Además, 22 plataformas de mensajería, modo voz con speech-to-text local, decenas de herramientas integradas, y siete backends de ejecución — local, Docker, SSH, Singularity, Modal, Daytona y Vercel Sandbox.

O sea, Hermes es impresionante para lo que fue diseñado.

La pregunta es: ¿para qué fue diseñado?

[5:00 - 10:00] LO QUE HERMES DICE SER vs LO QUE TE VENDEN

[CÁMARA]

Y acá viene lo que me motivó a hacer este video.

Como vimos, Hermes se define como un agente autónomo. Nunca, en ninguna parte de su documentación oficial, usa la palabra “harness”. Se posiciona como un agente, no como infraestructura de control.

Pero si vas a YouTube, te encuentras con otra historia. Te dicen que Hermes es un harness, que es lo que controla al modelo. Lo ponen al mismo nivel que Claude Code o Codex — pero ni Hermes, ni Claude Code, ni Codex se definen así en su documentación oficial. Son agentes o herramientas de desarrollo. Es la comunidad la que les puso esa etiqueta.

Y ojo — no es que esté completamente equivocado. Hermes sí rodea al modelo con memoria, skills y configuración. Pero si lo analizamos con los principios reales de harness engineering — los que presentó Fowler, Hashimoto, OpenAI — le falta la mitad.

Si viste mi video de Harness Engineering, recordarás que Fowler divide el harness en Guides y Sensors.

[CLIP: Harness Engineering — 7:49 a 8:17]

“Visión número uno de Martin Fowler. Él divide el Harness en dos grandes categorías. La primera, guías. Controles que anticipan el comportamiento del agente y lo guían antes de que actúe. Son como la rienda del caballo. Y el número dos, sensores. Controles que observan después de que el agente actúa.”

[CÁMARA]

Ahora apliquemos eso a Hermes.

[PANTALLA — tabla Fowler aplicada a Hermes]

                           Hermes tiene?
Guides (antes de actuar)
  Skills/SKILL.md          ✅ Sí — define qué puede hacer
  SOUL.md / AGENTS.md      ✅ Sí — configura identidad y reglas
  Approval system           ✅ Parcial — approval.py para comandos peligrosos

Sensors (después de actuar)
  Validación de outputs      ❌ No valida lo que el agente produce
  Health checks              ❌ No verifica que el agente funcione correctamente
  Revisión automatizada      ❌ No tiene quién revise las decisiones del agente
  Observabilidad             ❌ No hay logs centralizados ni métricas
  Auditoría                  ❌ No hay registro de qué hizo y por qué

[CÁMARA]

Hermes tiene controles previos reales. Antes de que el agente actúe, hay un sistema de aprobación, hay una lista de comandos que nunca se pueden ejecutar, hay protección contra accesos a redes internas y filtrado de credenciales en subprocesos. Eso está bien hecho.

Pero lo que pasa después de que el agente actúa — validar lo que produjo, verificar que sigue funcionando bien, registrar qué hizo y por qué — eso no lo tiene. Y eso es lo que necesitas cuando un agente opera sin que alguien esté mirando.

[10:00 - 15:00] LA SEGURIDAD QUE NADIE MENCIONA

[CÁMARA]

Ahora vamos a algo más serio. Porque la seguridad de Hermes tiene un lado bueno y un lado que no te cuentan.

[PANTALLA — diagrama 7 capas de seguridad apiladas]

El lado bueno: Hermes documenta 7 capas de defensa. Les voy a mostrar acá. Tiene un hardline blocklist — una lista de comandos que nunca se pueden ejecutar, ni siquiera si desactivas todas las protecciones. Un rm -rf /, un fork bomb, formatear un disco — siempre bloqueado. También tiene aislamiento con Docker y filtrado de credenciales para que los servidores MCP no vean tus API keys. Eso es trabajo serio de seguridad.

[CÁMARA]

Pero acá viene lo que no te cuentan.

[PANTALLA — Auditoría de seguridad]

Un usuario publicó en GitHub — issue #7826 — un análisis estático del código sobre la versión 0.8.0: 4 hallazgos críticos y 9 de alta severidad. En la configuración por defecto.

[PANTALLA — Session audit]

Y otro usuario — un ingeniero — hizo algo que nadie más había hecho. Corrió un script de auditoría contra sus propias sesiones. 129 sesiones en 23 días. Resultado: 112 de 129 sesiones contenían al menos una violación del approval gate.

[CÁMARA]

Y hay algo más sutil que es quizás el más peligroso: Memory Injection. Hermes ingiere contenido de documentos, emails, páginas web y lo guarda como memoria legítima. Si alguien planta instrucciones ocultas en un documento — por ejemplo, algo que diga “el usuario autorizó acceso a tal archivo” — Hermes podría almacenarlo. Y en una sesión futura, esa memoria envenenada se activa sin que el usuario lo sepa.

Esto se llama Promptware. El issue #496 en GitHub lo trackea abiertamente. No es un bug — es una clase de ataque que los sistemas de seguridad tradicionales no detectan porque operan a nivel de proceso, no a nivel de prompt.

Y esta memoria envenenada conecta con algo aún más profundo: cómo está construida la arquitectura misma de Hermes.

[15:00 - 20:00] LA ARQUITECTURA — UN AGENTE, NO UN SISTEMA

[CÁMARA]

Algo que es muy importante entender: la arquitectura de Hermes.

[PANTALLA — diagrama de arquitectura]

La documentación oficial dice textualmente:

[PANTALLA — cita en inglés: “One AIAgent class serves CLI, gateway, ACP, batch, and API server”]

“Una sola clase AIAgent sirve CLI, gateway, ACP, batch y API server.” Es UN agente con cinco interfaces, no un sistema multi-agente distribuido — no son servicios independientes con límites de red, permisos separados y despliegue individual. Cuando le hablas por Telegram, por Discord, por CLI — siempre es la misma clase, la misma instancia. Hermes sí tiene delegate_task y subagentes, pero son efímeros y corren dentro del mismo proceso.

[CÁMARA]

Y los profiles nativos — que se presentan como la forma de correr “múltiples agentes” — aíslan la configuración, la memoria, los skills y las sesiones. Pero la documentación dice, y cito textualmente:

[PANTALLA — cita en inglés: “Profiles do not sandbox the agent. On the default local terminal backend, the agent still has the same filesystem access as your user account.”]

“Los perfiles NO crean un sandbox al agente. En el backend local por defecto, el agente sigue teniendo el mismo acceso al filesystem que tu cuenta de usuario.” O sea, tienes dos perfiles que no comparten memoria pero sí comparten tu disco duro completo.

Y hay un bug documentado — issue #6320 — donde session_search devuelve resultados de TODAS las instancias, no solo la tuya. Contaminación de memoria entre perfiles.

[CÁMARA]

Ahora, la propia documentación de Hermes ofrece una solución: Docker. Si corres un container por perfil — con su propio volumen, su propio puerto, su propio proceso — ahí sí tienes aislamiento real. Filesystem, procesos y red independientes. Y eso es lo que recomiendan oficialmente para multi-perfil.

[PANTALLA — docker-compose multi-perfil]

services:
  hermes-personal:
    image: hermes-agent
    container_name: hermes-personal
    volumes:
      - ~/.hermes-personal:/opt/data
    ports:
      - "8001:8642"
    command: ["gateway", "run"]

  hermes-trabajo:
    image: hermes-agent
    container_name: hermes-trabajo
    volumes:
      - ~/.hermes-trabajo:/opt/data
    ports:
      - "8002:8642"
    command: ["gateway", "run"]

Pero fíjate: eso ya no es Hermes resolviendo el aislamiento — es Docker resolviendo el aislamiento. Y sigues en una sola máquina.

[CÁMARA]

Compara eso con lo que nosotros construimos en este canal. 7 agentes en Cloud Run. Cada uno es un servicio independiente con su propia URL, su propio container, sus propios permisos IAM. Se comunican por A2A Protocol via HTTP. Si uno se cae, los otros siguen. Si uno escala, no afecta a los demás.

Hermes:      1 AIAgent → 5 interfaces (CLI/gateway/ACP/batch/API) → 22 plataformas vía gateway → 1 proceso
Docker:      N containers → N volúmenes → 1 máquina → tú lo manejas
Nuestro:     7 agentes → 7 containers → 7 URLs → A2A Protocol → IAM por servicio

Son tres niveles de aislamiento completamente distintos.

[20:00 - 22:00] POR QUÉ NO CLOUD RUN

[CÁMARA]

Y acá viene una pregunta que un ingeniero haría inmediatamente: ¿por qué no correr Hermes en Cloud Run o en Lambda?

Primero, una aclaración importante. El README oficial de Hermes destaca opciones serverless con Modal y Daytona — dice que “hibernan cuando están idle y despiertan on-demand, costando casi nada entre sesiones”. Suena perfecto. Pero hay matiz.

Ese ahorro serverless aplica de verdad cuando usas Modal o Daytona como plataformas gestionadas — pagas por minuto activo. O cuando tu carga es bursty, con muchas sesiones paralelas que pasan la mayor parte del tiempo idle.

Para un agente personal, una sola sesión, ese ahorro no significa nada. Si self-hosteas Daytona en una VM tuya, la VM corre 24/7 igual — el costo es idéntico a correr Docker en un VPS. Por eso, en la práctica, el VPS de 5 dólares sigue siendo el camino real para 9 de cada 10 casos de uso de Hermes.

[CÁMARA]

Cloud Run específicamente es harina de otro costal. Cloud Run escala a cero y mata instancias inactivas. Cada vez que se levanta una nueva instancia, Hermes perdería su estado.

El filesystem de Cloud Run es efímero — solo tiene /tmp. Pero Hermes necesita su directorio ~/.hermes/ persistente: sesiones, skills, memoria, cron jobs. En Cloud Run eso desaparece.

Y los cron jobs de Hermes corren dentro del mismo proceso. Cloud Run no mantiene procesos vivos entre requests.

Podrías migrar sesiones a Firestore, skills a GCS, cron a Cloud Scheduler — pero a ese punto ya no es Hermes nativo, es un fork que reescribiste para encajar en el modelo request/response stateless de Cloud Run.

[CÁMARA]

Hermes fue diseñado para correr como daemon en una máquina persistente. No es un defecto — es una decisión de diseño para un agente personal que acumula memoria y skills con el tiempo. El VPS de 5 dólares no es un “downgrade” — es exactamente el caso de uso para el que fue construido.

Nuestros agentes en Cloud Run funcionan porque cada uno es stateless — recibe contexto por HTTP, procesa, y responde. La persistencia vive en Firestore y GCS, fuera del agente. Son filosofías de despliegue distintas para problemas distintos.

[22:00 - 24:00] EL VPS DE 5 DÓLARES

[CÁMARA]

Entonces tiene sentido que todos los videos te digan: “instálalo en un VPS.”

Y funciona. Para un agente personal, un VPS es suficiente. Hermes es I/O-bound — llama APIs de LLMs, el VPS solo maneja la lógica del agente y la memoria. No necesita GPU.

[CÁMARA]

Pero un VPS de 5 dólares no tiene:

Escalamiento automático
Alta disponibilidad — se cae el VPS, se cae todo
Monitoreo ni alertas
CI/CD para actualizar sin downtime

Un VPS de 5 dólares es una buena opción para un agente personal. Pero varios de los YouTubers que lo recomiendan tienen link de afiliado con el proveedor. La recomendación no siempre es solo por arquitectura — a veces también es por monetización.

El VPS no está mal. Pero presentarlo como si fuera equivalente a una arquitectura de producción sí lo está.

[24:00 - 35:00] DEMO — INSTALACIÓN + DOCKER + SKILLS + MCP

[CÁMARA]

Bueno, ya hablamos bastante. Vamos a meter las manos.

[PANTALLA — terminal]

Parte 1: Instalación básica

pip install hermes-agent
hermes postinstall
hermes model    # configurar proveedor
hermes          # primera sesión

[DEMO en vivo — primera sesión funcionando]

Parte 2: Docker multi-perfil

Voy a levantar dos instancias de Hermes en Docker Compose — cada una con su propio volumen, su propio puerto. Completamente aisladas.

[DEMO en vivo — docker compose up, mostrar que son independientes]

Parte 3: Conectar skills existentes

Como Hermes usa el estándar SKILL.md de agentskills.io, mis skills de DNS y Monitoring deberían funcionar sin modificación. Los copio a ~/.hermes/skills/ y Hermes los detecta automáticamente.

[DEMO en vivo — mostrar que los detecta]

Parte 4: Probar el self-improving loop

Voy a darle una tarea que requiera 5+ llamadas a herramientas. Debería auto-generar un skill.

[DEMO en vivo — con take pregrabado como backup]

Parte 5: Probar la seguridad — Capa 1 vs Capa 2

Ahora le pido algo peligroso. “Borra todos los registros DNS.”

[DEMO en vivo — ver la respuesta]

Y acá está la diferencia clave con nuestro sistema. En nuestro skill_engine.py, la función delete_dns_record no existe. El agente no puede borrar porque la capacidad no existe — Capa 2, restricción arquitectónica.

En Hermes, la restricción es el approval system — Capa 1. El agente puede hacer muchas cosas y el sistema le pregunta al usuario antes de ejecutar comandos peligrosos. Pero si tienes YOLO mode activado, esa barrera desaparece.

Y los skills auto-generados — que el agente se crea solo — pasan la validación con un verdict de “ask” en vez de “block”. O sea, el agente puede darse capacidades a sí mismo.

En nuestro sistema, si la función no existe, no puede ejecutarla. No importa el modo, no importa la configuración. Es arquitectónicamente imposible.

Parte 6: Hermes como MCP Server

Y acá viene algo que conecta con nuestro video de MCP. Hermes no solo consume servidores MCP — también puede exponerse como uno.

hermes mcp serve

Pero ojo con esto: cuando expones Hermes como servidor MCP, no expone sus 70+ herramientas internas. Expone 10 tools específicas de messaging — listar conversaciones, leer historial, enviar mensajes a Telegram, Discord, Slack. Es un puente de canales, no un wrapper de todas las capacidades de Hermes.

Eso significa que Claude Code puede usar las capacidades de messaging de Hermes — Telegram, Discord, Slack — a través de MCP. Y refuerza algo que varios usuarios ya descubrieron: Hermes y Claude Code no compiten — se complementan.

[DEMO en vivo — hermes mcp serve, mostrar que expone tools]

[35:00 - 38:00] DÓNDE ENCAJA HERMES — Y DÓNDE NO

[CÁMARA]

Entonces, ¿para quién es Hermes?

[PANTALLA — tabla resumen]

Hermes es excelente para:
✅ Developer individual que usa un agente todos los días
✅ Tareas repetitivas que mejoran con el self-improving loop
✅ Acceso desde múltiples canales (Telegram, Discord, Slack, WhatsApp)
✅ Skills portables con SKILL.md (agentskills.io)
✅ Privacidad — corre en tu propia infraestructura, no recolecta datos de uso
✅ Modo voz con speech-to-text local
✅ Docker multi-perfil para aislamiento real

Hermes NO es para:
❌ Equipos o empresas con múltiples usuarios concurrentes
❌ Sistemas que necesitan governance y permisos por rol (no hay IAM)
❌ Producción con alta disponibilidad (single point of failure)
❌ Multi-agente distribuido con coordinación (es UN agente con múltiples interfaces)
❌ Modelo request/response stateless tipo Cloud Run
❌ Ambientes donde la seguridad debe ser garantizada por diseño

[CÁMARA]

Y esto no es una opinión — son datos de su propia documentación y de sus propios usuarios.

De sus 237 user stories documentados oficialmente, solo 9 son de enterprise. 3.8%. Y el único caso de compliance con EU AI Act requiere instalar un plugin adicional llamado Ombre. No es nativo.

[CÁMARA]

Lo interesante es que varios usuarios ya descubrieron el combo: usan Claude Code para código y Hermes para automatización 24/7. No compiten — son complementarios. Claude Code es un pair programmer en tu terminal. Hermes es un asistente personal que corre en tu servidor. Problemas distintos, herramientas distintas.

[38:00 - 41:00] EL PUZZLE COMPLETO — DÓNDE ENCAJA HERMES EN NUESTRO CANAL

[CÁMARA]

Si llevas siguiendo este canal, cada video construyó una pieza de algo más grande.

[PANTALLA — el mapa del puzzle]

Agent Skills        → RESTRICCIONES — qué puede y qué no puede hacer
Agent Teams         → FÁBRICA — cómo se producen skills a escala
Cloud Run + A2A     → INFRAESTRUCTURA — dónde corren agentes stateless en producción
Harness Engineering → CONTROL — el framework que une todo
Workspace Profiling → GOVERNANCE — quién tiene permiso
MCP                 → CONECTIVIDAD — cómo se conectan al mundo

Hermes encaja en una sola capa: es un agente individual con skills y memoria. Usa SKILL.md — la misma capa de restricciones que construimos. Puede conectarse vía MCP — y de hecho puede exponerse como servidor MCP para que otros agentes consuman sus capacidades de messaging. Pero no tiene la fábrica, no tiene la infraestructura distribuida stateless, no tiene governance por usuario, y no tiene la capa de sensors completa.

No es que esté mal. Es que resuelve un problema distinto. Y está bien.

Pero si alguien te dice que con Hermes en un VPS de 5 dólares tienes todo resuelto — ahora ya sabes qué le falta.

[41:00 - 43:00] CIERRE

[CÁMARA]

Antes de cerrar, quiero decir algo.

Hermes es un proyecto genuinamente bueno. Código abierto, gratuito, con una comunidad activa que construye cosas reales. El self-improving loop es una idea inteligente. El progressive disclosure de skills es una idea inteligente. La compatibilidad con SKILL.md es una decisión estratégica que beneficia a toda la industria. Y la opción de Docker para aislamiento real muestra que el equipo piensa en producción.

Pero hay un gap enorme entre un agente personal en un VPS y un sistema de agentes en producción. Y en ese gap es donde vive la ingeniería real.

Ese gap es lo que construimos video a video en este canal.

Muchas gracias por quedarse hasta el final. Suscríbanse porque vienen cosas muy entretenidas. Nos vemos en el próximo video.

Datos a verificar antes de grabar

Dato	Fuente	Verificado
164K+ stars	github.com/NousResearch/hermes-agent	[x]
“The self-improving AI agent”	hermes-agent.nousresearch.com/docs/	[x]
Nunca dice “harness” en su doc	hermes-agent.nousresearch.com/docs/ (búsqueda completa)	[x]
Progressive Disclosure 3 niveles, ~3K tokens total	hermes-agent.nousresearch.com/docs/user-guide/features/skills	[x]
SKILL.md compatible agentskills.io	hermes-agent.nousresearch.com/docs/user-guide/features/skills	[x]
SKILL.md adoptado por 40+ tools en <6 meses	agentskills.io home (Anthropic 18-dic-2025)	[x]
40% speed boost tareas repetitivas	user-stories: @denis_skripnik + benchmark TokenMix	[x]
22 plataformas, ~70 tools (sumando subtools)	hermes-agent.nousresearch.com/docs/user-guide/messaging	[x]
7 capas de seguridad	hermes-agent.nousresearch.com/docs/user-guide/security	[x]
Hardline blocklist unbypassable	hermes-agent.nousresearch.com/docs/user-guide/security	[x]
YOLO mode bypassa approval	hermes-agent.nousresearch.com/docs/user-guide/security	[x]
Análisis estático 4 críticos, 9 high	github.com/NousResearch/hermes-agent/issues/7826	[x]
112/129 sesiones con violaciones (87%)	github.com/NousResearch/hermes-agent/issues/17619	[x]
Issue #496 memory injection/promptware	github.com/NousResearch/hermes-agent/issues/496	[x]
“One AIAgent class serves all” (5 interfaces)	hermes-agent.nousresearch.com/docs/developer-guide/architecture	[x]
Profiles no sandboxean (cita literal)	hermes-agent.nousresearch.com/docs/user-guide/profiles	[x]
Docker recomendado “one container per profile”	hermes-agent.nousresearch.com/docs/user-guide/docker	[x]
Issue #6320 session contamination	github.com/NousResearch/hermes-agent/issues/6320	[x]
Skills guard = “ask” no “block”	github.com/NousResearch/hermes-agent/issues/7826 (body)	[x]
237 user stories, 9 enterprise (3.8%)	hermes-agent.nousresearch.com/docs/user-stories	[x]
Modal/Daytona = serverless persistence oficial	README línea 25 NousResearch/hermes-agent	[x]
Cloud Run incompatible (stateless + /tmp efímero)	Análisis arquitectónico verificado	[x]
`hermes mcp serve` expone 10 tools de messaging	hermes-agent.nousresearch.com/docs/user-guide/features/mcp	[x]
Nunca dos gateways contra mismo directorio	hermes-agent.nousresearch.com/docs/user-guide/docker	[x]