Já contei por que a memória de um LLM não cabe num único arquivo, e por que o contexto é o ativo que o PM deve construir. Eram artigos sobre o porquê.

Este aqui fala do como. Vou abrir o capô do meu motor de contexto — o sistema que vive numa pasta 02-CONTEXT/ do meu vault — e acompanhar uma missão real do início ao fim. A cada etapa, vou explicar o bloco que entra em jogo: a missão, o foco, as diretrizes, o todo, a fila offline, e os três tipos de memória.

O objetivo: que um desconhecido que nunca viu esse sistema entenda como ele é organizado, e sobretudo por que é organizado assim. Porque cada pasta, cada arquivo, responde a um problema que encontrei ao trabalhar com uma IA em assuntos que se estendem por semanas.

O princípio de partida: o disco é a memória

Antes de tudo, vale deixar uma coisa clara. Nesse sistema, o sistema de arquivos é a memória principal da IA. Não a conversa.

Uma conversa com um LLM é volátil. Você fecha a aba, e tudo se perde. A janela de contexto é finita, e quanto mais você a enche, mais a atenção se degrada — é o fenômeno do Lost in the Middle de que falei em outro lugar. Então, em vez de guardar tudo na conversa, tudo é escrito em disco, em arquivos separados por natureza da informação. E a cada sessão, recarregamos apenas o estritamente necessário.

Um contexto é, portanto, uma pasta. Uma pasta = uma missão. Não há nenhuma memória transversal implícita entre dois contextos: o que a IA sabe sobre o projeto A não vaza para o projeto B. Cada missão tem a sua própria cabeça.

Um contexto, de forma simplificada, se parece com isto:

<contexto>/
├── 00_mission/     ← o quadro estável: por que estamos aqui, as regras
├── 01_active/      ← o estado vivo: onde estamos, hoje
├── 02_checkpoints/ ← as fotos de etapa
├── 03_sources/     ← o material bruto
├── 04_notes/       ← as ideias extraídas, conectadas entre si
├── 05_memory/      ← a memória consolidada
├── 06_index/       ← o índice de máquina, para a IA se localizar
└── 07_outputs/     ← os entregáveis

A lógica de arrumação é simples, mas estrita: o que é estável (a missão, as regras) fica separado do que muda a cada sessão (o estado atual), que por sua vez fica separado do material bruto (as fontes), do que extraímos dele (as notas) e do que produzimos (os entregáveis). Nada é misturado. Vamos ver que essa separação não é cosmética: é ela que torna o raciocínio rastreável ao longo do tempo.

Para tornar tudo isso concreto, vou acompanhar uma missão que realmente conduzi (um exemplo simples, para facilitar a leitura): PM016 — escrever posts de LinkedIn a partir de três artigos que publiquei numa revista de marketing. Uma missão de produção de conteúdo, curta, mas que ativa a maioria dos blocos.

Abrir um contexto: o que a IA carrega, e o que ela deixa em disco

Eu inicio uma sessão. A primeira coisa que a IA faz não é ler tudo. É ler um arquivo de configuração: o manifesto de carregamento (load_manifest.json). Esse arquivo diz a ela o que carregar, e o que, ao contrário, deve deixar em disco.

Ele contém três listas:

• always_load — o núcleo, carregado toda vez. A missão, o escopo, as diretrizes, os riscos, o estado atual, o plano, o foco, o todo, as decisões, as contradições, a ficha de retomada, a síntese.
• load_on_demand — tudo o que fica em disco e só é carregado se a tarefa exigir: as dezenas de fontes, as notas atômicas, os diários de sessão.
• Salvaguardas: no máximo 12 arquivos ativos, cerca de 1200 linhas no máximo na janela de contexto do LLM.

É como uma mesa de cirurgia. Os instrumentos essenciais já estão à mão; os outros estão ao alcance, mas ninguém cobre a mesa. Um especialista humano não relê o dossiê inteiro antes de cada reunião — ele já internalizou o essencial e vai buscar um documento específico quando precisa. Um LLM não consegue internalizar: ele só tem o que damos a ele. Daí a importância de dar a ele o subconjunto certo, não tudo.

Na prática, a abertura de um contexto acontece por um comando — eu digito /context_use pm016 — e a IA executa o manifesto: ela lê o núcleo, lê o último checkpoint, e está operacional. Ela sabe onde estamos sem que eu tenha precisado explicar tudo de novo para ela.

A missão e o foco: o objetivo não é a mesma coisa que a atenção

Zoom nas duas pastas de cabeça — a estável e a viva:

00_mission/          ← o quadro estável
├── mission.md       o objetivo (não muda)
├── scope.md         o perímetro
├── directives.md    como a IA deve trabalhar
├── risks.md         as ameaças a monitorar
└── glossary.md      o vocabulário da missão

01_active/           ← o estado vivo (muda a cada sessão)
├── focus.md         a atenção do momento
├── current_state.md onde estamos
├── current_plan.md  para onde vamos
├── todo.md          as ações futuras
├── decisions.md     o que decidimos
├── contradictions.md o que ainda não bate
├── resume_work.md   a ficha de retomada
└── offline.md       a caixa de correio

Aqui aparece a primeira sutileza, e provavelmente a mais importante de entender.

Há dois arquivos que parecem "aquilo em que trabalhamos", mas que não têm nada a ver.

O primeiro é a missão (00_mission/mission.md). É o objetivo. Ele é estável. Para o PM016, a missão cabe numa frase: "escrever posts de LinkedIn baseados nos três artigos que publiquei na revista nº16". Essa frase não muda durante toda a vida do contexto. É o rumo. O arquivo vive em 00_mission/, a pasta das coisas estáveis.

O segundo é o foco (01_active/focus.md). É a atenção do momento. Ele muda a cada sessão, às vezes várias vezes numa mesma sessão. O foco é "hoje, trabalhamos no recorte das ideias do artigo 2 em posts distintos". Não é o objetivo — é o subproblema sobre o qual apontamos o holofote agora. O arquivo vive em 01_active/, a pasta das coisas vivas.

Por que separar os dois? Porque confundir o objetivo e a atenção é a melhor forma de perder o rumo. Se a IA toma o foco do dia pelo objetivo da missão, ela corre o risco de redefinir toda a missão em torno de um detalhe. Do outro lado, se ela só tem o objetivo diante dos olhos, fica vaga demais: "escreva posts de LinkedIn" não diz sobre o quê nos concentramos neste instante. A missão dá a direção, o foco dá a profundidade de campo. Você pode refazer o foco dez vezes sem nunca tocar na missão. É exatamente como acontece com um humano: o seu cargo (a sua missão) não muda porque você passou a tarde numa tarefa específica (o seu foco).

Em torno da missão, em 00_mission/, existem três outros arquivos de enquadramento.

O escopo delimita o que está dentro do perímetro e o que não está — a barreira contra o desvio do assunto.

Os riscos (risks.md) são a grade das ameaças que pesam sobre a missão. No PM016, é modesto; mas numa verdadeira oportunidade de produto, esse arquivo acompanha os quatro grandes riscos de Marty Cagan — valor, usabilidade, viabilidade técnica, viabilidade de negócio. A ideia: manter permanentemente à vista as perguntas que podem fazer o projeto fracassar, e marcar cada risco à medida que algum elemento vem esclarecê-lo ou agravá-lo. Uma seção vazia = um risco ainda não documentado, ou seja, um ponto cego assumido.

O glossário (glossary.md) fixa o vocabulário da missão, para que as mesmas palavras mantenham o mesmo sentido do início ao fim. É o mesmo reflexo do meu contexto de condomínio, onde acabei tirando todos os termos técnicos e siglas para um arquivo dedicado: sem isso, cada um — tanto o humano quanto a IA — acaba usando as mesmas palavras com sentidos diferentes.

Um ponto importante sobre todos esses arquivos, e talvez o mais contraintuitivo do sistema: eles não se preenchem de uma vez só no início. Eles vão sendo preenchidos aos poucos, ao longo das trocas. E "troca" não quer dizer apenas "trazer um documento". Na maior parte do tempo, quer dizer conversar. Eu converso com a IA, penso em voz alta, dou a ela um contexto que tenho na cabeça — e é ela que arruma esse fluxo no lugar certo: este ponto é um risco de viabilidade, este termo merece uma entrada no glossário, esta frase delimita o escopo. Um risco não escrito vira uma linha em risks.md porque eu o mencionei conversando, não porque abri o arquivo para preenchê-lo. É aí que o contexto deixa de ser uma pasta a organizar e vira um secretário particular que anota o que penso em voz alta.

As diretrizes: codificar um conhecimento que a IA não tem

Outro arquivo do núcleo estável: as diretrizes (00_mission/directives.md).

Uma diretriz não fala do assunto da missão. Ela fala da maneira de trabalhar. É a diferença entre os ingredientes e a receita.

Um exemplo tirado de outro dos meus contextos, onde faço a IA tratar centenas de e-mails de condomínio: "quando duas pessoas têm o mesmo sobrenome, use o sentido do e-mail para indicar o primeiro nome e a empresa" (dois prestadores tinham o mesmo sobrenome). Isso não é uma informação sobre o condomínio. É uma regra de tratamento. Ela codifica um conhecimento que só eu tenho, e que a IA aplica em seguida de forma sistemática — sem esquecer, sem se cansar.

Para o PM016, uma diretriz típica seria: "cada post deve defender uma única ideia atômica, nunca um resumo do artigo inteiro". É uma restrição de produção que estabeleço uma vez, e que vale para os vinte e sete posts.

As diretrizes estão no núcleo always_load: então são recarregadas a cada sessão. Uma regra que estabelecemos na semana 1 ainda se aplica na semana 6, sem que eu precise repeti-la. É cumulativo. Quanto mais uma missão avança, mais suas diretrizes se refinam, e mais a IA trabalha como eu.

Detalhe de uso: para adicionar uma diretriz no meio da conversa, basta prefixar minha mensagem com alpha directive : ... e a IA vai consolidá-la no arquivo. Existe um punhado de palavras-chave assim (decision :, contradiction :, todo :, checkpoint, fim de sessão) — atalhos para arrumar uma informação no arquivo certo sem precisar dizer isso explicitamente. Não passam de comodidades; o coração do sistema são os conceitos, não as palavras-chave.

O todo: as ações futuras não poluem o raciocínio presente

O todo (01_active/todo.md) é um arquivo simples, mas que resolve um problema real.

Quando você trabalha num assunto, ideias de ações futuras surgem o tempo todo. "Vai ser preciso conferir esse número." "A gente devia transformar esse post num carrossel." "Lembrar de revisar a versão em inglês." Se você deixa essas ações flutuando na conversa, duas coisas acontecem: ou você as esquece, ou elas poluem o raciocínio em curso puxando a atenção para todos os lados.

O todo é o lugar onde depositamos essas ações para não precisar mais segurá-las na cabeça. É um backlog. Cada tarefa tem um identificador (T-NNN) e um status. Você o alimenta escrevendo todo : .... E porque ele faz parte do núcleo carregado a cada sessão, nenhuma ação se perde entre duas sessões.

É a mesma lógica de todo o resto: tirar uma informação da memória volátil da conversa para colocá-la num lugar estável e nomeado.

A fila offline: falar com o contexto quando ele dorme

Aqui aparece um bloco em que a gente não pensa no começo, e que logo se torna indispensável: o arquivo offline (01_active/offline.md).

O problema: as ideias não vêm apenas quando estamos sentados diante da IA, com o contexto aberto. Uma ideia sobre o PM016 me passa pela cabeça num domingo à noite, quando não tenho a menor vontade de abrir uma sessão completa. Onde colocá-la?

No arquivo offline. É uma caixa de correio. Deposito ali uma mensagem — uma ideia, uma correção, um lembrete — sem abrir uma sessão. O arquivo dorme junto com o contexto.

Depois, no início da sessão seguinte, o workflow prevê uma etapa específica: se offline.md não estiver vazio, tratar o conteúdo dele como uma mensagem recebida, e depois esvaziar o arquivo. A IA lê minha mensagem de domingo à noite como se eu tivesse acabado de digitá-la, leva em conta, age sobre ela, e zera a caixa. Nada se perde, e eu não precisei abrir uma sessão só para anotar uma ideia.

É uma forma assíncrona de falar com um contexto. O contexto vira algo para o qual posso deixar um recado, mesmo quando ele não está "ligado".

As fontes e as notas: do material bruto ao conhecimento reutilizável

Até aqui, falamos de como o sistema é conduzido. Agora, o conteúdo.

Zoom na cadeia que vai do bruto ao conhecimento:

03_sources/          ← o material bruto
├── SRC-001.md       a ficha (transcrição aproveitável)
└── raw/             o original tal como está (o PDF, ilegível para a IA)

04_notes/            ← o conhecimento extraído
├── atomic/          uma ideia = uma nota (NOTE-0001, 0002…)
└── thematic/        as sínteses que conectam várias notas

Quando adiciono material — para o PM016, o PDF dos três artigos — ele não vai se despejar na conversa. Vai para 03_sources/, o material bruto. Cada fonte recebe uma ficha e um identificador (SRC-001, SRC-002…). O PDF original, que a IA não consegue ler diretamente, é mantido como está numa subpasta raw/, e uma ficha .md dá dele uma transcrição aproveitável. Sabemos sempre de onde vem cada informação.

Em seguida vem o trabalho de extração. A partir das fontes, a IA produz notas atômicas em 04_notes/atomic/. Uma nota atômica captura uma única unidade de pensamento: um fato, uma definição, uma hipótese, um padrão, uma contradição. Para o PM016, a análise dos três artigos produziu vinte e duas notas. Aqui aparece uma delas, real:

NOTE-0022 — Arbitrar sem ficar cego: o cursor entre enquadramento e autonomia Padrão: dar a uma responsabilidade autoridade suficiente para arbitrar cria um risco novo — a centralização cega. […] A coerência não é a homogeneidade. Exemplo Nike: universos muito diferentes (corrida, futebol, basquete…) coexistem sem uniformizar tudo.

Essa nota é autônoma: você a entende sem reabrir o artigo. Ela é fundamentada (aponta para SRC-001, página 67). E é conectada: embaixo, uma seção ## Backlinks a liga à nota temática the-brand-man. É Zettelkasten — unidades de pensamento conectadas entre si, onde a inteligência emerge das conexões, não do acúmulo.

Há uma regra que me imponho aqui, e que é mais sutil do que parece: uma nota atômica nunca é material pré-formatado para o entregável. Mesmo que o objetivo da missão seja produzir posts de LinkedIn, uma nota não deve ser um "gancho" ou uma "punchline". A nota captura um conhecimento neutro e verdadeiro. A formatação a serviço do objetivo, essa, só acontece nos entregáveis. A cadeia é estrita: sources (bruto) → notes (conhecimento neutro) → outputs (entregável orientado). Enquanto estamos nas notas, o objetivo da missão ainda não tem voz. Senão, envenenamos o nosso próprio material de base.

Essa regra parece rígida. Na verdade, é ela que torna as notas poderosas — porque um conhecimento neutro é agnóstico ao entregável, ou seja, reutilizável para qualquer um.

Vamos pegar uma missão de produto em vez do PM016. A partir de um mesmo conjunto de notas atômicas — um desafio do cliente, uma restrição de adoção, um padrão de mercado — posso gerar materiais bem diferentes: um pitch para um comitê de direção, uma documentação de suporte, um artigo de blog, uma sales narrative, um onboarding. Cada entregável pesca e combina os blocos de que precisa nesse corpus comum. Se eu tivesse formatado essas notas para o pitch, elas só serviriam para o pitch. Mantendo-as neutras, servem para os cinco. A formatação, o ângulo, o tom: tudo isso chega no último momento, em 07_outputs/, quando já sabemos qual entregável vamos produzir.

E a reutilização não para na missão. Os contextos não são silos isolados. Uma nota produzida para um contexto pode esclarecer outro — porque dá para conectar contextos relacionados entre si. Posso até abrir um contexto para auditar outro: percorrer suas notas e identificar as boas ideias a reaproveitar. Um bloco de conhecimento escrito uma vez pode assim nutrir um entregável hoje, outro entregável amanhã, e uma decisão num terceiro contexto daqui a seis meses. É exatamente a promessa de partida: o entregável é descartável, a nota é um ativo.

Quando várias notas convergem, escrevemos uma nota temática em 04_notes/thematic/ — uma síntese de um ângulo ou de uma tensão. Para o PM016, uma por artigo.

As três memórias: episódica, semântica, e as fotos de etapa

Zoom nos três lugares de memória — três escalas de tempo:

05_memory/
├── journal/         o que aconteceu, dia a dia (a história)
└── synthesis.md     o que se retém disso (a lição)

02_checkpoints/      o estado completo num instante T (a foto de retomada)

É aqui que se joga a segunda grande sutileza do sistema. Um cérebro humano não tem uma memória, tem várias, que funcionam em escalas de tempo diferentes: a que retém o que acontece agora, a que armazena os eventos vividos, e a que consolida os saberes duradouros. O sistema reproduz essa arquitetura com três objetos distintos, que não podemos de forma alguma confundir.

O diário (memória episódica). Em 05_memory/journal/, um arquivo por dia de trabalho. Ele conta o que aconteceu: o que fizemos naquele dia, em que ordem, quais decisões foram tomadas, o que travou. É o relato cronológico. Vamos até ele quando nos perguntamos "mas o que a gente tinha decidido na terça, e por quê?". É datado, sequencial, nunca reescrito.

A síntese (memória semântica). Em 05_memory/synthesis.md, um único arquivo. Ele não conta o que aconteceu — condensa o que se retém disso. As conclusões estáveis, as convicções validadas, os padrões extraídos de dezenas de sessões. É a memória de longo prazo, livre da cronologia. Um product manager sênior não redescobre a cada projeto que os usuários mentem em entrevista: isso virou um saber semântico. A síntese é isso. Ela faz parte do núcleo carregado a cada sessão, porque é o condensado mais útil para retomar o fio.

Os checkpoints (as fotos de etapa). Em 02_checkpoints/, no máximo um arquivo por dia. Um checkpoint é um instantâneo completo do estado do contexto num dado momento. O ângulo de redação é muito preciso, e é isso que dá valor a ele: "se um LLM chegasse agora sem ter lido nada, o que ele precisa saber para retomar sem erro e sem recomeçar?" O checkpoint é a rede de segurança da retomada.

A distinção entre diário e síntese é a que mais escapa. O diário é a história; a síntese é a lição. Precisamos das duas, exatamente pela razão que tinha me levado, nos meus primeiros testes, a separar a agregação de um log cronológico: eu queria ao mesmo tempo saber onde estamos (a síntese) e poder voltar no fio (o diário). Esmagar um com o outro é perder ou a memória, ou a rastreabilidade.

E é precisamente isso que torna o sistema auditável. Um cérebro esquece — é a sua força. Um sistema de arquivos, esse, não esquece nada. Da síntese, voltamos ao checkpoint. Do checkpoint, aos diários. Dos diários, às notas. Das notas, às fontes brutas. Quando alguém pergunta "por que essa decisão?", a resposta nunca é "porque a IA disse". É uma cadeia de provas: fonte → nota → decisão.

O ciclo de uma sessão, de ponta a ponta

Agora que temos os blocos, aqui está o filme completo de uma sessão sobre o PM016.

No início. A IA lê o manifesto, carrega o núcleo, lê o último checkpoint. Ela verifica o arquivo offline: se ele contém um recado que deixei entre duas sessões, ela o trata e depois o esvazia. Em alguns segundos, ela sabe onde estamos. A ficha de retomada (resume_work.md) dá a ela até a primeira ação a fazer.

Durante a sessão. Conversamos — muitas vezes em voz alta, diante da tela. E ao longo da conversa, a IA arruma continuamente. Uma nova fonte chega → 03_sources/. Uma ideia duradoura emerge → uma nota atômica em 04_notes/. Uma decisão é tomada → decisions.md. Uma contradição aparece → contradictions.md (não a suavizamos artificialmente, mantemos ela visível). Uma ação futura → o todo. Cada vez que um arquivo é criado, o README.md da pasta dele e o índice de máquina são atualizados. O contexto se mantém constantemente atualizado, sem esforço da minha parte.

No fim da sessão. Eu digito /context_close. A IA dispara o ritual de encerramento: ela escreve o diário do dia, atualiza o estado atual e a ficha de retomada, promove para a síntese o que merece virar duradouro, e cria um checkpoint se um limiar for atingido. Depois faz o commit de tudo. A próxima sessão vai poder retomar exatamente onde esta parou.

Existe também uma compactação no meio do caminho (/context_push): quando o estado atual incha, quando o todo fica ilegível, ou quando ficamos rodando em círculos, condensamos, deduplicamos, priorizamos, arquivamos o que não serve mais — sem nunca perder a rastreabilidade.

Mas o /context_push tem um papel ainda mais vital, e é uma armadilha na qual você cai sem falta quando descobre o sistema. Quando uma sessão dura muito tempo, a conversa acaba ultrapassando a janela do LLM. Nesse momento, o LLM faz a sua própria compactação: ele resume silenciosamente as trocas antigas para abrir espaço. E tudo o que ainda não tinha sido escrito em disco naquele instante — uma decisão comentada de viva voz, uma ideia jogada de passagem, uma nuance importante — é aparado, deformado, ou pura e simplesmente perdido. O LLM não avisa você; ele acha que guardou o essencial, mas foi ele que escolheu o que era essencial.

O /context_push é o antídoto: ele força a persistência em disco antes que o LLM compacte a sua memória de trabalho. Empurrando com regularidade, garantimos que tudo o que importa já está escrito nos arquivos — no lugar certo, fundamentado, rastreado — e portanto que a compactação do LLM não faz mais perder nada de importante. É o princípio fundador do artigo, aplicado ao longo da sessão: o que vive apenas na conversa está por um fio; só o que está em disco é realmente memorizado.

O esquecimento sem a perda

Um último ponto, porque ele diz muito da filosofia do sistema. Não existe nenhuma exclusão brutal.

Quando uma informação não é mais útil, não a apagamos. Nós a tiramos do carregamento padrão, a compactamos, ou a arquivamos. Quando uma ideia substitui outra, não a esmagamos: marcamos como superseded, guardamos o antigo identificador, e fazemos o antigo apontar para o novo. Só excluímos de fato em caso de erro evidente ou de duplicata sem ambiguidade.

Por que tanta precaução? Porque a auditabilidade é todo o valor do sistema. No dia em que uma convicção de produto tiver que ser defendida, preciso poder voltar até a fonte dela, mesmo que ela seja de dois meses atrás e tenha sido "superseded" desde então. Um raciocínio cujo histórico foi apagado deixa de ser um raciocínio — vira uma opinião sem prova.

O que o contexto é de verdade

No fundo, esse motor de contexto não é um sistema de arrumação. É uma arquitetura de memória para uma inteligência que não tem uma nativamente.

Cada bloco responde a um limite do LLM: o manifesto responde à janela finita; as três memórias respondem ao esquecimento entre sessões; as notas atômicas respondem ao Lost in the Middle; a separação entre fontes, notas e entregáveis responde à necessidade de rastreabilidade; o arquivo offline responde ao fato de que o pensamento não para quando a sessão se fecha.

E o resultado é o que eu descrevia nos meus artigos anteriores: o entregável deixa de ser o ponto de partida do trabalho, vira um subproduto. O que tem valor é o próprio contexto — essa memória estruturada, rastreável, reutilizável, que enriquecemos sessão após sessão e que acaba produzindo bem mais do que pedimos a ela.

Para o PM016, o objetivo eram vinte e sete posts de LinkedIn. Mas o que fica, uma vez publicados os posts, é um contexto: vinte e duas ideias atômicas conectadas, três sínteses temáticas, fontes rastreadas. Um material que vou poder reabrir daqui a seis meses para um entregável totalmente diferente. O post era o objetivo. O contexto é o ativo.

Para saber mais

Do arquivo único ao sistema de contextos: por que a memória de um LLM não cabe em um só documento O PM como arquiteto do Contexto Um arquivo, algumas diretrizes, e o Claude faz o resto — como estruturei 500 e-mails sem esforço O que é uma nota atômica? O que é uma nota temática?