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

Você já conhece a rotina. Você abre um chat com um agente de IA, explica seu projeto, compartilha suas preferências, faz com que alguma tarefa seja concluída e fecha a aba. Ao voltar na semana seguinte, é como falar com um estranho — todo o contexto se foi, todas as preferências foram esquecidas, o projeto precisa ser explicado do zero.

Isso não é um bug. É assim que os Modelos de Linguagem Grande (LLMs) funcionam por design. Eles são stateless (sem estado): cada solicitação é independente, cada resposta é gerada a partir do prompt que você envia naquele momento, 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 é aceitável. Faça uma pergunta, obtenha uma resposta, siga em frente. Mas para agentes — sistemas que são supostos fazer coisas ao longo das sessões, aprender com erros e evoluir com você — a ausência de estado é um limite arquitetural rígido. É um dos problemas centrais não resolvidos em sistemas de IA auto-hospedados.

A indústria tentou resolver isso. A 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 “escala de memória” (memory scaling) — a ideia de que o desempenho do agente melhora com a experiência acumulada. Desde 2024, surgiram papers dedicados a benchmarks, revisões sobre memória episódica e um ecossistema de ferramentas em rápido crescimento para abordar o que é cada vez mais reconhecido como um dos problemas centrais não resolvidos na IA agêntica.

A maioria dessas abordagens compartilha um problema comum: tratam a memória como uma reflexão tardia — um banco de dados para consultar, uma janela de contexto para encher, 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 é em todos os momentos — integrado ao prompt do sistema, curado, delimitado e sempre ativo. É pequeno o suficiente para ser rápido, estruturado o suficiente para ser útil e disciplinado 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 “Basta 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 caber muito texto ali.

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

Contexto não tem curadoria. É um despejo: à 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 — consolida-se, atualiza-se 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 eles se importam, no que concordaram, o que aprenderam. O resto é esquecido ou pesquisável quando necessário.

O Cenário da Pesquisa

O espaço de memória de agentes de IA explodiu desde 2024, com suítes de benchmark dedicadas, literatura de pesquisa em crescimento e uma lacuna de desempenho mensurável entre diferentes abordagens arquitetônicas. Eis onde estamos.

Letta (anteriormente MemGPT) foi um dos primeiros frameworks a tratar a memória persistente como uma preocupação de primeira classe, atingindo 21,7K estrelas no GitHub. Usa um modelo em três camadas inspirado em sistemas operacionais: memória central (pequena, sempre em contexto), memória de recall (histórico de conversas pesquisável) e memória arquivada (armazenamento frio de longo prazo). O insight de que nem toda memória é igual estava correto. A implementação, no entanto, exige que os agentes rodem 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, menos adequado para agentes autônomos que rastreiam fatos do ambiente e convenções do projeto.

Cognee é 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. Excelentes em conhecimento institucional e pipelines RAG, mas menos focado em memória pessoal do agente. Veja auto-hospedagem do Cognee com LLMs locais para um guia prático de configuração.

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

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

Pesquisa de escala de memória da Databricks introduziu o conceito de que o desempenho do agente melhora com a experiência acumulada. Sua arquitetura mantém prompts de sistema, ativos empresariais e memórias episódicas/semânticas escopadas 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 entre a 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, é injetada no início da sessão e sempre presente. Sempre ativa, sempre disponível, curada o suficiente para permanecer útil.

Parte 2: Arquitetura — Dois Arquivos, Um Cérebro

O sistema de memória integrado 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 essa é exatamente a intenção 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. Eis como se parece:

O projeto do usuário é um microsserviço Go em ~/code/gateway usando gRPC + PostgreSQL
Esta máquina roda 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, cheios de informação. Sem carimbos de data/hora, sem enrolação, sem “no dia 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 usa principalmente Linux Ubuntu 22.04.
O usuário faz deploy na AWS usando Terraform.

Identidade, papel, preferências, habilidades técnicas, estilo de comunicação, irritantes. O que faz o agente responder a você de forma diferente do que responderia a 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 prompt do sistema. Eis como se parece:

══════════════════════════════════════════════
MEMÓRIA (suas notas pessoais) [7% — 166/2.200 chars]

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

══════════════════════════════════════════════ PERFIL DO USUÁRIO (quem é o usuário) [8% — 110/1.375 chars] ══════════════════════════════════════════════ 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 usa cabeçalhos, porcentagens de uso, contagens de caracteres e delimitadores `§` (signo de seção). As entradas podem ser multilinha. É projetado para ser analisável pelo modelo enquanto permanece legível por humanos.

Por que congelado? [Cache de prefixo](https://www.glukhov.org/pt/llm-performance/). O prompt do sistema é 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 cacheiar o cálculo do prefixo e processar apenas as partes variáveis — a conversa. Esta é uma otimização de desempenho significativa. Você não está re-computando 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 prompt do sistema no início da próxima sessão. As respostas das ferramentas sempre mostram o estado ao vivo, mas a "mente" do modelo não muda no meio da sessão. Isso impede que o modelo caia em loop infinito — atualizando a memória e reagindo à sua própria atualização na mesma conversa.

### Limites de Caracteres como 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 é uma desvantagem. Incentiva despejar tudo, nunca consolidar e eventualmente tornar-se 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 comprimido 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. Ler entradas atuais da resposta de erro
2. Identificar entradas removíveis ou consolidáveis
3. Usar `replace` para mesclar entradas relacionadas em versões mais curtas
4. Adicionar 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: Varredura de Injeção de Prompt

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

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

---

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

A pergunta mais comum sobre a memória do Hermes Agent é quando ela 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 proativamente. Ele não espera que você peça. Eis o que o aciona.

**Correções do usuário.** Quando você corrige o agente, esse é um sinal para lembrar. "Não faça isso novamente." "Use isso em vez disso." "Lembre-se disto." 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 certa ferramenta, framework ou fluxo de trabalho, isso é salvo.

Exemplo: após vê-lo usar `poetry` várias vezes em diferentes projetos, o agente salva isso 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 roda Ubuntu 22.04, tem Docker e kubectl instalados.`

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

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

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

**Estranhezas de ferramentas e soluções alternativas.** Quando o agente descobre algo não óbvio sobre uma ferramenta, API ou sistema — uma limitação, uma solução alternativa, uma convenção — ele salva.

**O que é pulado:**

- Informações triviais ou óbvias
- Coisas facilmente redescobertas
- Despejos de dados brutos
- Efémeras específicas da sessão
- Informações já em arquivos de contexto (SOUL.md, AGENTS.md)

### Gatilhos de Leitura: Quando o Agente Recupera?

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

**Início da sessão (automático).** MEMORY.md e USER.md são injetados no prompt do sistema. O agente os tem desde o primeiro token. Nenhuma consulta necessária, 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 pesquisa de texto completo FTS5 e resumização via Gemini Flash.

Exemplo: você pergunta "Discutimos rede 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 configurado).** Quando um provedor de memória externo está ativo, o agente tem ferramentas adicionais disponíveis: `honcho_search`, `hindsight_recall`, `mem0_search`, etc. Estes são usados quando o agente determina que contexto externo é necessário.

### A Árvore de Decisão

Veja como o agente pondera "isto vale a pena lembrar?":

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

O agente não superpensa isso. Ele salva proativamente, consolida quando cheio e confia nos limites de caracteres para manter as coisas concisas.

---

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

É aqui que a confusão frequentemente ocorre. O Hermes Agent tem *memória interna* (MEMORY.md, USER.md, provedores externos) e *bases de conhecimento externas* (LLM Wiki, Obsidian, Notion, ArXiv, sistema de arquivos), e eles servem papéis completamente diferentes. Isso é semelhante à distinção entre pipelines de [geração aumentada por recuperação](https://www.glukhov.org/pt/rag/) e memória de trabalho do agente — a recuperação externa é boa para consultas de conhecimento profundo, não para carregar identidade e preferências. A memória interna é o cérebro do agente — sempre ativa, curada, carregada em 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 prompt do sistema
- 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):**

- Vasta, apenas referência, acessada sob demanda
- Contém: documentos, papers, código, notas, bancos de dados
- Acessada via ferramentas quando necessário
- Não "lembrada" — pesquisada
- Exemplos: LLM Wiki, Obsidian, Notion, ArXiv, sistema de arquivos, GitHub

### Como Eles se Relacionam

O agente *acessa* bases externas via ferramentas quando necessário. Ele não as "lembra" — ele as pesquisa.

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

**[Obsidian](https://www.glukhov.org/pt/knowledge-management/tools/obsidian-for-personal-knowledge-management/):** 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 [gestão de conhecimento pessoal](https://www.glukhov.org/pt/knowledge-management/) que o Hermes pode usar como 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 papers acadêmicos. O agente pesquisa e extrai papers ao pesquisar um tópico.

**Sistema de Arquivos:** 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á o insight chave: insights críticos de bases externas podem ser *destilados* para a memória interna.

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

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

### Quando Usar Qual

**Memória interna para:**

- "Quem estou ajudando?"
- "O que eles preferem?"
- "O que acabamos de aprender?"
- "Qual é 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 deste serviço?"
- "Qual é a estrutura do código?"

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

---

## Parte 5: Como Funciona na Prática

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 há ação `read` — o conteúdo da memória é auto-injetado no prompt do sistema. O agente não precisa lê-lo porque ele sempre está lá.

**`add`** — Adiciona uma nova entrada.

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

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

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 substring.

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

Correspondência de Substring

replace e remove usam substrings curtas e únicas via old_text. Você não precisa do texto completo da entrada. Isso torna edições cirúrgicas possíveis 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.

Alvos de Armazenamento: memory vs user

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

• memory — Notas pessoais do agente. Fatos do ambiente, convenções do projeto, estranhezas de ferramentas, lições aprendidas.
• user — Perfil do usuário. Identidade, papel, fuso horário, preferências de comunicação, irritantes, 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ção:

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

Entradas de memória ruins são vagas ou verbosas:

O usuário tem um projeto.
No dia 5 de janeiro de 2026, o usuário me pediu para olhar seu projeto que está localizado em ~/code/gateway e 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 verbosa.

Busca de Sessão vs Memória Persistente

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

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

Parte 6: Provedores de Memória Externa — Todas as 8 Opções Comparadas

Além dos arquivos integrados MEMORY.md e USER.md, o Hermes Agent suporta 8 plugins de provedores de memória externa para conhecimento persistente e entre sessões.

Apenas um provedor externo pode estar ativo por vez. Os arquivos integrados estão sempre ativos junto com o provedor externo — aditivo, não substitutivo.

Ativação

hermes memory setup   # Seletor interativo + configuração
hermes memory status  # Verificar o que está ativo
hermes memory off     # Desativar provedor externo

Ou manualmente em ~/.hermes/config.yaml:

memory:
  provider: openviking  # ou honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory

Comparação de Provedores

Detalhamento

Honcho

Melhor para: sistemas multi-agente, contexto entre sessões, alinhamento usuário-agente.

O Honcho roda ao lado da memória existente — o USER.md permanece como está, e o Honcho adiciona uma camada adicional de contexto. Ele modela conversas como pares trocando mensagens — um par de usuário mais um par de IA por perfil Hermes, todos compartilhando um espaço de trabalho.

Ferramentas: honcho_profile (ler/atualizar cartão de par), honcho_search (pesquisa semântica), honcho_context (contexto de sessão — resumo, representação, cartão, mensagens), honcho_reasoning (sintetizado por LLM), honcho_conclude (criar/deletar conclusões).

Principais configurações:

• contextCadence (padrão 1): Turnos mínimos entre atualização da camada base
• dialecticCadence (padrão 2): Turnos mínimos entre chamadas LLM peer.chat() (1-5 recomendado)
• dialecticDepth (padrão 1): Passagens .chat() por invocação (limitado a 1-3)
• recallMode (padrão ‘hybrid’): hybrid (auto+tools), context (apenas injeção), tools (apenas ferramentas)
• writeFrequency (padrão ‘async’): Timing de flush: async, turn, session, ou inteiro N
• observationMode (padrão ‘directional’): directional (todos ligados) ou unified (pool compartilhado)

Arquitetura: Injeção de contexto em duas camadas — camada base (resumo da sessão + representação + cartão de par) + suplemento dialético (raciocínio LLM). Seleciona automaticamente prompts de cold-start vs warm.

Mapeamento multi-par: O espaço de trabalho é um ambiente compartilhado entre perfis. Par do usuário (peerName) é uma identidade humana global. Par de IA (aiPeer) é um por perfil Hermes (hermes padrão, hermes.<profile> para outros).

Configuração:

hermes memory setup  # selecionar "honcho"
# ou legado: hermes honcho setup

Config: $HERMES_HOME/honcho.json (local do perfil) ou ~/.honcho/config.json (global).

Gerenciamento de perfis:

hermes profile create coder --clone  # Cria hermes.coder com espaço de trabalho compartilhado
hermes honcho sync                   # Preenche pares de IA para perfis existentes

OpenViking

Melhor para: gestão de conhecimento auto-hospedada com navegação estruturada.

O OpenViking fornece uma hierarquia de sistema de arquivos com carregamento em camadas. É gratuito, auto-hospedado, e dá a você controle total sobre seu armazenamento de memória.

Ferramentas: viking_search, viking_read (em camadas), viking_browse, viking_remember, viking_add_resource.

Configuração:

pip install openviking
openviking-server
hermes memory setup  # selecionar "openviking"
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

Melhor para: gestão de memória sem esforço com extração automática.

O Mem0 lida com extração de memória no lado do servidor. Você não configura nada — ele simplesmente funciona. Trade-off: dependência de nuvem e custo.

Ferramentas: mem0_profile, mem0_search, mem0_conclude.

Configuração:

pip install mem0ai
hermes memory setup  # selecionar "mem0"
echo "MEM0_API_KEY=sua-chave" >> ~/.hermes/.env

Config: $HERMES_HOME/mem0.json (user_id: hermes-user, agent_id: hermes).

Hindsight

Melhor para: recall baseado em grafo de conhecimento com relacionamentos de entidades.

O Hindsight constrói um grafo de conhecimento da sua memória, extraindo entidades e relacionamentos. Sua ferramenta única reflect realiza síntese cruzada de memória — combinando múltiplas memórias em novos insights.

Ferramentas: hindsight_retain, hindsight_recall, hindsight_reflect (síntese cruzada de memória única).

Configuração:

hermes memory setup  # selecionar "hindsight"
echo "HINDSIGHT_API_KEY=sua-chave" >> ~/.hermes/.env

Instala automaticamente hindsight-client (nuvem) ou hindsight-all (local). Requer >= 0.4.22.

Config: $HERMES_HOME/hindsight/config.json

• mode: cloud ou local
• recall_budget: low / mid / high
• memory_mode: hybrid / context / tools
• auto_retain / auto_recall: true (padrão)

UI Local: hindsight-embed -p hermes ui start

Holographic

Melhor para: configurações focadas em privacidade com armazenamento apenas local.

O Holographic usa álgebra HRR (Representação Reduzida Holográfica) para codificação de memória, com pontuação de confiança para confiabilidade da memória. Sem dependência de nuvem — tudo roda localmente no seu próprio hardware.

Ferramentas: 2 ferramentas para operações de memória via álgebra HRR.

Configuração:

hermes memory setup  # selecionar "holographic"

Sem dependências. Tudo roda localmente.

RetainDB

Melhor para: atualizações de alta frequência com compressão delta.

O RetainDB usa compressão delta para armazenar atualizações de memória eficientemente. É baseado em nuvem com um custo de $20/mês, mas a compressão significa menos transferência de dados e atualizações mais rápidas.

Ferramentas: retaindb_profile (perfil do usuário), retaindb_search (pesquisa semântica), retaindb_context (contexto relevante à tarefa), retaindb_remember (armazenar com tipo + importância), retaindb_forget (deletar memórias).

Configuração:

hermes memory setup  # selecionar "retaindb"

ByteRover

Melhor para: ambientes com largura de banda limitada com extração de pré-compressão.

O ByteRover comprime a memória antes da extração, reduzindo o uso de largura de banda. Disponível em modos local ou nuvem.

Ferramentas: 3 ferramentas para operações de memória.

Configuração:

hermes memory setup  # selecionar "byterover"

Supermemory

Melhor para: fluxos de trabalho empresariais com cercamento de contexto e ingestão de grafo de sessão.

O Supermemory fornece cercamento de contexto (isolando memória por contexto) e ingestão de grafo de sessão (importando históricos inteiros de conversas). É baseado em nuvem e pago, mas projetado para gestão de memória em escala empresarial.

Ferramentas: 4 ferramentas para operações de memória.

Configuração:

hermes memory setup  # selecionar "supermemory"

Como Escolher

• Precisa de suporte multi-agente? Honcho
• Quer auto-hospedado e grátis? OpenViking ou Holographic
• Quer zero-configuração? Mem0
• Quer grafos de conhecimento? Hindsight
• Quer compressão delta? RetainDB
• Quer eficiência de largura de banda? ByteRover
• Quer recursos empresariais? Supermemory
• Quer privacidade (apenas local)? Holographic

Para configurações de provedor por perfil e padrões de fluxo de trabalho do mundo real, veja configuração de produção do Hermes Agent.

Parte 7: A Filosofia

Por que Memória Delimitada Vence Memória Ilimitada

O instinto é tornar a memória o maior possível. Armazene tudo. Recupere o que você precisa.

Memória delimitada funciona melhor. Eis o porquê.

Curadoria força qualidade. Quando você tem espaço limitado, você só salva o que importa. Você comprime, consolida e prioriza. Memória ilimitada incentiva despejar tudo e nunca limpar.

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

Ruído degrada o desempenho. Mais memória não é melhor memória. É memória mais ruidosa. O modelo tem que distinguir sinal de ruído, e isso requer 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 ativamente remover informações desatualizadas.

Veja como o Hermes Agent lida com isso:

• Ação remove: Deletar 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.
• Varredura de segurança: Bloqueia entradas maliciosas ou corrompidas.

Esquecer não é falha — é manutenção. Um agente que não pode desaprender eventualmente carregará tanto ruído quanto sinal.

Escala de Memória

A Databricks introduziu o conceito de “escala de memória”: um agente com milhares de usuários performa melhor do que um com um único usuário?

Sua pesquisa sugere que sim, mas com ressalvas. A escala 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. Ruído degrada o desempenho.
3. Generalização: As memórias devem ser padrões, não especificidades. “O usuário prefere Python” escala. “O usuário executou comando X no carimbo de data Y” não escala.

A memória delimitada do Hermes Agent suporta naturalmente a escala de memória. Ao forçar 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 fosso competitivo na IA agêntica — não o modelo em si, mas o que o modelo carrega entre sessões. Dois agentes com modelos subjacentes idênticos podem performar muito diferente: um lembra suas preferências, seu ambiente e seus erros passados; o outro começa do zero toda vez.

A pergunta não é mais se agentes devem ter memória persistente. Está resolvido: eles devem. A pergunta em aberto é como projetar essa memória bem — o que manter, o que descartar, como torná-la instantânea e como impedir que se torne ruído.

A resposta do Hermes Agent é manter a memória pequena, curada e sempre ativa — não um banco de dados para consultar, 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 de caracteres rígidos, sem pipeline de recuperação, sem banco de dados vetorial e sem latência por consulta. O que soa como uma restrição é todo o ponto.

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

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

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

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

O 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 instalação, configuração e guias de fluxo de trabalho, veja o visão geral do Hermes Agent.