A funcionalidade principal do Hermes Agent v0.2.0 não era uma integração de modelo nem um sistema de skills. Era o Gateway de Mensagens Multi-Plataforma — um único processo Hermes escutando em sete plataformas de chat simultaneamente: Telegram, Discord, Slack, WhatsApp, Signal, email (IMAP/SMTP) e Home Assistant. Na release de 8 de abril a lista já tinha crescido pra treze, com Matrix, Feishu, WeCom, Mattermost, DingTalk e SMS (via Twilio) adicionados no caminho.
O que é fácil de não perceber aqui é que construir um bot de Telegram não é muito difícil. Construir sete integrações simultâneas de chat que compartilham um único agente, uma única memória e um único registro de ferramentas — é aí que o trabalho arquitetural vai. Este post percorre como o Hermes faz isso de verdade.
A abordagem ingênua, e por que não funciona
Se você fosse construir "um bot de IA que responde no Telegram e no Discord", o primeiro instinto seria levantar dois bots separados. Cada um com seu próprio processo, banco de dados, estado. Ambos chamam a mesma API de modelo de linguagem. O usuário no Telegram e o do Discord recebem conceitualmente o mesmo agente, mas na prática recebem dois agentes que não sabem um do outro.
É o que a maioria dos projetos de bot faz, e é terrível de formas que demoram pra ficar óbvias:
- •A memória diverge. Um usuário que menciona no Telegram ter alergia a amendoim não terá esse fato quando perguntar algo sobre culinária no Discord. O agente precisa aprender a mesma coisa duas vezes.
- •O estado de ferramentas desvia. Um cron job configurado via Slack não aparece quando o usuário confere via Telegram. O histórico de sessão é fragmentado. Tokens de autorização pra recursos compartilhados (tipo uma integração com Notion) precisam ser instalados em cada bot separadamente.
- •A sobrecarga operacional multiplica. N bots significa N processos, N serviços, N streams de log, N arquivos de config, N pontos onde algo pode quebrar. A complexidade cresce linearmente com as plataformas.
- •As regras de segurança fragmentam. Se você reforça uma política de aprovação de comando perigoso num bot, precisa lembrar de atualizar nos outros. A deriva de segurança é o padrão.
O Hermes faz uma escolha diferente: existe exatamente um processo de agente, exatamente um banco de sessões, exatamente um store de memória, exatamente um registro de ferramentas. As plataformas são adaptadores — portas de entrada finas que canalizam mensagens pra dentro e pra fora do agente compartilhado.
A forma do gateway
Internamente, o gateway do Hermes tem três camadas.
Na base está o agente em si — o mesmo core do Hermes que roda no modo CLI. Ele não sabe nada sobre plataformas de chat. Recebe mensagens, roda seu loop de agente (chamadas LLM, chamadas de ferramentas, buscas na memória, checkpoints) e produz respostas. Sua única interface com o mundo exterior é uma API baseada em filas.
No meio está o core do gateway — gerenciamento de sessão, roteamento por usuário/plataforma, dispatch de aprovação, agendamento de cron, streaming, tratamento de mídia. É a parte que transforma "uma mensagem chegou na plataforma X do usuário Y no canal Z" em "uma execução de agente na sessão S com estas permissões." Também cuida de preocupações compartilhadas: rate limits, controle de flood, detecção de mensagem duplicada, timeouts por inatividade, roteamento de botões de aprovação, estado cross-platform.
No topo estão os adaptadores de plataforma. Um por plataforma: adaptador Telegram, adaptador Discord, adaptador Slack, e assim por diante. O trabalho de um adaptador é estreito — conectar à plataforma (via polling, long-poll, WebSocket, webhook, ou o que o SDK da plataforma preferir), traduzir eventos nativos da plataforma pro formato de mensagem interno do gateway, e traduzir as respostas de saída do gateway de volta pro que a plataforma espera (Markdown, MarkdownV2, mrkdwn, rich embeds do Discord, HTML do Matrix, blocks do Slack, MIME de email).
Os adaptadores são intencionalmente pequenos. Adicionar uma plataforma nova (um contribuidor da comunidade adicionou Mattermost em menos de 300 linhas de Python na v0.4.0) é na maior parte uma questão de mapear os eventos do SDK pro formato de mensagem interno do gateway e vice-versa.
Como as sessões funcionam entre plataformas
Uma sessão do Hermes é um thread de conversa com sua própria janela de memória, estado de ferramentas e histórico em andamento. Numa única plataforma, sessões mapeiam naturalmente — uma sessão por chat do Telegram, uma por canal do Discord, uma por thread do Slack. Entre plataformas, fica mais interessante.
Por padrão, o Hermes trata cada combinação plataforma/chat como sessão distinta. Sua DM do Telegram com o bot, seu thread do Slack com o bot e seu canal do Discord com o bot são três conversas separadas com tr��s contextos separados, mas todos compartilham a mesma memória de longo prazo pelo provider de memória plugável (Honcho por padrão na v0.7.0 em diante). Então a informação cross-sessão que você espera que se carregue — "o usuário tem alergia a amendoim", "o nome do usuário é Alice", "o projeto do usuário se chama Atlas" — viaja na camada de memória, enquanto o contexto de curto prazo de cada conversa fica no escopo da plataforma que você está usando.
É o design que faz o mesmo assistente parecer o mesmo assistente em toda plataforma, sem transformar cada mensagem num broadcast global emaranhado.
Por que sessões compartilhadas por thread importam
Na v0.4.0, o Hermes adicionou um recurso chamado sessões compartilhadas por thread como padrão — em chats de grupo, cada usuário ganha sua própria sessão dentro do mesmo thread. Parece pouco e é enorme pra qualquer um que já tentou rodar um bot multi-usuário num grupo.
Sem sessões por usuário num chat de grupo, toda mensagem faz parte de uma conversa compartilhada. Se Alice faz uma pergunta ao bot, e Bob faz outra trinta segundos depois, o contexto do bot agora é uma mistura confusa das duas. Respostas se cruzam. A memória da Alice se polui com dados do Bob. O modo gateway piora conforme mais usuários entram.
Com sessões compartilhadas por thread, Alice e Bob cada um têm sua sessão privada dentro do thread. Veem as mensagens um do outro no chat visível, mas o agente mantém contextos separados e escritas de memória separadas por usuário. Na v0.8.0 isso virou o comportamento padrão em todas as plataformas do gateway. É o tipo de fix que é invisível até você ter se queimado com a alternativa, aí você nunca mais quer voltar.
Pra que serve o gateway de verdade
Quando você olha tempo suficiente pra arquitetura, o gateway para de parecer "um jeito de rodar bots em plataformas de chat" e começa a parecer o que realmente é: uma camada de coordenação entre humanos (no app que estiverem usando) e um assistente de IA único com memória e ferramentas compartilhadas.
As plataformas de chat não são o produto. São os pontos de entrada. O produto é o assistente que existe atrás delas, e o fato de que você nunca precisa pensar em qual ponto de entrada está usando.
É isso que o Hermes entregou no dia um. Todo o resto é a história do que essa camada de coordenação aprendeu a fazer nas quatro semanas seguintes.