Ganhe Prontidão para Agentes Tratando seu Conhecimento como Formato, não Plataforma

Em junho de 2026, o Google Cloud publicou uma especificação para alimentar a IA com conhecimento interno confiável, e a parte surpreendente é o tamanho dela. O Open Knowledge Format é markdown com YAML no frontmatter. Um campo obrigatório: type. Dois nomes de arquivo reservados: index.md e log.md. A especificação v0.1 inteira cabe em uma página.

Essa pequenez é o argumento todo. Um contrato de conhecimento que um único engenheiro lê em cinco minutos é um contrato que a empresa de fato consegue carregar entre ferramentas. O instinto é o mesmo que produziu o CLAUDE.md e todo arquivo de contexto de agente que os times vêm escrevendo à mão há dois anos. O Google Cloud pegou o padrão e o padronizou. Com isso, a pergunta de governança deixa de ser se devemos documentar nosso conhecimento para agentes e passa a ser de quem é esse conhecimento: um formato que podemos mover, ou uma plataforma na qual ficamos presos.

O que o formato de fato especifica

O OKF v0.1 é deliberadamente enxuto. Um documento é um arquivo markdown. O frontmatter carrega os metadados, e o corpo carrega prosa, tabelas e links como qualquer documento legível por humanos. O único campo exigido, type, declara o que o documento descreve: um conjunto de dados, uma métrica, um processo, uma entidade. Todo o resto é opcional e extensível.

Os arquivos reservados fazem o trabalho estrutural. O index.md é o ponto de entrada de uma coleção de conhecimento, o arquivo que um agente lê primeiro para entender o que existe. O log.md é o registro de mudanças, o histórico corrente de como o conhecimento evoluiu. Esse é o esqueleto inteiro. Sem servidor de schema proprietário, sem banco de dados, sem SDK que você precise adotar antes de escrever o primeiro documento.

O Google Cloud entregou ferramentas em volta, e elas valem ser lidas como declaração de intenção. Um Enrichment Agent rascunha documentos OKF direto sobre o BigQuery, então o formato pode ser inicializado a partir de dados que você já tem em vez de ser escrito do zero. Um visualizador HTML sem backend renderiza a coleção como um grafo que você abre no navegador sem servidor algum rodando. Pacotes de exemplo vêm no repositório GoogleCloudPlatform/knowledge-catalog. O visualizador não precisar de backend é o indício decisivo: o conhecimento são arquivos, e arquivos renderizam em qualquer lugar.

Por que um formato vence uma plataforma na prontidão para agentes

Andrej Karpathy, citado no post, fez o caso de por que isso importa agora: “LLMs não ficam entediados, não esquecem de atualizar uma referência cruzada e conseguem tocar 15 arquivos numa única passagem.” Essa é a propriedade que torna uma camada de conhecimento em markdown subitamente prática. A objeção histórica à documentação como arquivos era a manutenção. Referências cruzadas apodrecem, definições derivam, ninguém atualiza o índice. Um agente remove essa objeção. Ele reescreve a coleção inteira numa passagem e mantém o log.md honesto enquanto faz isso.

Então a restrição que empurrava as empresas para plataformas pesadas de conhecimento, o custo de manter a documentação atual, está se dissolvendo. O que resta é a decisão de arquitetura. Você pode codificar seu conhecimento institucional como um formato que controla, ou como estado dentro do produto de catálogo de um fornecedor. Um formato viaja. O mesmo pacote OKF alimenta um agente do Google hoje, o agente de outro fornecedor no próximo trimestre e sua própria ferramenta interna sem um projeto de migração. Uma plataforma transforma esse mesmo movimento em chamado de exportação de dados, exercício de mapeamento de schema e renegociação.

É a mesma lógica estrutural que traçamos em O MCP Corporativo Acabou de Atravessar a Linha da Engenharia: o valor durável fica na camada portável entre fornecedores, não na camada presa a um só. O MCP tornou portável a camada de conexão. O OKF mira o mesmo instinto na camada de conhecimento abaixo dela. Um agente só é tão confiável quanto o conhecimento que lê, e o conhecimento só é tão durável quanto o formato em que vive.

A decisão de aprisionamento que o OKF força

Um padrão publicado por uma hyperscaler convida uma suspeita justa: formato aberto, gravidade proprietária. A leitura honesta é que o formato em si é genuinamente portável, markdown é markdown, e o risco de aprisionamento migra para as ferramentas. O Enrichment Agent roda sobre o BigQuery. O caminho conveniente enriquece seu conhecimento a partir do data warehouse do Google usando o agente do Google, e conveniência é como plataformas adquirem gravidade mesmo quando o formato de arquivo é aberto.

A postura de governança que vence é tratar o formato como ativo e as ferramentas como substituíveis. Seja dono do pacote OKF no seu próprio repositório. Versione-o junto com seu código. Deixe o agente de qualquer fornecedor lê-lo, e recuse deixar um único agente virar a única coisa capaz de escrevê-lo. O formato te dá essa opção de graça porque a especificação cabe em uma página. Jogar a opção fora é uma escolha, em geral feita por inércia, quando um time deixa o pipeline de enriquecimento mais conveniente virar o único que toca o conhecimento.

Há um custo relacionado que vale nomear, aquele que chamamos de imposto de integração dos agentes. Todo agente que a empresa adota precisa entender a mesma realidade interna: o que é um cliente, como um negócio é estruturado, o que cada métrica significa. Sem uma camada de conhecimento compartilhada, cada agente reaprende essa realidade por integração sob medida, e você paga o imposto por agente. Um formato portável paga uma vez. O conhecimento fica escrito numa forma que todo agente lê, e integrar um novo agente vira apontá-lo para o pacote em vez de reconstruir o contexto.

A promessa de manutenção merece uma ressalva

O caso a favor dos arquivos repousa na premissa de que os agentes os mantêm atualizados. Essa premissa é forte e não comprovada em escala. Um agente que toca 15 arquivos numa passagem também propaga um erro por 15 arquivos numa passagem. O log.md registra o que mudou; não valida que a mudança estava correta. Uma camada de conhecimento mantida por agentes precisa da mesma disciplina de revisão que o código mantido por agentes: um humano ou um segundo agente checando que a reescrita preservou a verdade, e um jeito de reverter quando não preservou.

A ressalva reforça o formato em vez de enfraquecê-lo. Ela pede que o pacote de conhecimento seja tratado como artefato governado, com os mesmos controles que você coloca num repositório de código: histórico de versões, revisão a cada mudança e um dono responsável pelo que os agentes leem. O formato torna esses controles baratos de aplicar, porque já são arquivos simples num repositório. Uma plataforma costuma esconder o histórico de mudanças atrás de uma interface que você não consegue comparar.

Faça isto agora

Escolha um domínio onde seus agentes já precisam de contexto interno, uma definição de métrica, um schema de cliente, um processo central. Escreva-o como um pequeno pacote OKF: um index.md, um punhado de documentos tipados, um log.md. Coloque num repositório git que seja seu, não num catálogo de fornecedor. Aponte um agente existente para ele e confirme que o agente responde melhor com o pacote do que sem. Depois torne a regra explícita antes que o pipeline conveniente a torne por você: a camada de conhecimento é um formato que a empresa carrega entre ferramentas, e nenhum agente de um único fornecedor é a única coisa autorizada a escrevê-la.

A empresa que ganha prontidão para agentes neste ano será aquela cujos agentes leem de uma camada de conhecimento que ela consegue pegar e mover. Contar agentes não diz nada; carregar o conhecimento entre ferramentas diz tudo.

Fontes

Google Cloud. “How the Open Knowledge Format can improve data sharing.” Junho de 2026.

A Victorino ajuda equipes a construir uma camada de conhecimento portável que os agentes leem e os fornecedores não aprisionam: contato@victorino.com.br | www.victorino.com.br