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

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

Notas de producción

• Formato: concepto + demo real (patrón validado)
• Duración objetivo: 35-45 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
• Cambios desde v3:
  1. Demo 1 reescrita: pip install → terraform apply (diferenciador real vs YouTubers) + mostrar log del startup-script en vivo
  2. Demo 2 reescrita: docker-compose validado + script test-aislamiento.sh con 4 verificaciones (filesystem, procesos, puertos, lifecycle)
  3. Demo 3 reescrita: skills REALES portados desde el proyecto Workspace Profiling (workspace-profile-checker + salary-access-verifier), no skills hipotéticos
  4. Demo 4 reescrita: los 3 mecanismos del self-improving (nudge ignorado en sesión, background review al /exit crea skill, reutilización autónoma). Validado en vivo bajando creation_nudge_interval a 3 — ya no requiere pregrabación
  5. Demo 5 reescrita: ejemplo real del proyecto Workspace Profiling (Lucía Junior DENEGADO vs Ana Manager PERMITIDO con verificar_acceso_salarial), no DNS hipotético
  6. Demo 6 reescrita: arrancar hermes mcp serve + tabla 10 tools de messaging + config Claude Code via SSH + caso de uso Telegram
  7. Sección [22:00-24:00] agrega aclaración: GCP/AWS tienen free tier, el proveedor es trivial
  8. Cierre del bloque demo menciona repo Skool Standard (Demo 1) + repo Skool Premium (Demos 2-6)

---

[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 approval gate 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:

1. Voy a desplegar Hermes en Google Cloud con Terraform — no click a click en Hostinger como hacen todos. 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 venden en YouTube. 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 complejas con 5 o más llamadas a herramientas, 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 te lo cuentan en otros videos, 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 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 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.

[PANTALLA — docker-compose multi-perfil]

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

  hermes-trabajo:
    image: nousresearch/hermes-agent:latest
    container_name: hermes-trabajo
    volumes:
      - ~/.hermes-trabajo:/opt/data
    ports:
      - "8643: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 (Y EL FREE TIER QUE NADIE TE CUENTA)

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

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 un Hetzner de 5 euros, en un Hostinger de 5 dólares o en cualquier VPS Linux. 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 - 35:00] DEMO — TERRAFORM + DOCKER + SKILLS + MCP

[CÁMARA]

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

Parte 1: Despliegue con Terraform (no click a click)

[CÁMARA]

Mientras todos los videos te muestran cómo instalar Hermes click a click en el panel de Hostinger, yo te lo voy a mostrar bien — con Terraform. Infraestructura como código. Si en algún momento quieres replicarlo, 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 -auto-approve

[PANTALLA — output de terraform apply]

Fíjate: 17 segundos para crear la VM y la regla de firewall. 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 hermes@35.224.139.27"
startup_log_command = "ssh hermes@35.224.139.27 'sudo tail -f /var/log/hermes-setup.log'"

[CÁMARA]

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 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, en YouTube te lo venden como “haz click acá en Hostinger y listo”. Yo te muestro qué pasa realmente.

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

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

Ahora sí. Control+C, y SSH normal:

ssh 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 OpenAI Codex — uso mi ChatGPT Plus de $20
                    # me pregunta qué modelo: elijo gpt-5.5
hermes              # primera sesión

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

Y acá ya tenemos Hermes corriendo con GPT-5.5, 29 tools y 85 skills disponibles. Sin pagar API key extra. Sin tarjeta de crédito nueva.

Parte 2: Docker multi-perfil — aislamiento real

[CÁMARA]

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.

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

[DEMO en vivo — levantar el stack]

docker compose up -d
docker ps

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

[DEMO en vivo — script test-aislamiento.sh]

./test-aislamiento.sh

[PANTALLA — output del script, ir resaltando cada bloque]

Verificación 1 — filesystem: creo un archivo en hermes-personal con docker exec hermes-personal sh -c 'echo "datos privados" > /opt/data/secret.txt'. Después intento leerlo desde hermes-trabajo. Resultado: cannot access /opt/data/secret.txt. El archivo no existe en el otro container. Filesystem aislado.

Verificación 2 — procesos: cada container tiene su propio PID 1 (tini como init supervisor). Las tablas de procesos son completamente separadas. No hay forma de que un container vea procesos del otro.

Verificación 3 — puertos: docker port muestra que cada container expone el puerto 8642 internamente, pero el host los mapea a 8642 y 8643. Misma app, dos endpoints independientes.

Verificación 4 — lifecycle: mato hermes-personal con docker kill. hermes-trabajo sigue corriendo intacto. Restauro hermes-personal con docker compose up -d. El otro nunca se inmutó.

[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 al directorio de Hermes]

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. Cuando un agente nuevo aparezca que soporte el estándar, 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 nudge en sesión. Cada N tool-calling iterations, Hermes inserta una sugerencia en el system prompt del modelo: “considera crear un skill para este patrón”. El valor por defecto es 15 tool calls.

Lo probé con dos modelos distintos — gpt-5.5 y gpt-5.4-mini, ambos vía OpenAI Codex. Bajé el threshold a 2 y a 3. El nudge se insertó múltiples veces. Y el modelo lo ignoró cada vez. Por qué: alineación de seguridad. Modelos modernos no crean cosas sin instrucción explícita.

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

[CÁMARA]

Mecanismo dos — el background review al cerrar sesión. Esto es lo que NADIE muestra.

Cuando haces /exit en Hermes, si durante la sesión el counter del nudge pasó el threshold al menos una vez, Hermes spawnea un sub-agent en thread separado. Le pasa el snapshot completo de los mensajes de la sesión. Le da un prompt especializado distinto al main, dedicado solo a revisión. Y ese sub-agent decide autónomamente qué patrones merecen guardarse como skill.

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

# Por defecto el threshold es 15. 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 con 6 tool calls discretos — un scaffolding de scripts bash para diagnóstico de VM. El modelo los crea, no carga ningún skill, no inventa nada. Termina la respuesta.

[DEMO en vivo — /exit y esperar]

/exit

Y ahora viene lo interesante. Salgo. Espero 30 segundos. Mientras tanto, en background, el sub-agent corre con max_iterations 16, sin nudges propios, revisando la sesión.

[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, autocreado, sin que yo se lo pidiera. Lo categorizó solo como devops. Le puso un nombre genérico — bash-utility-suites, no “vm-health” que era el path específico. Generalización inteligente. 131 líneas con “when to use”, “do not use”, design rules, canonical pattern. Calidad de manual real.

hermes curator status

[PANTALLA — agent-created skills: 1 total]

Y el curator de Hermes lo reconoce como agent-created — la categoría especial para skills generados autónomamente por el background review.

[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 aquí está el insight que NADIE explica:

1. Durante sesión: el modelo IGNORA el nudge en system prompt
2. Al /exit: un sub-agent en background ANALIZA la sesión y crea skills autónomamente
3. En sesiones siguientes: los skills se cargan solos cuando aplican

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.

Y un detalle práctico importante: con el creation_nudge_interval por defecto de 15, en una demo corta de 6-7 tool calls el background review no dispara. Por eso lo bajé a 3 para esta grabación. En uso real prolongado — un developer usando Hermes todos los días — el counter eventualmente acumula 15+ tool calls y dispara solo. Pero en demo aislada hay que ajustar el config para verlo.

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

[CÁMARA]

Hermes tiene un sistema de aprobación bien diseñado. Si le pido algo peligroso, pregunta antes de ejecutar. Es Capa 1 — approval gate. Bien para uso personal. Pero comparemos con lo que construimos en el video anterior — el proyecto de Workspace Profiling con 3 agentes ADK.

[DEMO en vivo — Hermes con tarea peligrosa]

Le pido a Hermes que ejecute algo que afecte el sistema. Mira lo que pasa.

[PANTALLA — Hermes pidiendo aprobación]

Approval gate dispara. Si apruebo, ejecuta. Si rechazo, no ejecuta. Funciona — para mí, que estoy mirando la pantalla. Pero hay tres formas de bypassearlo: --yolo mode, cron jobs no interactivos que auto-aprueban, y skills auto-generados por el propio agente que pasan validación con verdict “ask” en lugar de “block”.

[CÁMARA]

Ahora mira lo que hacemos nosotros en el proyecto de Workspace Profiling. Mismo prompt, dos usuarios distintos.

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

Tenemos una función verificar_acceso_salarial. Es código Python. Recibe el email del solicitante, su título, su departamento. Retorna PERMITIDO o DENEGADO en base a reglas duras: solo managers y RRHH ven salarios.

[DEMO en vivo — Lucía pregunta]

Lucía Torres es Junior Developer en Platform Engineering. Pregunta: “¿Cuánto gana María?”

El orquestador la perfila — title “Junior Developer”, department “Platform Engineering”. El agente RRHH llama verificar_acceso_salarial. La función retorna DENEGADO. El agente responde: “No tienes acceso a esa información.”

[DEMO en vivo — Ana pregunta lo mismo]

Ana Morales es Financial Manager. Mismo prompt: “¿Cuánto gana Carlos?”

El orquestador la perfila — title “Financial Manager”. El agente RRHH llama verificar_acceso_salarial. La función retorna PERMITIDO. El agente responde con la información salarial.

[CÁMARA]

Mismo agente. Mismo modelo. Mismo prompt. Distinto resultado. Y la diferencia no es lo que dice el system prompt — es código Python que se ejecuta antes de que el modelo responda.

[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
YOLO mode                     Bypassa todo             Verificador igual corre
Prompt injection              Modelo puede ser engañado  Verificador es Python, no prompt
Skill auto-generado           Pasa con verdict "ask"   Agente no puede crear código nuevo
Cron job no interactivo       Auto-aprueba             Verificador siempre corre

[CÁMARA]

La diferencia es la diferencia entre seguridad por convención y seguridad por diseño. Hermes confía en que el usuario apruebe correctamente. Nuestro sistema arquitectónicamente no puede hacer lo prohibido. No importa el modo, no importa la configuración. No importa lo que diga el system prompt. Si la función no autoriza, el dato no se entrega.

Para un agente personal en un VPS de 5 dólares, Capa 1 alcanza. Para agentes en producción con múltiples usuarios y datos sensibles, Capa 2 es obligatoria.

Y este código — verificar_acceso_salarial — está portado como SKILL.md de Hermes en el repo Premium. Cualquier sesión de Hermes con la guía correcta puede aplicar el mismo patrón.

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.

[DEMO en vivo — arrancar MCP serve]

hermes mcp serve

[PANTALLA — el comando esperando conexión stdio]

El server arrancó. Está en modo stdio, esperando que un cliente MCP se conecte. Pero hay un detalle crítico que hay que aclarar: cuando expones Hermes como MCP server, no expone sus 70+ herramientas internas. Solo expone 10 tools específicas de messaging.

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

[PANTALLA — claude-code-config.example.json]

{
  "mcpServers": {
    "hermes-remote": {
      "command": "ssh",
      "args": [
        "-i", "~/.ssh/id_ed25519_hermes_gcp",
        "hermes@TU_IP_DE_VM",
        "hermes mcp serve"
      ]
    }
  }
}

Claude Code corre el comando como subproceso. SSH abre el túnel a la VM. Hermes corre adentro. Stdio se serializa por la conexión SSH transparentemente. Es elegante porque 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 tools de messaging de Hermes.

[DEMO en vivo — caso de uso real]

Le pido a Claude Code algo así:

“Construye el proyecto. Cuando termine, mándame un mensaje a mi chat de Telegram avisándome.”

Claude Code ejecuta el build con sus tools nativos. Cuando termina, invoca message_send del MCP server de Hermes. Hermes en la VM usa su gateway de Telegram. Me llega el mensaje al celular.

[PANTALLA — notificación de Telegram llegando]

Sin escribir un solo adaptador a Telegram en Claude Code. Hermes hace todo el trabajo de messaging.

[CÁMARA]

Esto es exactamente lo que David Soria Parra, cocreador de MCP en Anthropic, presentó en su keynote. El agent harness — Claude Code en este caso — más MCP como capa de conectividad. Lo cubrimos en el video anterior del canal.

Y resuelve algo que la comunidad ya estaba descubriendo: Hermes y Claude Code no compiten — se complementan. Claude Code es tu pair programmer en la terminal. Hermes es tu asistente personal 24/7 en el servidor con todos los canales conectados. Via MCP, Claude Code accede a esos canales sin reinventar nada.

Cierre del bloque demo

[CÁMARA]

Todo lo que vieron en estos 11 minutos 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í.

---

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