Passei um sábado chuvoso lendo todas as sete notas de versão do Hermes Agent de uma vez. É o tipo de atividade de fim de semana que parece chata quando você conta, mas que na verdade é extremamente divertida se você é o tipo de pessoa que gosta de ver um projeto se descobrindo em público. No final eu tinha uma parede de post-its, quatro xícaras de café e uma imagem bem nítida da forma do que tinha acontecido.
Entre a primeira tag pública em 12 de março de 2026 e a release v0.8.0 em 8 de abril, o Hermes Agent entregou sete releases numeradas em vinte e sete dias. Uma release a cada quatro dias, na média. A contagem de PRs dessas releases, somada, passa dos quatro dígitos. O número de contribuidores cresceu de sessenta e três no lançamento pra bem mais de duzentos.
Esses números não são a parte interessante. A parte interessante é que as releases não parecem um fluxo longo e indiferenciado de PRs. Elas se organizam em quatro fases bem claras, e dá pra ver o projeto mudando o foco mais ou menos a cada semana.
Fase 1: Fundação (v0.2.0)
A v0.2.0 em 12 de março é o lançamento público, e a missão dela era entregar um esqueleto funcional: o gateway de mensagens multi-plataforma (Telegram, Discord, Slack, WhatsApp, Signal, IMAP/SMTP, Home Assistant num processo só), um cliente nativo do Model Context Protocol, um sistema de skills com mais de setenta skills incluídas, um roteador centralizado de provedores com um único ponto de entrada call_llm(), e isolamento com git worktree + checkpoints de filesystem como rede de segurança pra um agente que realmente tem permissão pra modificar sua máquina. Integração ACP com VS Code, Zed e JetBrains fez com que não fosse só-coisa-de-terminal desde o dia um.
Essa é a release "é isso que o negócio é". Tudo que vem depois é construído em cima dessas cinco decisões.
Fase 2: Amplitude (v0.3.0 – v0.5.0)
As três releases seguintes, entre 17 de março e 28 de março, foram sobre expandir a área de superfície em todas as direções.
v0.3.0 em 17 de março adicionou streaming ao longo de todo o loop do agente, hooks de sistema de plugins e a primeira das grandes integrações de memória — Honcho como provedor de memória. Essa é a release que transformou o Hermes de "um processo com ferramentas" em "um processo com um ecossistema vivo de plugins e uma camada de memória."
v0.4.0 em 23 de março foi expansão de plataformas: WhatsApp Business API, Signal com suporte completo a anexos e um punhado de adaptadores de gateway menores. Mais portas de entrada pro mesmo agente.
v0.5.0 em 28 de março foi uma release de endurecimento. Correções de concorrência, race conditions de sessão, tratamento de resultados de ferramentas, peculiaridades de provedores. O tipo de trabalho que não rende destaque, mas sem o qual nada acima funciona.
Lendo essas três juntas, dá pra ver o projeto tentando responder uma pergunta: "agora que temos um núcleo, quanto do mundo real a gente consegue alcançar a partir dele, sem quebrar o núcleo no processo?" A resposta, no final da v0.5.0, era: a maior parte.
Fase 3: Durabilidade (v0.6.0 – v0.7.0)
Aí o foco muda. A v0.6.0 em 30 de março e a v0.7.0 em 3 de abril são sobre fazer o negócio sobreviver.
v0.6.0 adicionou Profiles — Hermes multi-instância, onde uma instalação pode rodar vários agentes completamente isolados com sua própria config, memória, sessões, skills e serviços de gateway. Também entregou o modo MCP server, pra que o Hermes possa se expor pra outros clientes MCP como Claude Desktop ou Cursor, e um container Docker oficial. E introduziu cadeias ordenadas de fallback de provedores, que é onde a história de "trocar provedores sem reconstruir tudo" começa a ter dentes. Duas plataformas de mensagem novas, Feishu/Lark e WeCom, entraram no gateway.
v0.7.0, a release de resiliência, é onde a arquitetura ficou genuinamente defensiva. Provedores de memória plugáveis — memória vira um ABC de provedor que terceiros podem implementar, com Honcho como plugin de referência. Pools de credenciais do mesmo provedor com rotação thread-safe por menor uso e failover em 401. Backend de navegador anti-detecção Camofox pra trabalho web furtivo. Previews de diff inline pra operações de escrita e patch de arquivo. Continuidade de sessão no API server via headers X-Hermes-Session-Id. Uma varredura de segurança contra exfiltração de segredos, com respostas de LLM escaneadas pra credenciais em base64 e URL-encoded.
No final da v0.7.0, o projeto tinha parado de parecer uma coisa nova e começado a parecer infraestrutura. Do tipo que você põe num cron job e não fica preocupado.
Fase 4: Inteligência (v0.8.0)
O que nos traz ao 8 de abril e a v0.8.0, a release que eu cobri nos dois posts anteriores. A manchete é o loop de guidance auto-otimizada de ferramentas GPT/Codex — o agente diagnosticando e corrigindo seus próprios modos de falha em modelos OpenAI por benchmarking comportamental automatizado. Mas lido no contexto do arco de quatro fases, ele faz algo específico: é a primeira release onde o projeto virou a atenção de volta pra dentro, pra qualidade de raciocínio do próprio agente, depois de três semanas esticando pra fora. Troca de modelo ao vivo com /model, Gemini grátis, MiMo v2 Pro grátis, notificações de tarefas em background, timeouts por inatividade, botões de aprovação, MCP OAuth 2.1 PKCE, escaneamento de malware OSV pra extensões MCP. 209 PRs. 82 issues resolvidas. Cinco dias depois da v0.7.0.
O que o ritmo te conta
Olhando pra isso como um arco contínuo, três coisas se destacam.
As releases têm temas, e os temas não se repetem. Fundação, amplitude, durabilidade, inteligência. Ninguém parece ter decretado que deveria ser assim — o projeto simplesmente se comporta como se tivesse uma leitura de o que vem a seguir. Isso geralmente significa que um número pequeno de pessoas está prestando atenção muito de perto na superfície inteira, e todo mundo está puxando na mesma direção porque a direção é óbvia.
Os PRs vêm de muitas mãos. Não é um mantenedor e seis figurantes. As notas de versão estão salpicadas de handles que eu não reconheço. Pull requests anônimos de gente que apareceu semana passada. O projeto se comporta como uma cena, não como uma codebase. E cenas, quando funcionam, entregam muito mais rápido que times.
A velocidade não é só contagem — é juros compostos. A v0.2.0 entregou o roteador. A v0.6.0 entregou cadeias de fallback em cima do roteador. A v0.7.0 entregou pools de credenciais em cima das cadeias de fallback. A v0.8.0 entregou troca de modelo ao vivo com /model em cima das três coisas. Cada release não é um conjunto avulso de funcionalidades; é uma camada que assume que a release anterior está estável. Não dá pra fazer isso se as releases não forem realmente estáveis. Então ou os testes são de verdade, ou a velocidade já teria matado o projeto. Não matou, e isso te diz algo.
Vale dizer que eu não faço parte do time do Hermes. Sou um fã que lê notas de versão por diversão e mantém esse site porque o projeto é mais interessante do que a superfície de marketing dele sugere. O que você está vendo, ao longo desses vinte e sete dias, são sete releases de evidência de que a engenharia de agentes na camada open-source ficou substancialmente mais interessante em março e abril de 2026. Eu não sei o que a v0.9.0 vai ser. Seja o que for, eu vou ler as notas no dia em que saírem.