Fonte da verdade: a tua empresa numa pasta de ficheiros markdown

Sem sombra de dúvida, o documento mais útil da minha tese de mestrado não foi nenhum dos capítulos. Foi um repositório a que chamei brandbook. Qualquer marketer conhece o conceito, mas o meu tinha-se tornado noutra coisa: o sítio onde fixei tudo o que era verdade sobre a micro-PME que estava a transformar como caso de estudo. A comunicação partiu dali. O target partiu dali. O funil partiu dali. Hoje dar-lhe-ia provavelmente outro nome (fonte da verdade), e na altura tinha um único tipo de leitor: um humano.

A 12 de junho deste ano, uma especificação chamada Open Knowledge Format apareceu no repositório público Knowledge Catalog da Google Cloud, e no essencial é notavelmente simples: ficheiros markdown com um pequeno bloco de metadados, um conceito por ficheiro, ligações entre conceitos relacionados. Lembrou-me imediatamente aquele brandbook, com uma diferença. Há agora outro leitor sentado à mesa: a máquina.

O meu amigo TJ Robertson, que gere uma agência de AI SEO no Nevada, chegou mais ou menos ao mesmo sítio pelo caminho da operação diária. Na TJ Digital, cada cliente tem um Brand Ambassador, um conjunto de ficheiros markdown com os factos autoritativos sobre a marca, e os agentes consultam-no antes de escrever uma linha. Caminhos diferentes, a mesma conclusão: a AI é muito mais útil quando sabe onde vive a verdade da empresa.

O que quero dizer com fonte da verdade

O termo em si não é novo. As empresas têm fontes da verdade há décadas: um ERP, um CRM, uma base de dados de produto, às vezes apenas uma folha de cálculo em que toda a gente sabe que não se mexe. O que quero dizer aqui é um pouco mais estreito: um corpus curado de conhecimento confirmado da empresa, que os sistemas de AI leem antes de produzir uma resposta. Preços, políticas, métodos de trabalho, história, voz da marca, quem faz o quê, o que a empresa vende e o que se recusa a vender.

Nos sistemas que monto prefiro ficheiros simples, normalmente markdown: legíveis por humanos, fáceis de interpretar pelos modelos, fáceis de mover entre sistemas e triviais de versionar em git. Esta última parte vale mais do que parece, porque a verdade tem versões. Um preço correto em janeiro pode estar errado em junho, e com controlo de versões vês o que mudou, quando mudou e qual era a resposta anterior, sem comprar uma plataforma de knowledge management para isso. O formato exato importa menos do que a disciplina por trás dele.

O problema que resolve tem nome: palpite

Em setembro de 2025, a OpenAI publicou o paper "Why Language Models Hallucinate". O argumento central é direto: os sistemas de treino e avaliação tendem a recompensar o palpite em vez da admissão de incerteza. Pensa num aluno em exame. Se deixar a pergunta em branco garante zero pontos, chutar passa a ser a estratégia racional, e os modelos de linguagem cresceram dentro de sistemas com incentivos parecidos.

Agora aplica isso a uma empresa. Pergunta a um assistente de AI pelos teus prazos de entrega sem lhe dar acesso à tua política real, e ele pode dizer que não sabe, mas pode igualmente compor algo perfeitamente plausível a partir de tudo o que viu sobre empresas parecidas com a tua. É isso que torna o erro perigoso: a resposta errada não parece errada.

A regra que uso tem três degraus. Factos sobre a empresa vêm do corpus autoritativo da empresa. Factos sobre o mundo lá fora, como concorrência, regulação ou dados de mercado, vêm de fontes externas e são citados. Se nenhum dos dois contém a resposta, o sistema diz que não sabe, e este terceiro degrau é surpreendentemente difícil de impor com consistência.

O que uma fonte da verdade não é

Não é o llms.txt, o ponteiro público pensado para ajudar sistemas de AI a navegar um site. A Ahrefs analisou 137 mil domínios no seu conjunto de Web Analytics e encontrou o llms.txt em 28% deles; desses, 97% não receberam um único pedido durante o mês de maio. O ficheiro não é a parte interessante. Publicar o ponteiro custa dez minutos, enquanto decidir o que é verdade sobre a tua empresa, estruturá-la e mantê-la exata é o trabalho a sério.

Também não é uma cura para a alucinação. Um corpus autoritativo tira ao modelo a maior parte das razões para improvisar sobre factos da empresa, mas ele continua a poder interpretar mal um documento, ir buscar o ficheiro errado ou combinar dois factos de forma incorreta. Por isso testa-se. O meu ponto de partida é deliberadamente pouco sofisticado: vinte perguntas cujas respostas já conheces, corridas contra o sistema depois de cada mudança significativa no corpus. A resposta veio dos ficheiros, foi buscar o ficheiro certo, inventou alguma coisa? Não precisas de um framework de avaliação elaborado para apanhar a maioria das falhas iniciais.

E quando cresce demasiado?

Perguntam-me muitas vezes o que acontece quando a fonte da verdade fica maior do que a janela de contexto. Idealmente, nada. O agente nunca deve ler o repositório inteiro de uma vez: primeiro recebe um mapa do que existe, depois abre só os documentos relevantes para a tarefa. A Anthropic usa o termo progressive disclosure para um padrão semelhante nas Agent Skills, e a metáfora é menos exótica do que a tecnologia faz parecer: lês o índice antes de abrir o capítulo.

O MCP (Model Context Protocol) dá standard ao lado do acesso: um repositório exposto a qualquer agente através de meia dúzia de operações simples (listar, pesquisar, ler). Mas o transporte não é a parte difícil. Já vi repositórios com centenas de ficheiros onde a pesquisa tecnicamente funciona e o sistema continua a portar-se mal, porque os documentos estão mal nomeados, sobrepõem-se uns aos outros ou contêm informação desatualizada. Uma API não conserta má arquitetura de informação. O corpus continua a precisar de nomes descritivos, fronteiras sensatas entre temas, metadados úteis e alguém responsável por o manter atual.

A parte interessante não é técnica

Numa empresa real, os documentos contradizem-se. A proposta de março diz um preço, a tabela de abril diz outro, e um comercial ainda pratica um terceiro porque ninguém lhe disse que mudou. O modelo não deve decidir qual está certo; tem de ser uma pessoa, alguém com a autoridade e o contexto para dizer qual dos números é de facto verdade.

Vi isto com toda a clareza num viveiro de árvores ornamentais onde conduzi um engagement de growth. Muito do conhecimento que realmente importava, incluindo o método da casa e trinta anos de história, vivia na cabeça de duas pessoas, e transformá-lo em algo que um sistema de AI pudesse usar com fiabilidade envolveu entrevistas, edição, e voltar atrás de vez em quando para perguntar: "Ontem disseste X, mas este documento diz Y. Qual é que é verdade?" Muito pouco disso foi um problema de engenharia. As competências difíceis pareciam-se muito mais com trabalho editorial: extrair conhecimento tácito, reparar em contradições, decidir como separar os conceitos, escrever descrições úteis, testar se as respostas estão certas e decidir quem tem autoridade para as mudar. Alguém tem também de ser dono do repositório, porque sem dono ele começa a degradar-se quase de imediato.

Um padrão mais largo

Várias partes do ecossistema de AI têm derivado para primitivos parecidos. As Agent Skills da Anthropic usam pastas de markdown carregadas progressivamente, o AGENTS.md dá instruções locais a agentes de código, e há quem mantenha vaults de Obsidian e LLM-wikis caseiras pela mesma razão. Estas coisas não são idênticas e resolvem problemas diferentes, mas a preferência recorrente é por algo surpreendentemente aborrecido: ficheiros, texto simples, metadados e retrieval seletivo. Há boas razões para isso. São portáveis, os humanos conseguem inspecioná-los, as máquinas conseguem lê-los, o git consegue segui-los, e não ficas preso à plataforma de AI que estiver na moda este ano. Às vezes a infraestrutura aborrecida é exatamente a que sobrevive.

Por onde começar

Não pelo MCP, nem por escolher uma vector database. Começa por escrever as dez ou vinte coisas que a tua empresa repete constantemente: o que vendes, para quem é, quanto custa, com que condições, o que fazes de diferente, e que promessas estás mesmo disposto a fazer. Põe cada tema no seu ficheiro, dá nomes claros aos ficheiros, mete-os em git e decide quem é o dono. A primeira versão cabe numa tarde; a parte difícil vem depois, porque alguém tem de a manter verdadeira.

Escrevi há uns meses sobre o MCP e sobre como liguei o meu próprio site a agentes por essa porta. Esta é a camada que vem antes dessa: primeiro decides onde vive a verdade, depois decides como as máquinas lhe acedem.

E na tua empresa, onde é que a verdade vive hoje? Se a resposta for "na cabeça do sócio mais antigo", encontraste provavelmente um risco e o teu próximo projeto ao mesmo tempo.