A arquitetura de memória de 4 camadas que utilizo em 2 agentes de IA em produção

@MatthewGunnin
INGLÊShá 1 dia · 02 de jul. de 2026
115K
102
14
4
518

TL;DR

Matt Gunnin detalha uma arquitetura de memória de 4 camadas pronta para produção para agentes de IA, utilizando arquivos markdown, logs de estado compartilhado e busca semântica para manter o contexto de longo prazo e evitar o desvio do agente.

TLDR: A maioria dos agentes reiniciam e esquecem. Aqui está a pilha de memória exata que construí para que meus agentes compartilhem contexto entre reinicializações, coordenem sem pisar no pé uns dos outros e retenham decisões por meses.

O problema que ninguém resolve

Esta é a configuração típica de memória de agente de IA. Colocar coisas importantes no prompt do sistema. Torcer para que a janela de contexto não acabe. Reiniciar e perder tudo.

Eu executei dois agentes coordenados (Ella no OpenClaw, Lyra no Hermes) em centenas de sessões ao longo de 6 meses. A maior coisa que os torna úteis não são os modelos ou as ferramentas. É a arquitetura de memória.

Quando a Lyra envia uma correção às 2 da manhã, a Ella sabe disso pela manhã. Quando decidi em janeiro como os segredos deveriam ser armazenados, ambos os agentes ainda seguem essa decisão em julho. Quando uma sessão trava no meio de uma tarefa, a próxima continua exatamente de onde parou.

Aqui está o sistema exato de 4 camadas.

Camada 1: Contexto dentro da sessão

Toda sessão começa lendo dois arquivos. O arquivo de identidade é a identidade permanente do agente. Não é um prompt do sistema enterrado na configuração. É um arquivo Markdown real que posso editar. Ele contém como o agente deve se comportar, o que prioriza, o que nunca faz sem perguntar e seu relacionamento com os outros agentes.

O arquivo de índice de memória é o índice de tudo que vale a pena lembrar entre as sessões. Não é um banco de dados vetorial. Não são embeddings. É um simples sumário apontando para arquivos de memória individuais. Cada arquivo de memória é uma nota curta com um nome, uma descrição, um tipo e um corpo breve. O índice é sempre carregado. Arquivos individuais são lidos sob demanda quando relevantes.

Por que Markdown? Porque posso ler, editar e depurar. Quando um agente começa a agir errado, abro o índice e encontro a instrução errada. Quando quero mudar um comportamento, edito o arquivo. Sem API. Sem painel. Sem retreinamento.

Camada 2: Retenção pós-sessão (Hindsight)

O problema da memória apenas em Markdown: ela só captura o que alguém escreve explicitamente. A maior parte do contexto valioso é implícita. Decisões tomadas durante uma execução. Fatos inferidos de uma tarefa. Coisas que acabaram sendo importantes.

Hindsight é um backend de retenção de fatos local rodando em localhost. No final de cada sessão significativa, o agente envia automaticamente um conjunto selecionado de fatos retidos para um banco nomeado. Cada agente tem seu próprio banco.

O que é retido: decisões tomadas durante a sessão, fatos não óbvios sobre o usuário ou projeto, padrões de falha e as correções que adotamos, e preferências que o usuário confirmou ou corrigiu.

Quando uma nova sessão começa, o Hindsight é consultado por contexto relevante antes do agente responder. Não é uma busca de texto completo em transcrições. São fatos selecionados, marcados por tipo, que o agente aprendeu que valem a pena levar adiante.

O caminho promovido: fato do Hindsight, revisão humana, entrada no índice de memória. Retenção automática com um portal de aprovação humana.

Matt Gunnin - inline image

Camada 3: Estado compartilhado de longo prazo (Nexus)

A memória de agente único quebra quando você adiciona um segundo agente. Eles divergem. Um pensa que X é o status atual do projeto. O outro pensa que Y. Em uma semana, eles estão se contradizendo.

A solução é um arquivo de estado compartilhado e inspecionável que ambos os agentes leem e escrevem. Usamos um cofre Obsidian que chamo de Nexus. Ele contém um log de contexto ao vivo ao qual ambos os agentes acrescentam após cada turno significativo, um arquivo de estado do projeto, um log de decisões e um checkpoint de contexto de trabalho por agente atualizado a cada poucas chamadas de ferramenta durante tarefas longas.

O arquivo de contexto ao vivo é o handshake em tempo real. O invariante: antes de cada resposta, leia-o. Após cada turno significativo, acrescente a ele.

Quando a Lyra termina um PR às 2 da manhã e a Ella está respondendo minha pergunta matinal, a Ella já sabe. Ela leu o log. Sem passagem de mensagens. Sem API entre agentes. Sem polling. Um arquivo compartilhado, dois agentes, log somente de acréscimo.

Matt Gunnin - inline image

Camada 4: Conhecimento pesquisável (gbrain)

As três primeiras camadas lidam com a memória episódica. O que aconteceu, o que foi decidido, o que importa levar adiante. O gbrain é a camada semântica. É uma wiki compilada rodando como um servidor MCP sobre o cofre Nexus. Busca de texto completo e semântica em tudo que foi escrito.

Quando um agente precisa responder a uma pergunta de pesquisa, encontrar uma síntese anterior ou consultar como lidamos com uma classe de problema antes, ele consulta o gbrain em vez de reler cada arquivo. A saída é uma lista classificada de páginas relevantes com proveniência. O agente lê o que é relevante. Ele não despeja todo o cofre no contexto.

Esta é a diferença entre memória e recordação. As camadas 1 a 3 lidam com o que o agente carrega. A camada 4 lida com o que o agente pode consultar.

O invariante de sincronização entre agentes

Dois agentes, um arquivo de contexto ao vivo. O risco: eles se sobrescrevem ou perdem as entradas um do outro. O invariante que executamos: cada entrada é assinada com o nome do agente, canal, tipo e um resumo de uma linha. Somente acréscimo. Nunca editar a entrada de outro. Se a Lyra registrou algo relevante, a Ella reconhece isso explicitamente na próxima resposta. Para decisões significativas, ambos os agentes também escrevem no log de decisões com um timestamp e justificativa.

Isso foi executado em centenas de sessões. Tivemos um conflito: uma condição de corrida onde ambos os agentes acrescentaram dentro do mesmo minuto durante uma transferência. Resolução: ler ambas as entradas, reconciliar no próximo turno. Nenhuma mesclagem automatizada necessária.

Matt Gunnin - inline image

O que isso substitui

Antes desta arquitetura: cinco sessões de chat desconectadas, cada uma com seu próprio contexto desatualizado. Agentes se contradizendo porque nenhum podia ver o que o outro sabia. Instruções que dei há três semanas, esquecidas. Decisões que viviam na minha cabeça em vez de em um arquivo.

Depois: dois agentes que se atualizam antes de cada resposta. Um log de estado compartilhado que nenhum pode negar. Decisões retidas que sobrevivem a meses de redefinições de contexto. Cada preferência de comportamento em um arquivo que posso editar e verificar.

A troca honesta: este sistema requer disciplina. Você tem que escrever as coisas. Você tem que manter os arquivos. Você tem que revisar o que é retido antes que se torne permanente. Não é um sistema mágico sempre ativo. É disciplina manual estruturada mais automação nas emendas.

Como começar

Você não precisa de dois agentes ou de um cofre completo para executar a versão um disso.

Passo 1: Um arquivo de identidade mais um índice de memória. Crie-os. Leia-os no início da sessão. Escreva toda preferência de comportamento no índice na segunda vez que você corrigir o agente pela mesma coisa.

Passo 2: Um arquivo de estado compartilhado. Se você executa mais de um agente, ou usa Claude em várias janelas, crie um arquivo de contexto ao vivo. Cada sessão acrescenta a ele no final e o lê no início.

Passo 3: Uma regra de retenção. Quando uma sessão produz uma decisão que deve sobreviver, escreva-a no índice manualmente. Faça isso manualmente até confiar no padrão. Depois automatize a sinalização.

Passo 4: Um arquivo por fato, não um documento grande. O índice aponta para arquivos individuais. Isso facilita excluir uma memória desatualizada sem tocar nas outras.

A pilha completa de 4 camadas levou cerca de 6 meses para estabilizar. As camadas 1 e 3 levaram um fim de semana. Comece por aí.

Conclusão

A maioria das configurações de memória de agente são gerenciamento de janela de contexto com etapas extras. Elas funcionam até a janela reiniciar ou você adicionar um segundo agente.

A memória durável do agente é um problema de infraestrutura, não um problema de prompting. A resposta são múltiplas camadas com diferentes horizontes de tempo: contexto dentro da sessão, fatos entre sessões, estado compartilhado, conhecimento pesquisável.

Tudo nosso é Markdown simples. Sem banco de dados vetorial. Sem embeddings. Sem retreinamento. Apenas arquivos que posso abrir, editar e depurar.

Os agentes que são genuinamente úteis não são aqueles com a maior janela de contexto. São aqueles que lembram o que importa e esquecem o que não importa.

Se você está construindo agentes em que deseja confiar para trabalhos reais, comece com a arquitetura de memória antes de adicionar mais ferramentas.

Ferramentas referenciadas

Hindsight (retenção de memória local): https://github.com/vectorize-io/hindsight

gbrain (wiki compilada / busca semântica): https://github.com/garrytan/gbrain

OpenClaw (runtime de agente): https://openclaw.ai

Hermes (runtime de agente): hermes-agent.nousresearch.com

Save to YouMind

Use YouMind to read viral articles deeply

Save the source, ask focused questions, summarize the argument, and turn a viral article into reusable notes in one AI workspace.

Explore YouMind
Para criadores

Transforme seu Markdown em um artigo 𝕏 impecável

Quando você publica seus próprios textos longos, formatar imagens, tabelas e blocos de código para o 𝕏 é uma dor de cabeça. O YouMind transforma um rascunho completo em Markdown em um artigo 𝕏 impecável e pronto para publicar.

Experimente Markdown para 𝕏

Mais padrões para decifrar

Artigos virais recentes

Explorar mais artigos virais