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

Você já sabe como funciona. Você abre um chat com um agente de IA, explica seu projeto, compartilha suas preferências, realiza algum trabalho e fecha a aba. Ao voltar na semana seguinte, é como falar com um estranho — todo o contexto sumiu, 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 devem 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. O LangChain adicionou módulos de memória. A OpenAI introduziu assistentes com threads (fios de execução). Frameworks como Letta, Zep e Cognee construíram arquiteturas inteiras em torno de memória persistente. A Databricks publicou sobre “escalonamento de memória” — 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 agente.

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 Agente Hermes 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 — incorporado 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 — a camada específica do Hermes dentro do modelo multi-framework em Sistemas de Memória em Assistentes de IA e a stack mais ampla em Arquitetura de Assistente de IA. Para comandos de ativação e inspeção (hermes memory, hermes dump, acompanhamento de logs), combine com a Folha de Trapaça do CLI do Agente Hermes. Para o lado complementar do “conhecimento de longo prazo” do Hermes — procedimentos reutilizáveis em SKILL.md em vez de arquivos de memória curados — veja Autoração de Habilidades do Agente Hermes — Estrutura e Melhores Práticas do SKILL.md.

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. Anexe a conversa anterior. Inclua a documentação do projeto. Envie 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 — 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.

O 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, atualiza e esquece.

A memória humana funciona da mesma maneira. Você não se lembra de todas as conversas que já teve. Você lembra das partes que importam: com quem você 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 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, atingindo 21,7 mil estrelas no GitHub. Usa um modelo de três camadas inspirado no sistema operacional: 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 carregam janelas de validade para que o grafo saiba quando algo era verdade. É forte para chatbots que precisam de grafos de relacionamentos, 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. Excelente em conhecimento institucional e pipelines RAG, mas menos focado em memória pessoal de agentes. 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 de síntese reflect única que realiza síntese cruzada de memória — combinando múltiplas memórias em novos insights. Está entre os melhores desempenhos nos benchmarks de memória de agentes e está disponível como provedor de memória para o Agente Hermes.

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 no 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 48 mil estrelas no GitHub e suporta 21 integrações de framework. A compensação é a dependência de nuvem e custo.

A pesquisa de escalonamento 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 no nível da organização e do 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

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

Duas camadas

O Hermes empilha a memória em duas camadas:

1. Nativo — MEMORY.md e USER.md, suportados por arquivos, sempre ativos. 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 pares que você ativa via configuração. Apenas um backend externo é executado por vez. Ele adiciona recuperação e retenção ao lado dos arquivos; 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 prompt de sistema congelado.

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

O recall acontece antes do 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 à superfície de implementação (MemoryManager, prefetch / sync_turn / queue_prefetch por provedor).

Mensagem do usuário
    |
    v
MemoryManager.prefetch_all(query)        <-- fase de recall
    |
    +-- provider.prefetch(query)        <-- cada provedor externo busca em 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 nativos MEMORY.md e USER.md não são buscados através de prefetch_all — eles já fazem parte do prompt de sistema congelado. Backends externos conectam-se a prefetch_all / sync_all; queue_prefetch permite que um provedor aqueça 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 nativa. O modelo chama memory com add, replace ou remove quando as instruções dizem que algo deve persistir — fatos duráveis, preferências, correções, notas de ambiente. target='user' mantém o USER.md; target='memory' mantém o MEMORY.md. Formato de exemplo: 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 difere por backend — por exemplo, o Hindsight lota os turnos e executa retenção estruturada com entidades e relacionamentos; o Honcho envia o diálogo através de seu pipeline dialético; stacks estilo Mem0 e Supermemory extraem fatos passivamente dos turnos.

3. Ferramentas específicas do provedor. Quando o plugin as expõe, gravações explícitas como honcho_conclude, hindsight_retain ou honcho_profile armazenam fatias duráveis sob demanda.

Recall automático versus ferramentas de provedor

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

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), apenas os arquivos nativos e a pesquisa de sessão se aplicam — sem prefetch/sync de um plugin.

Caminhos no disco e orçamentos

A memória nativa do Agente Hermes 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. Veja como fica:

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, repletos de informações. Sem carimbos de tempo, 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 confortável 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. As coisas que fazem o agente responder de forma diferente para você do que para qualquer outro.

O Padrão de Instantâneo 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. Veja como fica:

══════════════════════════════════════════════
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 confortável 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, permanecendo legível para humanos.

Por que congelado? Cache de prefixo. O prompt do sistema é o mesmo em cada turno 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á recomputando 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 em tempo real, mas a “mente” do modelo não muda no meio da sessão. Isso impede que o modelo persiga sua própria cauda — atualizando a memória e depois reagindo à sua 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 é 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 através de submissões repetidas.

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

Além dos arquivos nativos MEMORY.md e USER.md, o Agente Hermes pode anexar um plugin de memória externo por vez — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover ou Supermemory — para conhecimento persistente e entre sessões. Apenas um provedor externo está ativo por vez; os dois arquivos centrais permanecem carregados ao lado dele (aditivo, não substituição).

Ative e inspecione 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 em $HERMES_HOME/honcho.json); use hermes memory setup para configuração interativa.

Formato YAML mínimo apenas nativo:

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

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

memory:
  provider: "hindsight"

Para a tabela de comparação completa, notas de dependência de LLM e embedding, breakdowns por provedor e como esses backends se relacionam com o OpenClaw e outras stacks, veja Provedores de memória de agentes comparados.

Para configuração específica de perfil e fluxos de trabalho de produção, veja Configuração de produção do Agente Hermes. O Hub de Memória de Sistemas de IA lista este guia e 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 Agente Hermes é quando ele realmente salva algo.

A resposta é: constantemente, mas seletivamente. O agente gerencia sua própria memória através da 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. Veja 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 isso 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 “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 ver você usar poetry várias vezes em diferentes projetos, o agente salva como uma preferência.

Fatos de 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 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 levou 5+ chamadas de ferramenta, o agente considera salvar a abordagem como uma habilidade ou pelo menos anotar o que funcionou.

Estranhamentos 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 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 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 busca de texto completo FTS5 e resumo do Gemini Flash. Use isso quando a pergunta parecer “falamos sobre isso antes” em vez de “lembre-se deste fato para sempre.”

Exemplo: você pergunta “Discutimos rede Docker na semana passada?” O agente pesquisa o histórico de sessões e retorna um resumo da conversa relevante.

Ferramentas de provedor externo (quando configurado). 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 são para pesquisas direcionadas quando o agente escolhe recuperação explícita — dependendo do recall_mode, injeção automática, ferramentas ou ambas podem estar ativas.

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 de 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 superestima isso. Ele salva proativamente, consolida quando cheio e confia nos limites de caracteres para manter as coisas firmes.

Parte 4: Memória Interna versus Bases de Conhecimento Externas

É aqui que a confusão frequentemente acontece. O Agente Hermes 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 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):

• Vastas, apenas referência, acessadas sob demanda
• Contém: documentos, papers, código, notas, bancos de dados
• Acessado via ferramentas quando necessário
• Não é “lembrado” — é pesquisado
• 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 interligada em Markdown 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: 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 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 principal: insights críticos de bases externas podem ser destilados na memória interna.

Exemplo: o agente lê um paper do ArXiv sobre escalonamento de memória para agentes de IA. Ele não salva o paper inteiro na memória. Ele salva o ponto-chave: Escalonamento 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ócios 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 última pesquisa sobre X?”
• “O que há 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 — não conflita pesquisar um documento com lembrar 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 está sempre lá.

add — Adiciona uma nova entrada.

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

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

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

Correspondência de Subcadeia

replace e remove usam subcadeias 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 subcadeia corresponder a múltiplas entradas, um erro é retornado solicitando uma correspondência mais específica. O agente então refina sua consulta.

Armazenamentos Alvo: memory versus user

O parâmetro target determina qual arquivo é atualizado.

• memory — Notas pessoais do agente. Fatos de ambiente, convenções do projeto, estranhamentos 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.
Em 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.

Pesquisa de Sessão versus Memória Persistente

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

Regra prática: use memória para fatos críticos que devem estar sempre no contexto. Use pesquisa de sessão para consultas históricas.

Parte 6: 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. Veja 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 é memória melhor. É memória mais ruidosa. O modelo precisa distinguir sinal de ruído, e isso leva atenção — atenção que deve 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 Agente Hermes 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.
• 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.

Escalonamento de Memória

A Databricks introduziu o conceito de “escalonamento 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. 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: Memórias recuperadas devem ser relevantes. Ruído degrada o desempenho.
3. Generalização: Memórias devem ser padrões, não especificidades. “O usuário prefere Python” escala. “O usuário executou o comando X no carimbo de tempo Y” não escala.

A memória delimitada do Agente Hermes naturalmente suporta o escalonamento de memória. Ao forçar a curadoria, 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 agente — 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 questão não é mais se os agentes devem ter memória persistente. Está resolvido: eles devem. A questão 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 Agente Hermes é 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 Agente Hermes é deliberadamente simples: dois arquivos, limites rígidos de caracteres, sem pipeline de recuperação, sem banco de dados vetorial e sem latência por consulta. O que soa como uma restrição é o ponto principal.

Funciona porque trata a memória como um cérebro funciona em vez de como um banco de dados — pequena, curada e sempre ativa. O agente não recupera memória quando precisa; a memória está simplesmente sempre 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 na memória interna; o resto permanece na biblioteca.

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

O Agente Hermes 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 a visão geral do Agente Hermes.