O primeiro post desta série foi sobre a prática — como estruturo prompts, itero em ciclos curtos, e delego trabalho mecânico mantendo o julgamento do meu lado. Este é sobre a infraestrutura por trás dessa prática: o sistema de memória em três camadas que faz isso funcionar entre sessões, projetos, e semanas.

Nenhuma dessas camadas é tecnicamente complexa. O valor vem de como elas se encaixam.

O problema da memória de IA (brevemente)

Modelos de linguagem não têm memória persistente. Toda sessão começa em branco. Isso é normal para uma pergunta pontual, mas se você usa IA como uma ferramenta séria de desenvolvimento, isso cria atrito: reexplicar a estrutura do projeto, reestabelecer convenções, corrigir o mesmo comportamento que você já corrigiu semana passada.

A correção não é colar contexto em cada sessão. Isso é manual, inconsistente, e não escala. A correção é construir um sistema de memória que carrega o contexto certo automaticamente — e fica mais inteligente quanto mais você usa.

Três camadas fazem isso, cada uma resolvendo uma parte diferente do problema.

Camada 1 — CLAUDE.md: contexto estático como código

Todo projeto em que trabalho com IA tem um arquivo CLAUDE.md na raiz. É carregado automaticamente no início da sessão pelo Claude Code. A IA entra em cada sessão já conhecendo o projeto.

A distinção chave: esse arquivo não é documentação para humanos. É contexto moldado ao redor das perguntas que uma IA vai fazer.

Um README responde “o que é isso?” para um humano que vai depois ler o código. Um CLAUDE.md responde “onde estão os arquivos de configuração?”, “como funciona o deploy?”, “o que é esse diretório .k8s/?”, “o que eu devo evitar mexer?” — as perguntas que de outra forma consumiriam os primeiros dez minutos de cada sessão.

Na prática, um CLAUDE.md bem escrito cobre:

• Estrutura de diretórios e o que cada pasta realmente faz
• Como rodar o projeto localmente, como buildar, como fazer deploy
• Convenções: nomenclatura de branch, estilo de commit, o que vai num PR
• Restrições: o que não fazer, por que certas decisões foram tomadas

O “porquê” importa tanto quanto o “o quê”. “Usamos a estratégia de deployment Recreate em vez de RollingUpdate” é um contexto útil. “Usamos Recreate porque a aplicação usa SQLite, que não suporta escritores concorrentes” é o contexto que impede a IA de sugerir prestativamente um rolling update e quebrar tudo.

Camada 2 — MemPalace: memória dinâmica entre sessões

O contexto estático cobre o que o projeto é. O contexto dinâmico cobre o que aconteceu — decisões tomadas na terça passada, feedback dado semana passada, um workaround descoberto na sessão sete.

É isso que o MemPalace resolve.

O nome não é acidental. O método dos loci — uma técnica mnemônica atribuída ao poeta grego Simonides de Ceos, por volta de 500 a.C. — funciona colocando mentalmente informações em cômodos de um lugar familiar. Para recordar, você caminha pelo palácio e encontra o que deixou para trás. O software toma emprestada a mesma estrutura deliberadamente: wings, rooms, drawers são o prédio. A IA caminha por ele.

O MemPalace é um sistema de memória local-first que roda como um servidor MCP (Model Context Protocol — um padrão aberto para conectar ferramentas de IA a fontes de dados externas) integrado ao Claude Code. Durante e depois das sessões, ele minera conversas e salva memórias estruturadas num banco de dados vetorial local (ChromaDB).

O primeiro post mencionou o formato disso de passagem — wings, rooms, drawers. Aqui está o quadro completo: wings (uma por projeto, mais uma wing sessions para trabalho entre projetos), rooms (tópicos: technical, architecture, planning, problems, diary), e drawers (trechos individuais de memória).

Como os hooks funcionam

A integração roda silenciosamente através de dois hooks:

Stop hook — dispara automaticamente a cada 15 trocas de mensagem. Salva um checkpoint de diário da conversa recente na wing do projeto. Sem interrupção, sem output: o modo silent_save faz isso em background.

Precompact hook — dispara antes do Claude Code comprimir a janela de contexto. Minera a transcrição completa da sessão em drawers estruturadas, classificando o conteúdo em rooms por tipo (detalhes técnicos, decisões de arquitetura, problemas e workarounds, etc.).

O resultado: quando uma sessão termina, tudo que vale a pena guardar já está arquivado. A próxima sessão começa com esse conhecimento disponível.

O que é armazenado

O extrator identifica cinco tipos de memória sem precisar de um LLM — correspondência de palavras-chave e padrões:

• Decisões — escolhas feitas, com sua justificativa
• Preferências — “sempre faça X”, “nunca faça Y”
• Marcos — algo que foi entregue, uma versão que foi para produção, um problema resolvido
• Problemas — bugs, erros, causas raiz, workarounds
• Marcadores emocionais — avanços, frustrações, contexto que molda o tom

Na prática, a room mais valiosa é architecture: ela acumula o raciocínio por trás de escolhas estruturais que não são visíveis no próprio código.

Camada 3 — O grafo de conhecimento: relações estruturadas

Drawers armazenam texto. São recuperadas via busca semântica — útil, mas imprecisa. Quando você pergunta “onde o personal-blog faz deploy?”, a busca semântica retorna trechos de texto que mencionam deploy. Você ainda precisa interpretar a resposta.

Um grafo de conhecimento armazena a resposta como um fato: personal-blog → deployed_on → home-cluster. A query é instantânea, estruturada, e sem ambiguidade.

O MemPalace inclui um grafo de conhecimento temporal construído sobre SQLite. Fatos são armazenados como triplas: sujeito → predicado → objeto, com janelas de tempo opcionais. Triplas podem ser invalidadas quando mudam — o fato antigo é marcado como expirado, o novo é adicionado. O histórico é preservado.

O KG é populado via chamadas de ferramenta MCP. Cada chamada é pequena:

subject:   "personal-blog"
predicate: "deployed_on"
object:    "home-cluster"

O custo é insignificante. O valor se acumula: uma vez que um fato está no grafo, ele é consultável em milissegundos — por mim, ou pela IA no início de qualquer sessão.

O grafo responde perguntas que drawers não conseguem responder de forma limpa: “quais projetos fazem deploy no home-cluster?”, “que bancos de dados essa stack usa?”, “quais ferramentas eu uso?”. Queries estruturadas, respostas estruturadas.

Quando fatos mudam

O KG não sobrescreve — ele expira. Quando algo muda (um novo banco de dados, um destino de deploy diferente, uma ferramenta trocada), o fluxo é:

1. Invalidar o fato antigo: mempalace_kg_invalidate(subject, predicate, object) → marca valid_to = hoje
2. Adicionar o fato novo: mempalace_kg_add(subject, predicate, new_object) → valid_from = hoje

O fato antigo permanece no grafo, com timestamp. O resultado é uma linha do tempo:

personal-blog → uses_theme → twentytwentyfour   (válido: ?→ 2025-11-30)
personal-blog → uses_theme → astra              (válido: 2025-12-01 → presente)

Você pode consultar o grafo com as_of="2025-06-01" para ver o que era verdade em qualquer ponto. Dois fatos com o mesmo predicado podem coexistir se ambos forem atuais — por exemplo, um projeto que genuinamente usa dois bancos de dados simultaneamente. O grafo representa a realidade, não só o último snapshot dela.

O protocolo que fecha o loop

As três camadas funcionam juntas quando são alimentadas consistentemente. O mecanismo é simples: no fim de cada sessão que produziu algo que vale a pena guardar, antes da conversa fechar:

1. O stop hook já salvou o checkpoint de diário
2. Eu extraio de 3 a 5 fatos da sessão e os adiciono como triplas no KG
3. O precompact hook vai minerar a transcrição completa na próxima compressão

O passo 2 é a única parte manual. Leva trinta segundos e talvez cinco chamadas MCP. Os fatos adicionados no fim de uma sessão ficam disponíveis como contexto estruturado em toda sessão futura.

Com o tempo, o sistema acumula: decisões com sua justificativa, detalhes de stack por projeto, preferências e correções que viram comportamento padrão. Cada sessão começa mais “aquecida” que a anterior.

Por que três camadas e não uma

Um único CLAUDE.md cobre o projeto mas não o histórico. Um banco de dados vetorial cobre o histórico mas não a estrutura. Um grafo de conhecimento cobre a estrutura mas não o contexto em prosa. Cada camada preenche uma lacuna que as outras deixam.

O overhead é baixo justamente porque cada camada é estreita: CLAUDE.md é um arquivo que você escreve uma vez e atualiza ocasionalmente. O MemPalace roda seus hooks automaticamente. O KG cresce algumas triplas por sessão.

O valor não está em nenhuma camada isolada — está em não precisar reestabelecer contexto toda vez. A décima sessão com um projeto deveria parecer uma continuação, não um recomeço. É isso que essa stack torna possível.

Esse é o design. Depois de alguns meses rodando isso em quatro projetos ativos, parei para contar o que realmente tinha se acumulado — quantas memórias, classificadas em quê, e o que o grafo poderia me contar que eu ainda não sabia.