Quando o Claude esquece o processo no meio da análise — o que o Karpathy descobriu e como aplicar no judiciário

Akita leu o código-fonte do Claude Code, do Codex CLI e do opencode pra entender por que agentes “esquecem” decisões tomadas três horas atrás

mai 19, 2026

Akita leu o código-fonte do Claude Code, do Codex CLI e do opencode pra entender por que agentes “esquecem” decisões tomadas três horas atrás. A resposta dele, combinada com o padrão LLM Wiki do Karpathy e o agentmemory do Rohit Ghumare, desenha exatamente a memória que está faltando pra quem usa IA em análise processual reiterada — sem programar nada, sem instalar nenhum servidor.

A cena que todo colega já viveu

Terça à tarde, na vara. Você abre o Claude Code pra analisar uma execução fiscal pesada. 1.247 movimentos, 4.300 fls, parte alterada três vezes por sucessão empresarial. O Claude lê via MCP os documentos relevantes, mapeia a cronologia, encontra na fl. 837 uma certidão de trânsito em julgado de 2018 que ninguém tinha notado, identifica a suspensão pelo art. 40 da LEF aplicada em 2020, marca o reinício da contagem em 2022.

Você sai pra audiência. Volta uma hora e meia depois. Manda:

“agora minuta o despacho considerando os marcos prescricionais que você levantou.”

E ele… reabre tudo. Re-busca os mesmos documentos. Lê de novo. Tenta reconstruir a análise. Esquece a fl. 837. Acha um marco diferente. A análise N+1 não parte de onde a N terminou — parte do zero, com pequenas variações que você precisa conferir uma a uma. Quando você abre o mesmo processo na quinta de manhã pra outro despacho, é tudo de novo.

Não é falha do modelo. É arquitetura. E até semana passada eu não tinha boa explicação técnica pra dar pros colegas que reclamam disso comigo. Agora tenho — e tenho também um caminho concreto pra resolver, sem programar nada.

Vou te apresentar três textos que se encaixam como peças de um quebra-cabeça e mostrar como o conjunto se aplica a quem usa Claude Code em análise processual: o post do Akita dissecando o código fonte dos três principais agentes de codificação, o padrão LLM Wiki do Karpathy, e a evolução do padrão (LLM Wiki v2) que o Rohit Ghumare consolidou no projeto open-source agentmemory.

Parte 1 — O que o Akita descobriu lendo o código

Em 18 de maio de 2026 o Akita publicou um post chamado AI Agent Memory: Karpathy LLM Wiki and agentmemory in Practice. Ele fez algo que poucos fazem: leu o código-fonte de três agentes de codificação — Codex CLI (Rust, OpenAI), opencode (TypeScript, sst) e Claude Code (TypeScript, via leak que circulou em março). Não pra criticar, pra entender exatamente como cada um decide o que esquecer.

Resumo do que ele descobriu, em palavras de servidor:

Todo agente tem uma janela de contexto — a “memória de trabalho” que cabe na requisição enviada ao modelo a cada turno. Cada mensagem trocada, cada PDF lido via MCP, cada saída de ferramenta, tudo entra nessa janela. Quando ela enche, o agente faz o que se chama compactação: pede ao próprio LLM que escreva um resumo da conversa até ali, joga fora o histórico bruto, e continua a partir do resumo. É o equivalente a você passar três horas lendo um auto, fechar tudo, e ficar apenas com cinco bullets do que descobriu.

Os três agentes fazem isso de jeitos diferentes:

Codex CLI tem um limite por modelo e quando bate, chama o LLM com um prompt específico de “checkpoint de contexto” pedindo um sumário de handoff — como se outro modelo fosse continuar a tarefa. É a versão mais executiva: progresso, decisões, próximos passos, referências.

opencode reserva 20K tokens de buffer e mantém um anchored summary — quando precisa compactar, atualiza o resumo existente com a história recente em vez de gerar tudo do zero. As últimas trocas ficam intactas. É o mais cirúrgico.

Claude Code é o mais sofisticado dos três. Tem três níveis de compactação rodando em paralelo:

microcompact (baseado em tempo): se passou mais de 60 minutos desde a última mensagem do assistente, o cache de prompt do servidor já expirou de qualquer jeito. Antes de enviar a próxima requisição, o Claude Code limpa o conteúdo dos resultados de ferramenta antigos (Read, Grep, Bash, WebFetch) e os substitui por [Old tool result content cleared]. É faxina de baixo custo — não chama o LLM.
autoCompact (baseado em tokens): reserva 13K de buffer pra disparar a compactação e 20K pro output do sumário. O TUI fica amarelo na zona de warning e vermelho na de erro. Tem circuit breaker: após 3 falhas consecutivas, para de tentar (segundo comentário no código, isso evitou ~250 mil chamadas inúteis por dia globalmente).
sessionMemoryCompact (experimental): liga no sistema de memória persistente entre sessões.

O detalhe que o Akita destaca como mais interessante: o prompt de compactação do Claude Code pede uma estrutura fixa de 9 seções. Pedidos do usuário, conceitos técnicos, arquivos e código, erros e correções, problemas resolvidos, todas as mensagens do usuário literais (sim, verbatim), tarefas pendentes, trabalho atual, próximo passo. A seção 6 — “ALL user messages” — é o que faz uma sessão compactada do Claude Code parecer preservar melhor o “tom” da conversa do que uma do Codex.

Mas note o que isso significa pra análise processual: a compactação preserva muito bem o que VOCÊ disse, mas necessariamente comprime o que o agente DESCOBRIU sobre o processo. O detalhe técnico — “marco prescricional na fl. 837, baseado em certidão da fl. 412 confrontada com despacho da fl. 530” — vira algo como “análise de prescrição concluída”.

E aqui chegamos ao ponto.

Parte 2 — Por que isso é pior em análise processual do que em programação

A compactação é um problema irritante pra quem programa. Em análise processual ela é um problema estrutural — por três razões que valem destrinchar:

1. Você revisita o MESMO processo várias vezes. Em programação, um arquivo auth.py raramente precisa ser reanalisado em profundidade depois que você já o conhece. Você abre, faz a edição, fecha. Em análise processual, o mesmo processo de execução fiscal pode passar pelo seu gabinete cinco vezes em três meses — exceção de pré-executividade, intimação da Fazenda, decisão sobre penhora, recurso, audiência. Cada vez você precisa do mesmo estado de conhecimento sobre os fatos do processo. Sem memória persistente, cada visita é uma análise nova.

2. Os autos não cabem em contexto, nem com janelas de 1M de tokens. Opus 4.7 tem 1M de tokens. GPT 5.5 tem 1M. Sonnet 4.6 tem 200K. Um auto de execução fiscal com 4.000 fls e 200 movimentos tem fácil 400-600 mil tokens. Cabe? Em alguns modelos. Mas como o próprio Akita aponta, janela cheia = inferência lenta e cara. Cada turno custa o equivalente a despachar 50 processos pequenos. Insustentável.

3. A descoberta tem alto custo cognitivo e baixo custo de armazenamento. Quando o Claude lê 30 peças e identifica que a defesa do executado nos embargos da fl. 1.245 contradiz a tese sustentada em manifestação anterior da fl. 678, isso é trabalho intelectual valioso. Salvar essa conclusão custa 3 linhas de markdown. Descartá-la na compactação e refazê-la na próxima sessão custa as mesmas 30 peças lidas via MCP, mais o esforço de raciocínio.

A relação entre custo de descoberta e custo de armazenamento, em análise processual, é absurdamente desigual. Faz pouco sentido descartar o que custou caro pra recriar.

É exatamente esse desequilíbrio que o Karpathy enxergou pra outra dor — bases de conhecimento pessoais — e resolveu com uma ideia muito simples.

Parte 3 — Karpathy: pare de re-derivar, comece a compilar

Em 4 de abril de 2026 o Andrej Karpathy publicou um gist chamado llm-wiki.md. É curto, abstrato, sem código. Mas mexeu com muita gente — passou de 5.000 stars na primeira semana.

A tese dele é uma frase só: stop re-deriving, start compiling.

Modo RAG (o jeito que quase todo mundo usa LLM com documentos): você carrega um monte de PDFs, faz uma pergunta, o agente busca trechos relevantes, lê, responde. Próxima pergunta? Mesma coisa: busca, lê, responde. Cada pergunta re-deriva o conhecimento do zero. NotebookLM, ChatGPT com files, MCP servers em modo retrieval — todos seguem esse padrão.

Modo Wiki: você dá um documento ao agente. Ele lê, extrai os fatos, atualiza páginas existentes da wiki, cria novas se preciso, aponta contradições com o que já estava lá, fortalece teses confirmadas por múltiplas fontes. A síntese é feita uma vez e mantida. A próxima pergunta começa da síntese, não dos documentos brutos.

A diferença é a mesma que existe entre, no cartório:

(RAG) Toda vez que alguém pergunta sobre o processo, abrir o auto e ler tudo de novo.
(Wiki) Manter uma ficha do processo atualizada — partes, situação atual, marcos relevantes, último despacho — e consultar a ficha primeiro. Só abre o auto se a ficha não responde.

Karpathy descreve três camadas:

E três operações:

Ingest: documento novo chega → o LLM lê, conversa com você sobre os pontos-chave, escreve uma página de resumo, atualiza 10-15 páginas existentes afetadas, anota no log.
Query: você pergunta → o LLM lê o índice, encontra páginas relevantes, sintetiza, responde com citações. Boa resposta vira nova página da wiki — explorações compõem.
Lint: periodicamente, o LLM faz uma varredura — contradições entre páginas, fatos superados por fontes mais novas, páginas órfãs sem links, conceitos importantes citados mas sem página própria.

A pergunta-chave do Karpathy, que define por que isso funciona agora e não funcionou antes:

“O gargalo não é ler nem pensar. É a manutenção. Humanos abandonam wikis porque o trabalho de manter cresce mais rápido que o valor. LLMs não cansam de atualizar referências cruzadas.”

Wikis humanas morrem por causa do tédio da manutenção. Wikis mantidas por LLM podem ficar vivas — porque o LLM tolera bem a parte chata. Você fica com a parte cognitivamente interessante (sourcing, exploração, decisão); o LLM faz a contabilidade.

O Karpathy não inventou o conceito — Vannevar Bush propôs algo parecido em 1945, o Memex. O que faltava era o bibliotecário paciente. Agora tem.

Parte 4 — Rohit Ghumare e o LLM Wiki v2: o que falta pra escalar

O post original do Karpathy é deliberadamente abstrato. Várias pessoas começaram a implementar — uma delas, Rohit Ghumare, foi mais longe. Publicou um gist chamado LLM Wiki v2 estendendo Karpathy com o que aprendeu construindo o agentmemory (projeto open-source com 11.6k stars no GitHub, licença Apache-2.0). O agentmemory é uma implementação concreta do padrão como servidor MCP + daemon local. O que importa pra gente são as ideias que ele formalizou, porque elas aplicam diretamente ao trabalho processual:

Confidence scoring. Cada fato na wiki carrega quantas fontes o confirmam, quando foi confirmado pela última vez, se há contradições. “O autor é fulano” não fica nu — vira “o autor é fulano (confirmado em: qualificação da inicial, contestação fl. 89, decisão saneadora fl. 312; confiança alta)”. Isso é, casualmente, a mesma cadeia de fundamentação que magistrado já cobra na análise humana.

Supersession (superação). Quando uma informação nova contradiz ou atualiza uma antiga, a antiga não é deletada — ganha um carimbo de “superada por X em Y”. Versionamento de conhecimento, não só de arquivos. Em processo: “Decisão de fl. 437 — superada pelo acórdão de fl. 1.245 que reformou”.

Forgetting curve. Inspirado em Ebbinghaus: o que não é acessado decai. Não some — fica em segundo plano. Decisões arquiteturais decaem devagar; bugs transitórios decaem rápido. Em processo: o cadastro original das partes (decai rápido se ninguém atualiza), a tese central da defesa (decai devagar, é o esqueleto do caso).

Consolidação em 4 camadas. Inspirado em como o cérebro humano consolida memória durante o sono:

Cada camada é mais comprimida, mais confiável e mais duradoura que a anterior. O agente promove informação para cima conforme evidência acumula. É como você sai de “vi isso uma vez” para “é assim que funciona aqui”.

Knowledge graph tipado. Em vez de só “página A linka página B”, você tem relações nomeadas: causa, superada-por, contradiz, fundamenta, é-da-mesma-parte-que, usa-mesma-tese-que. Isso é gold pra análise processual — porque o universo jurídico é violentamente relacional: mesmo advogado, mesma parte, mesma tese, mesmo juízo, mesma instituição financeira. Em consignado contra a mesma instituição você tem 50 processos com 5 teses recorrentes.

Hybrid search (BM25 + vetor + graph). Para wikis acima de ~200 páginas, índice manual não escala. Combinar busca por palavra-chave (BM25), busca semântica (vetorial) e travessia do grafo, fundindo os resultados via Reciprocal Rank Fusion. No benchmark LongMemEval-S (ICLR 2025, 500 perguntas) o agentmemory atinge 95,2% de R@5 — bem acima do BM25 puro (86,2%).

Hooks event-driven. Em vez de você lembrar de manter a wiki, ela mantém-se sozinha em eventos: novo documento entra → ingest dispara automaticamente; sessão termina → resumo é compactado; quando você faz uma pergunta com resposta útil → é arquivada como nova página.

Privacidade e auditoria. Filtro de ingest tira credenciais, dados sensíveis. Trilha de auditoria registra toda operação. Pra processo judicial, isso vira essencial: você precisa saber quando e por que uma página foi alterada — pra justificar a análise no eventual recurso.

Tudo isso é modular. Não precisa instalar tudo de cara. Mas saber que existe esse arsenal de ideias muda o que dá pra fazer no Claude Code já hoje, sem instalar nada.

Parte 5 — Por que esse padrão é feito sob medida pra análise processual

Aqui está a minha tese — o motivo de eu ter escrito esse post.

Quando li o gist do Karpathy pela primeira vez, no início de abril, fiquei animado mas vi como abstrato demais pra recomendar pros colegas servidores. Quando li o post do Akita semana passada e o gist do Rohit, percebi: as cinco coisas que tornam o padrão Wiki especial são exatamente as cinco coisas que tornam análise processual difícil. É quase suspeitamente bem encaixado.

Mapeamento direto, sem rodeios:

Os cinco pontos abaixo merecem destrinche:

(a) Você revisita o MESMO processo. Esse é o ponto onde análise processual diverge de programação. O programador que conhece bem um arquivo não precisa relê-lo. O servidor que conhece bem um processo precisa, sim, da memória estruturada — porque despachos sucessivos exigem o mesmo estado de fato. Aqui o padrão Wiki vale por ele só. Sem nenhum outro motivo, já paga.

(b) Confidence scoring é fundamentação. Pense bem: a estrutura “fato X, com base em fonte Y, confirmada por fonte Z” é literalmente como o juiz fundamenta sentença. Quando o Claude diz “marco prescricional em 25/03/2018, fundado em (1) certidão de trânsito da fl. 412 e (2) despacho de baixa da fl. 530”, isso não é hype técnico — é a forma como o trabalho intelectual jurídico já se organiza. A wiki só explicita o que o cérebro do servidor experiente já faz.

(c) Procedural memory captura o estilo. “Marcos costuma citar o art. 487, III antes de homologar acordo.” “Esta vara costuma intimar as partes antes de baixar processo executivo após a satisfação.” Isso é conhecimento tácito que normalmente só se transmite quando um servidor novo passa meses ao lado de um experiente. Codificar em texto, com o LLM extraindo padrões das sessões anteriores, é uma das poucas formas honestas de escalar mentoria.

(d) Token economy é dramática. Conta na próxima seção.

(e) Reusabilidade entre processos similares. A wiki de um processo de consignado contra determinada instituição financeira tem muito em comum com a wiki dos próximos 49 processos do mesmo tipo. Você pode promover páginas do semantic para o procedural — “tese recorrente da defesa: ausência de comprovação do desconto” deixa de ser conhecimento sobre um processo e vira conhecimento sobre o tipo de processo.

Parte 6 — Como rodar isso HOJE no Claude Code, sem instalar nada

O agentmemory é maravilhoso, mas tem fricção real pra colega servidor: precisa Node, daemon rodando local, um run-time chamado iii-engine. Em máquina de tribunal com Windows e antivírus paranoico, isso é problema. Para a maioria dos meus leitores, não vale a pena.

Mas o padrão funciona sem o agentmemory. A wiki é só uma pasta de markdown, e o Claude Code já tem as três ferramentas que precisam (Read, Edit, Write). O que falta é a disciplina, que mora num arquivo de Schema bem desenhado.

Estrutura mínima da pasta de um processo:

processo-XXXXXXX-DD.AAAA.8.06.NNNN/
├── SCHEMA.md                ← o coração: regras de como o Claude trabalha
├── raw/                     ← fontes imutáveis (não edite)
│   ├── peticao-inicial.pdf
│   ├── contestacao.pdf
│   ├── decisao-saneadora.pdf
│   └── certidao-transito.pdf
├── wiki/                    ← o Claude escreve e mantém
│   ├── index.md             ← catálogo + links pras outras páginas
│   ├── log.md               ← chronological, "[2026-05-19] ingest: ..."
│   ├── partes.md
│   ├── cronologia.md
│   ├── teses-autor.md
│   ├── teses-reu.md
│   ├── prescricao.md        ← análise dedicada
│   └── decisoes/
│       ├── saneadora.md
│       └── ...
└── minutas/                 ← suas saídas (despachos, sentenças)
    └── despacho-saneador-v1.md

O SCHEMA.md é o que faz isso funcionar. Esqueleto que eu recomendo (cole no projeto, ajuste pro seu tipo de processo):

# SCHEMA — Análise processual via padrão LLM Wiki

## Papéis
- `raw/`: fontes imutáveis. NUNCA edite. NUNCA delete. Só leia.
- `wiki/`: você (Claude) escreve. Mantenha curto, com referências
  às fls e à peça originária.
- `minutas/`: saídas para revisão humana (despachos, sentenças).

## Operação: INGEST
Quando o usuário disser "ingerir peça X":
1. Leia o arquivo em raw/.
2. Identifique partes, datas, pedidos, fundamentos, decisões.
3. ATUALIZE as páginas existentes em wiki/ afetadas
   (mínimo: index.md, log.md, mais as páginas temáticas).
4. Marque cada fato com fonte: (fl. X, peça Y) e data
   da observação.
5. SE encontrar contradição com afirmação existente,
   marque com "⚠️ CONTRADIÇÃO" e cite ambas as fontes.
6. Anote a operação em wiki/log.md no formato:
   ## [YYYY-MM-DD] ingest | peça | resumo de 1 linha

## Operação: QUERY
Quando o usuário fizer pergunta sobre o processo:
1. LEIA wiki/index.md PRIMEIRO.
2. Identifique 1-3 páginas relevantes; leia elas.
3. Só leia arquivos de raw/ se as páginas do wiki
   não respondem.
4. Responda CITANDO a página do wiki E a fonte
   original (fl. X, peça Y).
5. Se a resposta tem valor de referência futura,
   ofereça arquivá-la como nova página.

## Operação: LINT
Quando o usuário disser "rodar lint":
- Procure contradições entre páginas.
- Procure decisões superadas não marcadas.
- Procure partes/advogados sem qualificação completa.
- Procure páginas órfãs (sem links de entrada).
- Reporte sem editar; aguarde aprovação.

## Confidence
Para cada fato em wiki/, marque confiança:
- ALTA: 2+ fontes concordando, ou peça oficial (decisão,
  certidão).
- MÉDIA: 1 fonte, sem contradição.
- BAIXA: inferido, sem peça que confirme — preciso de
  validação humana.

## Procedural — esta vara
- Sempre intimar as partes antes de baixar executivo
  após satisfação.
- Citar art. 487, III antes de homologar acordo.
- Em consignado contra [INSTITUIÇÃO], conferir comprovação
  do desconto na inicial; é a tese recorrente da defesa.

Esse arquivo é o schema do Karpathy. Ele é o que separa um Claude genérico de um Claude que opera como assessor disciplinado. Você co-evolui com ele: depois de 10 processos, você percebe que sempre repete uma regra (”conferir se há precedente vinculante do TJCE sobre esse tema”) — adiciona ao schema. Nas próximas 100 análises, ele aparece sozinho.

As três operações no dia-a-dia ficam assim:

Ingest (no início do trabalho num processo):

"Ingerir a petição inicial em raw/peticao-inicial.pdf"

O Claude lê o PDF, cria/atualiza partes.md, cronologia.md, teses-autor.md, registra no log. Em 30 segundos você tem um mapa do processo.

Query (a qualquer momento, mesmo dias depois):

"Está prescrito?"

O Claude lê primeiro wiki/prescricao.md (que ele mesmo escreveu na sessão anterior). Se a resposta já está lá com confiança alta, ele responde. Se a análise precisa ser atualizada (por exemplo, uma peça nova foi ingerida), ele acessa as peças específicas — não todo o auto.

Lint (semanal, ou antes de despacho importante):

"Rodar lint no wiki deste processo"

Ele cruza páginas, reporta contradições, sugere correções. Você aprova ou descarta.

E aqui entra a ponte com o que eu já mantenho hoje: o TecJustiça MCP Lite é a fonte de raw/. Em vez de baixar peças manualmente, o Claude usa pdpj_visao_geral_processo, pdpj_read_documentos_batch, pdpj_buscar_precedentes etc, e armazena os retornos como conteúdo de raw/. O MCP te dá os autos. O padrão Wiki te dá a memória dos autos. Os dois juntos.

Parte 7 — Conta de padaria: a economia de tokens

Vou colocar números reais. Processo médio meu — execução fiscal de complexidade média, 1.500 movimentos, 50 peças relevantes pra análise.

Sem Wiki, três sessões de análise:

E observe: cada sessão é vulnerável a interpretar de forma ligeiramente diferente os mesmos fatos, porque é uma análise nova.

Com Wiki, mesmas três sessões:

Economia de 44%. Mas o ganho de qualidade importa mais: a análise N+1 começa de onde a N parou. Não há risco de o Claude interpretar diferente a mesma certidão entre segunda e quarta — porque a interpretação já está consolidada em wiki/prescricao.md, com fonte e confiança. Quando muda, a mudança é explícita (supersession), não silenciosa.

Pra quem está perto do limite semanal do Claude Pro (todos nós, depois das mudanças de cota da Anthropic — falei disso em outro post), essa diferença é a diferença entre conseguir despachar 50 processos por semana ou conseguir despachar 30.

E o benchmark do agentmemory (95,2% R@5 vs 86,2% do BM25 puro) sugere que a precisão da recuperação também aumenta com a wiki estruturada — não é só economia, é melhor performance.

Parte 8 — Quando NÃO usar

Vou ser honesto, porque essa é a parte que cursos pagos nunca te contam:

Não vale a pena pra processo simples. Despacho de mero expediente, processo de 5 fls, expedição de ofício: setup do wiki custa mais que o ganho. Faz na sessão única e segue.

Tem curva inicial. Você precisa investir tempo no SCHEMA.md da sua área (cível, criminal, executivo, fiscal). Não é coisa de 5 minutos. A boa notícia é que um schema serve pra todos os processos do mesmo tipo — você faz uma vez, usa pelo resto da carreira.

Wiki desatualizada engana. Se você não rodar lint periodicamente, a wiki pode ficar desencontrada com a realidade dos autos (novo despacho proferido por outro juiz, certidão de cumprimento que muda situação). Disciplina importa.

Se você só precisa de uma pergunta pontual. Auto de 500 fls, pergunta única (”qual o valor da causa”), MCP direto é mais rápido. Wiki é pra quando você vai voltar.

Onde compensa muito:

Processos complexos que você vai revisitar (consignado em fase de cumprimento, execução fiscal, criminal com várias audiências, inventário, recuperação judicial)
Vara com padrões repetidos: 50 ações de consignado contra a mesma instituição, 100 execuções fiscais de IPTU
Pré-audiência criminal: o juiz consulta várias vezes na semana
Sentenças de mérito complexas onde pediu vista
Recursos: o relator precisa do estado de fato consolidado, não da releitura dos 800 fls

Encerramento

Karpathy disse, no fim do gist dele, que o Memex de Vannevar Bush finalmente é construível — não porque os documentos ficaram melhores ou a busca ficou mais sofisticada, mas porque finalmente temos bibliotecários que não cansam de fazer a parte chata.

Pra análise processual, o sonho é o mesmo. Um assessor que LÊ o auto uma vez, MAPEIA tudo numa estrutura disciplinada, e quando você volta no processo na semana seguinte ele te entrega o estado de conhecimento atualizado — não te faz reler 4.000 fls. Um assessor que aprende o jeito da sua vara despachar e replica em casos análogos. Um assessor que aponta sozinho: “olha, a tese que você tá usando contradiz o que ficou consolidado no processo correlato 0001234-XX.2023”.

Não é IA mais inteligente. É arquitetura de memória melhor.

E a melhor parte: você não precisa esperar a Anthropic implementar isso. Você não precisa do agentmemory rodando local. Você precisa de uma pasta com SCHEMA.md, três subpastas (raw/, wiki/, minutas/), e o Claude Code que você já usa. A tecnologia tá pronta. A disciplina é o que falta — e essa é a parte que dá pra construir.

Continuo defendendo a mesma tese que carrega o TecJustiça desde o início: construir a ponte, não o produto. Quando o Claude 4.7 virar Claude 5 (e vai virar, em meses), as suas wikis processuais continuam funcionando. O SCHEMA.md continua funcionando. As páginas em markdown que o Claude maturou ao longo de centenas de processos continuam suas, na sua máquina, sob seu controle.

No próximo post vou publicar:

Um SCHEMA.md completo, anotado, pronto pra copiar/colar (cível, criminal, execução).
Um exemplo real de wiki de processo (anonimizado), com 3 ingests sucessivos mostrando como ela evolui.
O hook de auto-ingest pra integrar com o TecJustiça MCP Lite — quando você pede uma peça via MCP, ela cai direto em raw/ e dispara o ingest.

Quem quiser testar antes do post sair, responde essa newsletter. Mando o esqueleto direto.

Fontes consultadas

Akita, Fabio. AI Agent Memory: Karpathy LLM Wiki and agentmemory in Practice. 18 mai. 2026. Disponível em: akitaonrails.com.
Karpathy, Andrej. llm-wiki.md (gist). 04 abr. 2026. Disponível em: gist.github.com/karpathy/442a6bf555914893e9891c11519de94f.
Ghumare, Rohit. LLM Wiki v2 — extending Karpathy’s LLM Wiki pattern with lessons from building agentmemory (gist). 2026. Disponível em: gist.github.com/rohitg00/2067ab416f7bbe447c1977edaaa681e2.
Ghumare, Rohit. agentmemory — Persistent memory for AI coding agents (repositório). Apache-2.0. Disponível em: github.com/rohitg00/agentmemory.
Bush, Vannevar. As We May Think. The Atlantic, 1945. (Sobre o Memex.)
Codex CLI source: github.com/openai/codex.

Marcos Antônio é Técnico Judiciário na Vara Única da Comarca de Ocara (TJCE) e mantém o TecJustiça MCP Lite — servidor MCP aberto que conecta Claude ao DataLake do CNJ pra análise de processos do judiciário brasileiro. Cadastro gratuito em tecjustica.tec.br.

TecJustiça

Discussão sobre este post

Pronto para mais?