Memória e contexto no Hermes: MEMORY.md, USER.md, providers e Context Engine Link para o cabeçalho

No primeiro artigo desta série, tratamos o Hermes Agent como um harness: a camada que transforma um modelo de linguagem em um agente capaz de agir, lembrar, usar ferramentas, respeitar permissões e conversar por diferentes interfaces.

Agora entramos na parte que mais muda a sensação de continuidade: memória e contexto.

Para quem nunca viu Hermes, a ideia central é simples:

O modelo responde.
O Hermes decide o que o modelo vai receber antes de responder.

Essa diferença parece pequena, mas é quase tudo. O Hermes monta o prompt, injeta instruções, carrega arquivos, procura sessões antigas, adiciona memória, expõe ferramentas e, quando a conversa fica longa, decide como reduzir ou reorganizar o contexto.

Por isso este post não é sobre “guardar tudo”. É sobre escolher o menor sistema de continuidade que ainda resolve o problema.

Memória responde:

O que vale guardar entre sessões?

Contexto responde:

O que deve entrar no prompt deste turno?

Quando bem usada, memória dá continuidade. Quando mal usada, vira ruído permanente. Quando bem montado, contexto ajuda o modelo a agir com precisão. Quando mal montado, joga no prompt uma mistura de histórico velho, instrução duplicada e detalhe irrelevante.

A ordem saudável é esta: primeiro entenda o padrão, depois os limites, depois as extensões.

O padrão recomendado: comece simples Link para o cabeçalho

O ponto de partida no Hermes não é instalar todos os providers. É usar o padrão.

Um padrão conservador tem estas peças:

Peça	Para que serve
`MEMORY.md`	fatos operacionais curtos que devem atravessar sessões
`USER.md`	preferências estáveis do usuário
arquivos de contexto	identidade, regras de projeto e convenções
context references	arquivos, diffs, URLs e imagens apontados no turno atual
session search	busca em conversas antigas quando necessário
`compressor`	context engine padrão para conversas longas

Isso já resolve muita coisa.

Você consegue abrir os arquivos, ler o que está sendo injetado, revisar uma memória ruim e entender por que o agente agiu de determinada forma. Essa auditabilidade é uma feature. Quanto mais automático e externo fica o sistema de memória, mais importante se torna responder perguntas chatas: onde o dado está, quem acessa, como apaga, como audita, como evita que uma lembrança velha vire certeza.

Então a regra prática é:

fique no padrão até conseguir nomear o limite que encontrou.

Se você ainda não sabe qual limite o padrão atingiu, provavelmente ainda não precisa de provider externo nem de context engine alternativo.

Infográfico mostrando como o Hermes combina memória, contexto e context engine para montar o prompt final antes de chamar o modelo.

O que é memória no Hermes Link para o cabeçalho

Memória é o que o Hermes carrega para dar continuidade entre sessões. Ela não deve ser um arquivo morto de tudo que aconteceu. Deve ser uma coleção pequena de informações que mudam o comportamento do agente em conversas futuras.

Na documentação oficial, a memória persistente curta fica principalmente em dois arquivos:

~/.hermes/memories/MEMORY.md
~/.hermes/memories/USER.md

O MEMORY.md guarda fatos operacionais sobre ambiente, projetos, convenções e aprendizados. O USER.md guarda preferências e modo de trabalho do usuário.

Essa separação importa.

Um fato como:

Este projeto Hugo usa npm run build:dev para validar drafts.

pertence ao MEMORY.md.

Uma preferência como:

O usuário prefere respostas em pt-BR, com incertezas explicitadas.

pertence ao USER.md.

Preferência pessoal não é fato de ambiente. Fato técnico não é traço de personalidade. Misturar tudo deixa o agente menos previsível.

Por que a memória é pequena Link para o cabeçalho

Segundo a documentação atual, os limites padrão são pequenos de propósito:

MEMORY.md: 2.200 caracteres, cerca de 800 tokens;
USER.md: 1.375 caracteres, cerca de 500 tokens.

Isso pode parecer pouco. Na prática, é uma defesa.

Memória persistente entra no prompt no começo da sessão. Tudo que você coloca ali concorre com instruções, contexto de projeto, skills, histórico e espaço útil do modelo. Memória demais vira imposto fixo em todas as conversas.

O Hermes força a pergunta certa:

isso precisa mesmo estar sempre disponível?

Se a resposta for “talvez um dia seja útil”, provavelmente não deve entrar. Se a resposta for “isso muda como o agente deve agir em quase toda sessão”, aí sim.

Como a memória muda Link para o cabeçalho

O agente gerencia memória com ações como add, replace e remove.

add: adiciona uma nova entrada;
replace: substitui uma entrada existente;
remove: remove uma entrada que deixou de ser útil.

O replace e o remove usam correspondência por substring. Não é preciso repetir a entrada inteira; basta indicar um trecho curto e único.

Exemplo conceitual:

Memória existente:
Projeto usa pnpm, Vitest e limite de linha de 100 caracteres.

Substituição:
old_text = "limite de linha de 100"
content = "Projeto usa pnpm, Vitest e limite de linha de 120 caracteres."

Isso incentiva edição cirúrgica. Memória boa não cresce indefinidamente; ela é podada.

Um detalhe fácil de perder: a memória é carregada como snapshot no início da sessão. Quando o agente adiciona, substitui ou remove algo durante uma conversa, a alteração é gravada em disco, mas não muda automaticamente o prompt da sessão atual. Ela entra de verdade na próxima sessão.

Esse comportamento evita que o agente fique mudando a própria base no meio do raciocínio.

O que salvar em memória Link para o cabeçalho

O MEMORY.md deve guardar fatos operacionais densos.

Bons exemplos:

Projeto Atlas é um site Hugo.
Artigos finais ficam em content/articles/**.
Rascunhos editoriais ficam em docs/drafts/**.

No projeto LegadoERP, arquivos de integração antigos
devem preservar o encoding original até a migração ser validada.

Para novos artigos técnicos:
draft: true, slug sem acentos e entre 2 e 4 tags.

Essas entradas são específicas, reutilizáveis e difíceis de inferir com segurança sem contexto anterior.

O USER.md deve guardar preferências e modo de trabalho:

Usuário prefere respostas em pt-BR.
Separar conclusão direta, fatos confirmados e incertezas.

Usuário costuma querer análise baseada em evidência real
antes de mudanças em código legado.

Usuário prefere que tarefas operacionais sejam executadas
até validação quando a direção já está clara.

Isso orienta postura, não conhecimento técnico de um repositório.

Em um post público, exemplos precisam ser sanitizados. Evite publicar nomes de clientes, caminhos internos, nomes reais de repositórios privados, regras operacionais específicas do seu ambiente ou qualquer detalhe que ajude alguém a reconstruir sua estrutura de trabalho.

O que não salvar Link para o cabeçalho

Memória ruim parece útil na hora, mas cobra juros depois.

Evite salvar:

perguntas triviais feitas uma vez;
trechos grandes de log;
código inteiro;
informação facilmente redescoberta;
caminhos temporários;
decisões que só valiam para uma sessão;
instruções já presentes em AGENTS.md, CLAUDE.md, SOUL.md ou arquivos equivalentes;
segredos, tokens, chaves e URLs privadas sensíveis.

Exemplo ruim:

Usuário perguntou sobre Hermes.

Isso não diz nada. Não melhora nenhuma sessão futura.

Exemplo melhor:

Usuário está criando uma série avançada em pt-BR
sobre Hermes Agent.
Foco: arquitetura, memória, CLI, skills, gateway,
segurança, Docker e ACP.

Mesmo assim, essa entrada só deveria existir se a série continuar sendo relevante depois desta sessão.

Session search: histórico não é memória Link para o cabeçalho

Além de MEMORY.md e USER.md, o Hermes armazena sessões em ~/.hermes/state.db, com busca full-text via FTS5.

Essa camada serve para perguntas como:

“o que decidimos sobre aquele projeto semana passada?”;
“qual foi o comando que funcionou naquele servidor?”;
“em qual sessão apareceu aquele erro?”;
“já conversamos sobre esse provider?”

A documentação chama isso de session_search. O agente pode buscar conversas passadas e receber um resumo gerado por modelo auxiliar.

Isso é diferente de memória.

Recurso	Melhor uso
`MEMORY.md`	fatos críticos que devem estar sempre no contexto
`USER.md`	preferências e perfil do usuário
session search	recuperar detalhes de conversas antigas sob demanda

Memória é pequena e entra cedo. Session search é grande, mas precisa ser buscada. Essa distinção evita transformar todo histórico em regra permanente.

Para o usuário, essa camada aparece em comandos como:

hermes sessions list

O objetivo é navegar sessões anteriores, retomar conversas e recuperar contexto quando ele realmente importa.

Segurança na memória Link para o cabeçalho

Memória é sensível porque vira parte do prompt. Uma entrada maliciosa pode tentar instruir o agente a ignorar regras futuras, vazar segredos ou executar comandos indevidos.

A documentação do Hermes indica que entradas de memória passam por varredura contra padrões de prompt injection, exfiltração de credenciais, backdoors SSH e caracteres invisíveis.

Mesmo com varredura, a regra prática continua:

não salve segredos;
não salve instruções que enfraquecem aprovação;
não salve conteúdo copiado de fonte não confiável como se fosse regra;
revise memórias geradas depois de tarefas sensíveis.

Memória deve aumentar continuidade, não reduzir segurança.

Quando a memória padrão não basta Link para o cabeçalho

O padrão começa a mostrar limite quando você precisa lembrar mais do que cabe em notas curtas.

Isso acontece quando:

há muitos projetos recorrentes;
decisões técnicas aparecem de novo com frequência;
padrões de código e arquitetura atravessam sessões;
session search encontra coisas úteis, mas exige esforço demais;
você precisa de memória semântica, relações, perfil ou recuperação estruturada.

É aí que entram os memory providers externos.

O ponto importante: provider externo é aditivo. Ele não substitui MEMORY.md, USER.md e session search. Ele roda junto.

Providers externos de memória Link para o cabeçalho

O Hermes lista providers externos como Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover e Supermemory.

Eles não têm todos a mesma finalidade. Alguns são simples e locais; outros são serviços cloud; outros tentam modelar o usuário; outros funcionam mais como base de contexto ou grafo de conhecimento.

Modelos de memória, do simples ao complexo Link para o cabeçalho

Arquivo curto curado: MEMORY.md e USER.md.
Histórico pesquisável: session search.
Memória local simples: Holographic.
Memória técnica local-first: ByteRover.
Memória como serviço: RetainDB, Mem0, Supermemory.
Modelagem de usuário e relacionamento: Honcho.
Base de contexto navegável: OpenViking.
Memória relacional com reflexão: Hindsight.

A ordem não é ranking de qualidade. É escala de complexidade operacional.

Holographic Link para o cabeçalho

Holographic é um provider local focado em memória simples e privada. Ele faz sentido quando você quer experimentar memória persistente sem começar por uma plataforma cloud.

Infra/hardware: local; sem GPU obrigatória documentada.
Prós: simples, privado e bom para experimentação.
Contras: menor ecossistema e menos recursos avançados.
Use quando: você quer uma alternativa local leve antes de subir para um provider mais complexo.

ByteRover Link para o cabeçalho

ByteRover é um provider voltado a memória técnica local-first. Ele é interessante quando o agente precisa lembrar padrões de desenvolvimento, decisões de código e aprendizados operacionais entre sessões.

Infra/hardware: local, com CLI/provider adicional.
Prós: bom para trabalho recorrente de desenvolvimento e memória técnica.
Contras: adiciona uma peça operacional e ainda exige curadoria.
Use quando: decisões de código e arquitetura precisam atravessar sessões com mais estrutura que MEMORY.md.

RetainDB Link para o cabeçalho

RetainDB oferece memória persistente como serviço, com integração por API.

Infra/hardware: cloud; localmente exige Hermes e API key.
Prós: setup rápido e menos operação local.
Contras: dependência externa, custo e necessidade de revisar retenção e exclusão.
Use quando: você quer memória como serviço e aceita delegar infraestrutura.

Mem0 Link para o cabeçalho

Mem0 é uma camada de memória adaptativa para aplicações com LLM, com versão gerenciada e versão open source.

Infra/hardware: cloud no modo gerenciado; self-hosted exige servidor, LLM provider e armazenamento conforme a arquitetura escolhida.
Prós: ecossistema maduro, API clara e opção open source.
Contras: cloud adiciona dependência externa; self-hosted adiciona operação.
Use quando: você quer extração automática de fatos e busca semântica sem desenhar tudo do zero.

Supermemory Link para o cabeçalho

Supermemory se posiciona como infraestrutura de memória e contexto para agentes, combinando memória, extração de conteúdo, conectores, sincronização e RAG gerenciado.

Infra/hardware: cloud; localmente exige Hermes, pacote e API key.
Prós: forte para ingestão de documentos, conectores e memória semântica.
Contras: mais plataforma do que simples arquivo local; exige avaliar custo e governança.
Use quando: memória e contexto precisam incluir documentos, conectores e grafo além da conversa do Hermes.

Honcho Link para o cabeçalho

Honcho adiciona modelagem de usuário cross-session ao Hermes. Em vez de só lembrar fatos soltos, tenta construir uma representação mais sofisticada de quem é o usuário e de como o agente interage com ele.

Infra/hardware: Honcho Cloud ou instância self-hosted.
Prós: forte em personalização, multiagentes e modelagem de usuário.
Contras: é sensível em privacidade: quanto mais o sistema modela você, mais importam auditoria, exclusão e limites.
Use quando: você quer um agente pessoal que aprenda padrões de comunicação, preferências e relações.

OpenViking Link para o cabeçalho

OpenViking é um context database open source para agentes. Ele organiza memória, recursos e skills com navegação hierárquica e carregamento em camadas.

Infra/hardware: self-hosted; exige instalar e operar servidor.
Prós: bom para conhecimento estruturado, navegação e contextos grandes com carregamento progressivo.
Contras: exige pensar em hierarquia e operar mais uma peça.
Use quando: você quer uma base de contexto navegável, local ou self-hosted, com estrutura explícita.

Hindsight Link para o cabeçalho

Hindsight adiciona memória de longo prazo com banco de memória, entidades, relações, recall multi-estratégia e reflect, uma síntese sobre memórias recuperadas.

Infra/hardware: cloud ou local; no local, pode usar servidor embutido com PostgreSQL e LLM para extração/síntese.
Prós: forte para conhecimento relacional, entidades e síntese entre memórias.
Contras: conceitualmente e operacionalmente mais pesado.
Use quando: você precisa recuperar fatos, relações, histórico e conclusões através de muitas sessões.

O que é contexto no Hermes Link para o cabeçalho

Se memória é o que atravessa sessões, contexto é o pacote que o modelo recebe agora.

Antes do modelo responder, o Hermes monta um prompt com várias camadas. A documentação de prompt assembly descreve uma ordem aproximada que inclui identidade, ferramentas, contexto vindo de provider externo, system message, MEMORY.md, USER.md, skills, arquivos de contexto e metadados de sessão.

Isso explica por que contexto é tão importante. O modelo não “sabe” simplesmente o que aconteceu. O harness decide o que entra na chamada.

No Hermes, existem fontes de contexto e context engines.

Fontes de contexto são lugares de onde o Hermes puxa material: prompt, arquivos, referências, sessão, skills, ferramentas e memória.

Context engine é a estratégia escolhida por context.engine para lidar com a conversa quando ela cresce demais. O padrão é o compressor.

Então a expressão “provedor de contexto” precisa de cuidado. O nome mais preciso, no Hermes, é context engine plugin. O restante são fontes de contexto.

Fontes de contexto, do simples ao complexo Link para o cabeçalho

Prompt explícito Link para o cabeçalho

É o contexto mais simples: você escreve a informação na própria pergunta.

Infra/hardware: nenhum requisito além do modelo usado.
Prós: explícito, auditável e fácil de corrigir.
Contras: não reaproveita conhecimento e pode virar prompt longo demais.
Use quando: a tarefa é pontual e o contexto cabe bem em poucas linhas.

Arquivos de contexto Link para o cabeçalho

Os context files guardam instruções estáveis que acompanham o agente. Entram aqui identidade, regras do projeto, preferências operacionais e convenções locais.

Exemplos típicos:

SOUL.md
AGENTS.md
.hermes.md
CLAUDE.md

Infra/hardware: filesystem local.
Prós: local, auditável, versionável e fácil de revisar.
Contras: se crescer demais, vira ruído sempre presente.
Use quando: a informação deve orientar muitas sessões e pode ser lida por humanos.

Context references Link para o cabeçalho

Context references apontam material específico para o turno atual: arquivo, pasta, diff, URL, imagem ou outro recurso.

Infra/hardware: depende da referência; arquivo local é barato, URL depende de rede, imagem consome mais contexto.
Prós: sob demanda, explícito e melhor que gravar tudo em memória.
Contras: depende de apontar a fonte certa no momento certo.
Use quando: a tarefa depende de um artefato concreto, como arquivo, diff, página ou screenshot.

Skills Link para o cabeçalho

Skills são pacotes de instrução, scripts e workflows. Elas não são memória, mas funcionam como contexto procedural: ensinam o agente a agir em um domínio.

Infra/hardware: normalmente local; pode depender de CLIs, scripts ou APIs.
Prós: padroniza tarefas recorrentes e reduz prompt manual.
Contras: skill ruim injeta processo ruim; skill demais pode disputar atenção com a tarefa.
Use quando: existe um workflow repetível, como revisar post, validar deploy ou analisar um tipo de código.

Toolsets, ferramentas e MCP Link para o cabeçalho

Toolsets são grupos de ferramentas. Eles conectam o agente ao ambiente real: terminal, arquivos, web, browser, memória, execução de código, MCP e integrações.

Infra/hardware: varia por ferramenta; terminal e arquivos são locais, web/MCP dependem de rede e credenciais.
Prós: contexto fresco, verificável e conectado ao estado real do sistema.
Contras: aumenta superfície de risco.
Use quando: a resposta precisa ser baseada no estado atual do sistema, não só em memória.

Memória como fonte de contexto Link para o cabeçalho

MEMORY.md, USER.md e providers externos também alimentam o contexto. Eles trazem fatos, preferências ou memórias recuperadas para a chamada do modelo.

Infra/hardware: depende da fonte: arquivo local, banco, cloud, API, CLI ou LLM auxiliar.
Prós: continuidade cross-session.
Contras: risco de recuperar coisa errada ou velha.
Use quando: o agente precisa de continuidade além do turno atual.

Context engines: compressor, LCM e custom Link para o cabeçalho

As fontes dizem o que pode entrar no contexto. O context engine decide como lidar com a janela de contexto quando a conversa cresce.

`compressor` Link para o cabeçalho

O compressor é o context engine padrão do Hermes. Ele usa sumarização com perda para reduzir mensagens quando a conversa se aproxima do limite de tokens. Segundo a documentação de context compression and caching, ele trabalha junto de uma higiene de sessão no gateway.

Infra/hardware: embutido no Hermes; depende do modelo usado para gerar resumo quando necessário.
Prós: vem pronto, é previsível e resolve a maior parte das conversas longas.
Contras: por ser sumarização com perda, pode apagar nuance, detalhes de ferramenta ou decisões antigas.
Use quando: você quer comportamento padrão, simples e suficiente para sessões longas normais.

`lcm` Link para o cabeçalho

O lcm aparece na documentação como exemplo de context engine plugin para Lossless Context Management. A proposta é preservar conhecimento em uma estrutura mais pesquisável, em vez de depender apenas de resumo com perda.

No GitHub, o projeto hermes-lcm é o caso experimental mais concreto que encontrei. Ele usa SQLite, organiza contexto em um DAG de resumos e expõe ferramentas como lcm_grep, lcm_describe e lcm_expand. Para usar, a configuração segue a ideia:

plugins:
  enabled:
    - hermes-lcm

context:
  engine: lcm

Infra/hardware: plugin instalado, armazenamento local e processamento adicional conforme a implementação.
Prós: melhor para continuidade longa, recuperação estruturada e redução de perda conceitual.
Contras: mais complexo, experimental e precisa ser observado para não criar falsa sensação de memória perfeita.
Use quando: a conversa fica longa, o histórico importa e o resumo simples começa a perder decisões relevantes.

Context engine customizado Link para o cabeçalho

A documentação de context engine plugin permite criar um engine próprio implementando a interface ContextEngine. Ele precisa decidir quando comprimir, como comprimir, acompanhar tokens e devolver uma lista válida de mensagens.

Isso é poderoso, mas é outra categoria de trabalho. Você deixa de configurar o Hermes e passa a operar software próprio.

Infra/hardware: depende da implementação: pode usar banco local, embeddings, grafo, cache ou LLM auxiliar.
Prós: adapta o gerenciamento de contexto ao domínio real do agente.
Contras: exige código, testes, operação e política clara de privacidade e retenção.
Use quando: o problema de contexto é específico demais para compressor ou lcm.

Na pesquisa atual, não encontrei outro context engine pronto com maturidade comparável para listar como opção principal. O que existe é a arquitetura para criar engines e o hermes-lcm como experimento prático. Há também discussões no GitHub sobre engines plugáveis e documentação de instalação de engines de terceiros, o que reforça que esse ecossistema ainda está nascendo.

Como decidir: memória ou contexto? Link para o cabeçalho

Quando algo parece “faltar” no agente, primeiro identifique o tipo de falta.

Matriz de memória Link para o cabeçalho

Use esta matriz quando o problema é continuidade entre sessões.

MEMORY.md e USER.md: use quando simplicidade, auditabilidade e baixo risco bastam. Resolvem fatos e preferências curtos no prompt. O custo é curadoria manual.
Session search: use quando você precisa recuperar uma conversa antiga sob demanda. Evita transformar histórico inteiro em memória permanente. O custo é depender da busca certa.
ByteRover: use quando padrões técnicos e decisões de código precisam atravessar sessões. Resolve memória técnica local-first mais estruturada. O custo é operar provider adicional e manter curadoria.
Holographic: use quando a prioridade é memória local, leve e experimental. Resolve busca local mais rica sem cloud obrigatória. O custo é menor ecossistema e menos recursos avançados.
Outros memory providers: use quando você precisa de perfil, colaboração ou backend específico. Resolvem continuidade cross-session mais especializada. O custo é privacidade, custo financeiro e governança.

Matriz de contexto Link para o cabeçalho

Use esta matriz quando o problema é montagem, preservação ou redução do contexto do turno atual.

Arquivos de contexto: use quando regras de projeto, identidade e convenções são estáveis. Evitam repetir instruções em todo prompt. O custo é virar ruído se crescerem demais.
Context references: use quando a tarefa depende de arquivo, diff, URL ou imagem específica. Injetam contexto preciso no turno atual. O custo é apontar a fonte certa.
Skills, toolsets e MCP: use quando o agente precisa de processo ou observação do ambiente real. Transformam contexto em ação verificável. O custo é maior superfície operacional.
compressor: use quando conversa longa comum precisa caber na janela de contexto. Reduz tokens automaticamente. O custo é que resumo com perda pode apagar nuance.
lcm: use quando o problema é perda de contexto em conversas longas. Preserva contexto de forma mais rica que resumo simples. O custo é plugin, diagnóstico e complexidade.
Context engine customizado: use quando há requisito de domínio que compressor e lcm não cobrem. Resolve estratégia própria de compressão e recuperação. O custo é código, testes e governança.

O erro comum é tentar resolver problema de contexto com memória permanente. Se a tarefa precisa de um arquivo específico, use context reference. Se precisa de uma regra estável do projeto, use arquivo de contexto. Se precisa lembrar uma preferência, use USER.md. Se precisa recuperar uma decisão antiga, use session search. Se isso virou recorrente e semântico, aí sim pense em provider.

Receita prática Link para o cabeçalho

Eu usaria este padrão:

Comece com arquivos de contexto para identidade, regras do projeto e convenções.
Use USER.md para preferências pessoais e modo de trabalho.
Use MEMORY.md para fatos operacionais densos.
Use context references para artefatos concretos da tarefa atual.
Use session search para recuperar histórico antigo sob demanda.
Mantenha compressor enquanto a conversa longa comum estiver boa o suficiente.
Adicione memory provider quando o limite for continuidade entre sessões.
Considere lcm quando o limite for perda de contexto em conversas longas.
Considere context engine customizado só quando houver requisito de domínio que justifique operar software próprio.

Essa ordem evita usar memória como gaveta universal e evita instalar provider por curiosidade.

Checklist final Link para o cabeçalho

Antes de adicionar memória, provider ou engine, pergunte:

Isso é memória ou contexto do turno atual?
Isso será útil em várias sessões?
A informação é específica o bastante?
É seguro injetar isso no prompt?
Já existe em algum arquivo de contexto?
Poderia ser recuperado por session search em vez de virar memória?
O problema é perda de contexto por conversa longa?
O compressor realmente falhou ou eu só apontei contexto ruim?
Quem vai revisar, apagar ou corrigir memórias antigas?
Há dados sensíveis envolvidos?

Se a resposta não estiver clara, fique no padrão. Ele é menos glamouroso, mas mais fácil de entender, auditar e consertar.

Conclusão Link para o cabeçalho

Memória e contexto são o que fazem o Hermes parecer contínuo.

MEMORY.md e USER.md guardam o que deve acompanhar o agente entre sessões. Session search recupera o passado quando necessário. Memory providers aumentam a profundidade quando a memória curta não basta. Arquivos, referências, skills e ferramentas montam o contexto do turno atual. O compressor segura a conversa longa comum. O lcm e engines customizados entram quando o problema deixa de ser “lembrar” e passa a ser “preservar contexto sem perder estrutura”.

A regra de ouro é simples:

use a menor camada que resolve o problema com segurança.

No próximo post, vamos usar essa base para falar de perfis: como criar múltiplos agentes no Hermes, cada um com HERMES_HOME, identidade, memória, sessões e gateway próprios.