Open Knowledge Format do Google: um primeiro olhar na prática

Open Knowledge Format do Google: um primeiro olhar na prática sobre o OKF

Quase ignorei. Mais uma especificação, mais um acrônimo, mais um comunicado de imprensa sobre um "padrão independente de fornecedores" aparecendo no meu feed numa sexta-feira. O Google Cloud publicou o Open Knowledge Format — OKF v0.1 — em 12 de junho de 2026, e minha primeira reação honesta foi dar de ombros. Já vimos uma dúzia de formatos que "mudam tudo" chegar e desaparecer silenciosamente.

Então abri a especificação. E percebi que a coisa toda é simplesmente arquivos markdown com algumas linhas de YAML no topo, agrupados em uma pasta. Sem SDK. Sem runtime. Sem esquema de compressão. Sem API para chamar. Um "pacote de conhecimento" no Open Knowledge Format é, quase insultantemente, apenas arquivos que você poderia escrever em um editor de texto.

Essa foi a parte que me fez parar de rolar a tela e criar uma pasta de teste. Porque passei o último ano construindo workflows de agentes, e a única coisa contra a qual continuo batendo é a mesma parede: meus agentes são brilhantes em raciocinar e terríveis em lembrar. Eles re-scrapeiam, re-resumem, re-derivam o mesmo contexto a cada sessão. Se um formato tão simples assim pudesse dar a um agente um lugar limpo e estruturado para ler conhecimento — em vez de re-derivá-lo de HTML bruto toda vez — isso vale uma tarde.

Então passei essa tarde nisso. Construí um pequeno pacote manualmente a partir da especificação publicada, passei meu próprio site por um gerador comunitário, e abri o resultado no Obsidian para ver se a afirmação de "amigável para humanos" sobrevive ao contato com a realidade. Isto é o que encontrei — o que o OKF realmente é, as partes que os anúncios acertam, e a pilha muito maior de coisas que são promessas voltadas para o futuro em vez de realidade entregue. Serei claro sobre o que é o quê, porque a lacuna entre eles é onde a maior parte do hype vive.

O que é o Open Knowledge Format, na prática?

O Open Knowledge Format é uma especificação aberta e independente de fornecedores do Google Cloud para armazenar conhecimento como um diretório de arquivos markdown, cada um com YAML front matter, projetado para ser lido tanto por humanos quanto por agentes de IA. Isso é tudo. Uma frase cobre tudo.

Tirando a linguagem dos anúncios, o OKF toma exatamente três decisões estruturais:

• Conhecimento é uma pasta de arquivos markdown. O Google chama uma pasta de pacote de conhecimento. É um diretório — possivelmente com subdiretórios — cheio de arquivos .md.
• Cada arquivo é um conceito. Não uma página web. Não um documento inteiro. Uma unidade discreta de conhecimento: um playbook, uma definição de métrica, um runbook, uma descrição de API, uma entidade individual. A intuição de Karpathy de que o conhecimento deveria ser atomizado em páginas de conceito em vez de despejado como documentos longos está incorporada diretamente no formato.
• Todo conceito declara um type. A especificação requer exatamente um campo de front matter em cada arquivo: type. Todo o resto — title, description, resource, tags, timestamp — é recomendado, mas opcional.

Aqui está um arquivo de conceito que escrevi manualmente para testar o formato, modelado a partir de um dos meus próprios playbooks internos:

---
type: playbook
title: Client Onboarding Sequence
description: The exact steps I run when a new AI automation client signs.
tags: [onboarding, process, clients]
resource: https://mejba.me/onboarding
timestamp: 2026-06-18
---

# Client Onboarding Sequence

When a new client signs, I run these steps in order. Each one has a
trigger and a definition of done — agents reading this should treat the
"done" condition as the success check.

## 1. Access provisioning
Grant repo + cloud read access within 24h of signature...

## 2. Context capture call
A 45-minute recorded call. The recording becomes its own concept file...

Isso é um conceito OKF completo e válido pela especificação. Nenhuma ferramenta o produziu. Eu o digitei. E aqui está a parte silenciosamente importante: ele renderiza limpo em qualquer aplicativo markdown em que o joguei — o GitHub fez preview, o Obsidian indexou o front matter como propriedades, e cairia no Notion sem problemas. O formato não pede que você adote nada. Ele descreve o que você provavelmente já está fazendo, apenas com uma forma acordada.

Mas um arquivo individual não é a unidade interessante. O pacote é. Então deixe-me mostrar como um pacote é realmente conectado — porque é aqui que o OKF para de ser "um arquivo markdown" e começa a ser um sistema.

Como um pacote de conhecimento é estruturado

Um pacote de conhecimento é um diretório de conceitos, e a especificação lhe dá dois arquivos organizadores opcionais, mas poderosos, que transformam uma pasta plana em algo pelo qual um agente pode navegar inteligentemente.

A estrutura fica assim:

my-knowledge-bundle/
├── index.md          # visão geral + listagem do diretório (opcional)
├── log.md            # histórico cronológico de mudanças (opcional)
├── onboarding.md     # um conceito na raiz do pacote
├── pricing.md        # outro conceito
└── playbooks/        # um subdiretório agrupa conceitos relacionados
    ├── index.md      # subdiretórios podem ter seu próprio índice
    ├── refunds.md
    └── escalation.md

Os dois arquivos especiais são onde o design fica inteligente.

index.md é o mapa do pacote. Ele enumera o que está no diretório para que um agente possa inspecionar o pacote antes de ler qualquer coisa. Isso é revelação progressiva — exatamente o mesmo padrão que torna skills de agentes bem projetados eficientes. Um agente lê o índice, decide quais três dos quarenta arquivos de conceito realmente precisa, e carrega apenas esses. Ele não despeja toda a pasta no contexto. Se você já lutou com a inflação de tokens que vem de despejar tudo na janela de contexto, reconhecerá por que isso importa — é o mesmo princípio sobre o qual escrevi na minha análise de por que gerenciamento de contexto supera configuração para agentes de IA. O índice é o holofote; os conceitos são o que ele ilumina.

log.md é a memória do pacote sobre suas próprias mudanças. Um histórico cronológico de atualizações. Por que um formato de conhecimento precisa de um changelog? Porque o OKF assume que o conhecimento vive — que ele é revisado, contradito e corrigido ao longo do tempo. O log é como um agente (ou um humano) entende não apenas o que o conhecimento diz hoje, mas como chegou aqui.

Quando construí meu pacote de teste, o arquivo de índice foi o que me convenceu. Escrevi cinco arquivos de conceito, depois escrevi um index.md que listava cada um com uma descrição de uma linha. Então apontei o Claude para a pasta e fiz uma pergunta que apenas um conceito poderia responder. Ele leu o índice primeiro, abriu exatamente um arquivo e respondeu. Nunca tocou nos outros quatro. Essa é a diferença entre dar a um agente um catálogo de fichas de biblioteca versus despejar todos os livros na sua mesa.

Agora — antes que isso soe muito polido — deixe-me ser honesto sobre onde a simplicidade se torna uma limitação. Não há imposição. Nada impede você de escrever quarenta arquivos de conceito sem índice, com valores de type inconsistentes, e um log.md que é uma mentira. O formato é uma convenção, não uma garantia. O que me leva à comparação que todos continuam fazendo, e acertando apenas parcialmente.

OKF vs llms.txt vs schema.org: onde ele se encaixa?

Essa é a pergunta que tive dentro de dez minutos após ler a especificação, e é a que os anúncios respondem com menos clareza. Já temos llms.txt. Já temos schema.org. Precisamos de uma terceira coisa? A resposta curta: eles ficam em camadas diferentes, e o OKF é a mais profunda.

Eis como eu mapearia o stack para visibilidade de IA em 2026:

Pense nisso como um restaurante. llms.txt é o cardápio dizendo ao agente o que está disponível. Schema.org é a rotulagem de alérgenos e ingredientes que remove a ambiguidade sobre cada prato. OKF é a comida real, emplatada e pronta para comer — o conhecimento em si, entregue como um conceito markdown limpo em vez de forçar o agente a fazer engenharia reversa a partir de HTML scrapeado.

Esse enquadramento importa por causa de uma comparação que a especificação faz implicitamente e que farei explicitamente: OKF é a o que você recorre quando schema.org fica sem espaço. Schema.org é brilhante para as coisas para as quais tem tipos — produtos, receitas, eventos, organizações. Mas no momento em que seu conhecimento é um playbook nuançado, um processo proprietário, uma definição de métrica duramente conquistada, ou uma estratégia que não mapeia para nenhum @type no vocabulário, schema.org não tem nada para você. OKF não restringe você a um vocabulário predefinido. Seu type pode ser playbook, runbook, case-study, pricing-logic — o que seu domínio precisar. Essa é a troca: schema.org dá rigor validado por máquina dentro de um vocabulário fixo; OKF dá flexibilidade aberta com quase nenhuma validação.

E o provável tecido conectivo entre essas camadas é llms.txt novamente. A expectativa voltada para o futuro — e quero sinalizar isso claramente como esperado, não entregue — é que sites sinalizarão a existência de um pacote OKF através de um ponteiro estilo llms.txt, da mesma forma que sitemaps XML e dados estruturados chegaram após robots.txt. A partir da v0.1, não há protocolo de descoberta formalizado incorporado no OKF em si. Isso é uma lacuna, e é o tipo de lacuna que uma v0.1 deve ter.

Se você está construindo sistemas de conteúdo e quer essa camada automatizada em vez de mantida manualmente, isso é exatamente o tipo de pipeline que eu construo — transformar o conhecimento de um site em estrutura legível por agentes está se tornando uma disciplina própria, e você pode ver como eu abordo isso no meu trabalho sobre automatizar workflows de conteúdo SEO com Claude Code. Mas você não precisa de mim para começar. Você pode construir seu primeiro pacote hoje, e deveria, porque ler uma especificação não ensina quase nada comparado a escrever um pacote ruim.

Como construí meu primeiro pacote OKF (e o que quebrou)

Tomei dois caminhos de propósito: construir um pacote manualmente para entender o formato, e passar um site existente por um gerador para ver o que a automação produz. O contraste me ensinou mais do que qualquer um separadamente.

Caminho um: manualmente. Criei uma pasta, escrevi cinco arquivos de conceito baseados em documentos internos reais — minha sequência de onboarding, minha lógica de preços, dois playbooks, e um glossário de termos que uso com clientes. O front matter foi a única fricção. Decidir o type para cada conceito demorou mais do que escrever o conteúdo, porque a especificação deliberadamente não diz quais tipos usar. Meu documento de preços é um pricing? Uma policy? Uma reference? A liberdade é real, e a fadiga de decisão também. Minha conclusão: escolha seu vocabulário de tipos primeiro, escreva-o como seu próprio conceito, e mantenha-se nele. Tipos inconsistentes são a forma mais rápida de criar um pacote pelo qual um agente navega mal.

Então escrevi o index.md manualmente e imediatamente entendi por que é opcional na especificação, mas obrigatório na prática. Sem ele, um pacote é uma pilha. Com ele, é um grafo.

Caminho dois: um gerador. A comunidade se moveu rápido aqui. Suganthan Mohanadasan — um SEO que, notavelmente, já tinha seu próprio site falando um formato de conceito markdown antes do Google lançar o OKF — construiu um OKF Bundle Generator gratuito que recebe uma URL ou sitemap e produz um pacote baixável mais um mapa do seu conteúdo. Passei uma seção do meu próprio site por ele.

O resultado foi genuinamente útil e genuinamente limitado ao mesmo tempo, e a limitação é toda a lição. O gerador fez bem o óbvio: cada página se tornou um arquivo markdown limpo com front matter sensato, com links cruzados, sem lixo HTML. Mas produziu um conceito por página — e isso não é realmente para o que o OKF é feito. A unidade do OKF é o conceito, não a página. Um único post longo do meu blog pode conter quatro conceitos distintos que, em um pacote apropriado, deveriam ser quatro arquivos separados que um agente pode referenciar independentemente. O gerador traduziu fielmente minha estrutura de páginas; ele não pôde realizar o ato mais difícil de extração de conceitos — ler uma página e decidir que ela na verdade contém três ideias que merecem seus próprios arquivos.

Essa lacuna é a oportunidade real, e direi claramente: o ferramental valioso de OKF ainda não foi construído. Conversores de página para markdown são um problema resolvido e comoditizado. As ferramentas que importarão são as que leem seu conteúdo bagunçado e sobreposto e o decompõem em conceitos limpos e deduplicados que espelham sua estrutura empresarial real. O termo de Suganthan para o que o OKF permite — "desassar semântico," quebrar conhecimento assado junto de volta em elementos estruturados e interoperáveis — é exatamente a parte que a automação não resolveu. Um modelo de linguagem é adequado para essa extração, mas apontar um ingenuamente para "transforme este site em conceitos" ainda produz arquivos de conceito que se sobrepõem e contradizem. Fazer isso bem está sem solução.

Se você prefere que alguém construa essa pipeline de extração de conceitos para seu negócio em vez de lutar com ela você mesmo, esse é um projeto que eu aceito — você pode ver o tipo de sistemas que construo em fiverr.com/s/EgxYmWD. Mas genuinamente, construa um pacote de cinco arquivos manualmente primeiro. Levará vinte minutos e ensinará o que nenhuma ferramenta pode.

A conexão com Karpathy: conhecimento que se mantém sozinho

OKF não vem do nada. É a formalização de uma ideia que Andrej Karpathy propôs — o que ele chamou de padrão LLM Wiki — e entender essa origem diz para onde isso realmente está indo.

O argumento de Karpathy ia contra a corrente de como fazemos retrieval hoje. O padrão dominante, RAG, funciona dividindo documentos não estruturados em chunks, fazendo embedding deles, e recuperando os chunks mais próximos no momento da consulta. É poderoso, mas é fundamentalmente uma busca sobre uma pilha estática. A pilha não aprende. Não reconcilia. Se dois documentos se contradizem, RAG felizmente recupera ambos e deixa o modelo resolver.

O LLM Wiki de Karpathy inverte o modelo: em vez de uma pilha estática que você pesquisa, você mantém um wiki vivo que o próprio modelo constrói e revisa. Novas informações não são simplesmente adicionadas — são integradas. O modelo atualiza a página de entidade relevante, revisa um resumo, e quando dados novos contradizem uma afirmação antiga, reconcilia a contradição em vez de armazenar ambas. A base de conhecimento é algo dinâmico e em evolução, e o modelo faz a maior parte da manutenção. Essa última parte é o desbloqueio: a razão pela qual wikis geralmente não escalam é que humanos precisam mantê-los. Um agente que mantém seu próprio wiki remove o gargalo.

Você pode ver o log.md do OKF e o design de conceito por arquivo como o formato em disco para exatamente essa visão. Um arquivo de conceito é uma página de entidade. O log é o histórico de revisões. A estrutura é deliberadamente simples o suficiente para que um agente não apenas possa lê-la, mas também escrevê-la — abrir um conceito, revisar uma afirmação, adicionar ao log, salvar. Isso é um grafo de conhecimento vivo que uma máquina pode realmente manter atualizado.

Tenho perseguido uma versão caseira disso há um tempo usando Obsidian como armazenamento e Claude como mantenedor — escrevi todo esse experimento no meu setup de memória persistente com Obsidian + Claude Code e um deep-dive relacionado sobre construir uma base de conhecimento RAG ao estilo Karpathy no Obsidian. A contribuição do OKF não é uma nova ideia sobre isso. É uma forma compartilhada. A razão pela qual um padrão importa aqui é interoperabilidade: se meu agente e seu agente ambos falam OKF, meu pacote de onboarding poderia ser lido pelo seu agente sem tradução alguma. O que leva à parte que é ou a mais empolgante ou a mais sobre-prometida, dependendo do seu ceticismo.

Otimização de busca agêntica e conhecimento vendável

Aqui é onde os anúncios ficam barulhentos, então aqui é onde serei cuidadoso. Duas grandes afirmações viajam com o OKF, e ambas são direções plausíveis em vez de realidades atuais. Separarei o mecanismo do marketing.

Afirmação um: OKF reformula SEO em "otimização de busca agêntica." A lógica: à medida que agentes de IA cada vez mais mediam entre pessoas e informação, o objetivo muda de ser encontrável por um crawler de busca para ser utilizável por um agente. Em vez de otimizar uma página para que um humano clique nela, você publica conhecimento para que um agente possa lê-lo, citá-lo e agir sobre ele diretamente. Quando o próprio Google começa a descrever seu conteúdo como "contexto a ser servido para agentes," servi-lo na forma que o Google descreve é uma proteção racional.

Acho que a direção é real. A execução não está comprovada. Não há, em meados de 2026, nenhum mecanismo confirmado pelo qual publicar um pacote OKF melhore sua visibilidade nas superfícies mediadas por agentes do Google. O Google lançou um formato; não entregou — nem prometeu — um benefício de ranking por usá-lo. Trate qualquer um que venda "OKF para rankings" com a mesma suspeita que teria com alguém que lhe vendeu uma tag meta keyword. A jogada honesta é: OKF torna seu conhecimento mais limpo e mais utilizável para qualquer agente que o leia, e isso é uma aposta defensável por seus próprios méritos, independentemente de o Google alguma vez recompensá-lo.

Afirmação dois: pessoas empacotar e venderão pacotes de conhecimento OKF. Um advogado vende um pacote de playbooks jurídicos curados. Um contador vende conceitos de estratégia tributária. Um SEO vende um pacote de heurísticas de ranking. Uma empresa compra esses e os monta no contexto de seus próprios agentes. Como um pacote é apenas um tarball de markdown, é trivialmente enviável, hospedável em qualquer repositório git, e licenciável como qualquer produto digital.

Essa acho mais convincente, porque o mecanismo é sólido — um pacote genuinamente é uma unidade portátil e autocontida de expertise, e há demanda real por contexto curado que agentes possam consumir. Mas é um mercado que ainda não existe, não algo acontecendo em escala hoje. A mesma fricção que torna bons pacotes difíceis de gerar (extração de conceitos, consistência, manter o log honesto) torna bons pacotes vendáveis ainda mais difíceis, porque agora qualidade é uma feature do produto. Apostaria que esse mercado emerge. Não apostaria no cronograma, e seria cético em relação à primeira onda de "pacotes de expertise" da mesma forma que sou cético em relação a qualquer primeira onda.

Então, onde isso deixa um construtor agora? Com um movimento claro e de baixo risco e muita paciência para o resto.

O que eu realmente faria com OKF hoje

Deixe-me tornar isso concreto, porque "experimente" é o tipo de conselho que soa bem e não muda nada. Aqui está a sequência específica que eu executaria, e o que esperar de cada passo.

1. Leia a especificação real, não os resumos. A OKF SPEC.md no GitHub é curta e legível em quinze minutos. Todo resumo de segunda mão (incluindo este) perde fidelidade. A fonte é a fonte.

2. Construa um pacote de cinco arquivos manualmente. Escolha um pedaço real do seu próprio conhecimento — seus processos, sua documentação de produto, suas heurísticas duramente conquistadas. Escreva cinco arquivos de conceito, um index.md, e um log.md. Não use uma ferramenta. A fricção é a educação. Você aprenderá mais sobre sua própria estrutura de conhecimento em vinte minutos do que um gerador jamais lhe dirá.

3. Abra nas ferramentas que você já usa. Coloque a pasta no Obsidian, envie para um repositório GitHub, cole um arquivo no Notion. Confirme por si mesmo que "amigável para humanos" se sustenta. Essa é a propriedade que torna o OKF seguro para adotar: no pior caso, você escreveu um markdown bem organizado, que tem valor com ou sem qualquer agente.

4. Aponte um agente para o pacote e faça uma pergunta. Dê ao Claude ou Gemini a pasta e pergunte algo que apenas um conceito possa responder. Observe se ele usa o índice para navegar. Esse é o momento em que o OKF para de ser abstrato — quando você vê um agente inspecionar o mapa e abrir exatamente o arquivo certo, o design faz sentido.

5. Escreva seu vocabulário de type como seu próprio conceito. Esse é o hábito individual de maior alavancagem. A liberdade da especificação quanto a tipos é uma faca de dois gumes; os pacotes que envelhecem bem são os que têm um sistema de tipos deliberado e documentado. Tome essa decisão uma vez, de propósito, e faça referência a ela.

O que eu não faria hoje: reestruturar toda minha operação de conteúdo em torno do OKF, pagar por serviços de "OKF SEO", ou tratar a v0.1 como um padrão finalizado. O próprio Google chamou a v0.1 de ponto de partida, não uma especificação finalizada. Construir sobre ela é inteligente; apostar seu negócio na sua forma atual não é.

Perguntas frequentes

O que é o Open Knowledge Format (OKF)?

O Open Knowledge Format é uma especificação aberta e independente de fornecedores do Google Cloud, publicada como v0.1 em 12 de junho de 2026, para armazenar conhecimento como um diretório de arquivos markdown com YAML front matter — legível tanto por humanos quanto por agentes de IA. Cada arquivo representa um conceito e deve declarar um campo type. Para a explicação completa da estrutura, veja a seção de pacotes acima.

Como o OKF difere do llms.txt?

OKF e llms.txt operam em camadas diferentes: llms.txt é um arquivo de descoberta que aponta agentes para seus recursos importantes, enquanto o OKF entrega o conhecimento curado em si como documentos markdown no nível de conceito. llms.txt é o cardápio; OKF é a comida. São complementares, e pacotes OKF provavelmente serão sinalizados via um ponteiro estilo llms.txt no futuro.

O OKF é um fator de ranking SEO?

Não — em meados de 2026, o Google não anunciou nenhum benefício de ranking por publicar pacotes OKF. O OKF torna seu conhecimento mais limpo e mais utilizável para agentes de IA que o leem, o que é uma razão defensável para adotá-lo, mas trate qualquer afirmação de que o OKF melhora diretamente rankings com ceticismo. Veja a seção de busca agêntica acima para a ressalva completa.

Que ferramentas posso usar para criar pacotes OKF?

Você pode escrever pacotes OKF manualmente em qualquer editor de texto, já que são apenas markdown mais YAML. Geradores comunitários como o OKF Bundle Generator do Suganthan podem converter um site em um pacote básico, mas atualmente produzem um conceito por página em vez de verdadeira extração de conceitos — o ferramental mais valioso para decompor conteúdo em conceitos limpos ainda não foi construído.

O que é o LLM Wiki de Karpathy e como se relaciona com o OKF?

O LLM Wiki é o conceito de Andrej Karpathy de uma base de conhecimento viva que um modelo de IA constrói e mantém por conta própria — integrando novas informações, revisando afirmações e reconciliando contradições, em vez de pesquisar uma pilha estática como RAG tradicional. O OKF é essencialmente o formato de arquivo em disco para essa visão, com arquivos de conceito como páginas de entidade e um arquivo de log como histórico de revisões.

A verdadeira razão pela qual estou feliz por não ter ignorado

Entrei esperando mais uma especificação para arquivar em "interessante, nunca usado." Saí tendo mudado como armazeno meu próprio conhecimento — não porque o OKF está finalizado, mas porque apontou para algo verdadeiro.

O que ele acerta é humilde: conhecimento para agentes deveria ser curado, atomizado e entregue, não scrapeado, dividido em chunks e engenheirado ao reverso. Isso é correto independentemente de o formato específico do Google vencer. O pacote que construí manualmente sobreviverá qualquer previsão sobre a adoção do OKF, porque é simplesmente markdown bem estruturado que agora entendo melhor do que esta manhã.

Então aqui está a única coisa que realmente pediria que você fizesse antes desta semana acabar: abra uma pasta, escreva cinco arquivos de conceito sobre algo que você conhece profundamente, adicione um índice, e aponte um agente para ela. Vinte minutos. Então forme seu próprio julgamento sobre se o futuro é uma pasta. O meu é que o formato quase certamente evoluirá além da v0.1 — mas a forma que ele descreve, conhecimento como conceitos que um agente pode ler e manter, é a direção para a qual tudo já está se movendo. Melhor aprender a forma agora do que scrapear seu caminho até ela depois.

Vamos trabalhar juntos

Procurando construir sistemas de IA, automatizar workflows, ou escalar sua infraestrutura tecnológica? Adoraria ajudar.

• Fiverr (construções personalizadas e integrações): fiverr.com/s/EgxYmWD
• Portfólio: mejba.me
• Ramlit Limited (soluções empresariais): ramlit.com
• ColorPark (design e branding): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io