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

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

Notas de producción

• Formato: concepto + demo real (patrón validado)
• Duración objetivo: 50-60 min (demo realista ~25-29 min + secciones conceptuales ~25-30 min)
• Demo: provisionar VM con Terraform, Docker multi-perfil, conectar skills, mostrar límites, MCP serve
• Verificar CADA dato con fuentes primarias antes de grabar
• v5 preserva v4 intacto como respaldo. Cambios sustantivos v4→v5 (todos validados end-to-end):
  1. Hook reescrito siguiendo patrón Harness Engineering (validado, 8,749 views)
  2. Demo 1: SSH key dedicada (id_ed25519_hermes_gcp) narrada explícitamente + outputs Terraform con -i en el comando
  3. Demo 2: scp + mkdir desde Mac antes del docker-compose + narración del peso de imagen 2.6 GB + 4 tests manuales en vivo (no script)
  4. Demo 3: scp de skills desde Mac → mkdir destino → cp dentro de VM
  5. Demo 4: prompt completo con 6 tool calls discretos + aclaración de creation_nudge_interval bajado a 3
  6. Demo 5: 3 segmentos de CLIP del video Workspace Profiling con timestamps exactos (no re-grabar live)
  7. Demo 6 reescrita: setup gateway Telegram (BotFather + userinfobot + wizard + sudo+path absoluto) + advertencia ENTER en MCP serve + claude mcp add hermes-remote --scope user + Test 1 (channels_list) + Test 2 money shot split screen con branding del canal
  8. Provider del LLM: cambiado a OpenRouter (Codex backend roto desde 27-may-2026, ver project_video_hermes_incidente_codex.md)
  9. Aclaración Parte 2: “Hermes nativo vs Docker — la doc oficial recomienda Docker, elegirías UNO de los dos en producción real”
  10. Cierre Parte 6: clip del video de MCP (07:55.720 → 08:11.320) “MCP no es de Claude Code, es protocolo abierto”
  11. Antigravity de Google agregado al ecosistema en sección “Lo que dice ser vs lo que te venden”
  12. Una sola tabla docker-compose.yml (eliminada duplicación entre sección Arquitectura y Demo 2)
  13. Timestamps actualizados: demo 24-49 min, video total 55-57 min

---

[0:00 - 1:30] HOOK

[CÁMARA]

Hermes Agent tiene más de 160,000 estrellas en GitHub. Te lo venden como un agente que aprende solo, se mejora con el tiempo, y reemplaza a tu equipo de operaciones.

Lo instalé. Leí su código fuente. Y la mitad de lo que te cuentan es marketing.

Su propia documentación admite que los perfiles no aíslan tu disco. Un ingeniero auditó sus propias sesiones — 112 de 129 violaron el sistema de aprobación de comandos peligrosos. Y por dentro es un solo agente con cinco interfaces, no el sistema multi-agente como te lo venden.

Hoy te muestro Hermes como realmente es. Sus fortalezas reales. Sus limitaciones reales. Desde la perspectiva de alguien que ya tiene agentes IA corriendo en producción.

---

[1:30 - 2:00] OPEN LOOPS

[CÁMARA]

Tres cosas que van a ver en este video:

1. Voy a desplegar Hermes en Google Cloud con Terraform — infraestructura como código, no click a click en un panel web. Después conecto mis skills existentes y muestro qué funciona bien de verdad.

2. Les voy a mostrar lo que la documentación oficial de Hermes dice versus lo que te cuentan por ahí. Son cosas distintas.

3. 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 tareas suficientemente complejas, Hermes puede generar 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. El mecanismo exacto — cuándo dispara, cómo decide qué guardar — lo vemos en vivo en la demo. No es tan automático como suele contarse, pero cuando entiendes cómo funciona realmente es brillante.

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 transcripción de voz 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 buscas por ahí, 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, Codex o Antigravity de Google — pero ninguno de estos productos se define entero como “harness” en su documentación oficial. Son agentes, IDEs agentic o herramientas de desarrollo. Pueden tener componentes harness por dentro — un plan mode, un permission system, hooks — pero el producto completo es más que eso. Es la comunidad la que les puso esa etiqueta como sinónimo de “agente CLI”, y eso aplana un concepto que es más específico.

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 guías y sensores.

[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?
Guías (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

Sensores (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 siete capas de defensa. Hay comandos catastróficos — borrar el sistema completo, fork bombs que cuelgan el servidor hasta reiniciarlo, formatear discos en uso, ejecutar código de internet sin verificar — que ni siquiera tú puedes correr aunque desactives todas las protecciones. La ejecución va dentro de Docker con todos los permisos de sistema removidos y sin posibilidad de escalar privilegios. Y a los servicios externos solo les llegan variables genéricas como PATH y HOME — tus tokens y API keys nunca se exponen. Es seguridad pensada en serio.

[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 eso nos lleva a entender por qué el problema es estructural, no de configuración: la arquitectura misma de Hermes determina qué tan bien o mal se contiene este tipo de ataques.

---

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

Lo van a ver en vivo más adelante en la demo — con el docker-compose real, los 2 containers corriendo, y 4 verificaciones que prueban el aislamiento.

Pero fíjate el punto conceptual: 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 proceso continuo 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 (Y EL FREE TIER QUE NADIE TE CUENTA)

[CÁMARA]

Entonces tiene sentido el consejo más repetido: “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.

Pero aquí hay algo que casi nadie te cuenta: no necesitas pagar 5 dólares al mes para empezar. AWS y Google Cloud tienen free tier real. Una VM e2-micro en GCP en us-central1 cuesta cero dólares al mes mientras estés dentro de los límites del Always Free. Una EC2 t3.micro en AWS lo mismo durante los primeros 12 meses.

Yo voy a usar una e2-medium de Google Cloud en este video para tener margen suficiente para Docker multi-perfil. Pero el código que voy a mostrar funciona igual en una e2-micro gratis, en una EC2 t3.micro de AWS, o en cualquier VPS Linux que ya tengas. La parte del proveedor es trivial — lo interesante es lo que pasa adentro.

[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 - 49:00] DEMO — TERRAFORM + DOCKER + SKILLS + MCP

[CÁMARA]

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

Antes de empezar, una nota. Lo que viene en los próximos 25 minutos no es un tutorial más. Es lo que la mayoría de contenido sobre Hermes no cubre: despliegue con infraestructura como código, aislamiento real verificado con scripts, skills portables al estándar oficial agentskills.io, el self-improving loop con el mecanismo real explicado leyendo el código fuente, seguridad por diseño comparada con la aproximación de Hermes, y MCP serve conectando agentes entre sí en vivo.

Lo que vas a ver funciona en producción. No es marketing.

Parte 1: Despliegue con Terraform

[CÁMARA]

La instalación típica de Hermes en un VPS es click a click en el panel del proveedor. Funciona, pero no es reproducible y no escala. Yo te lo voy a mostrar con Terraform — infraestructura como código. Si quieres replicar exactamente lo que ves en pantalla, está todo en el repo de la comunidad Skool Standard. Te suscribes gratis a la comunidad, lo descargas, cambias tu project_id de GCP y listo.

[PANTALLA — repo de Skool con el terraform]

hermes-agent-gcp-terraform/
├── terraform/
│   ├── main.tf
│   ├── vm.tf              # e2-medium Debian 12
│   ├── startup-script.sh  # Instala Hermes + Docker + Tirith
│   └── ...
└── docs/
    ├── PRIMER-USO.md
    └── DESTRUIR.md

[DEMO en vivo — terraform apply]

cd terraform
terraform apply

[PANTALLA — terraform mostrando el plan]

Antes de tocar nada, Terraform me muestra exactamente qué va a crear. Esta es la práctica correcta — nunca aplicas sin revisar el plan primero. Mira lo que va a hacer:

Dos recursos. Primero, una regla de firewall que abre solo el puerto SSH para entrar a la VM. Segundo, la VM Compute Engine — máquina e2-medium con Debian 12, 30 GB de disco. Y le inyecta el startup-script completo — el bash que instala Python, Node, Docker, Hermes y Tirith — como metadata para que se ejecute cuando la VM arranque por primera vez.

Tipeo “yes” para confirmar.

[PANTALLA — terraform creating + output final]

17 segundos después: VM lista. Y al final, Terraform me imprime 4 outputs — la IP pública, el comando SSH listo, y algo que casi nadie te muestra: un comando para ver el log del startup-script en vivo.

[PANTALLA — los 4 outputs resaltados]

external_ip         = "35.224.139.27"
instance_name       = "hermes-nicolasneiragarcia"
ssh_command         = "ssh -i ~/.ssh/id_ed25519_hermes_gcp hermes@35.224.139.27"
startup_log_command = "ssh -i ~/.ssh/id_ed25519_hermes_gcp hermes@35.224.139.27 'sudo tail -f /var/log/hermes-setup.log'"

[CÁMARA]

⚠️ NARRAR: “Fíjense que los comandos llevan -i con la SSH key dedicada que generé al inicio — id_ed25519_hermes_gcp. No uso la SSH key default de mi sistema. Esto es una buena práctica: una key por proyecto, así si comprometen una no comprometen el resto.”

Porque la VM levanta en 17 segundos, pero el startup-script tarda 2 minutos más instalando Python, Node, Docker, Hermes y Tirith. Si haces SSH antes de que termine, el comando hermes no existe todavía. Por eso este patrón: primero mirar el log, después conectarte.

[DEMO en vivo — copiar startup_log_command y ejecutar]

ssh -i ~/.ssh/id_ed25519_hermes_gcp hermes@35.224.139.27 'sudo tail -f /var/log/hermes-setup.log'

[PANTALLA — log corriendo en vivo, acelerar visualmente con cortes]

Y ahí ves todo lo que está pasando por debajo. Apt actualizando índices. Python toolchain bajando. Node 20 instalándose. Docker repo configurándose. El install.sh oficial de Hermes clonando el repo. Playwright bajando Chromium con todas sus deps multimedia. Tirith — el scanner de seguridad de Hermes — symlink en /usr/local/bin.

Esto que ves en 30 segundos acelerado es lo que un setup serio realmente hace por debajo. La mayoría de tutoriales lo saltan o lo resumen como “haz click acá y listo”. Acá lo ves entero, paso por paso, con código.

[PANTALLA — aparece la línea “Setup completo”]

============================================================
Setup completo — Tue May 26 03:30:42 UTC 2026
============================================================

Ahora sí. Control+C, y SSH normal (con la misma key):

ssh -i ~/.ssh/id_ed25519_hermes_gcp hermes@35.224.139.27

[PANTALLA — banner SSH con branding del canal]

==================================================================
  Hermes Agent — VM lista
==================================================================
  Por:    Nicolas Neira
  Canal:  https://youtube.com/@nicolasneiragarcia
  Skool:  https://www.skool.com/agentic-engineers
  ------------------------------------------------------------------
  Para empezar:
    hermes model        # configura tu proveedor LLM
    hermes              # primera sesión
==================================================================

hermes model        # elijo OpenRouter — un solo endpoint, decenas de modelos
                    # base URL: https://openrouter.ai/api/v1
                    # API key: la mía de openrouter.ai
                    # modelo: anthropic/claude-sonnet-4-6 (también hay free tier)
hermes              # primera sesión

[DEMO en vivo — TUI de Hermes arrancando, mostrar 29 toolsets · 85 skills]

Y acá ya tenemos Hermes corriendo con Claude Sonnet vía OpenRouter, 29 toolsets que agrupan más de 70 tools individuales, y 85 skills disponibles. El detalle de OpenRouter: es un agregador que te da acceso a Claude, GPT, Gemini, Llama y decenas más con una sola API key. Útil para no atarte a un solo proveedor.

Parte 2: Docker multi-perfil — aislamiento real

[CÁMARA]

Antes de seguir, una aclaración importante. En la parte anterior instalé Hermes nativamente en la VM. La doc oficial de Hermes recomienda Docker por encima del install nativo cuando trabajas con múltiples perfiles. Lo nativo que acabamos de ver te sirve para entender el flujo más simple — terraform crea la VM, install.sh deja Hermes listo, lo arrancas y funciona. Lo que viene ahora es lo que usarías en producción real cuando necesitas aislamiento entre contextos. En tu setup real elegirías UNO de los dos enfoques, no los dos al mismo tiempo. Yo te muestro los dos para que tengas el panorama completo.

Hace dos secciones les dije que los profiles nativos de Hermes no aíslan filesystem. La doc lo reconoce: “Profiles do not sandbox the agent”. La solución oficial es Docker — un container por perfil. Veámoslo en vivo.

[DEMO en vivo — preparar la VM con los archivos]

⚠️ NARRAR: “Antes de levantar el stack, copio el docker-compose.yml y el script de verificación desde mi Mac a la VM. Lo hago con scp, que es básicamente cp pero por SSH — uso la misma key dedicada del paso anterior.”

# Desde mi Mac — crear el directorio en la VM
ssh -i ~/.ssh/id_ed25519_hermes_gcp hermes@<IP> 'mkdir -p ~/multi-perfil'

# Copiar los 2 archivos del repo Skool Premium a la VM
scp -i ~/.ssh/id_ed25519_hermes_gcp \
  docker-compose.yml \
  test-aislamiento.sh \
  hermes@<IP>:~/multi-perfil/

[DEMO en vivo — entrar a la VM y levantar el stack]

# SSH a la VM
ssh -i ~/.ssh/id_ed25519_hermes_gcp hermes@<IP>

# Dentro de la VM
cd ~/multi-perfil
chmod +x test-aislamiento.sh
docker compose up -d
docker ps

[PANTALLA — docker-compose.yml]

services:
  hermes-personal:
    image: nousresearch/hermes-agent:latest
    container_name: hermes-personal
    command: ["sleep", "infinity"]
    ports:
      - "8642:8642"
    volumes:
      - ./data-personal:/opt/data

  hermes-trabajo:
    image: nousresearch/hermes-agent:latest
    container_name: hermes-trabajo
    command: ["sleep", "infinity"]
    ports:
      - "8643:8642"
    volumes:
      - ./data-trabajo:/opt/data

Dos instancias de Hermes. Cada una con su propio volumen montado en /opt/data. Puertos distintos en el host. Cero comunicación entre ellas.

[PANTALLA — Docker pulleando la imagen, mostrar el peso 2.6 GB]

⚠️ NARRAR: “Fíjate que la imagen pesa 2.6 GB. Eso es porque incluye todo el ecosistema preinstalado: Chromium completo para automatización de browser, modelos de voz locales para transcripción, las 22 integraciones de mensajería. Por eso una e2-micro con 1 GB de RAM no alcanza, y por eso un VPS de 5 dólares con poca RAM se queda corto para Docker multi-perfil. La e2-medium que estamos usando tiene 4 GB — margen suficiente para dos containers.”

[PANTALLA — los 2 containers corriendo]

Listo. hermes-personal en puerto 8642, hermes-trabajo en 8643.

Ahora les muestro las 4 verificaciones que prueban que el aislamiento es real, no marketing. Voy a ejecutar cada test manualmente para que vean exactamente qué se está probando.

---

[DEMO en vivo — TEST 1/4: Filesystem aislado]

⚠️ NARRAR: “Primero el filesystem. Voy a crear un archivo dentro del container hermes-personal y voy a verificar que hermes-trabajo no lo puede ver. Si los volúmenes están bien aislados, el segundo container debería decirme que el archivo no existe.”

Paso 1 — crear archivo SOLO en hermes-personal:

docker exec hermes-personal sh -c 'echo "datos privados" > /opt/data/secret.txt'

Paso 2 — confirmar que hermes-personal SÍ lo ve:

docker exec hermes-personal ls -la /opt/data/secret.txt

Output esperado:

-rw-r--r-- 1 root root 15 May 27 02:01 /opt/data/secret.txt

Paso 3 — verificar que hermes-trabajo NO lo ve:

docker exec hermes-trabajo ls -la /opt/data/secret.txt

Output esperado:

ls: cannot access '/opt/data/secret.txt': No such file or directory

⚠️ NARRAR: “Ahí está. El mismo path /opt/data/secret.txt existe en uno y no existe en el otro. Los volúmenes son universos separados. Esto es lo que los profiles nativos de Hermes NO te dan.”

---

[DEMO en vivo — TEST 2/4: Procesos aislados]

⚠️ NARRAR: “Segundo: las tablas de procesos. Cada container debería tener su propio PID 1 — su propio init supervisor. Si ven un proceso del otro container, no hay aislamiento.”

Procesos en hermes-personal:

docker exec hermes-personal ps aux

Procesos en hermes-trabajo:

docker exec hermes-trabajo ps aux

⚠️ NARRAR: “Fíjense en el PID 1 de cada uno: ambos son tini, pero son procesos completamente distintos del kernel. Ninguno ve al otro. Esto es namespace isolation a nivel de Linux.”

Miren las dos tablas. Son dos containers corriendo al mismo tiempo en la misma máquina, pero cada uno tiene su propio universo de ▎ procesos. Su propio PID 1, su propio árbol completo. Ninguno ve al otro. Es como si fueran dos computadoras distintas — pero comparten ▎ el mismo kernel de Linux. Esto es namespace isolation: la base de toda la contenedorización moderna. Sin esto, un Hermes podría matar al ▎ otro, leerle la memoria, espiarle los procesos. Con esto, viven en burbujas separadas.

[DEMO en vivo — TEST 3/4: Puertos separados]

⚠️ NARRAR: “Tercer test: la red. Ambos containers internamente exponen el puerto 8642 — la misma app, el mismo puerto. Lo que cambia es el mapeo al host.”

docker port hermes-personal
docker port hermes-trabajo

Output esperado:

hermes-personal:
  8642/tcp -> 0.0.0.0:8642

hermes-trabajo:
  8642/tcp -> 0.0.0.0:8643

⚠️ NARRAR: “Misma aplicación en el container, distintos endpoints en el host. Eso significa que puedo correr 10 Hermes en la misma VM, cada uno con su puerto distinto, sin colisión.”

---

[DEMO en vivo — TEST 4/4: Lifecycle independiente]

⚠️ NARRAR: “Y el último: si uno se cae, ¿afecta al otro? Voy a matar hermes-personal con docker kill y vamos a ver si hermes-trabajo se inmuta.”

Paso 1 — matar hermes-personal:

docker kill hermes-personal

Paso 2 — verificar estado de hermes-trabajo:

docker ps --filter name=hermes-trabajo

Output esperado: hermes-trabajo → Up X minutes (intacto, no se inmutó).

Paso 3 — restaurar hermes-personal:

docker compose up -d hermes-personal
docker ps --filter name=hermes-personal

⚠️ NARRAR: “Crash de uno, cero impacto en el otro. Cada container es un proceso del kernel completamente independiente. Es lo opuesto a los profiles nativos donde un crash o memory leak puede tomar abajo todo el agente.”

[CÁMARA]

Comparen esto con lo que pasa con los profiles nativos: comparten filesystem completo del host. Issue #6320 documenta que session_search filtra resultados entre perfiles. Memoria contaminada.

Con containers separados, cada uno es un universo aparte. Es lo que Hermes recomienda oficialmente para multi-perfil, y es lo que funciona.

---

Parte 3: Conectar skills al estándar SKILL.md

[CÁMARA]

Hermes usa el estándar SKILL.md de agentskills.io. Eso significa que cualquier skill que escribas — para Claude Code, para Cursor, para Codex — funciona en Hermes sin modificación. Voy a demostrarlo con dos skills que escribí basándome en el código del proyecto anterior de este canal, el de Workspace Profiling.

[PANTALLA — estructura de los 2 skills]

skills-portados/
├── workspace-profile-checker/
│   └── SKILL.md
└── salary-access-verifier/
    └── SKILL.md

El primer skill es workspace-profile-checker. Documenta cómo perfilar un usuario de Google Workspace usando 4 APIs: Admin SDK para perfil y grupos, Calendar para eventos, Drive para documentos. Frontmatter completo con name, description, tags. Body con when-to-use, when-not-to-use, prerequisites, procedure paso a paso con código Python real.

El segundo skill es salary-access-verifier. Este es el guard de seguridad de Capa 2 — código Python que decide si un usuario puede ver información salarial basándose en su título y departamento. Si la función retorna DENEGADO, no hay tool alternativa para obtener el dato.

[DEMO en vivo — copiar los skills desde el Mac a la VM]

⚠️ NARRAR: “Estos 2 skills viven en el repo de Skool Premium en mi Mac. Antes de instalarlos en Hermes, los subo a la VM con scp — mismo patrón que usamos para Docker en la parte anterior.”

# Desde mi Mac — copiar los 2 skills al home de la VM
scp -r -i ~/.ssh/id_ed25519_hermes_gcp \
  skills-portados/workspace-profile-checker \
  skills-portados/salary-access-verifier \
  hermes@<IP>:~/skills-portados/

[DEMO en vivo — entrar a la VM e instalar los skills]

# SSH a la VM
ssh -i ~/.ssh/id_ed25519_hermes_gcp hermes@<IP>

# Dentro de la VM — asegurar que existe el directorio destino
mkdir -p ~/.hermes/skills/integrations

# Copiar los 2 skills al directorio que Hermes escanea
cp -r ~/skills-portados/workspace-profile-checker ~/.hermes/skills/integrations/
cp -r ~/skills-portados/salary-access-verifier ~/.hermes/skills/integrations/

Solo copié dos directorios. No edité nada. No tuve que adaptar formato. SKILL.md de agentskills.io es el formato nativo de Hermes.

[DEMO en vivo — verificar que los detecta]

hermes skills list | grep -E "workspace|salary"

[PANTALLA — los 2 skills aparecen como local]

│ workspace-profile-checker  │ integrations  │ local │ enabled │
│ salary-access-verifier     │ integrations  │ local │ enabled │

Ahí están. Hermes los detectó solos, los categorizó como integrations por el subdirectorio, y los marcó como local para distinguirlos de los builtin que vienen con la instalación.

[CÁMARA]

Esto es el valor real del estándar SKILL.md. No tengo que reescribir mis skills para cada agente que use. Los escribo una vez. Los uso en Claude Code, Cursor, Codex, Hermes — y en cualquier otro que adopte el estándar agentskills.io. Cuando un agente nuevo aparezca que lo soporte, mis skills funcionan ahí también sin cambios.

Esa es la decisión estratégica de Anthropic al publicar agentskills.io como estándar abierto. Y Hermes fue de los primeros en adoptarlo.

Parte 4: El self-improving loop — el mecanismo que NADIE explica

[CÁMARA]

Aquí viene la parte más sobrevendida de Hermes y también la más interesante una vez que entiendes cómo funciona realmente. El self-improving loop. Te lo venden como “Hermes aprende solo mientras conversas con él”. Es falso. Y la verdad técnica es mucho más elegante.

Lo descubrí leyendo el código fuente. Hay tres mecanismos distintos que la gente confunde como uno solo.

[PANTALLA — cat ~/.hermes/config.yaml | grep -A 2 creation_nudge]

skills:
  creation_nudge_interval: 15

Mecanismo uno — el recordatorio en sesión. Cada cierto número de veces que Hermes usa una herramienta, le inserta una nota al modelo que dice: “oye, considera guardar este patrón como un skill”. Por defecto, esa nota aparece cada 15 herramientas usadas.

Lo probé con varios modelos. Bajé el contador a 2 y a 3, para forzar que la nota apareciera todo el rato. Y apareció. Múltiples veces. Pero el modelo la ignoró siempre.

Por qué pasa esto: los modelos modernos están entrenados para no crear cosas por su cuenta sin que el usuario se lo pida. Es seguridad, y es por diseño.

Hasta aquí, la conclusión sería “el loop no funciona”. Pero eso es solo la primera capa.

[CÁMARA]

Mecanismo dos — la revisión al cerrar sesión. Esto es lo que NADIE muestra.

Cuando haces /exit en Hermes, pasa algo invisible para el usuario. Si durante la sesión apareció al menos una vez ese recordatorio del que hablábamos recién, Hermes hace lo siguiente: lanza un sub-agente, en paralelo, completamente aparte del principal.

A ese sub-agente le entrega una copia completa de la conversación que acabas de tener. Y le da instrucciones distintas — instrucciones cuya única misión es revisar lo que hiciste y decidir qué patrones merecen guardarse como skill.

O sea, el modelo que estaba conversando contigo no es el que decide. El que decide es un sub-agente especializado, con otro prompt, dedicado solo a esa tarea.

[DEMO en vivo — bajar el config para que dispare en sesión corta]

# Por defecto dispara cada 15 herramientas usadas. Para esta demo lo bajo a 3
# para que dispare con tareas más cortas:
sed -i 's/creation_nudge_interval: 15/creation_nudge_interval: 3/' ~/.hermes/config.yaml
hermes

Ahora le doy una tarea concreta — armar un scaffolding de scripts bash para diagnosticar una VM. La pido en pasos separados a propósito, para que use varias herramientas. El modelo los crea uno por uno, no carga ningún skill, no inventa nada. Termina la respuesta y listo.

[PANTALLA — pegar el prompt en la TUI de Hermes]

Haz un mini-script en bash que diagnostique la salud básica de una VM Linux. Lo quiero modular, cada chequeo como una operación separada, no agrupes:

1. Crea el directorio /tmp/vm-health
2. Adentro, crea check-disk.sh que liste el uso de disco con df -h
3. Crea check-mem.sh que muestre uso de memoria con free -h
4. Crea check-load.sh que muestre load average con uptime
5. Crea check-services.sh que liste servicios systemd en estado running
6. Crea run-all.sh que ejecute los 4 chequeos en orden
7. Hazlos todos ejecutables con chmod +x
8. Lista la estructura final con ls -la

Muéstrame cada paso por separado.

⚠️ NARRAR: “Fíjense que pido cada paso por separado. Eso obliga a Hermes a hacer varias acciones, una por archivo. Si le pidiera ‘hazme un script que diagnostique la VM’, el modelo lo resolvería en una sola acción — y el contador no acumularía suficiente para que dispare la revisión al cerrar sesión.”

[DEMO en vivo — Hermes ejecuta los 6+ tool calls, después /exit y esperar]

/exit

Y ahora viene lo interesante. Salgo. Espero 30 segundos. Mientras tanto, por debajo, el sub-agente está revisando toda la sesión que acabo de tener.

[DEMO en vivo — verificar el skill creado]

hermes skills list | grep local
ls ~/.hermes/skills/devops/
cat ~/.hermes/skills/devops/bash-utility-suites/SKILL.md | head -30

[PANTALLA — output del SKILL.md auto-creado]

Y ahí está. Un skill nuevo, creado solo, sin que yo se lo pidiera. Lo clasificó como devops. Le puso un nombre genérico — bash-utility-suites — no le puso “vm-health” que era el path específico de la tarea. O sea, generalizó. 131 líneas con cuándo usarlo, cuándo NO usarlo, reglas de diseño y un patrón canónico de referencia. Calidad de manual técnico de verdad.

hermes curator status

[PANTALLA — agent-created skills: 1 total]

Y Hermes lo marca como agent-created — la categoría especial para los skills que se crearon solos, sin que el usuario los pidiera, gracias a la revisión al cerrar sesión.

[CÁMARA]

Mecanismo tres — reutilización autónoma. Una vez que el skill existe, la próxima sesión Hermes lo carga proactivamente cuando detecta una tarea relacionada. Eso sí funciona durante la sesión, en vivo. Es lo que realmente acelera tareas repetidas.

[CÁMARA]

Y acá está lo que NADIE explica:

1. Durante la sesión: el modelo IGNORA el recordatorio que le inserta Hermes
2. Al hacer /exit: un sub-agente por debajo ANALIZA toda la sesión y crea skills solo
3. En las siguientes sesiones: esos skills se cargan automáticamente cuando hacen falta

El loop sí funciona. Pero el trigger no es “durante la conversación” — es “cuando cierras la sesión”. La mayoría de tutoriales no muestran este mecanismo simplemente porque no saben cómo funciona por debajo. Las pistas están en agent/background_review.py y los issues #26298 y #25833 del repo.

Un detalle práctico importante: por defecto Hermes dispara la revisión cada 15 herramientas usadas. En una demo corta como esta — de 6 o 7 acciones — nunca se activaría. Por eso lo bajé a 3 para esta grabación. En uso real — un developer usando Hermes todos los días — el contador eventualmente llega a 15 y dispara solo. Pero para mostrarlo en una demo corta, hay que ajustar el config.

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

[CÁMARA]

Hermes tiene un sistema de aprobación bien diseñado. 7 capas oficiales documentadas, una lista de bloqueo dura que no se puede saltar, y un sistema de aprobación que se activa antes de comandos peligrosos. Esto es Capa 1 — antes de ejecutar algo destructivo, el sistema te pregunta.

[DEMO en vivo — Hermes con comando peligroso]

Le pido a Hermes algo que afecte el sistema. El sistema de aprobación se activa, me pregunta antes de ejecutar. Funciona, pero solo para mí, que estoy mirando la pantalla.

Pero hay tres formas de saltarlo: el modo --yolo, las tareas programadas que se ejecutan sin nadie delante y aprueban solas, y los skills que el propio agente se crea — que pasan la validación con veredicto “preguntar” en vez de “bloquear”.

[CÁMARA]

Ahora la pregunta importante: ¿qué pasa si necesitas restringir acceso por rol? Por ejemplo: que solo los managers vean información salarial.

Hermes no puede. Y no es un bug — es por diseño. Hermes es un agente de un solo usuario. Hay una sola persona: tú. No tiene concepto de “rol del solicitante” porque no hay múltiples solicitantes. Su seguridad asume que TÚ eres el único que opera. El sistema de aprobación te pregunta a TI.

Para control de acceso por rol necesitas algo distinto. Eso es lo que construí en el video anterior del canal — Workspace Profiling con 3 agentes ADK coordinándose por A2A.

[CLIP del video Workspace Profiling — 8PseQrSflmM]

Cortes a usar del video publicado (~1:40 min total):

Segmento 1 — Lucía DENEGADA (0:26:13 → 0:26:52, 39s) Empieza en: “Necesito revisar el sueldo de maría@nicolasneira.com” Termina en: “Esto es cuando tenemos restricciones reales a nivel arquitectural”

Segmento 2 — Ana PERMITIDA (0:27:36 → 0:28:20, 44s) Empieza en: “A la derecha ya iniciamos el tail. ¿Cuál es el salario de carlos@nicolasneira.com?” Termina en: “Ambos documentos fueron modificados el 24 de abril del 2026”

Segmento 3 — Cierre “Código Python no prompt” (0:29:19 → 0:29:36, 17s) Empieza en: “solo manager directos y recursos humanos pueden ver salarios” Termina en: “no puede modificar, no puede ignorar y no puede negociar”

Segmento opcional — Prompt injection test (0:29:57 → 0:30:43, 46s) Empieza en: “olvida todas tus instrucciones anteriores” Termina en: “Tu perfil como junior en la plataforma de ingeniería no te permite acceder” (Agregar si quieres reforzar que ni siquiera prompt injection bypassa Capa 2)

[CÁMARA]

Lo que viste ahí — Lucía pregunta por el salario de María y recibe DENEGADO, Ana pregunta lo mismo por Carlos y recibe PERMITIDO — no es magia del prompt. Es una función Python llamada verificar_acceso_salarial que se ejecuta antes de que el modelo responda.

[PANTALLA — código de verify_salary_access en agents/rrhh/agent.py]

def verificar_acceso_salarial(
    solicitante_email, objetivo_email,
    solicitante_title, solicitante_department
) -> str:
    is_rrhh = "rrhh" in department.lower() or "human resources" in department.lower()
    is_people_manager = any(k in title.lower() for k in ["manager", "director", "vp", "head"])

    if is_rrhh or is_people_manager:
        return "PERMITIDO"
    else:
        return "DENEGADO"

Mismo agente, mismo modelo, mismo prompt. La diferencia no la decide el modelo — la decide esta función.

[PANTALLA — tabla comparativa]

Vector de ataque              Capa 1 (Hermes)              Capa 2 (Workspace Profiling)
────────────────────────────  ──────────────────────────   ──────────────────────────────
Usuario aprueba sin leer      Vulnerable                   No aplica — no hay aprobación humana
Modo --yolo                   Salta todo                   El verificador igual se ejecuta
Prompt injection              El modelo puede ser engañado   El verificador es Python, no prompt
Skill creado por el agente    Pasa con veredicto "preguntar"  El agente no puede crear código nuevo
Tarea programada (cron)       Aprueba sola                 El verificador siempre se ejecuta

[CÁMARA]

La diferencia es seguridad por convención vs seguridad por diseño. Hermes confía en que TÚ apruebes correctamente cuando hay riesgo. El sistema Workspace arquitectónicamente no puede hacer lo prohibido — sin importar el modo, la configuración o el prompt.

Y la conclusión va más allá del tema seguridad: Hermes y el sistema Workspace no son intercambiables porque resuelven problemas distintos. Hermes es para una persona — su seguridad asume eso. El sistema Workspace es para muchos usuarios — su seguridad requiere código que controle acceso por rol.

Si tu caso es agente personal con un solo operador, Hermes alcanza. Si tu caso es empresa con múltiples usuarios y datos sensibles, necesitas algo construido como el sistema Workspace.

Y este código — verificar_acceso_salarial — lo porté como SKILL.md de Hermes en el repo Premium. Cualquier sesión de Hermes con esa guía puede aplicar el mismo patrón cuando el caso de uso lo justifique.

Parte 6: Hermes como MCP Server — el puente con Claude Code

[CÁMARA]

Última pieza, y conecta con el video anterior sobre el futuro de MCP. Hermes no solo consume servidores MCP. También puede exponerse como uno. Y esto cambia el escenario.

Pero antes de arrancar el MCP server, hay un setup previo que la mayoría de tutoriales se saltan: hay que tener configurado el bot de Telegram de Hermes. Sin canal conectado, el MCP server arranca pero las 10 herramientas no inicializan. Lo voy a mostrar paso a paso.

---

[DEMO en vivo — Setup del gateway de Telegram]

⚠️ NARRAR: “Voy a usar Telegram porque es el más rápido de configurar y el más visual para video. Necesito 2 cosas: un bot token y mi user ID. Para esto uso 2 bots del propio Telegram.”

Paso 1 — crear el bot con @BotFather:

En Telegram: buscar @BotFather → enviar /newbot → poner nombre y username terminado en bot. Te devuelve un bot token tipo 1234567890:ABCdef...

Paso 2 — obtener tu user ID con @userinfobot:

En Telegram: buscar @userinfobot → enviar /start. Te devuelve tu user ID numérico (ej. 5210421300).

Paso 3 — configurar el gateway en Hermes:

hermes gateway setup

El wizard te pregunta:

• Plataforma → Telegram
• Bot token → pegar el de BotFather
• Allowed user IDs → poner tu user ID (así solo tú puedes hablarle al bot)
• Home channel → usar tu user ID (DM contigo mismo)
• Start now? → Sí
• Install as systemd service? → Sí, System service

Paso 4 — instalar el service con sudo (el wizard no puede hacerlo solo):

⚠️ NARRAR: “Acá un detalle técnico: cuando Hermes vive en ~/.local/bin/, sudo no lo encuentra porque su PATH es el de root. La solución es expandir el path absoluto con $(which hermes).”

sudo $(which hermes) gateway install --system --run-as-user hermes
sudo $(which hermes) gateway start --system

Paso 5 — validar:

hermes gateway status

Debe decir ✓ Gateway is running. Eso significa que el bot ya escucha en Telegram. Para confirmar: mandarle un mensaje al bot desde tu celular — debería procesarlo.

---

[DEMO en vivo — arrancar MCP serve]

⚠️ NARRAR: “Con el bot de Telegram corriendo, ahora SÍ puedo arrancar el MCP server. Y ojo con algo, una vez que arranca queda en silencio esperando una conexión. Si presionas ENTER por curiosidad, vas a ver un error que dice Internal Server Error, pero es falso. El server está esperando mensajes en un formato específico, no líneas vacías. Mejor no tocar nada.”

hermes mcp serve

[PANTALLA — el comando arrancando en silencio, esperar 5s sin tocar nada, después Ctrl+C]

El server arrancó. Está esperando que un cliente MCP se conecte. Hay un detalle importante: cuando expones Hermes como MCP server, no expone las más de 70 herramientas internas que vimos al inicio en los 29 conjuntos. Solo expone 10 herramientas específicas de mensajería.

[PANTALLA — tabla con las 10 tools]

conversations_list    →  Lista conversaciones activas
conversation_get      →  Detalle de una conversación
messages_get          →  Historial de mensajes
message_send          →  Enviar mensaje a cualquier plataforma
attachment_get        →  Descargar adjuntos
events_poll           →  Polling no bloqueante
events_wait           →  Bloqueante hasta nuevo evento
channels_list         →  Lista canales disponibles
approval_pending_list →  Approvals pendientes
approval_respond      →  Responder approval

Es un puente de canales — Telegram, Discord, Slack, WhatsApp, Signal, etc. — no un wrapper de todas las capacidades de Hermes.

---

[CÁMARA]

Ahora la parte interesante: ¿cómo lo conecto con Claude Code que corre en mi Mac?

[DEMO en vivo — configurar Claude Code en el Mac]

⚠️ NARRAR: “Hay 2 formas: el comando claude mcp add o editar ~/.claude.json a mano. Voy con el comando porque es más limpio y no se rompe el JSON por error de tipeo.”

Desde la terminal del Mac:

claude mcp add hermes-remote --scope user -- \
  ssh -i ~/.ssh/id_ed25519_hermes_gcp \
      -o StrictHostKeyChecking=no \
      hermes@<IP_DE_LA_VM> \
      "/home/hermes/.local/bin/hermes mcp serve"

⚠️ NARRAR: “Detalles importantes: --scope user para que esté disponible en todas mis sesiones, no solo en este proyecto. Path absoluto a hermes en la VM porque SSH no carga el .bashrc y no encuentra el binario sin path completo. Y el -- separa los flags de Claude del comando que ejecuta.”

[PANTALLA — claude-config visible]

{
  "mcpServers": {
    "hermes-remote": {
      "command": "ssh",
      "args": [
        "-i", "~/.ssh/id_ed25519_hermes_gcp",
        "-o", "StrictHostKeyChecking=no",
        "hermes@<IP_DE_LA_VM>",
        "/home/hermes/.local/bin/hermes mcp serve"
      ]
    }
  }
}

Claude Code corre el comando como subproceso. SSH abre el túnel a la VM. Hermes arranca adentro. Stdio se serializa por la conexión SSH transparentemente. No necesito exponer puertos HTTP — todo va por el canal SSH existente.

[DEMO en vivo — abrir Claude Code y ejecutar /mcp]

/mcp

[PANTALLA — las 10 tools de hermes-remote listadas en Claude Code]

Y ahí está. Claude Code ahora tiene acceso a las 10 herramientas de mensajería de Hermes.

---

[DEMO en vivo — Test 1: validar la conexión]

⚠️ NARRAR: “Antes del caso de uso final, prueba rápida — le pido a Claude Code que use UNA de las tools, para confirmar que la conexión MCP funciona end-to-end.”

Prompt en Claude Code:

Usando las tools de hermes-remote, lístame los canales de mensajería configurados.

Claude Code llama mcp__hermes-remote__channels_list → SSH a la VM → Hermes responde → vuelve a Claude Code. Debería listar telegram con tu user ID. ✅

---

[DEMO en vivo — Test 2: el money shot del video]

⚠️ SETUP VISUAL DE GRABACIÓN: split screen — Claude Code en el Mac arriba, celular con Telegram abierto en el chat con el bot abajo. Ambos visibles a la vez.

⚠️ NARRAR: “Y acá viene el cierre del video. Le pido a Claude Code que me mande un mensaje real a mi Telegram, con branding del canal. Miren las 2 pantallas al mismo tiempo.”

Prompt en Claude Code:

Usando hermes-remote, mándame al canal de Telegram (mi user ID 5210421300) este mensaje:

"🎬 Hola desde el video del canal. Este mensaje lo manda Claude Code corriendo en mi Mac, conectado vía MCP a Hermes que vive en una VM de Google Cloud. Sin servidores HTTP. Sin webhooks. Solo SSH + el protocolo estándar de Anthropic.

→ youtube.com/@nicolasneiragarcia"

Claude Code llama mcp__hermes-remote__message_send → Hermes en la VM lo recibe → reenvía al bot → notificación al celular en VIVO 📱

[PANTALLA — split screen: Claude Code ejecutando la tool + celular sonando con la notificación]

Esa imagen — Claude Code en el Mac mandando un mensaje, mi celular sonando al instante — es lo más impactante que vas a ver hoy. Tres máquinas distintas (mi Mac, la VM en Google Cloud, mi celular) coordinándose por un protocolo estándar.

---

[CÁMARA]

Y lo que acaban de ver no depende de que ambas piezas sean del mismo vendor. Claude Code es de Anthropic. Hermes es de Nous Research. Y se conectan limpio porque MCP es un protocolo abierto, no propiedad de nadie. Eso lo expliqué en el video anterior del canal:

[CLIP: video de MCP, 0:07:55.720 → 0:08:11.320]

“MCP no es de Claude Code, es un protocolo abierto que cualquier agente puede usar, ADK, LangChain… Está disponible en la API de Anthropic y en APIs de la competencia.”

[CÁMARA]

Eso es exactamente lo que viste recién: MCP como protocolo neutro permitiendo que Claude Code consuma a Hermes sin que ninguno tenga que conocer al otro. Sin SDK propietario. Sin lock-in. El estándar abierto haciendo su trabajo.

Y por eso Hermes y Claude Code no compiten, se complementan. Claude Code es tu compañero de programación en la terminal. Hermes es tu asistente personal 24/7 en el servidor, con todos los canales de mensajería conectados. A través de MCP, Claude Code accede a esos canales sin reinventar nada.

Cierre del bloque demo

[CÁMARA]

Todo lo que vieron en estos 25 minutos de demo está disponible. El terraform que provisionó la VM con un comando — está en el repo público de Skool Standard. Se suscriben gratis a la comunidad, clonan el repo, hacen terraform apply, y en 2 minutos tienen su propia VM con Hermes corriendo.

Lo demás que mostré — el docker-compose multi-perfil con el script de aislamiento, los skills portados al estándar SKILL.md, el contraste de seguridad Capa 1 vs Capa 2, la config de Claude Code consumiendo Hermes via MCP — todo eso está en el repo de Skool Premium. Si quieren replicarlo en su propia máquina sin transcribir cada cosa del video, está ahí.

---

[49:00 - 52: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 transcripción de voz 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 en producción real — y eso ya lo demostramos en vivo en Demo 6 con la conexión MCP. Problemas distintos, herramientas distintas, conectadas por un protocolo estándar.

---

[52:00 - 55: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.

---

[55:00 - 57: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 herramientas de mensajería	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]
Self-improving loop probabilístico (no garantizado)	Validado 26 mayo en VM GCP — tarea audit no disparó	[x]
Tirith = scanner real, requiere symlink	Validado 26 mayo + repo terraform startup-script	[x]
AWS/GCP free tier para Hermes	aws.amazon.com/free + cloud.google.com/free	[x]