Bots en Hermes Agent: perfiles especializados, colaboración multiagente y trabajo distribuido
Introducción
Hermes Agent incorpora un sistema denominado Bot Mode que permite convertir perfiles independientes de Hermes en agentes especializados con identidad, memoria, herramientas y responsabilidades propias.
La idea fundamental es sencilla:
Un bot de Hermes es un perfil de Hermes presentado como un agente independiente.
No existe un segundo motor de agentes ni una arquitectura paralela. Bot Mode utiliza los perfiles que ya forman parte de Hermes y añade una interfaz orientada a trabajar con varios agentes especializados.
Esto permite pasar de utilizar un único asistente generalista a disponer de un pequeño equipo de agentes:
Usuario
│
├── Arquitecto
├── Programador
├── QA
├── Infraestructura
└── Documentación
Cada uno puede disponer de su propio contexto y especialización.
1. Qué es realmente un bot en Hermes
Hermes define explícitamente:
A Bot is a profile.
Por tanto, un bot aprovecha toda la infraestructura existente de perfiles.
Cada bot puede disponer de forma independiente de:
- configuración;
- modelo LLM;
- proveedor;
- memoria;
- skills;
- credenciales;
- sesiones;
- historial de conversaciones;
SOUL.md;- herramientas;
- servidores MCP habilitados;
- rutinas programadas;
- avatar;
- nombre y descripción.
Los datos pertenecen al perfil correspondiente y no a una base de datos especial creada por Bot Mode.
Conceptualmente:
Hermes
│
├── profile: general
│
├── profile: development
│
├── profile: qa
│
└── profile: amableai
En Bot Mode estos perfiles pueden aparecer visualmente como:
Hermes Bots
│
├── General
├── Developer
├── QA
└── AmableAI
2. Los bots y los perfiles son la misma entidad
Esta equivalencia es importante porque significa que el bot también puede utilizarse desde la línea de comandos.
Por ejemplo:
hermes -p amableai chat
abre el mismo agente correspondiente al perfil amableai.
El directorio habitual del perfil sigue la estructura:
~/.hermes/profiles/<nombre>/
y puede contener configuración, memoria, skills y sesiones propias.
Esto significa que Bot Mode no bloquea al usuario dentro de Hermes Desktop.
Se puede trabajar indistintamente mediante:
Desktop
CLI
Gateway
Automatizaciones
Bots
sobre el mismo perfil.
3. Aislamiento entre bots
Uno de los aspectos más importantes es que los perfiles están aislados.
La documentación de Hermes confirma que diferentes perfiles no comparten automáticamente:
- memoria;
- sesiones;
- configuración;
- historial.
Cada uno mantiene su propio espacio de trabajo.
Esto permite crear verdaderos especialistas.
Por ejemplo:
@arquitecto
MEMORY:
Arquitectura del proyecto
Patrones
Decisiones técnicas
@crm
MEMORY:
Leads
Pipeline
Booking
Procesos comerciales
@qa
MEMORY:
Tests
Regresiones
Errores conocidos
Criterios de aceptación
El bot de QA no necesita cargar continuamente todo el conocimiento comercial del CRM.
Y el bot CRM no necesita cargar todo el historial de administración de sistemas.
Esto reduce ruido contextual y puede mejorar la precisión del agente.
4. Crear un bot
Hermes Desktop dispone de la opción New Agent dentro de Bot Mode.
La creación básica solicita:
- Name;
- Title;
- Description.
La configuración avanzada permite además:
- clonar un perfil existente;
- crear un perfil vacío;
- seleccionar modelo;
- seleccionar proveedor;
- definir
SOUL.md; - habilitar skills concretos;
- habilitar toolsets concretos;
- habilitar servidores MCP concretos.
Por tanto, diferentes bots pueden incluso utilizar modelos distintos simultáneamente.
Ejemplo:
@arquitecto
Qwen3-Coder 30B
@qa
Qwen 14B
@documentacion
modelo más pequeño
@investigacion
modelo especializado diferente
No es obligatorio que todo el equipo utilice el mismo modelo.
5. Chat permanente de cada bot
Cada bot dispone de una conversación principal denominada canonical Bot Chat.
Esta conversación representa la relación permanente con ese agente.
Hermes trata esta conversación de forma diferente a una sesión temporal.
En particular, dentro del Bot Chat principal, comandos como /new o /reset no destruyen esa relación permanente; Hermes redirige el comportamiento hacia compactación del contexto.
Esto permite que el bot mantenga una continuidad mayor.
Conceptualmente:
@amableai
│
├── memoria persistente
├── Bot Chat permanente
├── sesiones auxiliares
└── grupos
6. Comunicación entre bots
Una de las funciones más interesantes de Bot Mode es que los agentes pueden enviarse mensajes entre sí.
Hermes utiliza menciones:
@nombre-del-bot
Por ejemplo:
@qa revisa los cambios que acaba de realizar @developer.
Hermes resuelve la mención contra el listado de bots disponibles.
El agente activo puede entonces utilizar el sistema interno message_agent para enviar trabajo al agente correspondiente.
La comunicación mantiene atribución.
Por ejemplo:
USUARIO
│
▼
@arquitecto
│
├────► @developer
│
├────► @qa
│
└────► @documentacion
Esto permite delegar trabajo sin convertir una única sesión en una conversación gigantesca.
7. Un detalle importante sobre los mensajes
Cuando el usuario escribe:
@qa revisa este módulo
Hermes no se limita necesariamente a reenviar literalmente el texto al otro bot.
El agente activo interpreta la petición y compone el mensaje que envía al especialista mediante el mecanismo de comunicación entre agentes.
Por tanto, existe una capa real de delegación.
Esto permite patrones como:
Usuario
↓
Coordinador
↓
convierte objetivo en tarea
↓
Especialista
↓
resultado
↓
Coordinador
↓
Usuario
8. Chats de grupo
Hermes también permite crear conversaciones con varios bots.
Los grupos pueden contener entre 2 y 6 bots.
Ejemplo:
Grupo: AmableAI Desarrollo
@arquitecto
@developer
@qa
@infra
El usuario puede escribir:
Tenemos que implementar el nuevo workflow de contratación de demo.
Analizad el problema y proponed el plan.
Los agentes pueden participar por rondas.
Hermes impone límites para impedir conversaciones infinitas entre agentes:
- hasta tres rondas;
- máximo de diez mensajes por envío del usuario.
Además, los bots pueden decidir no intervenir si consideran que no tienen información nueva que aportar.
9. Menciones dentro de grupos
Dentro de un grupo también se pueden dirigir tareas concretas.
Por ejemplo:
@developer implementa el cambio.
@qa no modifiques nada:
limítate a comprobar posteriormente el resultado.
Esto permite utilizar roles muy diferenciados.
También es posible que un bot solicite intervención humana mediante:
@user
cuando detecta una decisión que no debería tomar autónomamente.
Esto resulta especialmente útil en operaciones críticas.
10. Persistencia de los grupos
Cada miembro mantiene su propia sesión correspondiente al grupo.
Por ejemplo:
@arquitecto
└── Group: AmableAI Development
@developer
└── Group: AmableAI Development
@qa
└── Group: AmableAI Development
Por tanto, los miembros mantienen contexto del trabajo realizado dentro de ese grupo sin convertirlo necesariamente en memoria global.
11. Bots en máquinas diferentes
Esta es probablemente una de las capacidades más interesantes para infraestructuras distribuidas.
Hermes Desktop puede registrar múltiples conexiones:
- runtime local;
- servidores SSH;
- gateways remotos;
- otras instancias Hermes;
- Hermes Cloud.
Los bots pertenecientes a esas conexiones pueden aparecer dentro del mismo roster de Desktop.
Esto permite una arquitectura:
MÁQUINA A
@arquitecto
MÁQUINA B
@backend
MÁQUINA C
@infra
y aun así:
@arquitecto → @backend
@backend → @infra
pueden colaborar desde la misma interfaz.
12. Dónde se ejecuta realmente cada bot
Un detalle fundamental:
El trabajo de cada bot se ejecuta en la máquina propietaria de su perfil.
Hermes Desktop actúa como superficie de coordinación, pero no mueve físicamente el agente de un servidor a otro.
Por ejemplo:
PC LOCAL
@arquitecto
│
│ mensaje
▼
SERVIDOR
@backend
Cuando @backend trabaja:
CPU
RAM
archivos
configuración
herramientas
son los de su propia máquina.
Esto abre la puerta a agentes especializados físicamente próximos a los sistemas que administran.
13. Bots con el mismo nombre en diferentes máquinas
Hermes contempla que pueda existir el mismo perfil en distintas conexiones.
Para evitar ambigüedad puede desambiguarlos utilizando:
@nombre-dispositivo
Por ejemplo:
@qa-ring
@qa-vps
Así los agentes pertenecientes a máquinas distintas no se confunden entre sí.
14. Routines: tareas recurrentes de los bots
Cada bot puede tener tareas programadas llamadas Routines.
Internamente utilizan el sistema cron de Hermes.
Por ejemplo:
@qa
Todos los días:
verificar endpoints críticos.
@infra
Cada mañana:
comprobar servicios.
@crm
Cada viernes:
generar informe comercial.
Las rutinas aparecen asociadas al propio bot y sus ejecuciones terminan dentro de su historial.
Desde CLI también pueden verse mediante:
hermes cron list
Los nombres de jobs relacionados con bots incluyen el namespace correspondiente al bot.
15. Skills diferentes para cada bot
Cada agente puede disponer únicamente de las skills necesarias para su trabajo.
Ejemplo:
@developer
├── php
├── composer
├── git
└── amableai-safe-change
@qa
├── testing
├── browser
├── http-validation
└── log-analysis
@infra
├── ssh
├── docker
├── systemd
└── backup-audit
Esto permite aplicar el principio de:
mínima capacidad necesaria.
Un agente dedicado exclusivamente a QA no necesita necesariamente herramientas capaces de modificar producción.
16. MCP diferente para cada bot
Durante la creación/configuración avanzada de agentes, Hermes también permite seleccionar qué servidores MCP puede utilizar cada bot.
Conceptualmente:
@hub
│
└── MCP-HUB
@developer
└── herramientas código
@qa
└── herramientas pruebas
Esto permite limitar tanto contexto como privilegios.
17. Modelos diferentes para bots diferentes
Un bot puede fijar su propio proveedor/modelo.
Esto permite optimizar recursos.
Por ejemplo:
Arquitectura compleja
↓
modelo grande
QA rutinario
↓
modelo medio
Clasificación sencilla
↓
modelo pequeño
En una infraestructura local esto resulta especialmente interesante porque no todas las tareas necesitan reservar un modelo de gran tamaño.
Hermes permite que diferentes bots utilicen diferentes configuraciones de modelo de forma independiente.
18. Bot Mode no crea procesos permanentes adicionales
Bot Mode no necesita crear un nuevo daemon simplemente por existir un bot.
La documentación indica que es fundamentalmente una interfaz sobre perfiles existentes:
- no introduce un nuevo sistema de almacenamiento;
- no exige parches al core;
- no exige un daemon independiente para cada bot.
El agente se ejecuta cuando debe realizar trabajo.
19. Bot Mode puede desactivarse
Bot Mode es un plugin integrado en Hermes Desktop.
Puede desactivarse desde:
Settings
→ Plugins
→ Bots
Deshabilitar la interfaz no elimina:
- perfiles;
- sesiones;
- cron jobs;
- memoria.
Los datos siguen perteneciendo al sistema normal de perfiles.
20. Bots ocultos
Hermes permite ocultar bots del roster sin eliminarlos.
Un bot oculto:
- continúa existiendo;
- continúa participando en grupos;
- puede seguir recibiendo menciones;
- mantiene sus rutinas.
La acción únicamente afecta a su visibilidad en la interfaz.
Esto permite mantener muchos especialistas sin saturar visualmente Desktop.
21. Bots frente a Skills
No deben confundirse.
Skill
Una skill representa principalmente:
CÓMO HACER ALGO
Ejemplo:
amableai-safe-change
puede definir el procedimiento:
analizar
→ backup
→ cambiar
→ probar
→ documentar
Bot
Un bot representa:
QUIÉN HACE ALGO
Ejemplo:
@developer
puede utilizar:
amableai-safe-change
Por tanto:
BOT
│
├── identidad
├── memoria
├── modelo
├── herramientas
└── SKILLS
Los dos conceptos son complementarios.
22. Bots frente a sesiones
Una sesión es una conversación.
Un bot es una entidad persistente respaldada por un perfil.
Por tanto:
BOT
├── memoria
├── configuración
├── skills
├── Bot Chat
├── sesiones normales
└── sesiones de grupos
No debe diseñarse un especialista simplemente abriendo otra conversación con el mismo perfil.
El aislamiento real proviene del perfil.
23. Bots frente a subagentes temporales
También conviene distinguir un bot permanente de un agente temporal creado para resolver una tarea.
Un bot representa normalmente:
ROL PERSISTENTE
Por ejemplo:
QA
Infraestructura
CRM
Arquitectura
Un subagente temporal representa normalmente:
TAREA CONCRETA
Por ejemplo:
analiza estos 50 logs
y después deja de tener importancia.
Los bots resultan especialmente útiles cuando la especialización debe conservarse durante semanas o meses.
24. Arquitectura multiagente aplicada a AmableAI
A partir de aquí entramos en una propuesta de arquitectura, no en una configuración que Hermes imponga automáticamente.
Para un sistema distribuido como AmableAI podría tener sentido utilizar inicialmente:
USUARIO
│
▼
@amableai
Arquitecto / coordinador
/ | \
/ | \
▼ ▼ ▼
@developer @qa @infra
No sería recomendable comenzar con quince agentes.
Tres o cuatro roles bien definidos suelen aportar más claridad que una flota de bots con responsabilidades solapadas.
25. Ejemplo: bot coordinador
@amableai
Responsabilidad:
- entender la petición;
- determinar qué sistemas intervienen;
- consultar arquitectura;
- dividir trabajo;
- delegar;
- integrar resultados;
- solicitar decisiones humanas cuando corresponda.
Puede tener acceso a:
ARCHITECTURE.md
AGENTS.md
.hermes.md
Obsidian
MCP-HUB
No necesariamente debería realizar todos los cambios personalmente.
26. Ejemplo: bot desarrollador
@developer
Responsabilidad:
- modificar código;
- ejecutar tests;
- revisar Composer;
- trabajar con Git;
- aplicar cambios mínimos.
Podría utilizar una skill:
amableai-safe-change
Su función sería implementar.
No debería ser necesariamente quien certifique que su propio trabajo está correcto.
27. Ejemplo: bot QA
@qa
Responsabilidad:
- comprobar;
- intentar reproducir errores;
- revisar HTTP;
- ejecutar tests;
- revisar logs;
- realizar pruebas E2E;
- verificar criterios de aceptación.
Regla especialmente útil:
No confiar en la afirmación de éxito del agente que implementó el cambio.
Debe obtener evidencia independiente.
Esto crea una separación:
Developer
│
IMPLEMENTA
│
▼
QA
│
VERIFICA
│
▼
SUCCESS / ERROR
28. Ejemplo: bot infraestructura
@infra
Responsabilidad:
- VPS;
- SSH;
- Docker;
- servicios;
- red;
- Tailscale;
- backups;
- procesos;
- almacenamiento;
- observabilidad.
Puede disponer de tools diferentes al desarrollador.
Esto evita que el agente de programación tenga necesariamente acceso a todas las operaciones administrativas.
29. Ejemplo completo de trabajo colaborativo
El usuario solicita:
La contratación de demo no está creando correctamente
la oportunidad en el CRM.
El coordinador podría trabajar conceptualmente así:
@amableai
│
├── consulta ARCHITECTURE.md
│
├── identifica Web + Hub + CRM
│
├── @developer → inspecciona implementación
│
├── @infra → comprueba servicios implicados
│
└── @qa → prepara criterios E2E
Después:
@developer
↓
implementa
@qa
↓
prueba flujo completo
@amableai
↓
integra evidencias
Usuario
Este patrón puede reducir uno de los mayores problemas de los agentes autónomos:
que el mismo agente implemente, interprete sus propios resultados y se declare exitoso.
30. Separación entre ejecución y certificación
Una arquitectura especialmente interesante es:
@amableai
coordinador
/ \
▼ ▼
@developer @qa
modifica verifica
\ /
\ /
▼ ▼
resultado
El desarrollador puede afirmar:
IMPLEMENTACIÓN TERMINADA
pero únicamente QA puede aportar evidencia suficiente para:
VERIFICACIÓN: PASS
y entonces el coordinador puede determinar:
RESULTADO: SUCCESS
Este diseño es especialmente apropiado para proyectos donde se desea minimizar falsos positivos.
31. Arquitectura distribuida posible
En una infraestructura con distintas máquinas puede ampliarse el concepto:
RING
│
├── @amableai
├── @developer
├── @qa
└── @docs
VPS-HUB
│
└── agentes o herramientas especializadas Hub/MCP
VPS-WEB
│
└── agentes o herramientas especializadas Web
Hermes permite que bots pertenecientes a diferentes conexiones aparezcan en el mismo roster y participen en grupos.
No obstante, esto debe diseñarse atendiendo a seguridad, permisos y consumo de recursos.
32. No crear bots por cada tecnología
Un error frecuente sería diseñar:
@php
@mysql
@apache
@docker
@git
@ssh
@bootstrap
Esto fragmentaría excesivamente el trabajo.
Es mejor que las tecnologías sean:
TOOLS / SKILLS
y que los bots representen:
RESPONSABILIDADES
Mejor:
@developer
@qa
@infra
que:
@php
@mysql
@docker
33. Qué debería justificar la creación de un bot
Crear un bot tiene sentido cuando existe al menos una de estas condiciones:
Memoria diferente
El agente debe recordar información distinta.
Herramientas diferentes
Necesita permisos diferentes.
Modelo diferente
La tarea necesita otro modelo.
Responsabilidad diferente
Existe una separación clara de funciones.
Rutina recurrente
El especialista debe trabajar periódicamente.
Entorno diferente
Debe ejecutarse desde otra máquina.
Si nada de esto ocurre, probablemente basta con utilizar:
- una skill;
- una sesión;
- o una tarea temporal.
34. Limitaciones importantes
Bot Mode no significa automáticamente:
inteligencia colectiva perfecta
Los agentes pueden:
- equivocarse;
- interpretar mal una delegación;
- consumir contexto;
- duplicar trabajo;
- generar conflictos;
- llegar a conclusiones incorrectas.
Por eso la arquitectura de agentes importa tanto como los propios modelos.
También existen límites deliberados en los chats de grupo para evitar conversaciones infinitas entre bots.
35. Estado actual de algunas capacidades
La documentación actual de Hermes describe Bot Mode como una funcionalidad integrada en Desktop y activa por defecto.
Sin embargo, algunas partes del ecosistema continúan evolucionando.
Por ejemplo, existen incidencias recientes relacionadas con la exposición de determinadas salas de Bot Mode fuera de Desktop, lo que demuestra que la capa multiagente sigue desarrollándose activamente.
Por tanto, cualquier despliegue complejo debe validar las capacidades concretas de la versión instalada de Hermes y no basarse únicamente en documentación histórica.
36. Cuándo utilizar bots
Los bots tienen especial sentido para:
- desarrollo de software;
- QA;
- investigación;
- administración de sistemas;
- operaciones;
- documentación;
- CRM;
- soporte;
- análisis;
- tareas recurrentes;
- sistemas distribuidos.
Resultan menos necesarios para tareas aisladas de pocos minutos.
37. La combinación potente: Bot + Skill + MCP + Memoria
La verdadera potencia aparece cuando se combinan las distintas piezas de Hermes:
BOT
│
├── SOUL
│
├── MEMORY
│
├── MODEL
│
├── SKILLS
│
├── TOOLS
│
├── MCP
│
├── ROUTINES
│
└── SESSIONS
Entonces el agente deja de ser simplemente:
un prompt
y pasa a comportarse como:
un trabajador especializado persistente
dentro de la infraestructura.
38. Conclusión
Los bots de Hermes no son simples personajes ni ventanas de chat separadas.
Son una capa visual y operativa sobre el sistema de perfiles de Hermes que permite mantener agentes especializados con:
- identidad propia;
- memoria aislada;
- configuración propia;
- modelos independientes;
- skills específicas;
- MCP específicos;
- rutinas;
- conversaciones persistentes;
- colaboración entre agentes;
- grupos;
- ejecución distribuida entre máquinas.
La idea clave puede resumirse así:
PROFILE
+
IDENTIDAD
+
MEMORIA
+
TOOLS
+
SKILLS
+
MCP
+
RUTINAS
=
BOT ESPECIALIZADO
Y varios bots correctamente diseñados permiten pasar de:
UNA IA QUE HACE DE TODO
a:
UN EQUIPO DE AGENTES
CON RESPONSABILIDADES DIFERENCIADAS
Para un proyecto complejo, el valor no está en crear muchos bots.
Está en crear pocos agentes con responsabilidades inequívocas, contexto correcto, permisos limitados y mecanismos independientes de verificación.