---
title: "Exocortex: como dei memória permanente à IA para que as conversas parem de evaporar"
description: "Por padrão, toda conversa com IA começa do zero — e as correções nativas, o /compact e as memórias embutidas, deterioram o contexto em vez de preservá-lo. Este é o estudo de caso do Exocortex, a memória em camadas que construí para que nem eu nem a IA voltemos a começar do zero. Dados reais, medidos no dia 16 de julho de 2026, com as limitações abertas por inteiro."
canonical: "https://ficaadica.com.br/novidades/exocortex-memoria-permanente-ia/"
language: "pt-BR"
type: "BlogPosting"
author: "Paulo Teixeira"
sameAs:
  - "https://www.youtube.com/@FicaaDica"
  - "https://www.instagram.com/pauloctxr"
  - "https://br.linkedin.com/in/pauloctxr"
  - "https://ficaadica.com.br/sobre/"
---

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

Aqui você vai ver o que aconteceu quando parei de aceitar que toda conversa com IA evapora no fim da sessão. Eu conto por que construí uma memória permanente para IA — inspirada em como a memória humana funciona —, como ela captura, destila e recupera contexto por conta própria, e o que 8 meses de uso diário acumularam: de 32 memórias em novembro de 2025 para 4.276 em julho de 2026, com uma redução média de ~80% no tamanho ao longo do caminho. Vou abrir a arquitetura em nível de mecanismo, mostrar de onde vem cada número, e ser honesto sobre onde o sistema ainda tropeça. Não é panfleto: um alerta de orçamento estourado no exato momento em que escrevo está no texto, porque esconder isso seria mentir.

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.

![Crescimento acumulado de memórias ao longo de 8 meses: 32 em nov/2025, 223 em dez, 326 em jan/2026, 499 em fev, 1.519 em mar, 3.034 em abr, 4.004 em mai, 4.225 em jun, 4.276 em jul. O pico de acúmulo entre março e maio de 2026.](/assets/posts/exocortex-memoria-permanente-ia-g2.webp)

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.

![O funil de compressão em três marcos, somando 4.276 memórias: 56,08 milhões de tokens brutos (L0) → 14,05 milhões após o refinamento (L1) → 11,00 milhões após a densificação com NTC. Redução total de ~80%, cerca de 45 milhões de tokens economizados.](/assets/posts/exocortex-memoria-permanente-ia-g1.webp)

### 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:

![Sessões reais, janela de contexto no pico contra a memória final recuperável: 969 mil → 18,6 mil tokens; 966 mil → 13,8 mil; 965 mil → 15,5 mil; 963 mil → 17,2 mil; 943 mil → 8,3 mil. Uma janela em torno de 95% de 1 milhão vira uma memória final de 13 a 19 mil tokens.](/assets/posts/exocortex-memoria-permanente-ia-g3.webp)

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:

![Custo real de duas mensagens no Claude Opus 4.8 conforme o tamanho da janela de contexto: janela em 900 mil tokens custa US$ 6,16; em 700 mil, US$ 4,81; em 500 mil, US$ 3,46; contra US$ 0,20 de uma sessão nova com ~18 mil tokens de memória recuperada. Continuar numa janela cheia sai de 17 a 30 vezes mais caro.](/assets/posts/exocortex-memoria-permanente-ia-g4.webp)

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.

P: Por que a IA esquece tudo a cada nova conversa?
R: Porque, por padrão, o contexto de uma conversa vive dentro da janela daquela sessão — e quando a sessão fecha, ele evapora. A inteligência construída ali, as decisões, o porquê de cada escolha, tudo some junto. Foi para resolver isso que construí o Exocortex, uma memória permanente em camadas: ela captura a conversa, destila o que importa e guarda num banco de dados fora da janela, para devolver depois. Assim nem eu nem a IA começamos do zero na sessão seguinte.

P: O /compact do Claude Code preserva o contexto da conversa?
R: Na minha experiência de uso diário, não bem — ele deteriora. A compactação nativa funciona por resumo, e resumir é decidir o que jogar fora; pontos importantes da janela somem ou ficam borrados, e você só percebe quando a IA responde como se nunca tivesse tido aquela informação. A memória embutida nas CLIs de IA tem o mesmo defeito de origem: guarda uma versão empobrecida. Por isso construí uma memória em camadas por baixo, que preserva o sinal limpo em vez de apenas descartar com mais elegância.

P: O que é o Exocortex?
R: É uma memória permanente para IA que criei — internamente também chamada de CMS, Context Memory System — inspirada em como funciona a memória humana. Ela captura conversas automaticamente, destila esse material por um pipeline de vários estágios, guarda de forma permanente num banco de dados e reinjeta a memória relevante quando você precisa. A arquitetura tem três camadas (Foundation, Context e Active, como memória de longo e curto prazo) e usa busca semântica por vetores para recuperar por significado, não por palavra exata.

P: Como dar memória permanente a uma IA?
R: O caminho que segui foi tirar a memória de dentro da janela de contexto e guardá-la fora, num banco de dados dedicado. O material da conversa é capturado bruto, refinado para separar sinal de ruído, densificado, transformado em vetores para busca semântica e persistido em PostgreSQL. Na sessão seguinte, a memória relevante é reinjetada automaticamente por relação, data e semelhança de significado. O resultado é que a conversa não evapora quando a sessão fecha — ela fica, e volta quando importa.

P: Como funciona a arquitetura de memória em camadas do Exocortex?
R: São três camadas espelhando a memória humana. A Foundation guarda o que é estável e quase sempre relevante — a memória de longo prazo consolidada. A Context guarda o médio prazo, acessado quando o assunto pede. A Active guarda o que está quente na sessão atual, volátil e detalhado. Cada camada tem orçamento próprio de tokens e comportamento próprio, então o sistema trata de forma diferente o que é permanente, o que é contextual e o que é descartável — em vez de espremer tudo junto como faz a compactação nativa.

P: Como a IA recupera a memória certa sem eu colar o histórico de novo?
R: Por vínculos, não por cópia. Quando abro uma sessão nova, o sistema reinjeta a memória relevante por conta própria, e "relevante" é definido por relacionamentos entre memórias, por datas e por proximidade semântica calculada com embeddings vetoriais. Eu pergunto sobre um projeto e volta o que aquele assunto evoca em toda a base — inclusive coisas de outras sessões que eu nem lembraria de procurar. É o mais perto de "lembrar" que já vi uma máquina chegar.

P: Quanto de contexto o Exocortex já acumulou?
R: Apurado em 16 de julho de 2026, eram 4.276 memórias, partindo de 32 em novembro de 2025 — cerca de 229 dias de acúmulo contínuo sem perder nada no caminho. A base tem 4.254 memórias refinadas, 2.644 capturas brutas ocupando 5,28 GB, embeddings de 4.271 memórias em 384 dimensões cada, e 123.906 mensagens já processadas ao longo de 2.021 execuções do pipeline. O pico de crescimento foi entre março e maio de 2026.

P: Quanta compressão o Exocortex faz na memória?
R: Ao longo das 4.276 memórias, a redução média foi de cerca de 80%: o material bruto ocupava 56,08 milhões de tokens e caiu para 11,00 milhões depois de destilado e densificado — cerca de 45 milhões de tokens economizados. Na memória típica, a mediana guarda uns 19% do tamanho bruto (uns 81% de redução). Uma única conversa passou de 92% de redução, mas isso é o melhor caso da distribuição, não a média — e faço questão de marcar a diferença.

P: O NTC é usado dentro do Exocortex?
R: É, como um dos estágios. Depois que a memória é refinada — o passo que separa sinal de ruído —, o NTC, a engenharia de prompt proprietária que criei e que foi tema do primeiro estudo de caso desta série, entra por cima para densificar. Aqui ele não corta muito: na mediana, guarda uns 90% dos tokens que recebeu. O valor dele nesse ponto não é enxugar, é organizar e deixar a memória mais densa e mais fácil de buscar depois. O grande enxugamento é a destilação; o NTC é a arrumação por cima.

P: Guardar a memória da IA em banco de dados não é uma fraqueza?
R: Para mim é o oposto — é 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: pode ser compartilhada entre máquinas, entre aplicações e, 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.

P: Em que ponto da janela de contexto compensa salvar a memória e começar uma sessão nova?
R: Depende do modo de uso, e eu trabalho com dois. No uso normal do dia a dia, não fico compactando: deixo a sessão correr e, por volta de 70% a 90% de uso da janela, salvo a memória e recupero numa sessão nova — a partir daí uma janela cheia atrapalha mais do que ajuda, e fica mais cara. No modo em que deixo agentes rodando 24 horas por dias ou semanas, é diferente: configuro a compactação automática para disparar já em 45% da janela, porque a memória permanente por baixo garante que a sessão seguinte não fique refém dessa compactação — o que importa é reinjetado automaticamente. São os dois únicos percentuais que eu cravo; não invento precisão além disso.

P: Sai mais barato continuar numa janela cheia ou salvar a memória e abrir uma sessão nova?
R: Sai muito mais barato recuperar a memória numa sessão nova, e dá para calcular com o preço real do modelo. No Claude Opus 4.8, continuar numa janela de contexto em 900 mil tokens custa cerca de US$ 6,16 por duas mensagens; salvar a memória e recuperá-la numa sessão nova de uns 18 mil tokens custa cerca de US$ 0,20 — aproximadamente 30 vezes mais barato. Numa janela de 700 mil são umas 24 vezes, e em 500 mil, umas 17 vezes. É um cálculo ilustrativo com preços de tabela, não uma fatura, mas a proporção é robusta: cada mensagem numa janela cheia reprocessa a janela inteira, então quanto maior ela está, mais cara fica.

P: Uma sessão de quase 1 milhão de tokens vira uma memória de que tamanho?
R: Medindo em sessões reais, uma janela de contexto no pico de cerca de 950 a 970 mil tokens — perto de 95% de uma janela de 1 milhão — vira uma memória final na casa de 13 a 19 mil tokens. Não é compressão bruta: é o resultado de estágios sucessivos de eliminação de ruído (a captura tira repetição, o refinamento reescreve como conhecimento limpo, a densificação organiza) e das camadas. E não é minúsculo de propósito: se a memória fosse espremida demais, perderia o detalhe do que aconteceu. Os ~15 mil tokens são o equilíbrio entre caber numa sessão nova e não perder o contexto.

P: Dá para rodar projetos de IA por 24 horas sem parar?
R: Dá, mas na prática só com memória em camadas por baixo. Eu rodo projetos que trabalham 24 horas por dia, por dias ou semanas, com agentes e sub-agentes contínuos. Sem a memória, cada compactação de janela comeria um pedaço do contexto até o projeto perder o rumo. Com ela, o trabalho não para: a cada ciclo os agentes recuperam o sinal limpo em vez de arrastar a bagunça acumulada.

P: Quanto tempo o Exocortex leva para processar uma memória?
R: Em 2.019 execuções completas de ponta a ponta, a mediana foi de cerca de 227 segundos (uns 3,8 minutos) e o percentil 95 ficou em torno de 581 segundos (uns 9,7 minutos). A distribuição é bimodal: 367 execuções abaixo de 10 segundos são casos sem nada novo para processar (cache batido), e o resto são os processamentos completos de 2 a 10 minutos. O estágio mais caro é o refinamento, que sozinho leva cerca de 73% do tempo. A inteligência custa; o armazenamento é barato.

P: O sistema evita guardar a mesma informação duas vezes?
R: Evita, por deduplicação com SHA-256. Entre as capturas, foram identificados 1.348 conteúdos únicos — 647 hashes de conversa e 701 de documento —, então conteúdo repetido não é armazenado de novo. É parte de manter a base como sinal, e não como um depósito que só cresce acumulando cópia do que já existe.

P: Esses números do Exocortex são confiáveis? De onde vêm?
R: Foram todos apurados em modo somente-leitura no dia 16 de julho de 2026, direto do sistema em produção — nada é estimativa. E eu abro as limitações junto com os acertos: há 823 entradas que ficaram com zero tokens refinados (pedaços vazios), 122 memórias que cresceram em vez de encolher, e a camada Active estava com o orçamento estourado (394%, em alerta) no momento da apuração. Também sou honesto sobre o que não medi: não consultei a contagem de linhas ao vivo no PostgreSQL, então afirmo a memória distribuída pelo livro-razão local de sincronização, não por uma contagem no banco em tempo real.

P: O alerta de orçamento estourado na camada Active é um defeito?
R: Não — é o mecanismo funcionando. No momento da apuração, a Active estava em 59.210 tokens contra um orçamento de 15.000 (394%), em alerta. Eu poderia ter esperado um momento mais bonito para apurar e não esperei de propósito: esse alerta é a fiscalização de orçamento reagindo ao vivo. Quando a Active estoura, o sistema reorganiza, comprime e consolida. Ver o alerta aceso é ver a engrenagem trabalhando, não um problema escondido debaixo do tapete.

P: O Exocortex funciona com qualquer IA ou só com uma ferramenta específica?
R: A memória é guardada num banco de dados dedicado, com embeddings vetoriais, fora da janela de qualquer sessão — e é justamente isso que a torna portátil. Por não viver presa dentro de uma CLI ou de uma janela de contexto, pode em tese ser compartilhada entre máquinas e aplicações diferentes. A ideia de projeto é essa: uma instância aprende e todas podem lembrar, em vez de cada ferramenta ter sua própria memória isolada que morre com a sessão.

P: Preciso ser programador para me beneficiar de uma memória de IA como essa?
R: Não. 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 — do mesmo jeito que não precisa saber como a geladeira funciona para conservar comida. Isso é parte do método Prompthen que guia o meu trabalho: a complexidade deve ser opcional, nunca uma barreira. A porta está aberta para quem quiser abrir o capô, mas ninguém é obrigado. O que importa é o resultado: a conversa que não evapora.