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

Este aqui fala do como. Vou abrir o capô do meu motor de contexto — o sistema que vive em uma pasta 02-CONTEXT/ do meu vault — e acompanhar uma missão real do começo ao fim. A cada etapa, explico o bloco que entra em cena: a missão, o foco, as diretrizes, a lista de tarefas, a fila offline e os três tipos de memória.

O objetivo: que alguém que nunca viu esse sistema entenda como ele é organizado e, principalmente, por que é organizado assim. Porque cada pasta, cada arquivo, responde a um problema que encontrei trabalhando com uma IA em assuntos que duram 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 a enchemos, mais a atenção se degrada — é o fenômeno do Lost in the Middle, sobre o qual já falei em outro lugar. Então, em vez de guardar tudo na conversa, tudo é escrito em disco, em arquivos separados por natureza de 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 existe 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 própria cabeça.

De forma simplificada, um contexto se parece com isto:

<contexto>/
├── 00_mission/     ← o enquadramento estável: por que estamos aqui, as regras
├── 01_active/      ← o estado vivo: em que pé estamos, hoje
├── 02_checkpoints/ ← as fotos de cada etapa
├── 03_sources/     ← o material bruto
├── 04_notes/       ← as ideias extraídas, ligadas 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 organização é simples, mas rígida: 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 fica misturado. Vamos ver que essa separação não é cosmética: é ela que permite rastrear o raciocínio ao longo do tempo.

Para deixar 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 em uma revista de marketing. Uma missão de produção de conteúdo, curta, mas que aciona a maior parte dos blocos.

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

Começo 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, ao contrário, o que deve ficar em disco.

Ele contém três listas:

• always_load — o núcleo, carregado sempre. A missão, o escopo, as diretrizes, os riscos, o estado atual, o plano, o foco, a lista de tarefas, 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 quando a tarefa exige: as dezenas de fontes, as notas atômicas, os diários de sessão.
• Alguns limites de segurança: no máximo 12 arquivos ativos, cerca de 1200 linhas no máximo dentro da janela de contexto do LLM.

É como uma mesa de cirurgia. Os instrumentos essenciais já estão à vista; os outros ficam ao alcance da mão, mas a mesa não fica coberta. 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 o subconjunto certo, e 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: lê o núcleo, lê o último checkpoint, e está operacional. Ela sabe em que pé estamos sem que eu precise explicar nada de novo para ela.

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

Um zoom nas duas primeiras pastas — a estável e a viva:

00_mission/          ← o enquadramento 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 vigiar
└── 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 em que pé estamos
├── current_plan.md  para onde vamos
├── todo.md          as ações futuras
├── decisions.md     o que já decidimos
├── contradictions.md o que ainda não fecha
├── 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.

Existem dois arquivos que parecem dizer "aquilo em que estamos trabalhando", mas que não têm nada a ver um com o outro.

O primeiro é a missão (00_mission/mission.md). É o objetivo. Ele é estável. Na PM016, a missão cabe em uma 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 dentro de uma sessão. O foco é "hoje vamos trabalhar em quebrar as ideias do artigo 2 em posts distintos". Não é o objetivo — é o subproblema sobre o qual o holofote está apontado agora. O arquivo vive em 01_active/, a pasta do que está vivo.

Por que separar os dois? Porque confundir o objetivo com 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 a missão inteira em torno de um detalhe. Por outro lado, se ela só tem o objetivo diante dos olhos, fica vaga demais: "escreva posts de LinkedIn" não diz sobre o quê estamos nos concentrando neste instante. A missão dá a direção; o foco dá a profundidade de campo. Dá para refazer o foco dez vezes sem nunca mexer na missão. É exatamente como acontece com um humano: seu cargo (sua missão) não muda porque você passou a tarde em uma tarefa específica (seu foco).

Em volta da missão, em 00_mission/, existem outros três arquivos que dão o enquadramento.

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

Os riscos (risks.md) são a grade das ameaças que pesam sobre a missão. Na PM016, isso é modesto; mas em uma oportunidade de produto de verdade, esse arquivo acompanha os quatro grandes riscos de Marty Cagan — valor, usabilidade, viabilidade técnica e viabilidade de negócio. A ideia: manter permanentemente diante dos olhos as perguntas capazes de fazer o projeto fracassar, e marcar cada risco à medida que algum elemento o esclarece ou o agrava. Uma seção vazia = um risco ainda não documentado, ou seja, um ponto cego assumido.

O glossário (glossary.md) congela o vocabulário da missão, para que as mesmas palavras mantenham o mesmo sentido do começo ao fim. É o mesmo reflexo que tive no meu contexto de condomínio, onde acabei tirando todos os termos técnicos e siglas para um arquivo dedicado: sem isso, cada um — o humano e 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 são preenchidos de uma vez só no início. Vão sendo preenchidos aos poucos, ao longo das conversas. E "conversa" não quer dizer apenas "trazer um documento". Na maior parte do tempo, quer dizer falar. Eu converso com a IA, penso em voz alta, dou a ela um contexto que estava na minha cabeça — e é ela que arruma esse fluxo no lugar certo: este ponto é um risco de viabilidade, este termo merece uma entrada de glossário, esta frase delimita o escopo. Um risco que nunca foi escrito vira uma linha em risks.md porque eu mencionei falando, não porque abri o arquivo para preencher. É aí que o contexto deixa de ser uma pasta a organizar e vira um secretário particular que anota o que eu 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 forma de trabalhar. É a diferença entre os ingredientes e a receita.

Um exemplo tirado de outro dos meus contextos, onde mando processar centenas de e-mails de condomínio: "quando duas pessoas tiverem o mesmo sobrenome, use o teor do e-mail para indicar o primeiro nome e a empresa de cada uma" (dois prestadores tinham o mesmo sobrenome). Isso não é uma informação sobre o condomínio. É uma regra de processamento. Ela codifica um conhecimento que só eu tenho, e que a IA passa a aplicar sistematicamente — sem esquecer, sem se cansar.

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

As diretrizes estão no núcleo always_load: são recarregadas a cada sessão. Uma regra estabelecida na semana 1 continua valendo na semana 6, sem que eu precise repetir. É cumulativo. Quanto mais a missão avança, mais as diretrizes se refinam, e mais a IA trabalha como eu.

Detalhe de uso: para acrescentar uma diretriz no meio da conversa, basta eu começar a mensagem com alpha directive : ... e a IA consolida no arquivo. Existe um punhado de palavras-chave como essa (decision :, contradiction :, todo :, checkpoint, fin de session) — atalhos para arrumar uma informação no arquivo certo sem precisar dizer isso explicitamente. São apenas conveniências; o coração do sistema são os conceitos, não as palavras-chave.

A lista de tarefas: as ações futuras não poluem o raciocínio presente

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

Quando estamos trabalhando em um assunto, ideias de ações futuras surgem o tempo todo. "Vou precisar conferir esse número." "Dava para desdobrar esse post em um carrossel." "Lembrar de revisar a versão em inglês." Se deixamos essas ações flutuando na conversa, acontece uma de duas coisas: ou esquecemos delas, ou elas poluem o raciocínio em curso, puxando a atenção para todos os lados.

A lista de tarefas é o lugar onde a gente deposita essas ações para não precisar mais manter tudo isso na cabeça. É um backlog. Cada tarefa tem um identificador (T-NNN) e um status. A gente alimenta a lista escrevendo todo : .... E, como ela 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 e colocar em um lugar estável e com nome.

A fila offline: falar com o contexto enquanto ele dorme

Este é um bloco em que ninguém pensa no começo, e que logo vira indispensável: o arquivo offline (01_active/offline.md).

O problema: as ideias não vêm só quando estamos sentados diante da IA, com o contexto aberto. Uma ideia sobre a PM016 me ocorre num domingo à noite, e eu não tenho a menor vontade de abrir uma sessão inteira. Onde colocar?

No arquivo offline. Ele é uma caixa de correio. Deixo ali um recado — uma ideia, uma correção, um lembrete — sem abrir sessão nenhuma. O arquivo dorme junto com o contexto.

Depois, no início da sessão seguinte, o fluxo prevê uma etapa específica: se offline.md não estiver vazio, tratar o conteúdo como uma mensagem recebida e, em seguida, esvaziar o arquivo. A IA lê meu recado de domingo à noite como se eu tivesse acabado de digitar, leva em conta, age em cima dele 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 eu 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 da condução do sistema. Agora, o conteúdo.

Um zoom na cadeia que vai do bruto ao conhecimento:

03_sources/          ← o material bruto
├── SRC-001.md       a ficha (transcrição utilizável)
└── raw/             o original sem alteração (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 ligam várias notas

Quando adiciono material — na PM016, o PDF dos três artigos —, ele não é despejado na conversa. Ele vai para 03_sources/, o material bruto. Cada fonte ganha uma ficha e um identificador (SRC-001, SRC-002…). O PDF original, que a IA não consegue ler diretamente, é guardado sem nenhuma alteração em uma subpasta raw/, e uma ficha .md traz uma transcrição utilizável. Sempre dá para saber de onde vem cada informação.

Depois 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. Na PM016, a análise dos três artigos produziu vinte e duas notas. 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. […] Coerência não é homogeneidade. Exemplo da Nike: universos bem diferentes (corrida, futebol, basquete…) convivem sem que tudo seja uniformizado.

Essa nota é autônoma: dá para entender a nota sem reabrir o artigo. Ela tem fonte (aponta para SRC-001, página 67). E ela é ligada: no pé, uma seção ## Backlinks conecta a nota à nota temática the-brand-man. Isso é Zettelkasten — unidades de pensamento ligadas entre si, onde a inteligência surge das ligações, não do acúmulo.

Existe uma regra que eu 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 pode ser um "gancho" ou uma "punchline". A nota captura um conhecimento neutro e verdadeiro. A formatação a serviço do objetivo acontece exclusivamente nos entregáveis. A cadeia é rígida: sources (bruto) → notes (conhecimento neutro) → outputs (entregável orientado). Enquanto estamos nas notas, o objetivo da missão ainda não tem voz. Do contrário, envenenamos nossa própria matéria-prima.

Essa regra parece rígida. Na verdade, é ela que dá potência às notas — porque um conhecimento neutro é agnóstico em relação ao entregável, e portanto reutilizável em qualquer um deles.

Pense em uma missão de produto em vez da PM016. A partir de um mesmo conjunto de notas atômicas — um problema do cliente, uma restrição de adoção, um padrão de mercado —, eu consigo gerar materiais bem diferentes: um pitch para uma diretoria, uma documentação de suporte, um artigo de blog, uma sales narrative, um onboarding. Cada entregável escolhe e combina os blocos de que precisa dentro desse acervo comum. Se eu tivesse formatado essas notas para o pitch, elas só serviriam para o pitch. Mantendo as notas neutras, elas 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 estamos produzindo.

E a reutilização não para na missão. Os contextos não são silos herméticos. Uma nota produzida para um contexto pode iluminar outro — porque dá para ligar contextos vizinhos entre si. Eu posso até abrir um contexto para auditar outro: percorrer as notas dele e identificar as boas ideias a aproveitar. Um bloco de conhecimento escrito uma única vez pode assim alimentar um entregável hoje, outro entregável amanhã, e uma decisão em um terceiro contexto daqui a seis meses. É exatamente a promessa do começo: 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. Na PM016, uma por artigo.

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

Um 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 a gente retém disso (a lição)

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

É aqui que entra 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 está acontecendo agora, a que guarda os eventos vividos, e a que consolida os saberes duradouros. O sistema reproduz essa arquitetura com três objetos distintos, que não podem de jeito nenhum ser confundidos.

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 emperrou. É o relato cronológico. Voltamos ali 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 a gente 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 em um dado momento. O ângulo de redação é bem preciso, e é isso que lhe dá valor: "se um LLM chegasse agora sem ter lido nada, o que ele precisa saber para retomar sem errar e sem começar do zero?" O checkpoint é a rede de segurança da retomada.

A distinção entre diário e síntese é a que mais passa despercebida. O diário é a história; a síntese é a lição. Precisamos dos dois, exatamente pelo motivo que me levou, nas minhas primeiras tentativas, a separar a agregação de um log cronológico: eu queria ao mesmo tempo saber em que pé estamos (a síntese) e poder voltar no tempo (o diário). Sobrescrever um com o outro é perder ou a memória, ou a rastreabilidade.

E é justamente isso que torna o sistema auditável. Um cérebro esquece — essa é a força dele. Um sistema de arquivos 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, do início ao fim

Agora que temos os blocos, aqui vai o filme completo de uma sessão na PM016.

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

Durante a sessão. A gente conversa — muitas vezes em voz alta, diante da tela. E, ao longo da conversa, a IA vai arrumando tudo continuamente. Chega uma fonte nova → 03_sources/. Surge uma ideia duradoura → uma nota atômica em 04_notes/. Uma decisão é tomada → decisions.md. Aparece uma contradição → contradictions.md (não suavizamos artificialmente, a contradição fica visível). Uma ação futura → a lista de tarefas. Sempre que um arquivo é criado, o README.md da pasta dele e o índice de máquina são atualizados. O contexto fica constantemente em dia, sem esforço da minha parte.

No fim da sessão. Eu digito /context_close. A IA dispara o ritual de encerramento: 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 algum limite foi atingido. Depois faz o commit de tudo. A próxima sessão vai conseguir retomar exatamente de onde esta parou.

Existe também uma compactação no meio do caminho (/context_push): quando o estado atual incha, quando a lista de tarefas fica ilegível, ou quando começamos a andar em círculos, condensamos, tiramos duplicatas, priorizamos, arquivamos o que não serve mais — sem nunca perder a rastreabilidade.

Mas o /context_push tem um papel ainda mais vital, e essa é uma armadilha em que todo mundo cai ao descobrir o sistema. Quando uma sessão dura muito, a conversa acaba ultrapassando a janela do LLM. Nesse momento, o LLM faz a 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 falada, uma ideia lançada de passagem, uma nuance importante — é aparado, deformado ou 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 é a defesa: ele força a gravação em disco antes que o LLM compacte a própria memória de trabalho. Fazendo push com regularidade, garantimos que tudo o que importa já está escrito nos arquivos — no lugar certo, com fonte, rastreado — e que, portanto, 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 só na conversa está com os dias contados; só o que está em disco é de fato memorizado.

Esquecer sem perder

Um último ponto, porque ele diz muito sobre a filosofia do sistema. Não existe exclusão bruta.

Quando uma informação deixa de ser útil, ela não é apagada. Ela sai do carregamento padrão, é compactada, ou é arquivada. Quando uma ideia substitui outra, a antiga não é sobrescrita: ela recebe a marca superseded, mantemos o identificador antigo, e fazemos o antigo apontar para o novo. Só apagamos de verdade 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 precisar ser defendida, eu tenho que conseguir voltar até a fonte dela, mesmo que seja de dois meses atrás e tenha sido marcada como "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 organização. É uma arquitetura de memória para uma inteligência que não tem memória nativa.

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 rastrear tudo; o arquivo offline responde ao fato de que o pensamento não para quando a sessão fecha.

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

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