No artigo anterior, descrevi um sistema de contextos estruturados para trabalhar com um LLM em assuntos complexos. Pastas, arquivos de missão, manifestos de carregamento, notas atômicas conectadas entre si. O modelo é poderoso. Mas não é simples de entender, e menos ainda de colocar de pé quando você começa do zero.

E, principalmente — eu não cheguei lá de primeira. Esse sistema é o resultado de 40 dias de tentativas, erros, versões jogadas fora e reconstruídas. Ninguém compra uma Ferrari como primeiro carro. Aqui é a mesma coisa: primeiro você precisa dirigir, entender como funciona, e só depois aumentar a complexidade.

Este artigo conta como eu comecei. Não com um framework. Com um arquivo.

O problema: 500 e-mails e nenhuma visão de conjunto

Como membro do conselho do meu condomínio, recebo muitos e-mails. Da administradora, de proprietários, de inquilinos. Às vezes um assunto novo, às vezes a enésima resposta a um thread que dura meses.

O volume não é o verdadeiro problema. O verdadeiro problema é que cada pessoa que responde a um thread tem o contexto na cabeça — é ela quem acompanhou o assunto desde o início. Eu, quando abro um e-mail novo, preciso subir a corrente toda, descobrir quem disse o quê, entender em que ponto estamos. Para uma obra que dura seis meses, é um trabalho enorme. Multiplique por quinze assuntos em paralelo e você entende por que fui atrás de outra solução.

Decidi entregar ao Claude a estruturação dessa informação que chegava. Ele coleta os e-mails automaticamente, associa cada um ao seu thread e agrega tudo. A coleta automática dos e-mails é pura técnica — não vou falar dela aqui. O que me interessa é o que acontece depois: como construí, passo a passo, um sistema de memória que se sustenta.

Etapa 1 — Um arquivo, uma frase

No início, era um simples arquivo context.md com uma diretriz vaga:

"Agregue as informações e divida em temas."

E funcionava. O Claude recebia os e-mails, classificava por assunto, mantinha um resumo por tema. Para uma primeira tentativa, já era útil.

Etapa 2 — O problema da perda de informação

Depois vi que eu estava perdendo informação. Quando uma obra terminava, por exemplo, o Claude atualizava a agregação: "obra concluída, recebimento em conformidade". Ótimo. Mas o histórico sumia. Quando a obra tinha começado? Quando ela foi adiada? Quando um aditivo foi assinado? Tudo isso era sobrescrito pela última atualização.

Eu precisava dos dois: a informação final e o histórico.

A solução foi pedir ao Claude que mantivesse, além da agregação, um log cronológico. Se uma obra começa, é uma linha. Se ela atrasa, é outra linha. Se um aditivo diz respeito à obra, é mais uma linha. Na agregação, você vê o estado atual: "obra iniciada em janeiro, concluída em junho, em conformidade". No log, você vê cada etapa, cada evento, em ordem.

Duas visões do mesmo assunto. Uma para entender rápido, outra para subir o fio da história.

Etapa 3 — As diretrizes de negócio

Depois quis dar regras de tratamento mais finas. Não regras genéricas — diretrizes específicas do meu contexto.

Por exemplo: quando uma pessoa é citada pelo sobrenome, encontrar o primeiro nome correspondente. Parece trivial, mas não é quando dois prestadores têm o mesmo sobrenome. Nesse caso, a diretriz especifica: usar o sentido do e-mail para desambiguar.

Outro caso: algumas pessoas são chamadas ora pelo nome de solteira, ora pelo nome de casada. Sem diretriz, o Claude cria duas entradas diferentes para a mesma pessoa. Com a diretriz, ele sabe que é a mesma.

Mais um exemplo: separar os pequenos devedores (menos de 100 euros) dos grandes devedores. Não é a mesma gestão, não é o mesmo acompanhamento, não é o mesmo nível de atenção.

Essas diretrizes não são regras universais. Elas são específicas do meu contexto. E é exatamente isso que as torna poderosas: elas codificam um conhecimento que só eu tenho, e que o Claude aplica depois de forma sistemática, sem esquecer, sem se cansar.

Etapa 4 — O muro das mil linhas

Funcionava bem. Meu context.md organizava direitinho o meu conhecimento. Mas ele começou a inchar. 500 linhas, depois 800, depois mais de mil.

O problema não é só a legibilidade para mim. É a janela de contexto do LLM. Quanto maior o arquivo, mais o Claude precisa carregar tudo a cada sessão. E, como expliquei no artigo anterior, um LLM perde precisão nas informações enterradas no meio de um documento longo. Meu arquivo único começava a jogar contra mim.

Etapa 5 — Separar as diretrizes do contexto

Primeira solução: extrair as diretrizes para um arquivo separado.

As diretrizes — como tratar os nomes, como separar os devedores, como lidar com as duplicatas — não são informações sobre o condomínio. São regras de tratamento. Misturá-las com o contexto é misturar a receita com os ingredientes.

Um arquivo directives.md de um lado. O context.md do outro. Já melhorou.

Mas o context.md continuava inchando.

Etapa 6 — Dividir o contexto por tema

A verdadeira solução foi pedir ao Claude que dividisse meu context.md em tantos arquivos quantos fossem os temas. As obras em um arquivo. As finanças em outro. Os prestadores em um terceiro. E assim por diante.

E para que ele se encontrasse: um readme.md que lista todos os arquivos, com uma descrição curta de cada tema.

A primeira divisão não me convenceu totalmente. É normal: eu tinha pedido que ele dividisse sem dar diretrizes precisas sobre como fazer, então ele fez do jeito dele. E às vezes a visão dele da divisão não batia com a minha. Eu tinha um arquivo de vários milhares de linhas — e não o enxergava necessariamente da mesma forma que ele.

Com um pouco de conversa e algumas diretrizes reforçadas sobre a divisão, chegamos a algo que me servia. Os arquivos estão bem divididos. E, principalmente: o Claude agora só lê e escreve nos arquivos de que precisa. Chega de arquivo monolítico carregado por inteiro a cada sessão. A janela de contexto não dispara mais.

Etapa 7 — Externalizar o vocabulário

Último refinamento: temos muito vocabulário técnico no contexto do condomínio. Nomes técnicos, siglas (DPAE…), termos jurídicos. Em vez de deixá-los espalhados por cada arquivo temático, pedi que ele centralizasse tudo em um glossary.md.

O modelo final — simples e robusto

E pronto. Sem partir para um sistema de memória complicado — sem manifesto de carregamento, sem notas atômicas, sem memória episódica — tenho um modelo que cobre de sobra a minha necessidade:

directives.md       — regras de tratamento
glossary.md         — vocabulário técnico
readme.md           — índice dos temas
themes/
  residence.md
  travaux.md
  finances.md
  prestataires.md
  ...               — um arquivo por tema

Quatro conceitos. Um arquivo de regras, um glossário, um índice e arquivos temáticos. É isso.

Para dar uma ideia concreta, aqui está o readme.md real do meu contexto de condomínio, tal como ele existe hoje — 15 arquivos temáticos:

Esse diretório antes era um único arquivo monolítico de mais de mil linhas. Ele foi decomposto em 14 arquivos temáticos em uma única sessão, e depois o debiteurs.md foi extraído de acteurs.md no mesmo dia — porque a gestão dos devedores merecia seu próprio espaço.

O que isso muda no dia a dia

O ganho é enorme.

Para quem acompanha um assunto há seis meses — a administradora que toca uma obra, o prestador que responde sobre um orçamento — o contexto está na cabeça. Essa pessoa sabe em que ponto estamos porque foi ela que viveu cada etapa.

Eu, quando chego em um e-mail, não tenho esse luxo. Preciso subir a corrente, reler as trocas anteriores, reconstituir o estado do assunto. Com 15 assuntos em paralelo e threads que se espalham por meses, é um trabalho gigantesco.

Com o sistema no lugar, tudo fica agregado. Eu sei que chegou um e-mail novo. Mas, principalmente, sei quais são as evoluções, como um dado evoluiu, em que ponto estamos. Tenho a trilha histórica. Tenho a lista das pessoas contatadas. Tenho a lista dos prestadores com suas áreas e seus valores. Todas essas informações estão organizadas e estáveis. A lista dos prestadores não muda a cada e-mail — ela vai sendo enriquecida aos poucos.

E quando eu tenho uma pergunta — "qual prestador fez o último orçamento das calhas?", "em que ponto está o caso com tal devedor?" — basta fazer a pergunta ao Claude. Se você tem 300, 400, 500 e-mails e precisa achar a resposta para esse tipo de pergunta garimpando a caixa de entrada, é um inferno.

Por onde começar?

Se você quiser experimentar, eu recomendaria passar pelo Claude CoWork quando você não vem do desenvolvimento. É mais simples, você não precisa recorrer a uma ferramenta de desenvolvimento inteira. Só duas coisas a fazer:

1. Criar um arquivo context.md
2. Dar 2-3 diretrizes na conversa: "vou te dar informações, você as agrega, você registra o histórico se houver várias etapas para essa informação, e coloca tudo isso no context.md"

E aí você começa a conversar com o Claude. Você dá informação para ele, vê como ele organiza, ajusta. O objetivo da primeira vez é só aprender. Não é construir o sistema perfeito. Aprender como funciona, como a IA reage, o que ela faz bem e o que ela faz mal.

No meu caso, fui direto para o Claude Code porque venho do desenvolvimento. Era mais simples para mim, é mais poderoso. Mas a escolha da ferramenta não é o mais importante — o que importa é o método.

O custo de entrada

Quanto tempo isso me levou? Partindo do zero, sem nunca ter conhecido o Claude, estou em uns 40 dias para chegar ao sistema atual (mais um monte de outras coisas sobre as quais vou ter que falar: monitoramento da concorrência, este blog também é inteiramente gerenciado pelo Claude, gestão da documentação de suporte, agente data analyst…). Mas tenho uma vantagem: antes de ser product manager, fui desenvolvedor. Isso ajuda na parte de ferramentas. Na parte de método — como estruturar a informação, quais diretrizes dar — é acessível para qualquer pessoa.

A questão da confiança

Claro que o Claude comete erros. Mas um humano também comete.

O que você precisa enxergar é que ninguém entregaria, obviamente, a gestão de documentos bancários para uma IA. Existem áreas onde não se pode errar. Mas para estruturar e-mails de condomínio, se de vez em quando o Claude junta mal uma informação, não é grave. O ganho de tempo é tão grande que algumas imprecisões são um preço aceitável.

E, principalmente, eu sempre tenho uma porta de saída: minha caixa de e-mails. Todos os e-mails brutos ficam guardados no repositório — uma cópia de todos os e-mails brutos dentro do projeto Claude. Posso a qualquer momento fazer uma busca direto nos e-mails originais pelo Claude Code, sem passar pela informação agregada. O sistema estruturado é um acelerador, não um substituto. A fonte da verdade continua acessível.

Do pessoal ao profissional

Apliquei exatamente a mesma abordagem para o meu trabalho de PM. No começo, era mesmo uma gambiarra — um arquivo de contexto, um skill, conversas no console sem saber direito como aquilo funcionava. E aí eu aprendi. Me lancei, cometi um monte de erros.

Joguei fora a primeira versão do que eu tinha feito. A segunda, eu pensava em jogar fora também, dizendo para mim mesmo "vai ficar bem melhor, mas pelo menos vou aprender umas coisas". E a segunda eu acabei guardando — ela ainda funciona. E iterei em cima dela para chegar a uma terceira versão, aquela que descrevo no artigo anterior.

Faça evoluir, não pule etapas

Estou na terceira versão do meu sistema. Acabei de converter os últimos elementos da V2 para a V3. E talvez um dia eu tenha uma V4, ainda mais complexa, mas que traga ainda mais valor.

Mas você precisa ser pragmático. A gente faz uma evolução de versão porque as necessidades vão crescendo — não só porque dá prazer. Senão, é sobre-engenharia.

O caminho é: um arquivo → algumas diretrizes → uma divisão → um glossário → um sistema. Cada etapa responde a um problema concreto. Você só passa para a próxima quando a anterior não basta mais. E em cada etapa você tem algo que funciona.

Comece por um arquivo. Você vai perceber sozinho quando for hora de dividir.

Para saber mais

O PM como arquiteto do Contexto Adicionar uma memória de sessão como no OpenClaw