Sistema de Memória do Hermes Agent: Como a Memória Persistente de IA Realmente Funciona

Você já conhece o processo. Você abre um chat com um agente de IA, explica seu projeto, compartilha suas preferências, realiza algum trabalho e fecha a aba. Volta na semana seguinte e é como falar com um estranho — todo o contexto se foi, cada preferência foi esquecida, o projeto precisa ser reexplicado do zero.

Isso não é um bug. É como os Large Language Models funcionam por design. Eles são “stateless” (sem estado): cada requisição é independente, cada resposta é gerada a partir de qualquer prompt que você envie agora, sem memória, sem histórico e sem continuidade além dos tokens na janela de contexto atual.

Para interações de turno único, isso funciona bem. Você faz uma pergunta, recebe uma resposta e segue em frente. Mas para agentes — sistemas que devem fazer coisas ao longo de várias sessões, aprender com erros e evoluir com você — a falta de estado é um limite arquitetural rígido. É um dos problemas centrais não resolvidos nos self-hosted AI systems.

A indústria tentou resolver isso. O LangChain adicionou módulos de memória. A OpenAI introduziu assistentes com threads. Frameworks como Letta, Zep e Cognee construíram arquiteturas inteiras em torno de memória persistente. A Databricks publicou sobre “memory scaling” — a ideia de que o desempenho do agente melhora com a experiência acumulada. Artigos de benchmark dedicados, pesquisas sobre memória episódica e um ecossistema de ferramentas em rápido crescimento surgiram desde 2024 para abordar o que é cada vez mais reconhecido como um dos problemas centrais não resolvidos na IA de agentes.

A maioria dessas abordagens compartilha um problema comum: elas tratam a memória como algo secundário — um banco de dados que você consulta, uma janela de contexto que você preenche, um sistema de recuperação que adiciona latência e ruído em vez de clareza.

O Hermes Agent adota uma abordagem fundamentalmente diferente. A memória não é algo que o agente recupera quando necessário. É algo que o agente é o tempo todo — integrada ao system prompt, curada, delimitada e sempre ativa. É pequena o suficiente para ser rápida, estruturada o suficiente para ser útil e disciplinada o suficiente para saber o que esquecer.

Este artigo explica exatamente como isso funciona.

Parte 1: O Problema da Memória do Agente de IA

Por que “Apenas Adicionar Contexto” não escala para Agentes

A solução óbvia para a IA sem estado é adicionar contexto. Anexar a conversa anterior. Incluir a documentação do projeto. Enviar todo o histórico.

Por um tempo, isso funciona. Você tem uma janela de contexto de 128K. Você pode colocar muito texto ali.

Mas contexto não é memória — existe uma diferença real e importante entre eles. Contexto é tudo o que lhe é mostrado agora; memória é o que você mantém e carrega ativamente para frente.

O contexto não possui curadoria. É um descarte: à medida que cresce, o modelo precisa processar milhares de tokens de histórico irrelevante para encontrar o único fato de que precisa. Isso custa tokens e dinheiro, aumenta a latência e, eventualmente, atinge o limite.

A memória é curada. É a destilação da experiência em algo compacto e acionável. Ela não cresce indefinidamente — ela consolida, atualiza e esquece.

A memória humana funciona da mesma forma. Você não se lembra de todas as conversas que já teve. Você se lembra das partes que importam: com quem está falando, o que interessa à pessoa, o que vocês concordaram, o que você aprendeu. O resto é esquecido ou pesquisável quando você precisa.

O Cenário de Pesquisa

O espaço de memória de agentes de IA explodiu desde 2024, com suítes de benchmark dedicadas, uma literatura de pesquisa crescente e uma lacuna de desempenho mensurável entre diferentes abordagens arquiteturais. Aqui está a situação atual.

Letta (anteriormente MemGPT) foi um dos primeiros frameworks a tratar a memória persistente como uma preocupação de primeira classe, alcançando 21,7 mil estrelas no GitHub. Utiliza um modelo de três camadas inspirado em sistemas operacionais: memória central (pequena, sempre no contexto), memória de recall (histórico de conversação pesquisável) e memória de arquivo (armazenamento frio de longo prazo). A percepção de que nem toda memória é igual estava correta. A implementação, no entanto, exige que os agentes funcionem inteiramente dentro do runtime da Letta — adotá-la significa adotar toda a plataforma, não apenas uma camada de memória.

Zep / Graphiti foca em memória conversacional com rastreamento de entidades temporais — os fatos possuem janelas de validade para que o grafo saiba quando algo era verdadeiro. É forte para chatbots que precisam de grafos de relacionamento, sendo menos adequado para agentes autônomos que rastreiam fatos do ambiente e convenções de projeto.

Cognee foi construído para extração de conhecimento de documentos e dados estruturados, com mais de 30 conectores de ingestão e um backend de grafo de conhecimento. Ele se destaca em conhecimento institucional e RAG pipelines, mas é menos focado na memória pessoal do agente. Veja self-hosting Cognee with local LLMs para um guia de configuração prática.

Hindsight faz recall baseado em grafos de conhecimento com relacionamentos de entidades e uma ferramenta de síntese única chamada reflect, que realiza síntese entre memórias — combinando múltiplas memórias em novos insights. Está entre os melhores desempenhos em benchmarks de memória de agentes e está disponível como um provedor de memória para o Hermes Agent.

Mem0 lida com a extração de memória no lado do servidor via análise de LLM, exigindo configuração mínima. O artigo de pesquisa do Mem0, publicado no ECAI 2025 (arXiv:2504.19413), testou dez abordagens distintas de memória de IA e validou a abordagem de extração seletiva — armazenando fatos discretos, removendo duplicatas e recuperando apenas o que é relevante. O Mem0 cresceu para aproximadamente 48 mil estrelas no GitHub e suporta 21 integrações de frameworks. A desvantagem é a dependência da nuvem e o custo.

A pesquisa de memory scaling da Databricks introduziu o conceito de que o desempenho do agente melhora com a experiência acumulada. Sua arquitetura mantém system prompts, ativos corporativos e memórias episódicas/semânticas delimitadas em nível de organização e usuário, validando a ideia de que a qualidade da memória importa tanto quanto a capacidade do modelo.

O fio condutor na maioria dos frameworks é que eles tratam a memória como um problema de recuperação: armazene-a em algum lugar, consulte-a quando necessário, injete-a no contexto. O Hermes faz o oposto — a memória não é recuperada sob demanda, ela é injetada no início da sessão e está sempre presente. Sempre ativa, sempre disponível, suficientemente curada para permanecer útil.

Parte 2: Arquitetura

Leia esta parte de cima para baixo — primeiro as camadas e o recall/store por turno, depois o que reside em MEMORY.md e USER.md, e por fim como anexar um provedor externo.

Duas camadas

O Hermes empilha a memória em duas camadas:

1. Built-in (Integrada) — MEMORY.md e USER.md, baseadas em arquivos, sempre ativas. Limites rígidos de 2.200 caracteres (notas do agente) e 1.375 caracteres (perfil do usuário).
2. Um provedor externo (opcional) — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory e outros que você habilitar via configuração. Apenas um backend externo é executado por vez. Ele adiciona recuperação e retenção além dos arquivos; ele não os substitui.

O modelo mental é aditivo — arquivos centrais congelados mais, no máximo, um plugin. Hooks de prefetch e sync orquestram a camada externa; os dois arquivos permanecem injetados separadamente como parte do system prompt congelado.

Fluxo de tempo de execução (prefetch e sync)

O recall acontece antes de o modelo responder; a persistência acontece após a mensagem do assistente. No gerenciador de memória do Hermes Agent, isso mapeia para prefetch na entrada e sync na saída. Os nomes abaixo correspondem à interface de implementação (MemoryManager, por provedor prefetch / sync_turn / queue_prefetch).

Mensagem do usuário
    |
    v
MemoryManager.prefetch_all(query)        <-- fase de recall
    |
    +-- provider.prefetch(query)        <-- cada provedor externo pesquisa seu armazenamento
    |
    v
Contexto injetado no turno do LLM
    |
    v
LLM responde (mensagem do assistente)
    |
    v
MemoryManager.sync_all(user, assistant)  <-- fase de armazenamento
    |
    +-- provider.sync_turn(user, assistant)
    +-- provider.queue_prefetch(user)    <-- busca em segundo plano para o próximo turno

Os arquivos integrados MEMORY.md e USER.md não são buscados através de prefetch_all — eles já fazem parte do system prompt congelado. Backends externos conectam-se a prefetch_all / sync_all; o queue_prefetch permite que um provedor prepare a recuperação para o turno seguinte sem bloquear a resposta atual.

Três caminhos para a memória de longo prazo

1. Ferramenta memory integrada. O modelo chama memory com add, replace ou remove quando as instruções indicam que algo deve persistir — fatos duradouros, preferências, correções, notas de ambiente. target='user' mantém o USER.md; target='memory' mantém o MEMORY.md. Exemplo de formato: memory(action='add', target='user', content='…').

2. Retenção passiva em provedores externos. A cada turno, o framework invoca o caminho de sincronização do provedor para que a conversa possa ser fragmentada, resumida ou extraída sem que o modelo nomeie cada fato. O comportamento varia conforme o backend — por exemplo, o Hindsight agrupa turnos e executa retenção estruturada com entidades e relacionamentos; o Honcho envia o diálogo através de seu pipeline dialético; pilhas no estilo Mem0 e Supermemory extraem fatos passivamente dos turnos.

3. Ferramentas específicas do provedor. Quando o plugin as expõe, escritas explícitas como honcho_conclude, hindsight_retain ou honcho_profile armazenam fatias duradouras sob demanda.

Recall automático versus ferramentas do provedor

A memória central não precisa de uma ferramenta de leitura — ela já está no prompt. Backends externos adicionam ou a injeção automática via prefetch (sem chamada de ferramenta de recall separada para aquela fatia de contexto) ou ferramentas de recuperação explícitas (honcho_search, honcho_reasoning, honcho_context, hindsight_recall, hindsight_reflect e similares) quando o modelo precisa de uma consulta mais precisa do que apenas o prefetch.

Modos de recall (provedores externos)

Os plugins suportam um modo de recall configurável (tipicamente recall_mode ao lado de memory.provider na configuração) que troca tokens por controle.

Quando nenhum provedor externo é definido (memory.provider vazio ou não definido), aplicam-se apenas os arquivos integrados e a busca de sessão — sem prefetch/sync de um plugin.

Caminhos no disco e orçamentos

A memória integrada do Hermes Agent reside em dois arquivos.

• ~/.hermes/memories/MEMORY.md — Notas pessoais do Agente (2.200 caracteres, ~800 tokens)
• ~/.hermes/memories/USER.md — Perfil do Usuário (1.375 caracteres, ~500 tokens)

Essa é toda a superfície de memória persistente: dois arquivos, menos de 3.600 caracteres no total, menos de 1.300 tokens. Parece deliberadamente pequeno porque é — e esse é exatamente o objetivo do design.

MEMORY.md: As Notas do Agente

É aqui que o agente armazena tudo o que aprende sobre seu ambiente, o projeto, ferramentas, convenções e lições aprendidas. Veja como é:

O projeto do usuário é um microserviço Go em ~/code/gateway usando gRPC + PostgreSQL
Esta máquina executa Ubuntu 22.04, tem Docker e kubectl instalados
O usuário prefere snake_case para nomes de variáveis e evita camelCase

Estes não são logs. São fatos. Densos, declarativos, carregados de informações. Sem timestamps, sem enrolação, sem “em 5 de janeiro o usuário me pediu para…”.

USER.md: O Perfil do Usuário

É aqui que o agente armazena tudo o que sabe sobre você.

O usuário é um desenvolvedor full-stack familiarizado com TypeScript, Go e Python.
O usuário prefere snake_case para nomes de variáveis e evita camelCase.
O usuário utiliza principalmente Linux Ubuntu 22.04.
O usuário faz deploy na AWS usando Terraform.

Identidade, função, preferências, habilidades técnicas, estilo de comunicação, irritações. As coisas que fazem o agente responder de forma diferente para você do que para qualquer outra pessoa.

O Padrão de Snapshot Congelado

No início da sessão, ambos os arquivos são carregados do disco e injetados como um bloco congelado no system prompt. Veja como fica:

══════════════════════════════════════════════
MEMORY (suas notas pessoais) [7% — 166/2.200 caracteres]
══════════════════════════════════════════════
O projeto do usuário é um microserviço Go em ~/code/gateway usando gRPC + PostgreSQL
§
Esta máquina executa Ubuntu 22.04, tem Docker e kubectl instalados
§
O usuário prefere snake_case para nomes de variáveis e evita camelCase
§

══════════════════════════════════════════════
USER PROFILE (quem é o usuário) [8% — 110/1.375 caracteres]
══════════════════════════════════════════════
O usuário é um desenvolvedor full-stack familiarizado com TypeScript, Go e Python.
§
O usuário prefere snake_case para nomes de variáveis e evita camelCase.
§

O formato utiliza cabeçalhos, porcentagens de uso, contagem de caracteres e delimitadores § (sinal de seção). As entradas podem ser de múltiplas linhas. Foi projetado para ser analisável pelo modelo, mantendo-se legível para humanos.

Por que congelado? Prefix caching. O system prompt é o mesmo em todos os turnos de uma sessão. Ao manter a memória estática após o início da sessão, o modelo pode fazer o cache da computação do prefixo e processar apenas as partes variáveis — a conversa. Esta é uma otimização de desempenho significativa. Você não está recomputando a atenção sobre os mesmos tokens de memória em cada turno.

As alterações feitas durante uma sessão persistem no disco imediatamente, mas só aparecem no system prompt no início da próxima sessão. As respostas de ferramentas sempre mostram o estado atual, mas a “mente” do modelo não muda no meio da sessão. Isso evita que o modelo fique “andando em círculos” — atualizando a memória e reagindo à própria atualização na mesma conversa.

Limites de Caracteres como um Recurso

2.200 caracteres. 1.375 caracteres. Estes não são limites arbitrários. São restrições de design que forçam a curadoria.

Memória ilimitada é um passivo. Ela incentiva o descarte de tudo, sem nunca consolidar, tornando-se eventualmente ruído. Memória delimitada força o agente a ser seletivo. O que é realmente importante? O que eu precisarei novamente? O que pode ser compactado sem perder o significado?

Quando a memória está cheia, o agente não falha silenciosamente. Ele recebe um erro com as entradas atuais e o uso, e então segue um fluxo de trabalho:

1. Lê as entradas atuais da resposta de erro
2. Identifica entradas removíveis ou consolidáveis
3. Usa replace para mesclar entradas relacionadas em versões mais curtas
4. Adiciona a nova entrada

É assim que a memória permanece útil. Não é um banco de dados. É uma coleção curada de fatos que importam.

Segurança: Escaneamento de Prompt Injection

Cada entrada de memória é escaneada antes da aceitação. O sistema bloqueia tentativas de prompt injection, exfiltração de credenciais, backdoors de SSH e caracteres Unicode invisíveis.

A memória também é desduplicada. Entradas duplicadas exatas são rejeitadas automaticamente. Isso evita que adversários tentem injetar conteúdo malicioso através de submissões repetidas.

Provedores de memória externos (ativação e links)

Além do MEMORY.md e USER.md integrados, o Hermes Agent pode anexar um plugin de memória externo por vez — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover ou Supermemory — para conhecimento persistente entre sessões. Apenas um provedor externo fica ativo de cada vez; os dois arquivos centrais permanecem carregados junto com ele (aditivo, não substitutivo).

Ative e inspecione os provedores com hermes memory setup, hermes memory status e hermes memory off, ou defina memory.provider e recall_mode em ~/.hermes/config.yaml. Os padrões de credenciais variam (por exemplo, HINDSIGHT_API_KEY, chaves do Honcho sob $HERMES_HOME/honcho.json); use hermes memory setup para a configuração interativa.

Formato YAML minimalista apenas com recursos integrados:

memory:
  provider: ""
  memory_enabled: true
  user_profile_enabled: true

Exemplo de ativação para um backend (substitua hindsight por honcho, mem0, supermemory ou outros suportados pela sua instalação):

memory:
  provider: "hindsight"

Para a tabela comparativa completa, notas sobre dependência de LLM e embeddings, detalhamento por provedor e como esses backends se relacionam com o OpenClaw e outras pilhas, consulte Agent memory providers compared.

Para configurações específicas de perfil e fluxos de trabalho de produção, consulte Hermes Agent production setup. O AI Systems Memory hub lista este guia além de artigos relacionados sobre Cognee e camadas de conhecimento.

Parte 3: Quando a Memória Dispara — Gatilhos e Decisões

A pergunta mais comum sobre a memória do Hermes Agent é quando ele realmente salva algo.

A resposta é: constantemente, mas seletivamente. O agente gerencia sua própria memória via ferramenta memory, e a decisão de salvar é impulsionada por uma combinação de sinais explícitos e padrões implícitos.

Gatilhos de Escrita: Quando o Agente Decide Salvar?

O agente salva a memória de forma proativa. Ele não espera que você peça. Aqui está o que o aciona.

Correções do usuário. Quando você corrige o agente, isso é um sinal para lembrar. “Não faça isso de novo.” “Use isto em vez disso.” “Lembre-se disso.” Estas são instruções explícitas para atualizar a memória.

Exemplo: você pede ao agente para configurar um ambiente Python. Ele sugere pip. Você diz “Eu uso poetry para tudo”. O agente salva: O usuário prefere usar o gerenciador de pacotes 'poetry' para todos os projetos Python.

Preferências descobertas. O agente observa padrões e infere preferências. Se você usa consistentemente uma determinada ferramenta, framework ou fluxo de trabalho, isso é salvo.

Exemplo: após ver você usar poetry várias vezes em diferentes projetos, o agente o salva como uma preferência.

Fatos do ambiente. Coisas sobre a máquina, o projeto, as ferramentas instaladas. Estes são descobertos através de exploração e salvos como fatos.

Exemplo: o agente verifica o que está instalado e salva: Esta máquina executa Ubuntu 22.04, tem Docker e kubectl instalados.

Convenções de projeto. Como o projeto é estruturado, quais ferramentas utiliza, quais padrões segue. Estes são descobertos através de inspeção de código e salvos.

Exemplo: O projeto do usuário é um microserviço Go em ~/code/gateway usando gRPC + PostgreSQL.

Fluxos de trabalho complexos concluídos. Após concluir uma tarefa que exigiu mais de 5 chamadas de ferramentas, o agente considera salvar a abordagem como uma habilidade ou, pelo menos, anotar o que funcionou.

Peculiaridades de ferramentas e contornos (workarounds). Quando o agente descobre algo não óbvio sobre uma ferramenta, API ou sistema — uma limitação, um contorno, uma convenção — ele salva.

O que é ignorado:

• Informações triviais ou óbvias
• Coisas facilmente redescobertas
• Despejos de dados brutos (raw data dumps)
• Efêmeros específicos da sessão
• Informações já presentes nos arquivos de contexto (SOUL.md, AGENTS.md)

Gatilhos de Leitura: Quando o Agente Faz o Recall?

A memória não é recuperada — ela está sempre lá. Mas existem diferentes níveis de acesso.

Início da sessão (automático). MEMORY.md e USER.md são injetados no system prompt. O agente os tem desde o primeiro token. Sem necessidade de consulta, sem latência, sem chamada de ferramenta. Esta é a memória central — sempre ativa.

session_search (sob demanda). Quando o agente precisa encontrar algo de conversas passadas que não está na memória central, ele usa a ferramenta session_search. Isso consulta o SQLite (~/.hermes/state.db) com busca de texto completo FTS5 e sumarização Gemini Flash. Use isto quando a pergunta soar como “falamos sobre isso antes” em vez de “lembre-se deste fato para sempre”.

Exemplo: você pergunta “Nós discutimos redes Docker na semana passada?”. O agente pesquisa o histórico da sessão e retorna um resumo da conversa relevante.

Ferramentas de provedores externos (quando configuradas). Quando um provedor de memória externo está ativo, o framework também executa uma etapa de prefetch automático antes de cada resposta (veja a Parte 2). Ferramentas adicionais como honcho_search, hindsight_recall ou mem0_search servem para buscas direcionadas quando o agente escolhe a recuperação explícita — dependendo do recall_mode, a injeção automática, ferramentas ou ambos podem estar ativos.

A Árvore de Decisão

Veja como o agente pondera “isso vale a pena ser lembrado?”:

Isso é uma correção ou instrução explícita?
  SIM → Salvar na memória
  NÃO → Isso é uma preferência ou padrão?
    SIM → Salvar no perfil do usuário
    NÃO → Isso é um fato do ambiente ou convenção?
      SIM → Salvar na memória
      NÃO → Isso é facilmente redescoberto?
        SIM → Ignorar
        NÃO → Isso é específico da sessão?
          SIM → Ignorar
          NÃO → Salvar na memória

O agente não pensa demais sobre isso. Ele salva proativamente, consolida quando está cheio e confia nos limites de caracteres para manter tudo enxuto.

Parte 4: Memória Interna vs. Bases de Conhecimento Externas

É aqui que a confusão costuma ocorrer. O Hermes Agent possui memória interna (MEMORY.md, USER.md, provedores externos) e bases de conhecimento externas (LLM Wiki, Obsidian, Notion, ArXiv, sistema de arquivos), e elas servem papéis completamente diferentes. Isso é semelhante à distinção entre pipelines de retrieval-augmented generation e a memória de trabalho do agente — a recuperação externa é boa para buscas de conhecimento profundo, não para carregar identidade e preferências. A memória interna é o cérebro do agente — sempre ativa, curada, levada para cada sessão. As bases de conhecimento externas são sua biblioteca — vastos recursos de referência consultados sob demanda.

A Distinção

Memória Interna (o cérebro):

• Pequena, persistente, injetada no system prompt
• Contém: preferências do usuário, convenções do agente, lições imediatas
• Sempre “na mente” durante a conversa
• Curada, delimitada, gerenciada ativamente
• Exemplos: MEMORY.md, USER.md, Honcho, Hindsight, Mem0

Bases de Conhecimento Externas (a biblioteca):

• Vastas, apenas para referência, acessadas sob demanda
• Contém: documentos, artigos, código, notas, bancos de dados
• Acessadas via ferramentas quando necessário
• Não são “lembradas” — são consultadas
• Exemplos: LLM Wiki, Obsidian, Notion, ArXiv, sistema de arquivos, GitHub

Como elas se relacionam

O agente acessa bases externas via ferramentas quando necessário. Ele não as “lembra” — ele as consulta.

LLM Wiki (llm-wiki): A base de conhecimento em Markdown interligada de Karpathy para construir e consultar conhecimento de domínio. O agente usa a habilidade llm-wiki para ler, pesquisar e consultar. É um recurso de referência, não memória.

Obsidian: Cofres de notas pessoais com links bidirecionais. O agente usa a habilidade obsidian para ler, pesquisar e criar notas. O Obsidian faz parte do ecossistema mais amplo de personal knowledge management do qual o Hermes pode fazer uso como um recurso de biblioteca.

Notion/Airtable: Bancos de dados estruturados e wikis acessados via API. O agente os consulta quando necessário.

ArXiv: Repositórios de artigos acadêmicos. O agente pesquisa e extrai artigos ao pesquisar um tópico.

Sistema de arquivos (Filesystem): Código do projeto, documentação, configurações. O agente lê arquivos ao trabalhar em um projeto.

O Padrão de Destilação

Aqui está a ideia fundamental: insights críticos de bases externas podem ser destilados para a memória interna.

Exemplo: o agente lê um artigo do ArXiv sobre escalonamento de memória para agentes de IA. Ele não salva o artigo inteiro na memória. Ele salva o ponto principal: Escalonamento de memória: o desempenho do agente melhora com a experiência acumulada através da interação com o usuário e o contexto de negócio armazenado na memória.

O recurso externo é vasto. A memória interna é a destilação.

Quando usar cada uma

Memória interna para:

• “Quem eu estou ajudando?”
• “O que eles preferem?”
• “O que acabamos de aprender?”
• “Como é a configuração do projeto?”
• “Quais ferramentas estão disponíveis?”

Bases de conhecimento externas para:

• “Qual é a pesquisa mais recente sobre X?”
• “O que está na documentação do meu projeto?”
• “O que discutimos no mês passado?”
• “Qual é a API para este serviço?”
• “Qual é a estrutura do código?”

O agente entende a diferença e usa cada uma apropriadamente — ele não confunde consultar um documento com lembrar de algo que aprendeu sobre você e seu ambiente.

Parte 5: Como Funciona de Fato

Vamos olhar para a mecânica.

A Ferramenta memory

O agente gerencia a memória através de uma única ferramenta com três ações: add, replace, remove.

Não existe uma ação de read (leitura) — o conteúdo da memória é auto-injetado no system prompt. O agente não precisa lê-lo porque ele está sempre lá.

add — Adiciona uma nova entrada.

memory(action="add", target="memory",
       content="O usuário utiliza macOS 14 Sonoma, usa Homebrew, tem o Docker Desktop instalado.")

replace — Substitui uma entrada existente usando correspondência de substrings.

memory(action="replace", target="memory",
       old_text="modo escuro",
       content="O usuário prefere modo claro no VS Code, modo escuro no terminal")

remove — Remove uma entrada usando correspondência de substrings.

memory(action="remove", target="memory",
       old_text="fato temporário do projeto")

Correspondência de Substrings (Substring Matching)

replace e remove usam substrings curtas e únicas via old_text. Você não precisa do texto completo da entrada. Isso permite edições cirúrgicas sem conhecer o conteúdo exato.

Se uma substring corresponder a múltiplas entradas, um erro é retornado solicitando uma correspondência mais específica. O agente então refina sua consulta.

Armazenamentos de Destino (Target Stores): memory vs user

O parâmetro target determina qual arquivo será atualizado.

• memory — Notas pessoais do Agente. Fatos do ambiente, convenções de projeto, peculiaridades de ferramentas, lições aprendidas.
• user — Perfil do usuário. Identidade, função, fuso horário, preferências de comunicação, irritações, hábitos de fluxo de trabalho.

Gerenciamento de Capacidade

Quando a memória está >80% cheia, o agente consolida. Ele mescla entradas relacionadas, remove fatos desatualizados e comprime informações.

Boas entradas de memória são compactas e densas em informações:

O usuário utiliza macOS 14 Sonoma, usa Homebrew, tem o Docker Desktop instalado. Shell: zsh com oh-my-zsh. Editor: Neovim com plugin Telescope.

Boas entradas de memória são vagas ou prolixas:

O usuário tem um projeto.
Em 5 de janeiro de 2026, o usuário me pediu para olhar o projeto dele que está localizado em ~/code/gateway e que usa Go com gRPC e PostgreSQL para a camada de banco de dados.

A primeira é densa e útil. A segunda é ou muito vaga ou muito prolixa.

Busca de Sessão vs Memória Persistente

session_search e a memória persistente servem a propósitos diferentes.

Regra de ouro: use a memória para fatos críticos que devem estar sempre no contexto. Use a busca de sessão para consultas históricas.

Parte 6: A Filosofia

Por que Memória Delimitada Vence a Memória Ilimitada

O instinto é tornar a memória o maior possível. Armazenar tudo. Recuperar o que for necessário.

A memória delimitada funciona melhor. Aqui está o porquê.

A curadoria força a qualidade. Quando você tem espaço limitado, você só salva o que importa. Você comprime, consolida e prioriza. A memória ilimitada incentiva o descarte de tudo sem nunca limpar nada.

A velocidade importa. 1.300 tokens no system prompt é rápido. 100.000 tokens recuperados de um banco de dados é lento. A memória deve ser instantânea, não uma consulta.

O ruído degrada o desempenho. Mais memória não significa melhor memória. Significa uma memória mais ruidosa. O modelo precisa distinguir sinal de ruído, e isso exige atenção — atenção que deveria ser gasta na tarefa real.

Esquecer é um recurso. A memória humana esquece. Isso não é um bug — é como priorizamos. Agentes também devem esquecer. Nem tudo merece ser lembrado.

O Problema do “Esquecimento”

Agentes precisam desaprender. Não apenas esquecer, mas remover ativamente informações desatualizadas.

Veja como o Hermes Agent lida com isso:

• Ação remove: Excluir entradas que não são mais relevantes.
• Ação replace: Atualizar entradas com novas informações.
• Pressão de capacidade: Quando a memória está cheia, o agente consolida e remove entradas antigas.
• Escaneamento de segurança: Bloqueia entradas maliciosas ou corrompidas.

Esquecer não é falha — é manutenção. Um agente que não consegue desaprender acabará carregando tanto ruído quanto sinal.

Escalonamento de Memória (Memory Scaling)

A Databricks introduziu o conceito de “memory scaling”: um agente com milhares de usuários tem um desempenho melhor do que um com um único usuário?

A pesquisa deles sugere que sim, mas com ressalvas. O escalonamento de memória requer:

1. Extração de qualidade: Nem todas as interações valem a pena ser lembradas. O agente deve extrair insights, não logs.
2. Recuperação eficaz: As memórias recuperadas devem ser relevantes. O ruído degrada o desempenho.
3. Generalização: As memórias devem ser ser padrões, não especificidades. “Usuário prefere Python” escala. “Usuário executou o comando X no timestamp Y” não escala.

A memória delimitada do Hermes Agent suporta naturalmente o escalonamento de memória. Ao forçar a curadoria, ela garante que as memórias sejam generalizáveis, compactas e úteis.

O que isso significa para o futuro

A memória está se tornando o diferencial competitivo na IA de agentes — não o modelo em si, mas o que o modelo carrega entre as sessões. Dois agentes com modelos subjacentes idênticos podem ter desempenhos muito diferentes: um lembra de suas preferências, seu ambiente e seus erros passados; o outro começa do zero toda vez.

A questão não é mais se os agentes devem ter memória persistente. Isso já está decidido: eles devem. A questão aberta é como projetar essa memória bem — o que manter, o que descartar, como torná-la instantânea e como evitar que ela se torne ruído.

A resposta do Hermes Agent é manter a memória pequena, curada e sempre ativa — não um banco de dados que você consulta, mas um modelo de trabalho do usuário que o agente carrega consigo em cada conversa.

Conclusão

O sistema de memória do Hermes Agent é deliberadamente simples: dois arquivos, limites rígidos de caracteres, sem pipeline de recuperação, sem vector database e sem latência por consulta. O que parece uma restrição é, na verdade, o objetivo principal.

Funciona porque trata a memória da maneira como um cérebro funciona, em vez de como um banco de dados — pequena, curada e sempre ativa. O agente não recupera a memória quando precisa; a memória está simplesmente lá, tecida no system prompt desde o primeiro token de cada sessão.

Provedores de memória externos estendem este sistema para usuários que precisam de mais: grafos de conhecimento, suporte multi-agente, armazenamento auto-hospedado, recursos corporativos. Mas o núcleo permanece o mesmo: delimitado, curado, sempre disponível.

E as bases de conhecimento externas — LLM Wiki, Obsidian, Notion, ArXiv — servem a um papel diferente. Elas são a biblioteca, não o cérebro. O agente as consulta, não as lembra. Insights críticos são destilados na memória interna; o resto permanece na biblioteca.

É assim que um agente de IA lembra de você. Não armazenando tudo, mas lembrando do que importa.

Hermes Agent foi lançado pela Nous Research em fevereiro de 2026 e atingiu mais de 64.000 estrelas no GitHub em abril de 2026 (v0.9.0), com mais de 242 contribuidores. É open-source e está disponível em github.com/NousResearch/hermes-agent. Para guias de instalação, configuração e fluxo de trabalho, consulte o Hermes Agent overview.