Além de um cemitério organizado: second brains

Embora a AI tenha sido usada para corrigir erros de português e verificar questões estilísticas e de conteúdo, todas as palavras nesse artigo foram escritas por mim. Se eu não me dar ao trabalho de escrever, você não precisa se dar ao trabalho de ler.

–

 

Piadas com AI ficam velhas mais rápido do que os modelos mudam, mas esta continua relevante. Um quadrinho com dois frames, no primeiro: “A AI transforma este único tópico em um e-mail longo que eu posso fingir que escrevi”. No outro: “A IA transforma este e-mail longo em um único tópico que eu posso fingir que li”.

LLMs tornaram trivial processar quantidades enormes de informação. Extrair algo útil é, como o ditado popular diz, outros quinhentos. Como todo mundo, eu tenho uma maçaroca de notas, apresentações, artigos salvos, e-mails etc., que compõem uma boa parte da minha vida pessoal e profissional. Da última vez que me mudei, eu achei fichas escritas à mão, coletadas em alguma reunião já esquecida e nunca transcritas.

Não é de hoje que existem técnicas e formatos para lidar com isso. Até o Zettelkasten, literalmente um método de uso de fichários para notas, ressurgiu recentemente. O problema é que essas técnicas resultam em repositórios que são verdadeiros cemitérios, onde a informação fica apenas enterrada. 

Grafos que mostram nada além de lápides. E destilação, convenhamos, não é uma competência humana comum. Essa atenção ao detalhe e essa força bruta são justamente o que as LLMs trazem para o processo.

Modelos mais recentes também se tornaram melhores em teorizar, discordar e notar discrepâncias e padrões. Sem isso, você acaba com um repositório que é simplesmente uma echo chamber, com um loop semântico embutido.

Depois de alguns meses rodando o meu second brain e entendendo suas nuances e problemas, este artigo traz algumas considerações para quem quiser experimentar esse formato.

Não há aqui nenhuma performance no teatro da AI que envolva menções como superfícies de controle, enxames de agentes e outras ideias similares. Não tem nem um OpenClaw sequer. Você pode adicionar isso depois — ou não. Na maioria dos casos, um simples reconhecimento de padrões inesperados já traz bastante valor.

 

Não há também nenhum stack específico. Adapte conforme o necessário. A maioria das harnesses providas pelos modelos possuem projetos, como é o caso do Claude e OpenAI/Codex. 

Crie um projeto novo para esses prompts para evitar que outros chats acabem acidentalmente poluindo o seu second brain.

Um crítico, um provocador

Para começar, você precisa de 4 peças básicas:

1. O repositório em si. Você pode usar Obsidian, Notion, Apple Notes ou simplesmente uma pasta no seu Dropbox ou Drive. Desde que seja algo acessível pelo seu modelo, isso já é suficiente. Desnecessário dizer: faça backups regulares.
2. Um pipeline de entrada. Uma pasta chamada “inbox/” ou “entrada/” onde tudo aterrissa: artigos, transcrições de reuniões, ideias movidas a cafeína às 3 da manhã, screenshots, PDFs, conversas do WhatsApp… 

Você pode começar com um simples prompt no seu agente:

“Crie uma automação que processe o diretório de entrada, chamado inbox/, e destile cada item encontrado em um local canônico. Identifique automaticamente o conteúdo e coloque em pastas chamadas conceitos/, opiniões-do-mercado/, reuniões/, clientes/ e assim por diante. Se os diretórios não existirem, você pode criá-los. Se encontrar um item que não saiba classificar, me pergunte até que você tenha material suficiente para fazer isso sozinho. Em cada pasta, escreva um arquivo README com o tipo de conteúdo e como ele é processado. Tudo na pasta deve ser processado e, no final do processamento, escreva um briefing no diretório inbox/briefing contendo um resumo da execução. Crie uma automação para isso rodando a cada [x] horas e sempre que um novo tipo de material for incorporado, atualize a automação e os diretórios.”

Você pode incluir no prompt também informações suas e deixar em um diretório específico. Adapte como quiser. O importante é verificar que a automação foi criada (seu agente lhe dirá como verificar isso e, se por algum acaso não disser, não hesite em perguntá-lo até que esteja tudo certo).

3. Um crítico diário. Esse é o passo em que o valor começa a ser extraído do seu repositório. Um novo prompt:

“Uma vez por dia, processe o repositório, considerando todo o conteúdo do dia, e encontre três conexões, um padrão consistente e uma pergunta que eu deva responder. Também crie uma automação para isso. Escreva os resultados em um briefing diário no diretório inbox/briefings/. Esse resultado não deve ser meramente texto corrido, mas ser legível e estruturado. Junto a isso, crie uma visualização em HTML para que eu possa ler mais facilmente no meu navegador.”

A frequência pode ser ajustada, mas, na minha opinião, uma vez por dia é mais do que suficiente para evitar tanto o excesso de informações quanto a diminuição do valor dos elos entre os conteúdos. A não ser que você seja uma dessas pessoas que termina cada hora com uma centena de novas entradas. Nesse caso, ajuste a automação até entender o que funciona melhor.

4. Um provocador semanal. No domingo, pronto para o seu início de semana, o agente olha para tudo o que foi gerado nos últimos sete dias. O prompt:

“Uma vez por semana, aos domingos, processe todas as notas que você encontrou e escreva quatro seções: uma tese emergente a partir de tudo o que entrou nesses sete dias; contradições entre os diversos materiais; lacunas de conhecimento que precisam ser preenchidas; e uma ação que me ajude a alterar e amplificar o caminho percorrido até agora. Crie uma automação para isso também.”

Não tem mágica aqui. Em alguns dias e semanas, tanto o briefing crítico quanto o provocador vão produzir conexões genuínas, ações e ideias que alterarão a forma como você vê o conteúdo. Em outros, vão simplesmente papaguear aquilo que você já sabe. É o preço de como a tecnologia existe hoje. Mas dá para fazer algumas coisas para reduzir esse erro.

Três princípios fundamentais

1. O README é autoritativo. Cada diretório no repositório tem um README.md explicando o que existe ali e como ele deve ser usado. Serve tanto como documentação para humanos, caso você esqueça ou queira compartilhar, quanto como guia para o seu agente.

Como cada agente no mercado tem sua própria forma de operar no que diz respeito a instruções globais, ainda é necessária uma instrução geral para encontrar esses arquivos. O Claude usa CLAUDE.md, enquanto o ChatGPT e o Codex usam AGENTS.md, e por aí vai. O mais fácil é simplesmente pedir:

“Crie um arquivo no seu formato (CLAUDE.md, AGENTS.md ou outro) que será lido a cada execução realizada neste diretório e que contenha regras básicas. A primeira delas é que todo diretório possui um README.md, e ele deve ser lido sempre que o diretório for acessado de alguma forma, tanto para escrita quanto para leitura.”

Lembre-se de que agentes são sistemas não determinísticos. Ocasionalmente, eles vão esquecer e ignorar um desses arquivos. A geração de conteúdo não pressupõe a ausência de autonomia humana. Mas esses arquivos funcionam como guias para que o seu second brain seja útil, e não simplesmente o cemitério de notas descrito anteriormente.

2. O output não pode ser o input. Esse é o princípio mais fácil de descobrir do jeito difícil. A primeira iteração do meu briefing diário ficou bonita. A segunda foi meio que uma repetição da primeira. A terceira voltou à primeira. Demorou uma semana para eu perceber que o agente tinha construído um loop fechado em cima da própria escrita e estava produzindo novos “insights” ao reformular os de ontem.

Uma regra que deve ser colocada como parte de todas as automações:

O diretório briefing/ é write-only. O briefing diário nunca lê de briefing/. A revisão semanal nunca lê de briefing/. Somente o material bruto deve ser considerado: o que entrou na inbox naquela semana e o que mudou nos demais diretórios. Se eu quero continuidade entre semanas, releio deliberadamente um briefing mais antigo e específico. Não use esse diretório como parte de nenhuma varredura automática.

3. Markdown para o conteúdo original, HTML para visualizações humanas. Essa é uma regra que ainda estou considerando. O Markdown acabou se transformando em uma espécie de contrato sobre como agentes e modelos transacionam dados. 

Por outro lado, mesmo com ferramentas como o Obsidian para leitura e edição, acho o formato um tanto inadequado para esse uso específico. No momento, então, estou combinando abordagens. Todo prompt que solicita uma saída inclui:

“Use Markdown como formato canônico para processamento mas, para visualizações e leituras, gere um HTML a partir dele. Mantenha os dois sincronizados sempre que as tarefas ou automações aplicáveis rodarem.”

Isso duplica alguns conteúdos, mas permite que eu use o repositório como uma wiki e também consiga construir visualizações ricas, como gráficos, ilustrações vetoriais e dashboards, de uma forma mais orgânica.

Eu não me chamo Tom: alucinações virais

Se você ainda está comigo, provavelmente concorda que tudo o que viu até agora parece, nas palavras de Arthur C. Clarke, “indistinguível de mágica”. Mas toda mágica tem seu preço.

LLMs são máquinas estocásticas. Produzem alucinações e são suscetíveis a drift semântico, mesmo em situações corriqueiras.

Um exemplo clássico foi quando o meu second brain decidiu que meu apelido era Tom. Por alguma cadeia indireta entre Dominique, Dom e Tom — impossível de encontrar diretamente nos documentos — ele começou a usar isso como meu apelido. Erros assim se tornam virais. Um comentário sobre o lançamento de um produto chamado Crys, dizendo “Crys está ON”, fez com que o repositório renomeasse o produto para Crys ON. Quando percebi, 63 documentos já usavam a nova nomenclatura, incluindo propostas para clientes em andamento.

Outro problema é o envelhecimento dos arquivos e o constante aumento do contexto. Em algum momento, torna-se impossível, pelo menos com os modelos atuais, que cada processamento leve em conta todas as relações e todos os arquivos. Isso aparece principalmente nas automações e nos pedidos de processamento mais gerais.

Por isso, tenho duas rotinas que rodam ao lado da entrada, do crítico e do provocador.

Manutenção: pegando o agente no pulo. LLMs são notoriamente treinadas para preencher vazios. Se algo não está explícito, uma resposta não é encontrada ou alguma coisa não se encaixa, o autocomplete inerente aos modelos preenche esse vácuo com alguma alternativa plausível. Por conta disso, sempre que uma resposta gera um erro ou alguma inconsistência, eu coloco o problema em um arquivo de correções. Uma outra automação, executada uma vez por semana, percorre todo o repositório corrigindo esses erros.

No caso do apelido incorreto mencionado acima, um simples “registre isso no arquivo de pendências de manutenção semanal”, combinado com uma automação que executa “leia o arquivo de pendências encontradas semanalmente, uma por uma, e corrija todas as instâncias desse erro no repositório”, já resolve grande parte do problema. Com o tempo, fui criando regras de resiliência e classificadores automáticos, mas esse é o ponto de partida.

Curadoria: quando um item aluga um triplex no repositório. Uma vez por semana, outra automação executa auditorias proativas. Arquivos que cresceram demais são sinalizados para compactação. Briefings e logs antigos são compactados e arquivados (e as automações foram instruídas a ignorá-los no caso do crítico e do provocador). O material não desaparece, mas deixa de ter tanto impacto no dia a dia do repositório, tornando a execução mais rápida, mais concisa e mais realista.

E, sempre que preciso usar material antigo, é fácil executar um prompt separado para isso.

Três escalas

A arquitetura que descrevi não é a única forma possível. As três escalas abaixo mantêm os mesmos princípios, mas abrem mão de elementos diferentes.

Escala um: repositório unificado mais destilação. Uma única pasta inbox/, alguns destinos canônicos para destilação e uma pasta notes/ para o restante. Não há segmentação por projeto ou função. O crítico diário continua funcionando; o provocador semanal também. É uma ótima escala para quem está começando e, para algumas pessoas, é tudo o que é necessário.

Escala dois: repositório segmentado em projetos, com tarefas. Uma pasta para cada projeto em andamento e, dentro de cada uma, o material destilado, as teses que vão tomando forma (o que você acredita sobre aquele projeto, por exemplo) e as tarefas ativas. A inbox/ continua sendo a porta de entrada única, mas o roteamento já leva em conta os destinos de cada projeto.

Você pode ter um crítico semanal para cada projeto e outro para o repositório como um todo, ou simplesmente manter apenas um. O mesmo vale para o provocador. É uma boa escala para quem quer organizar uma única função ou cargo junto com os projetos associados.

Escala três: repositórios para uma função inteira. Clientes, prospectos, propostas, ofertas, projetos, pessoas, reuniões, briefings, conhecimento, tarefas internas e de clientes — tudo organizado pelos diferentes escopos da sua vida, sejam eles trabalho, hobbies, projetos paralelos ou outros.

É a escala que estou usando hoje, e precisei refinar as automações à medida que construía esses repositórios. Funciona como uma espécie de monorepo de conhecimento e tem seus próprios problemas. Em alguns momentos, há vazamento entre escopos por causa de alucinações e erros. Ainda estou avaliando se é mais simples duplicar tudo e executar automações separadas.

Essas questões se tornam mais prementes quando governança — seja de segurança, isolamento ou custo — passa a ser necessária.

O que custa

Não vou mentir: não é trivial. No momento, para a escala três, eu uso o maior plano disponível para o meu agente, e os repositórios consomem uma quantidade substancial das allowances. É algo valioso e que se paga, mas deve ser considerado na hora de escolher o tamanho do plano.

O teste final

O teste para saber se o seu second brain funciona é relativamente simples: no fim de uma semana de trabalho, ele lhe disse alguma coisa que você ainda não sabia?

Se ele apenas organizou o que você capturou, então não passa de um repositório. Se ele destilou o conteúdo, mas não criou nenhuma tese minimamente instigante e digna de exploração, então também não passa de um repositório.

Não vou lhe dizer qual é a sua versão disso. A minha ainda é um processo de tentativa e erro. Cada nova atualização de um modelo ou ferramenta que aprendo a usar produz um certo efeito meta sobre o conjunto. Há dias em que simplesmente jogo coisas na inbox e só volto a olhar no dia seguinte. Mas, na maioria das vezes, o que emerge das conexões entre projetos, conversas com clientes e colegas, artigos e tutoriais, e-mails, threads do Slack e até mesmo encíclicas papais vale os tokens gastos.

Se você também já ouviu o termo harness e se perguntou o que ele significa, tudo o que foi descrito aqui é uma harness para um second brain. É a forma como o conteúdo é delimitado e processado, com sinais de entrada e saída, para que o máximo de utilidade seja extraído. Como você percebeu, isso falha às vezes. É algo inerente ao ferramental e, em certa medida, inevitável.

Com evals e uma outra LLM atuando como juíza, seria possível reduzir os erros, mas com aumento de custo. Esse, porém, é um tópico para outra hora.

Ah, a próxima revisão semanal é na segunda-feira. Esse é o combinado. Não que o agente deixe de esquecer o que precisa fazer de vez em quando.

Apêndice: e daqui em diante?

O second brain roda na sua máquina local, o que é uma limitação inicial. Além disso, ele só se baseia nas notas às quais tem acesso. Algumas evoluções são possíveis.

Integrações: uma forma muito simples de enriquecer o repositório é conectá-lo ao Google Mail, Google Drive, Slack, Microsoft Teams ou equivalentes. Basta adicionar os MCPs que o seu modelo fornecer (no caso do Claude, eles são chamados de Connectors; no caso do OpenAI/Codex, de Plugins; e assim por diante) e incluir, no prompt de processamento da inbox/, uma instrução simples:

“Também processe todos os e-mails, mensagens do Slack e documentos compartilhados no Drive que sejam endereçados a mim ou que contenham atribuições para mim.”

É um começo simples.

Usando fora de casa ou do escritório: essa é uma parte um pouco mais complicada. No começo do meu repositório, eu usei o próprio Claude Code para criar uma integração rápida com o meu WhatsApp. Essencialmente, eu tinha um pequeno programa rodando no meu computador que monitorava um canal específico do WhatsApp para o qual eu enviava perguntas e novos itens para a inbox.

Hoje, já tenho uma integração completa com o OpenClaw, e o próprio repositório não está mais no Dropbox, mas sim no GitHub. É uma possibilidade mais complexa e que foge ao escopo deste artigo, mas pretendo revisitá-la no futuro.

Enquanto isso, existem bons tutoriais que podem ser encontrados sobre o tema.