Já mantiveste um chat aberto de segunda a sexta, a ver o context crescer mais pesado e mais caro a cada resposta — e, mesmo assim, o Hermes nunca parecia ficar mais esperto, nem sequer lembrar-se da preferência que lhe disseste na semana passada? Um developer partilhou esta semana a sua própria versão dessa história (I think I used the Hermes Agent wrong), e a conclusão dele merece ser lida com atenção: o problema pode ser que ele quase nunca terminava uma sessão.

A correr o Hermes num Raspberry Pi com Telegram, ele passou 18 dias com apenas 5 sessões — todas as noites o Pi desligava e todas as manhãs o Hermes retomava silenciosamente a sessão anterior. O resultado: ao longo de 1.990 mensagens, o Hermes usou proativamente o session_search (o tool de recuperação entre sessões) apenas 9 vezes, e os ficheiros de memória quase não mudaram. A razão não é o agente ter ficado mais burro. Tudo o que era importante continuava na context window, por isso não havia nada para lembrar. A memória de longo prazo do Hermes, no entanto, é explicitamente desenhada à volta do pressuposto de que as sessões acabam.

Como funciona realmente a memória do Hermes

O Hermes guarda dois tipos de memória persistente, e perceber cada um explica porque é que os limites interessam.

As notas entre sessões: MEMORY.md e USER.md. Cada profile guarda estes ficheiros de texto (mais o SOUL.md, opcional): o USER.md armazena factos sobre ti; o MEMORY.md, notas e preferências que o Hermes foi acumulando. No arranque de uma sessão nova, os dois ficheiros são injetados no context para o Hermes se lembrar de quem és e do que aprendeu. Mas têm um teto de tamanho — os padrões na fonte são memory_char_limit: 2200 e user_char_limit: 1375, mais ou menos 800 e 500 tokens. Perto do teto, o Hermes tem de usar o memory tool para fundir, aparar e priorizar — mantendo o que mais importa.

O arquivo do histórico completo: state.db. Cada mensagem vive numa base de dados SQLite local. O session_search é o tool que permite ao Hermes olhar para fora da sessão atual — «como é que resolvi aquela falha de CI da última vez?». É essa a outra metade do desenho: quando o context não aguenta tudo, a recuperação traz de volta os detalhes antigos.

E quando é que a escrita acontece? Além do uso explícito do memory tool a meio da conversa, o Hermes corre uma background review: depois de cada turn, revisita a conversa de forma assíncrona e destila o que vale a pena persistir — lições, correções, preferências. Esse ciclo só funciona bem quando as sessões têm fins naturais: assentar um lote no fim, injetá-lo no arranque seguinte e repetir.

O que acontece quando nunca terminas uma sessão

Põe esse desenho em cima de uma única sessão de 18 dias e o modo de falha é óbvio:

• Os ficheiros de memória tornam-se decoração. MEMORY.md/USER.md são injetados no arranque da sessão — numa mega-sessão, o conteúdo deles já está no context, por isso o Hermes nunca precisa dos ficheiros para «recuperar» nada, e a background review não encontra nada que valha a pena atualizar. Ficam em silêncio desatualizados.
• O session_search raramente dispara. O tool existe para o «não está no context, mas está no histórico». Numa sessão interminável, a semana passada ainda está na janela, por isso a recuperação não tem trabalho. Nove usos em 1.990 mensagens não é burrice — é um tool sem nada para fazer.
• O custo e a latência sobem. Cada turn reenvia o histórico, sempre a crescer, para o modelo; a fatura de tokens escala com o tamanho da sessão. Perto do limite da janela, entra a compression, que dobra o conteúdo antigo em resumos — resumos com perdas, onde os detalhes se evaporam em silêncio.
• Perdes as camadas da memória. A mega-sessão baralha o context de curto prazo e a memória de longo prazo no mesmo pote. Lembrar-se de tudo significa não se lembrar de nada com precisão: preferências duradouras que deviam estar numa nota e detalhes pontuais que deviam estar na pesquisa, tudo a cozinhar junto.

Quando começar do zero, quando retomar

As boas notícias: a regra é simples. A tarefa ainda está em curso?

Retoma a sessão quando:

• A mesma tarefa está inacabada — só em pausa (saíste a meio de um documento longo);
• O passo seguinte precisa de context transitório (um caminho de ficheiro, o código exato que estás a depurar) e não vale a pena voltar a explicá-lo;
• Estás a alternar entre tarefas no mesmo terminal e queres manter intacto o histórico de cada thread.

Começa uma sessão nova quando:

• A tarefa anterior foi entregue ou está claramente concluída — até um «feito por agora» conta;
• O tema mudou e as duas tarefas não partilham nenhum context que tenhas de arrastar;
• O context já é grande (vê o uso de tokens na barra de estado ou em vistas ao estilo de hermes status) e a tarefa nova não vai usar o conteúdo antigo;
• Queres que o Hermes se lembre mesmo desta conversa — terminá-la deixa a background review destilar as conclusões.

A forma certa de mudar: antes de começares algo novo, pede ao Hermes que escreva na memória as conclusões que valem a pena guardar, ou arquiva a conversa com o comando /save de que falámos antes. Quando retomares, o truque de retoma por terminal hermes chat -c mantém cada terminal na sua própria thread. E se os dados de sessão alguma vez se portarem mal, o nosso guia de campo para incidentes de sessão percorre o diagnóstico e a recuperação.

Faz dos limites de sessão um hábito

A história do developer vale a pena ser partilhada porque ele não apanhou um bug — apanhou um desajuste de uso, a usar um sistema de memória feito para muitas sessões como se fosse uma thread sem fim. Não precisas de terminar sessões com um temporizador; abre simplesmente uma nova, com naturalidade, quando uma tarefa chega ao fim. Assim, a injeção dos ficheiros, a consolidação da background review e a recuperação do session_search fazem cada uma o seu trabalho. Sessões com limites dão um ciclo à memória — e um Hermes que se lembra mesmo de ti é aquele para o qual o instalaste.