A maioria das interfaces de chat com IA que você já usou não tem memória de verdade. Elas têm uma janela de contexto, que é algo bem diferente. O que você disse mais cedo na mesma conversa ainda está na frente do modelo. O que você disse na conversa de ontem, sumiu. No dia seguinte você começa do zero, e o assistente se apresenta de novo como um estranho.
O Hermes Agent é diferente. Ele tem uma camada real de memória — separada do contexto da conversa — que aprende coisas sobre você ao longo do tempo, carrega essas coisas entre sessões e plataformas, e faz o bot se comportar como a mesma entidade toda vez que você fala com ele. Este post é sobre como isso funciona de verdade, quais decisões importam, e o que a interface plugável de memória da v0.7.0 mudou.
Memória de curto prazo vs memória de longo prazo
Primeiro, a distinção que importa.
Memória de curto prazo no Hermes é a janela de contexto da sessão. É uma fatia do histórico da conversa que o agente está tendo, gerenciada com uma estratégia proativa de compressão: quando o contexto chega perto do limite do modelo, o Hermes roda um passo de sumarização que colapsa turnos antigos num resumo estruturado, preservando as trocas mais recentes na íntegra. A compressão foi refinada ao longo de várias releases — resumos estruturados com atualizações iterativas na v0.4.0, proteção de cauda por budget de tokens, endpoint de sumarização configurável e suporte a modelo de fallback. Em conversas longas, isso mantém o agente rápido e barato sem perder contexto importante.
Memória de longo prazo é a parte interessante. É um store de fatos, preferências, correções e modelos de usuário que vive fora da conversa. Quando você diz pro bot "meu nome é Alice" no Telegram hoje, esse fato é gravado na memória de longo prazo. Amanhã, quando você perguntar algo pelo Slack, o fato é puxado e injetado no contexto antes do agente ver sua mensagem. O modelo ainda só recebe o que cabe na janela, mas a janela é preparada com coisas que ele deveria saber sobre você.
Memória de curto prazo é um buffer. Memória de longo prazo é uma pessoa.
Honcho: o que é e por que importa
O provider padrão de memória de longo prazo no Hermes é o Honcho, uma biblioteca construída especificamente pra memória nativa de IA. O trabalho do Honcho é rodar por trás do agente e fazer três coisas específicas:
- 1.Observar. Cada mensagem do usuário e cada resposta do agente alimentam o Honcho como um stream de eventos. O Honcho constrói um modelo interno do usuário a partir desse stream — não histórico bruto de chat, mas fatos estruturados e preferências inferidas da conversa.
- 2.Raciocinar sobre o usuário. O Honcho roda uma camada "dialética" que tenta construir uma imagem coerente de quem você é, o que quer e o que corrigiu. Não é só extração de palavras-chave — é um modelo mental contínuo do usuário.
- 3.Injetar. Em cada turno novo, o Honcho produz um snippet curto de contexto resumindo o que acha relevante sobre o usuário, que o Hermes prefixa ao system prompt. O snippet muda conforme o Honcho aprende mais.
Dois detalhes merecem atenção porque são fáceis de passar batido.
Primeiro, as escritas do Honcho são assíncronas. O agente não bloqueia numa escrita de memória. Ele responde, e a camada de memória processa a troca em background. Isso significa que conversas longas não pagam taxa de latência por updates de memória, e uma queda do backend de memória não para o bot — você perde updates durante a queda, mas o assistente continua conversando.
Segundo, o recall do Honcho é mantido fora do prefixo de sistema cacheado. O recurso de cache de prompt da Anthropic (usado pesadamente em modelos como Claude Sonnet 4.6) quer que o system prompt seja estável entre turnos pra o cache acertar. O snippet injetado do Honcho muda turno a turno, então o Hermes deliberadamente o adiciona depois da seção de sistema cacheada. O cache continua funcionando pros pedaços estáticos; a camada dinâmica de memória continua funcionando pros pedaços que mudam. É o tipo de tradeoff mecânico que não entra nas release notes mas decide se sua conta mensal é $50 ou $500.
Isolamento multi-usuário no modo gateway
O gateway padrão do Hermes roda múltiplos usuários pelo mesmo processo de agente. A memória de longo prazo precisa ser por usuário, senão as alergias da Alice acabam nas sugestões culinárias do Bob. A v0.3.0 adicionou isolamento multi-usuário adequado pro Honcho dentro do gateway, que na prática significa:
- •Cada ID de usuário do gateway mapeia pra um peer Honcho distinto, e escritas de memória são escopadas por peer.
- •Sessões de chat em grupo herdam sessões por usuário por padrão, então um canal compartilhado ainda grava streams de memória separados pra cada participante.
- •Isolamento de memória por perfil (v0.5.0/v0.6.0) significa que se você roda múltiplos perfis do Hermes na mesma máquina, a memória de cada perfil é um universo separado. Trocar de perfil não vaza uma persona na outra.
Nada disso é visível pros usuários. Tudo isso é o motivo pelo qual o bot não lembra acidentalmente a pessoa errada.
A interface plugável de memória (v0.7.0)
Nas cinco primeiras releases do Hermes, o Honcho era hardwired. Na v0.7.0 a camada de memória foi refatorada numa interface de provider adequada — uma ABC pequena em Python que qualquer backend de memória pode implementar. A mudança é arquiteturalmente modesta e praticamente enorme.
A interface permite trocar backends de memória sem mexer no core do Hermes:
- •Honcho é o provider de referência (e ainda é o padrão). É completo, roda um modelo de usuário real e trata isolamento multi-usuário corretamente.
- •Supermemory foi adicionado na v0.8.0 como segundo provider de primeira classe, com suporte multi-container, modos de busca configuráveis e templating de identidade.
- •mem0, OpenViking, RetainDB, Hindsight e ByteRover todos têm plugins de memória comunitários no sistema de plugins do Hermes, com profundidade variada de integração.
- •Você também pode escrever o seu. A ABC é pequena: implemente
write(),recall(), alguns hooks de ciclo de vida, e registre como plugin.
O provider de memória embutido — o padrão sem dependências se você não configurou nada — é um store de fatos com SQLite que cuida do básico: gravar fatos, buscar por relevância, escopar por usuário. Não é tão esperto quanto o Honcho, mas não precisa de serviço externo, e pra um assistente pessoal numa VPS de 5 dólares geralmente é tudo que você precisa.
O que isso desbloqueia silenciosamente
Memória plugável é o tipo de mudança arquitetural que parece trabalho de zelador nas release notes. "Refatorou memória pra interface de provider" não é manchete. O que realmente faz é desacoplar a pergunta "o que um assistente de IA deveria lembrar sobre você" da pergunta "como o Hermes funciona."
Agora dá pra substituir o Honcho por um backend de memória afinado pro seu caso — um vector store pra quem quer busca semântica sobre uma base de conhecimento pessoal, um banco de dados em grafo pra quem quer relações explícitas entre entidades, um store SQLite puramente local pra quem não quer que dados de memória saiam da máquina, um serviço de memória interno da empresa pra equipes. O agente não muda. Só o que está atrás da interface memory muda.
Essa é a abstração certa pra um projeto que quer existir daqui a alguns anos. Memória é pessoal, e o backend de memória certo pra você não é necessariamente o certo pra qualquer outra pessoa. O trabalho do Hermes é ser um bom cidadão pra qualquer camada de memória que você plugar, e sair do caminho.