Exocortex: como dei memória permanente à IA para que as conversas parem de evaporar

Existe um defeito na forma como a maioria de nós usa IA e que a gente nem percebe mais, de tão acostumado: toda conversa começa do zero. Você passa uma tarde inteira ensinando um modelo o contexto de um projeto — as decisões, os becos sem saída, o porquê de cada escolha —, fecha a janela, e no dia seguinte é como se nada tivesse acontecido. A inteligência estava toda ali, e evaporou junto com a sessão.

Este texto é sobre o que eu fiz para parar de aceitar isso. Não um truque, não um plugin: uma memória permanente, em camadas, que captura o que acontece nas conversas, destila esse material, guarda para sempre e devolve o que importa quando importa. Eu a chamo de Exocortex — internamente, também de CMS, Context Memory System. Faz oito meses que ela roda todo dia no meu trabalho, e a essa altura eu não sei mais trabalhar sem ela.

Por ser proprietária, o que compartilho neste estudo de caso são os resultados, a arquitetura e o mecanismo — não o passo a passo de implementação, o molho secreto. Mas por ser um estudo de caso, e não um artigo de vitrine, eu vou mais fundo no técnico do que num post comum: explico o quê, o como em nível de camada e pipeline, e principalmente de onde vem cada número. Inclusive os feios. Sobretudo os feios.

O problema de verdade não é a IA esquecer. É que a "solução" nativa piora as coisas.

Todo mundo que trabalha com IA de forma séria bateu nessa parede: a janela de contexto tem um limite, e quando ela enche, alguma coisa precisa sair. As ferramentas oferecem duas saídas nativas para isso. A primeira é a compactação — no Claude Code, o /compact — que resume a conversa para caber mais. A segunda são os recursos de "memória" embutidos em praticamente qualquer CLI de IA, que prometem guardar o que você já disse.

O problema é que, na minha experiência de uso diário, as duas deterioram o contexto em vez de preservá-lo. A compactação nativa é subtração: ela resume, e resumir é escolher o que jogar fora. Pontos importantes da janela somem ou ficam borrados, e você só descobre quais quando a IA responde como se nunca tivesse tido aquela informação. A memória nativa tem o mesmo defeito de origem — ela guarda uma versão empobrecida, não o sinal limpo.

E aqui está a consequência concreta, a que doeu: projetos que antes eram simplesmente impossíveis de tocar por causa dessa perda de contexto passaram a ser viáveis quando resolvi o problema por baixo. Não é conveniência. É a diferença entre "dá para fazer" e "não dá".

A compactação nativa de contexto é subtração: ela resume, e resumir é decidir o que jogar fora. O problema de a IA esquecer não se resolve descartando com mais elegância — se resolve guardando o sinal limpo em outro lugar e trazendo de volta o que importa.

A pergunta que ficou martelando foi essa: e se, em vez de espremer a conversa para caber numa janela que sempre vai encher de novo, eu tirasse a memória de dentro da janela? Guardasse fora, num lugar próprio, destilada e organizada — e devolvesse à IA só o pedaço relevante, na hora certa?

Por que memória, e por que em camadas: o modelo veio da cabeça humana

A ideia não foi inventada do nada. Ela veio de olhar para como a memória humana funciona.

Você não carrega o dia inteiro na consciência o tempo todo. Tem o que está agora na sua frente — quente, imediato, volátil. Tem o contexto de médio prazo, aquilo que você acessa quando precisa. E tem a memória de longo prazo, consolidada, que não some, mas também não fica ocupando espaço mental o tempo inteiro — você a puxa quando algo a evoca, por associação, por data, por semelhança.

O Exocortex copia essa arquitetura em três camadas:

Foundation — a base. O que é estável e quase sempre relevante: quem é você, as decisões estruturais, o que não muda de uma sessão para outra. É a memória de longo prazo consolidada.

Context — a camada intermediária. O contexto de médio prazo que se acessa quando o assunto pede.

Active — o que está quente agora, o material da sessão em andamento, volátil e cheio de detalhe.

A analogia com memória de curto e longo prazo não é enfeite de texto: ela é o princípio de projeto. Cada camada tem um orçamento próprio de tokens e um comportamento próprio. A Foundation é enxuta e protegida; a Active é generosa e efêmera. E isso resolve um problema que a compactação nativa nunca resolve: em vez de tratar toda a conversa como uma coisa só que precisa encolher, o sistema sabe o que é permanente, o que é contextual e o que é descartável — e trata cada um de forma diferente.

Para dar dimensão concreta, estes eram os orçamentos e o uso real de cada camada no momento em que apurei os dados: a Foundation em 843 de 5.000 tokens, a Context em 1.043 de 10.000, e a Active em 59.210 de 15.000 — sim, acima do orçamento, num estado de alerta. Volto a esse alerta mais adiante, na parte das limitações, porque ele conta uma verdade sobre o sistema em vez de esconder um defeito.

A jornada até aqui: 8 meses, de 32 para 4.276 memórias

Uma memória só prova o seu valor com o tempo — porque a graça dela é justamente acumular. Então o dado que mais me diz alguma coisa não é uma medição de um instante, é a curva.

O Exocortex começou a registrar em novembro de 2025 com 32 memórias. Em julho de 2026, quando apurei os números para este texto, eram 4.276 — cerca de 229 dias de acúmulo contínuo, sem que nada tenha evaporado no caminho. A curva mês a mês conta a história: 32 em novembro de 2025, 223 em dezembro, 326 em janeiro de 2026, 499 em fevereiro, 1.519 em março, 3.034 em abril, 4.004 em maio, 4.225 em junho, 4.276 em julho. O pico de crescimento foi entre março e maio de 2026 — o período em que a coisa passou de experimento a infraestrutura do meu dia a dia.

Uma memória de IA que nunca evapora se prova na curva, não no instante: de 32 registros em novembro de 2025 para 4.276 em julho de 2026, sem perder o acumulado no caminho. É a diferença entre uma ferramenta que lembra e uma que recomeça do zero toda sessão.

Isso é a prova mais direta do argumento inteiro. Cada uma dessas 4.276 memórias é uma conversa que, num fluxo normal de IA, teria evaporado no fechamento da sessão. Aqui, ficou.

Como a memória se forma: o pipeline de destilação, contado por dentro

Capturar a conversa é a parte fácil. O trabalho de verdade é transformar um monte de texto bruto de sessão em memória que valha a pena guardar e recuperar. É aí que mora a engenharia, e é aqui que vou ser o mais concreto possível sem entregar o passo a passo.

O material passa por um funil de estágios:

L0 — captura bruta. É a conversa como ela aconteceu, sem tratamento. Volumosa, repetitiva, cheia de ruído: idas e vindas, coisas que não deram em nada, o mesmo ponto dito de três formas. É a matéria-prima.

L1 — refinamento. Aqui é onde a inteligência acontece. O bruto é lido, entendido e reescrito como uma memória limpa: o que importou, por quê, quais decisões ficaram de pé. É o estágio que separa sinal de ruído — e, como vou mostrar nos números, é o que custa tempo, porque pensar custa.

Densificação com NTC. Sobre a memória já refinada entra o NTC, a engenharia de prompt proprietária que criei — a mesma do primeiro estudo de caso desta série. Aqui ele não corta muito; ele organiza. A memória fica mais densa e mais fácil de buscar depois, sem virar um resumo empobrecido. Sinal sem ruído, do jeito que a tese do NTC prega.

Embeddings. Cada memória vira também um vetor — uma representação numérica do seu significado — para permitir busca por semelhança semântica, não por palavra exata.

L2 — PostgreSQL. No fim, a memória destilada e vetorizada é persistida num banco de dados dedicado, permanente, fora da janela de qualquer sessão.

Repare no encadeamento: bruto → refinado → densificado → vetorizado → guardado. Cada estágio faz uma coisa e passa adiante. E o resultado é uma memória que não é um "resumo" no sentido de coisa cortada — é uma destilação no sentido de coisa concentrada.

A recuperação: por relação, por data, por significado — não por "colar tudo de volta"

A parte que muda a minha vida no dia a dia não é o guardar. É o recuperar.

Quando abro uma sessão nova, o sistema não me faz colar o histórico. Ele reinjeta a memória relevante por conta própria — e "relevante" aqui é definido por vínculos: relacionamentos entre memórias, datas, e proximidade semântica via os embeddings. Eu pergunto algo sobre um projeto, e o que volta é o que aquele assunto evoca em toda a base, inclusive coisas de outras sessões que eu nem lembraria de procurar.

Na prática, isso significa uma coisa que virou rotina para mim: eu saio de uma sessão com a janela em torno de 90% de uso — cheia — e abro uma nova sem perder os detalhes. Não só os da conversa anterior, mas os de várias. A memória volta pela relação, pela data, pelo significado. É o mais perto de "lembrar" que eu já vi uma máquina chegar.

E tem o controle: as camadas são geradas de forma automática, mas eu posso forçar o salvamento quando quero cravar um momento. Automático por padrão, manual quando importa. Essa combinação é o que me dá a segurança de saber que nada vai se perder.

Os números, e de onde cada um veio

Agora os dados. Todos foram apurados em modo somente-leitura no dia 16 de julho de 2026, direto do sistema em produção. Nada aqui é estimativa.

O funil de compressão

O número de manchete é este: as 4.276 memórias ocupavam 56,08 milhões de tokens em estado bruto (L0). Depois do refinamento (L1), caíram para 14,05 milhões. Depois da densificação com NTC, para 11,00 milhões. Isso dá uma redução média de ~80% ao longo das 4.276 memórias — de 56 milhões para 11 milhões de tokens, cerca de 45 milhões economizados. Só a etapa de refinamento (L0 para L1) já responde por 42 milhões desse corte; a densificação com NTC apara o resto.

Na memória típica, a mediana guarda por volta de 19% do tamanho bruto — ou seja, uns 81% de redução na conversa mediana. Uma única conversa chegou a passar de 92% de redução, mas isso é um caso ilustrativo, o melhor da distribuição, não a média — e eu marco isso de propósito, porque citar o melhor caso como se fosse o normal é o começo da desonestidade.

Tem uma nuance que preciso abrir, porque ela é contraintuitiva. O corte pesado acontece de L0 para L1 — o refinamento. A etapa do NTC, de L1 para o final, é um aperto leve: na mediana, ela guarda uns 90% dos tokens que recebeu. O valor do NTC aqui não é cortar, é densificar e deixar buscável. Confundir uma coisa com a outra seria vender fumaça, então: o grande enxugamento é a destilação; o NTC é a organização por cima.

A escala

Para dar dimensão do que existe guardado hoje: 4.276 memórias em NTC, 4.254 memórias refinadas em L1, 2.644 capturas brutas ocupando 5,28 GB. A deduplicação por SHA-256 identificou 1.348 conteúdos únicos (647 hashes de conversa e 701 de documento) — ou seja, o sistema não guarda a mesma coisa duas vezes. Os embeddings são 4.271 memórias representadas em 384 dimensões cada, com um modelo multilíngue. No total, 123.906 mensagens já passaram pelo pipeline, ao longo de 2.021 execuções.

Um aviso que faço questão de repetir sempre que apareço com um número grande de tokens: token é escala de uso, não prova de competência. 56 milhões de tokens brutos dizem que eu uso IA muito, não que uso bem. A parte que fala de qualidade é a redução e a recuperação — não o tamanho da pilha.

A latência: a inteligência custa tempo

O pipeline rodou 2.019 execuções completas de ponta a ponta. A mediana de tempo foi de cerca de 227 segundos (uns 3,8 minutos), e o percentil 95 ficou em torno de 581 segundos (uns 9,7 minutos).

Mas a distribuição é bimodal, e esconder isso distorceria a leitura. Há 367 execuções abaixo de 10 segundos — essas são casos em que não havia nada de novo para processar: cache batido, sem trabalho a fazer. O resto são as execuções de verdade, as de 2 a 10 minutos, que fazem o processamento completo.

Quando abro uma execução real por estágio, fica claro onde o tempo mora: o refinamento L1 levou 272,6 segundos, algo em torno de 73% do tempo total. A densificação com NTC, 73,8 segundos. Embeddings e a sincronização com o L2 são caudas baratas. A lição é honesta e vale como frase solta:

A parte cara do pipeline não é comprimir nem guardar — é entender. O refinamento, que transforma bruto em memória limpa, come cerca de 73% do tempo. A inteligência custa; o armazenamento é barato.

PostgreSQL não é fraqueza. É a memória que atravessa máquinas.

Tem uma objeção que eu ouço e discordo: "mas guardar num banco de dados externo não é frágil?". Para mim é o contrário — é justamente a força do projeto.

Uma memória presa dentro de uma janela de contexto morre com a sessão. Uma memória num banco de dados dedicado, com embeddings vetoriais, é portátil. Ela pode ser compartilhada entre máquinas, entre aplicações — em tese, até entre robôs. Uma instância aprende, e todas podem lembrar. É a diferença entre a lembrança de um indivíduo e o conhecimento de uma organização.

Sobre a evidência dessa camada, preciso ser rigoroso e honesto. No livro-razão local, 4.275 das 4.276 memórias estão marcadas como sincronizadas com o L2, e 1.645 processos filhos de sincronização foram disparados ao longo do histórico. Na execução mais recente, os estágios de sincronização e de embeddings do L2 completaram — o que prova que a cadeia inteira, de L0 até o PostgreSQL, chega ao fim de ponta a ponta.

Agora o limite, dito na cara: eu não consultei a contagem de linhas ao vivo no PostgreSQL. Isso exigiria abrir credenciais do banco, o que evitei de propósito para este estudo. Então a capacidade de memória distribuída eu afirmo pelo livro-razão local de sincronização e pelos estágios que completaram — não por uma contagem de linhas no banco em tempo real. Não vou inventar um número de PG que eu não fui buscar.

As limitações (porque candura é credibilidade)

Um estudo de caso que só tem boas notícias é panfleto. Então, com o mesmo cuidado dos números bons, os buracos.

Tem lixo na base, e eu sei disso. Das memórias que passaram de L0 para L1, 823 entradas ficaram com zero tokens refinados — são pedaços vazios ou só de metadado, coisas que entraram no pipeline mas não tinham conteúdo real para destilar. E, na direção oposta, 122 memórias cresceram em vez de encolher: eram entradas minúsculas que ganharam mais estrutura do que tinham de origem. Nenhuma das duas coisas é bonita, e as duas são reais.

O orçamento da camada Active está estourado agora, no momento em que escrevo. Os números que mostrei lá em cima: Foundation em 843 de 5.000 tokens, Context em 1.043 de 10.000, e Active em 59.210 de 15.000 — 394% do orçamento, em alerta. Eu poderia ter apurado num momento mais bonito. Não apurei de propósito. Esse alerta é a fiscalização de orçamento funcionando ao vivo: quando a Active estoura, o sistema reage — reorganiza, comprime, consolida. Ver o alerta aceso é ver o mecanismo trabalhando, não um defeito varrido para debaixo do tapete.

E aqui vale uma comparação que confunde muita gente, então deixo explícita: a soma da camada Active (59.210 tokens) e o current.md (o retrato consolidado e ao vivo da memória, 4.254 tokens, bem abaixo do alvo de 30.000) são coisas diferentes. A Active soma todo o conteúdo quente de sessão, bruto. O current.md é a visão destilada — o que sobra depois de organizar. Um é a bagunça momentânea; o outro é o resumo limpo dela.

Não meço tudo que eu gostaria. Uma coisa eu consigo cravar com número real, e outra não. O custo de arrastar uma janela cheia contra recuperar a memória numa sessão nova, isso eu calculo com o preço de tabela do modelo, e mostro adiante. Mas a qualidade da recuperação — o quanto a IA de fato trabalha melhor com a memória destilada do que com a janela entulhada — essa é a minha experiência e a minha lógica, não uma métrica que eu bati num teste controlado. Vou defender esse ponto com o que tenho: raciocínio ancorado em dados. Mas aviso que é raciocínio, não um índice de qualidade que eu não medi.

Uma sessão de quase 1 milhão de tokens vira uma memória de 15 mil

Este é o número que melhor resume o que a memória faz, e ele merece ser dito com cuidado, porque é fácil apresentar errado.

Primeiro, o que não fazer: pegar um estágio intermediário do meu pipeline e dizer "olha quanto isso comprimiu". O começo real de tudo não é um arquivo já tratado — é a janela de contexto da sessão, cheia, do jeito que ela fica depois de uma tarde de trabalho: o system prompt, as ferramentas, os arquivos que a IA leu, e o ruído que se repete a cada turno da conversa. É essa janela inteira que precisa virar memória. E o fim de tudo é a memória final — refinada, densificada, organizada em camadas — que eu recupero na sessão seguinte.

Então medi exatamente isso, de ponta a ponta, em sessões reais deste e de outros projetos: qual era o pico da janela de contexto, e em quanto de memória final ela se transformou. Os números são estes:

Uma sessão que chegou a 969 mil tokens de janela — quase 97% de uma janela de 1 milhão — virou uma memória final de 18,6 mil tokens. Outra, de 966 mil, virou 13,8 mil. Outra, de 943 mil, virou 8,3 mil. O padrão se repete: uma janela beirando o milhão se transforma numa memória final na casa dos 13 a 19 mil tokens. Sessões menos densas geram menos; algumas ficam em 7 ou 8 mil. A faixa é essa, e eu prefiro dar a faixa a fingir um número único.

E aqui está a parte que quero deixar clara, porque é o mérito do sistema e não um acaso: esse encolhimento não é "espremer" a janela. É o resultado de estágios sucessivos de eliminação de ruído. A captura já entra tirando repetição; o refinamento tira mais, e reescreve o que sobrou como conhecimento limpo; a densificação com NTC organiza; e as camadas separam o que é permanente do que é passageiro. Cada etapa joga fora ruído e preserva sinal. O que sobra no fim não é um resumo cortado — é o essencial concentrado.

Uma sessão de IA que encheu quase 1 milhão de tokens de janela de contexto vira, no fim do pipeline, uma memória final de 13 a 19 mil tokens. Não por compressão bruta, mas por eliminação de ruído em camadas: a captura tira repetição, o refinamento reescreve como conhecimento limpo, e o que sobra é sinal concentrado — pequeno o bastante para caber numa sessão nova, grande o bastante para não perder o que aconteceu.

Repare que a memória final não é minúscula, e isso é de propósito. Se eu espremesse até virar meia dúzia de linhas, ela perderia o detalhe do que aconteceu — e recuperar uma memória sem detalhe é começar quase do zero de novo. Os 15 mil tokens são o ponto de equilíbrio: uma fração limpa da janela original, mas densa o suficiente para reconstruir o contexto de verdade. Não é à toa que, quando recupero cerca de 30 memórias de uma vez, isso dá algo em torno de 100 mil tokens — o suficiente para retomar semanas de trabalho numa sessão nova e leve.

Onde a memória em camadas muda o meu trabalho de verdade

Números são abstratos até você ver onde eles pousam. Então deixa eu ser concreto sobre o que essa memória faz no meu dia a dia — e são dois modos de uso bem diferentes.

Modo um: uso normal, do dia a dia. No trabalho comum, eu não fico compactando a toda hora. Deixo a sessão correr, e chega um ponto — por volta de 70% a 90% de uso da janela — em que já não compensa continuar ali. Uma janela nesse nível de ocupação atrapalha mais do que ajuda: virou bagunça, ruído acumulado, e cada mensagem nova fica mais cara e menos precisa. Aí eu salvo a memória, fecho, e recupero o destilado numa sessão nova e limpa. Isso conecta direto com a tese do NTC do primeiro estudo de caso: o inimigo da compreensão não é a densidade, é a bagunça. Sinal sem ruído.

E a diferença de custo aqui não é retórica — dá para calcular, com o preço real do modelo. Vou usar o Claude Opus 4.8, cujo preço de tabela é 5 dólares por milhão de tokens de entrada, ou 50 centavos por milhão quando a entrada vem do cache. O detalhe importante é como o cache funciona: a primeira mensagem numa janela grande precisa escrever o cache — e paga caro por isso; as mensagens seguintes leem do cache, mais barato, mas ainda proporcional ao tamanho da janela. Ou seja: janela grande é cara mesmo com o cache ajudando. Veja o que custam duas mensagens em cada cenário:

Continuar numa janela em 900 mil tokens custa cerca de US$ 6,16 por duas mensagens. Na mesma situação, salvar a memória e recuperá-la numa sessão nova de uns 18 mil tokens custa US$ 0,20 — cerca de 30 vezes mais barato. Numa janela em 700 mil, a conta é US$ 4,81 contra os mesmos US$ 0,20 (umas 24 vezes). Em 500 mil, US$ 3,46 (umas 17 vezes). E isso já contando o cache a favor da janela cheia, no cenário mais generoso possível para ela. Preciso ser honesto sobre o que é isto: um cálculo ilustrativo, com preços reais de tabela, não uma fatura que eu bati. Mas a proporção é robusta, porque o que encarece é físico — quanto maior a janela, mais tokens você reprocessa a cada mensagem.

Continuar trabalhando numa janela de contexto em 900 mil tokens custa, no Claude Opus 4.8, cerca de 30 vezes mais por mensagem do que salvar a memória e recuperá-la numa sessão nova de 18 mil tokens. Janela cheia não é só mais lenta e mais confusa — é literalmente mais cara, porque cada mensagem reprocessa a janela inteira.

Modo dois: agentes rodando 24 horas, por dias ou semanas. Este é o uso que a memória de fato viabiliza, e onde eu configuro as coisas de um jeito diferente. Quando deixo um agente coordenador dirigindo vários sub-agentes num projeto complexo, sem parar, eu ligo a compactação automática para disparar quando a janela chega a 45% de uso. Parece contraintuitivo compactar tão cedo, mas o motivo é justamente a memória: a compactação nativa, sozinha, deterioraria o contexto — comeria pedaços importantes a cada ciclo, até o projeto perder o rumo. Com a memória em camadas por baixo, ela vira só uma limpeza de janela. O que importava já foi guardado limpo, e é reinjetado automaticamente na continuação, por conta própria, via hooks e configuração complementar. A sessão seguinte não fica refém da compactação — ela recomeça com o sinal, não com o resíduo.

Para deixar agentes trabalhando 24 horas por dia, por dias ou semanas, eu configuro a compactação automática em 45% da janela. Sozinha, a compactação nativa deterioraria o contexto. Com a memória permanente por baixo, ela vira apenas uma limpeza — o que importa é reinjetado automaticamente, e o desenvolvimento não para.

É a diferença entre um agente que se perde depois de algumas horas e um que atravessa a semana inteira sem perder o fio. Sem memória em camadas, projetos assim são inviáveis — cada compactação seria uma amnésia parcial. Com ela, o coordenador e os sub-agentes seguem, porque a cada ciclo recuperam o sinal limpo em vez de arrastarem a bagunça acumulada.

O que isso significa, e por que conta a mesma história do NTC

Tirando a moldura de estudo, o que sobra é simples: eu não consigo mais trabalhar sem essa memória. Não é força de expressão. A segurança de saber que consigo recuperar o que foi feito — pelas camadas, pela geração automática, pelo poder de forçar um salvamento quando quero — mudou o que eu me permito começar.

E isso fecha um arco com o primeiro estudo de caso desta série. O NTC mostrou que o inimigo da compreensão da IA não é a densidade da informação, é a bagunça. O Exocortex é essa mesma ideia aplicada ao tempo: o inimigo da continuidade não é a quantidade de história acumulada, é o ruído dela. Guarde o sinal, jogue fora o ruído, e traga de volta só o que importa — e a IA para de recomeçar do zero. O NTC, aliás, é uma das peças de dentro do Exocortex: a etapa que densifica a memória depois de destilada.

Isso conversa com a ideia que guia tudo o que faço no método Prompthen, que também criei: a complexidade deve ser opcional, nunca uma barreira. Você não precisa entender como um pipeline de destilação em camadas funciona por dentro para colher o resultado de uma IA que lembra. A porta está aberta para quem quiser abrir o capô — este texto é essa porta —, mas ninguém é obrigado.

E, para ser transparente sobre o sustento de quem escreve: o método e o conteúdo são gratuitos. O que se cobra, quando se cobra, é o serviço de aplicar isso na dor específica de alguém — consultoria, treinamento, projeto. Menciono uma vez só, para você saber de onde vem o pão, e sigo. O conhecimento fica aberto.

No fim, o Exocortex não é sobre um banco de dados esperto. É sobre uma teimosia: a de que uma IA que esquece tudo a cada sessão está desperdiçando a parte mais valiosa do trabalho, que é o contexto construído. Dê memória a ela — memória de verdade, destilada e permanente, não um resumo que apaga o que importa — e ela para de começar do zero. Eu também.