La funcionalidad estrella de Hermes Agent v0.2.0 no fue una integración de modelos ni el sistema de skills. Fue el Gateway de Mensajería Multi-Plataforma — un único proceso de Hermes escuchando simultáneamente en siete plataformas de chat: Telegram, Discord, Slack, WhatsApp, Signal, email (IMAP/SMTP) y Home Assistant. Para la versión del 8 de abril, la lista había crecido a trece, sumando Matrix, Feishu, WeCom, Mattermost, DingTalk y SMS (vía Twilio).
Lo que es fácil pasar por alto aquí es que construir un bot de Telegram no es muy difícil. Lo difícil es ejecutar siete integraciones de chat simultáneas que comparten un mismo agente, una misma memoria y un mismo registro de herramientas — ahí es donde va el trabajo de arquitectura real. Este artículo explica cómo lo hace Hermes.
El enfoque ingenuo, y por qué no funciona
Si te pidieran construir "un bot de IA que responda en Telegram y en Discord", el primer impulso sería levantar dos bots separados. Cada uno con su proceso, su base de datos, su estado. Los dos llaman a la misma API de modelo de lenguaje. El usuario de Telegram y el de Discord tienen conceptualmente el mismo agente, pero en la práctica son dos agentes que no saben nada el uno del otro.
Así funciona la mayoría de proyectos de bots existentes, y es desastroso en formas que tardan un rato en hacerse evidentes:
- •La memoria diverge. Un usuario que menciona en Telegram que es alérgico a los cacahuetes no tendrá ese dato cuando pregunte por una receta en Discord. Al agente hay que enseñarle lo mismo dos veces.
- •El estado de las herramientas se desincroniza. Un cron programado desde Slack no aparece cuando el usuario consulta sus crons en Telegram. El historial de sesiones está fragmentado. Los tokens de autorización para recursos compartidos (una integración de Notion, por ejemplo) tienen que instalarse en cada bot por separado.
- •El coste operativo se multiplica. N bots significan N procesos, N servicios, N flujos de logs, N archivos de configuración, N sitios donde algo puede romperse. La complejidad crece linealmente con las plataformas.
- •Las reglas de seguridad se fragmentan. Si refuerzas la política de aprobación de comandos peligrosos en un bot, tienes que acordarte de actualizarla en los demás. La deriva en seguridad es el estado por defecto.
Hermes eligió otro camino: hay exactamente un proceso de agente, una base de datos de sesiones, un almacén de memoria, un registro de herramientas. Las plataformas son adaptadores — puertas de entrada finas que canalizan mensajes hacia y desde el agente compartido.
La forma del gateway
Internamente, el gateway de Hermes tiene tres capas.
En la base está el agente en sí — el mismo núcleo de Hermes que se ejecuta en modo CLI. No sabe nada de plataformas de chat. Recibe mensajes, ejecuta su bucle de agente (llamadas al LLM, llamadas a herramientas, consultas de memoria, checkpoints) y produce respuestas. Su única interfaz con el exterior es una API basada en colas.
En el medio está el núcleo del gateway — gestión de sesiones, enrutamiento de usuarios y plataformas, despacho de aprobaciones, programación de crons, streaming, manejo de medios. Esta capa convierte "ha llegado un mensaje de la plataforma X, del usuario Y, en el canal Z" en "una ejecución del agente en la sesión S con estos permisos". También se encarga de los asuntos transversales: límites de tasa, control de inundación, detección de mensajes duplicados, timeouts por inactividad, enrutamiento de botones de aprobación, estado cross-platform.
Arriba están los adaptadores de plataforma. Hay uno por plataforma: adaptador de Telegram, de Discord, de Slack, y así sucesivamente. La responsabilidad de un adaptador es estrecha — conectar con su plataforma (polling, long-poll, WebSocket, webhook o lo que prefiera su SDK), traducir los eventos nativos al formato de mensajes interno del gateway, y traducir las respuestas del gateway al formato que espera la plataforma (Markdown, MarkdownV2, mrkdwn, embeds de Discord, HTML de Matrix, bloques de Slack, MIME para email).
Los adaptadores son intencionalmente pequeños. Añadir una nueva plataforma (un contribuidor de la comunidad añadió Mattermost en menos de 300 líneas de Python en la v0.4.0) es básicamente cuestión de mapear los eventos de su SDK al formato de mensajes interno del gateway, y viceversa.
Cómo funcionan las sesiones entre plataformas
Una sesión de Hermes es un hilo de conversación con su propia ventana de memoria, estado de herramientas e historial de ejecución. En una sola plataforma, las sesiones encajan de forma natural — una sesión por chat de Telegram, una por canal de Discord, una por thread de Slack. Entre plataformas, la cosa se pone más interesante.
Por defecto, Hermes trata cada combinación plataforma/chat como una sesión distinta. Tu DM con el bot en Telegram, tu thread con el bot en Slack y tu canal con el bot en Discord son tres conversaciones separadas con tres contextos independientes, pero todas comparten la misma memoria a largo plazo a través del proveedor de memoria pluggable (Honcho por defecto a partir de la v0.7.0). Así que la información que esperas que se mantenga entre sesiones — "el usuario es alérgico a los cacahuetes", "el usuario se llama Alice", "el proyecto del usuario se llama Atlas" — viaja en la capa de memoria, mientras que el contexto a corto plazo de cada conversación permanece acotado a la plataforma que estás usando.
Este diseño es lo que permite que el mismo asistente se sienta como el mismo asistente en todas las plataformas, sin convertir cada mensaje en una emisión global enredada.
Por qué importan las sesiones compartidas por hilo
En la v0.4.0, Hermes añadió una funcionalidad llamada sesiones por usuario en hilos compartidos — en chats de grupo, cada usuario tiene su propia sesión dentro del mismo hilo. Suena a un cambio menor, pero es enorme para cualquiera que haya intentado ejecutar un bot multiusuario en un grupo.
Sin sesiones por usuario en un chat grupal, cada mensaje forma parte de una única conversación compartida. Si Alice le hace una pregunta al bot y Bob hace otra diferente treinta segundos después, el contexto del bot es ya una mezcla enredada de ambas. Las respuestas se cruzan. La memoria de Alice se contamina con los datos de Bob. El modo gateway empeora a medida que se unen más usuarios.
Con sesiones compartidas por hilo, Alice y Bob tienen cada uno su propia sesión privada dentro del hilo. Ven los mensajes del otro en el chat visible, pero el agente mantiene contextos separados y escrituras de memoria separadas por usuario. En la v0.8.0 esto se convirtió en el comportamiento por defecto en todas las plataformas del gateway. Es el tipo de mejora que es invisible hasta que te ha quemado la alternativa, y entonces ya no quieres volver atrás.
Para qué sirve realmente el gateway
Cuando miras la arquitectura el tiempo suficiente, el gateway deja de parecer "una forma de ejecutar bots en plataformas de chat" y empieza a parecer lo que realmente es: una capa de coordinación entre humanos (en cualquier app que estén usando) y un asistente de IA singular con memoria y herramientas compartidas.
Las plataformas de chat no son el producto. Son los puntos de entrada. El producto es el asistente que existe detrás de ellas, y el hecho de que nunca tengas que pensar en qué punto de entrada estás usando.
Eso es lo que Hermes lanzó el primer día. Todo lo demás es la historia de lo que esa capa de coordinación aprendió a hacer durante las cuatro semanas siguientes.