Montei o sistema de memória, usei por alguns meses, e depois parei para olhar o que ele realmente tinha acumulado.

O post anterior descreve como as três camadas funcionam: CLAUDE.md para contexto estático, MemPalace para memória dinâmica de sessão, um grafo de conhecimento para fatos estruturados. O MemPalace não é o recurso de memória embutido do Claude — é uma infraestrutura que eu mesmo rodo, com memórias armazenadas em ChromaDB e SQLite na minha máquina e integração via MCP (Model Context Protocol), um padrão aberto que qualquer cliente compatível pode falar. Se eu trocasse de modelo amanhã, tudo o que ele acumulou continuaria no lugar.

Os termos abaixo vêm da própria estrutura do MemPalace: uma wing é uma por projeto (mais uma compartilhada para sessões entre projetos), uma room é um tópico dentro de uma wing (technical, architecture, problems, e assim por diante), e uma drawer é uma memória individual armazenada. Este post é o outro lado do design — o que realmente está lá dentro depois de meses de uso real, e o que isso revela sobre como trabalho nos meus projetos.

O palácio, em números

A primeira vez que rodei essa autópsia, o palácio tinha 2.388 drawers em 8 wings. Estou rodando de novo agora, semanas depois — e nesse meio-tempo, um hackathon fez surgir novos projetos e deixou sessões longas para os hooks minerarem. Os números se moveram mais do que eu esperava.

12.732 drawers no total, em 13 wings.

Wings por contagem de drawers:

Conteúdo por tipo de room, em todas as wings:

A primeira coisa que notei: architecture (861) ainda supera problems (46) — cerca de 19 para 1. Diferença menor do que os 114 para 1 que encontrei da primeira vez, mas o formato da conclusão não mudou: a maior parte do tempo nessas sessões vai para design e raciocínio sobre estrutura, não para debugging.

A segunda coisa: diary cresceu de 108 entradas para 251. A room de diary não é por projeto — é o checkpoint do stop hook para qualquer sessão — então esse número é na verdade uma contagem de salvamentos não assistidos: 251 checkpoints que aconteceram sem eu fazer nada.

A terceira coisa: uma room chamada disk, três drawers. Essa veio de uma sessão em que pedi ao Claude para caçar arquivos que eu poderia apagar para liberar espaço em disco, e o extrator decidiu que o tópico merecia sua própria room.

O que o extrator classificou

O extrator funciona sem um LLM — correspondência de palavras-chave e padrões no conteúdo da conversa. É conservador. Uma sessão precisa bater claramente com um padrão antes de um trecho ser classificado.

Aqui está um exemplo real da room problems — o problema de SSH Git que surgiu durante a configuração do homelab:

ssh: connect to host localhost port 2222: Connection refused O problema é que o remote SSH aponta para localhost:2222, mas essa porta não está ativa. origin2 aponta para localhost:2222, mas o Git SSH é exposto via NodePort 30022 no IP do servidor — não no localhost.

Esse trecho foi classificado corretamente: é um problema, com uma causa raiz, com duas opções de solução explícitas. O classificador pegou porque “problem”, “Connection refused”, e a estrutura de opções batem com os padrões dele.

Um exemplo real de architecture, da exploração de um projeto privado de API geoespacial:

Documentos de arquitetura principais: /docs/architecture/decisions.md — ADRs justificando escolhas arquiteturais. Layout de schema: public, ref, raw, ingest, outbox. Responsabilidades de container, variáveis de ambiente, exchanges do RabbitMQ.

Isso foi para architecture porque descreve estrutura de sistema. É um trecho que eu gostaria de ter disponível ao voltar para aquele codebase semanas depois — sem precisar reler cinco arquivos para reconstruir o que eu já sabia.

O que não é classificado: idas e vindas conversacionais, perguntas genéricas, trocas incompletas. As 357 drawers em general são o resíduo — coisas que não se encaixaram num tipo específico de room mas continham conteúdo útil.

O que eu perguntei ao grafo de conhecimento (KG)

O KG começou vazio. Eu o semeei manualmente com o que sei sobre o estado atual dos meus projetos. Depois de uma única sessão adicionando triplas, eu conseguia perguntar:

“Em que o User trabalha?”

User → works_on → personal-blog
User → works_on → geo-service
User → works_on → rural-registry
User → works_on → devops-toolkit
User → works_on → video-pipeline
User → works_on → content-studio
User → uses → Claude Code  (desde 2026-01-01)
User → uses → MemPalace    (desde 2026-01-01)

A lista acima está reduzida por espaço — o grafo rastreia uma dúzia de wings de projeto a essa altura, não quatro.

“Qual é a stack do personal-blog?”

personal-blog → uses_framework → Hugo
personal-blog → uses_theme      → theme-engine
personal-blog → deployed_on     → home-cluster
personal-blog → serve_via     → cloudflared

“O que o geo-service usa?”

geo-service → uses_backend  → FastAPI
geo-service → uses_db    → PostgreSQL
geo-service → uses_extension → PostGIS
geo-service → deployed_on    → home-cluster

Essa última query levou uma chamada MCP e retornou resultados estruturados. Compare isso com a alternativa: buscar no palácio, interpretar texto, torcer para que a sessão relevante já tenha sido minerada antes dessa.

O que percebi olhando de fora

Tudo faz deploy no home-cluster. Todo projeto ativo — uma dúzia deles agora, não os quatro que eu tinha da primeira vez que rodei essa checagem — resolve para a mesma tripla → deployed_on → home-cluster. Eu já sabia isso abstratamente; ver isso soletrado como uma dúzia de fatos quase idênticos tornou o ponto único de falha concreto de um jeito que a versão abstrata nunca tinha feito. Se o servidor doméstico tiver um dia ruim, nada degrada graciosamente — tudo cai de uma vez.

A wing sessions supera todo o resto. Mais do que na primeira vez, inclusive: 12.478 de 12.732 drawers estão na wing entre projetos — 98%, subindo de 95%. Isso é esperado — o hook de sessão roda em toda conversa, e novos projetos majoritariamente adicionam conversas, não drawers específicos de projeto — mas significa que as wings de projeto estão mais subrepresentadas agora do que antes. No momento, elas seguram cerca de 2% do total de conhecimento, combinadas.

O extrator pegou mais dessa vez. problems foi de 4 drawers para 46 — um salto real, não ruído. Parte disso é só mais sessões para minerar; parte é mais debugging de fato, já que alguns dos projetos mais novos estão em estágio inicial e mais bagunçados. 46 de 12.732 ainda é uma fatia pequena, mas já não sustenta a ideia de que debugging é raro para mim. Ainda assim, uma taxa de problemas abaixo de meio por cento é uma margem que eu aceitaria qualquer dia.

O KG revela o que as drawers não conseguem. Uma drawer conhece o conteúdo de um trecho de sessão. O KG conhece as relações entre as coisas. “Quais projetos compartilham a mesma infraestrutura?” é uma pergunta de grafo, não uma pergunta de busca. Antes de construir o KG, essa resposta exigia ler entre wings. Agora é uma única query.

O que o sistema está começando a permitir

Agora consigo perguntar coisas que não conseguia antes — ou não conseguia perguntar eficientemente:

• “Quais projetos usam o home-cluster?” → resposta estruturada imediata
• “O que era verdade sobre o personal-blog numa data específica?” → query temporal, à medida que o grafo cresce
• “Quais ferramentas eu uso consistentemente?” → padrão em todos os projetos, não só numa sessão

Nada disso era possível quando o contexto vivia só na minha cabeça, ou só em texto colado no início de cada sessão. O sistema não está substituindo julgamento — está tornando o histórico acessível da mesma forma que boa documentação torna um codebase acessível: sem precisar reconstruir entendimento do zero toda vez.

O que ainda falta

O KG está vazio de feedback. Adicionei fatos de projeto — o que um projeto usa, onde faz deploy — mas não as correções e preferências que o MemPalace já armazena como drawers: “não faz X por causa de Y”, “sempre Z antes de W”.

A lacuna não é de vocabulário. Já existe um predicado para preferências de IA. A lacuna é de formato: uma tripla é sujeito → predicado → objeto, três slots planos, e “por causa de Y” não cabe em nenhum deles sem virar uma frase inteira espremida no objeto. Isso me dá um fato que posso consultar, não um que posso pesquisar estruturalmente — o que anula o propósito de ter um grafo em vez de só uma drawer.

O extrator tem uma versão do mesmo problema. Ele não sabe o que é importante numa sessão, só o que bate com o padrão de “decisão”, “problema” ou “marco”. Sinal e ruído acabam misturados nas drawers. Busca semântica cobre isso razoavelmente bem, mas não perfeitamente.

No momento o KG tem 34 entidades e 32 triplas, todas atuais — nada mudou o suficiente ainda para forçar uma invalidação. Cada uma dessas triplas, eu adicionei manualmente.

Isso provavelmente não é um estado temporário. O extrator de drawers consegue pular o LLM porque classificar um trecho como “parece um problema” só precisa estar certo na maior parte das vezes — um problema de recall. Construir uma tripla é um problema de precisão: o sujeito certo, o predicado certo de uma lista fixa, o objeto certo, e um julgamento sobre se substitui algo já existente no grafo. Correspondência de padrões não faz esse tipo de trabalho de precisão. Automatizar isso direito significa colocar um LLM no loop no momento de criação da tripla, não só adicionar mais um hook.

O que vale a pena guardar

A parte mais interessante de construir esse sistema não foi a configuração. Foi olhar o que saiu do outro lado.

Parte disso foram só números se mantendo estáveis sob uma luz nova: a room de architecture ainda cheia, a room de problems ainda fina, a wing de sessions engolindo quase tudo mais. Nada disso precisava de um grafo — uma tabela de contagens já dizia isso claramente.

O que precisava do grafo era um tipo diferente de pergunta: não o que um projeto é, mas com o que ele se conecta. “Quais projetos fazem deploy no home-cluster?” traz os doze de volta numa única query. Sem o grafo, obter a mesma resposta significa abrir cada uma das doze wings e checar manualmente — mais lento, e fácil de errar deixando uma passar.

Essa é a parte que vale a pena guardar: não o MemPalace especificamente, mas o framework que ele implementa — camadas separadas para o que uma coisa é, o que aconteceu com ela, e como ela se conecta a tudo mais. A ferramenta poderia mudar. A stack da solução, e a razão pela qual um grafo é a peça que responde “como as coisas se conectam”, não mudaria.