Como o conhecimento da agência é organizado, mantido e consultado — da pasta bruta ao insight cruzado entre clientes.
A arquitetura inteira deste wiki — cada pasta, cada regra, cada convenção — é uma implementação direta do conceito descrito no artigo Wiki LLM. Entender o artigo é entender o porquê de cada decisão tomada aqui.
"Na prática, deixo o agente do LLM aberto em uma janela e o Obsidian na outra. O LLM faz edições com base na nossa conversa, e eu navego pelos resultados em tempo real. O Obsidian é a IDE; o LLM é o programador; a wiki é a base de código."
Toda agência acumula conhecimento todos os dias — em calls, relatórios, testes que funcionaram, erros que não devem se repetir. O problema é que esse conhecimento some: fica na cabeça de uma pessoa, num doc solto, num relatório que ninguém abre mais. Este sistema existe para resolver isso.
Cada reunião, cada teste, cada insight vai para o wiki. Não para um doc solto — para um grafo interligado que nunca some entre sessões.
Um insight de um cliente pode valer para três outros no mesmo segmento. Links internos tornam isso possível — qualquer página referencia qualquer outra.
O Claude lê o wiki como contexto antes de qualquer tarefa. É como briefar um analista que já conhece todo o histórico sem precisar reexplicar nada.
Obsidian não é só um editor de notas. É uma engine de links bidirecionais sobre arquivos .md locais.
Isso o torna perfeito como camada de visualização do wiki — enquanto o Claude escreve, o Obsidian conecta.
Arquivos .md são texto puro, sem lock-in, legíveis por qualquer ferramenta e perfeitamente processáveis por LLMs. O Claude lê e escreve markdown nativo sem fricção.
[[page]]Ao escrever [[kk-foods]] em qualquer página, o Obsidian cria automaticamente uma referência bidirecional. Você vê quem aponta para onde no grafo visual.
O Obsidian renderiza todos os links como um grafo visual interativo. Você vê em segundos quais clientes têm mais conexões, quais conceitos são mais referenciados, quais páginas estão isoladas.
O vault (pasta raiz) é uma pasta local comum. Não há servidor, não há conta — os arquivos ficam no seu computador, sincronizáveis via OneDrive, Dropbox ou git como qualquer outra pasta.
A estrutura não é arbitrária — cada nível resolve um problema específico de organização de conhecimento. Clique em qualquer pasta para entender sua lógica.
Não é documentação para humanos — é o sistema operacional do Claude. Define identidade, missão, formatos de página, fluxos de trabalho e regras de qualidade. Lido no início de cada sessão antes de qualquer ação.
Lista plana de todas as páginas existentes com uma linha de descrição cada. Funciona como o sumário do segundo cérebro — o Claude consulta o index antes de qualquer busca para saber onde olhar.
Registro cronológico append-only de tudo que o Claude fez: fontes ingeridas, clientes criados, reuniões registradas, análises geradas. Nunca se apaga — só cresce.
Repositório de fontes originais: artigos copiados, transcrições de calls, notas cruas, PDFs. Nunca são editados. São a matéria-prima — o Claude lê daqui, processa, e escreve em wiki/.
Tudo que o Claude escreveu e mantém. Dividida em subpastas por tipo de conhecimento — cada uma responde a uma pergunta diferente sobre o negócio.
perfil, reunioes, acoes e resultados. Responde: quem é o cliente, o que foi decidido, o que foi feito, e quais são os números.raw/. Contém: resumo dos pontos principais, insights, conexões com clientes e segmentos, e path para o arquivo bruto original.Tudo que sai do sistema para o mundo externo: relatórios HTML, planos de ação, slides, tabelas para o cliente, apresentações. São gerados a partir do conhecimento acumulado no wiki — não o contrário.
Scripts e configurações do agente que coleta dados das plataformas de ads (Meta Graph API, Google Ads API) e alimenta o wiki automaticamente. É a camada de automação que mantém o wiki atualizado sem intervenção manual.
resultados.md e campanhas/ de cada cliente.
Cada informação que entra no sistema percorre um caminho definido. Não existe shortcut — fonte bruta vai para raw, processamento vai para wiki, produto vai para outputs.
Gravação ou notas de reunião com o cliente
Conteúdo externo: artigos, posts, estudos de caso
Meta Ads, Google Ads, plataformas de delivery
A fonte vai para raw/transcripts/, raw/articles/ ou raw/notes/ exatamente como chegou — sem alteração. Este é o princípio da fonte imutável: se precisar reverificar, o original está aqui.
Resumo, insights principais e conexões com o grafo
Reuniões, ações e resultados atualizados
Padrões cruzados entre clientes do mesmo nicho
Relatórios, planos de ação, apresentações e análises são gerados consultando o wiki — não reconstruídos do zero. O histórico já está lá; o output é só a renderização para consumo externo.
Seis regras que garantem a integridade do sistema. Quebrar qualquer uma degrada a confiabilidade do wiki inteiro.
Nenhum arquivo em raw/ é editado pelo Claude, jamais. A fonte original precisa ser verificável a qualquer momento. Se o dado mudar, cria-se uma versão nova em raw — não se sobrescreve.
Toda operação do Claude termina com atualização do index (nova página catalogada) e append no log (operação registrada). Sem isso, o mapa fica desatualizado e o histórico perde continuidade.
Toda referência entre páginas usa [[Nome da Página]] — nunca caminhos relativos como ../clients/kk-foods. O formato Obsidian é o único que o graph view processa corretamente.
Se uma nova informação contradiz algo no wiki, as duas versões são anotadas com a data de cada uma — a mais antiga não é apagada. Silenciar uma contradição é mais perigoso que mantê-la visível.
Uma observação de um único cliente é uma hipótese. Só vira padrão — e vai para a página do segmento — quando confirmada em dois ou mais clientes. Isso previne overfitting de caso único.
Antes de criar uma página nova, verificar se existe uma que pode ser atualizada. Wiki com duplicatas perde coerência — a informação fragmentada em dois lugares fica desatualizada nos dois.
As linhas no Obsidian não são decoração — cada uma representa uma intenção. Dois clientes nunca se ligam diretamente: eles se ligam através de um hub intermediário que tem propósito semântico. Entender isso é entender o núcleo do sistema.
[[integrative-campinas]] → [[integrative-ipatinga]] não faz sentido semântico — o que os une não é o fato de serem clientes, mas o que eles compartilham: segmento, padrão de campanha, benchmark, fonte de conhecimento. O hub é o nome desse compartilhamento.
O mais poderoso. Todos os clientes do mesmo nicho apontam para cá. O hub agrega o que funciona e o que não funciona validado em 2+ clientes.
Um criativo ou estratégia que foi testado. O hub guarda os resultados por cliente — se o mesmo formato for usado em outro cliente, os dados ficam aqui centralizados.
Um artigo ou benchmark externo que é relevante para múltiplos clientes. Um único raw processado pode conectar 3 clientes diferentes via a mesma fonte.
Uma estratégia, framework ou metodologia usada em vários clientes. Clientes de segmentos diferentes podem se conectar aqui se usam o mesmo framework.
/prep-reuniao integrative-ipatingaclients/integrative-ipatinga/perfil.md, reunioes.md, acoes.md — lê o histórico completo deste cliente.[[segments/medicina-integrativa]]. Segue o link e lê a página do segmento — que já tem os padrões validados em Integrative Campinas e Support Health. O Claude agora sabe o que funciona no segmento inteiro, não só neste cliente.
[[segmento]] no acoes.mdReferência rápida: o que cada componente é, quem escreve e para que serve.