O que é o Open Knowledge Format (OKF)? O padrão Markdown da Google para agentes de IA

Em 12 de junho de 2026, a equipa de dados do Google Cloud publicou o Open Knowledge Format (OKF), uma especificação aberta para representar um corpo de conhecimento como um diretório de ficheiros Markdown. Sem novo produto, sem SaaS, sem SDK: e é exatamente isso que o torna interessante. Numa altura em que cada fornecedor tenta fechar-te na sua plataforma, a Google publica um formato que ninguém possui: Markdown, ficheiros, ponto final.

Este artigo explica o que é o OKF, como está estruturado, porque chega no momento certo para os agentes de IA, e o que o distingue de um grafo de conhecimento ou de uma ferramenta como o NotebookLM.

O problema que o OKF procura resolver

Quando um agente de IA tem de responder a uma pergunta de negócio («calcula os utilizadores ativos semanais»), monta a sua resposta a partir de fontes fragmentadas: um catálogo de metadados aqui, um wiki ali, comentários no código, uma definição de métrica numa folha de cálculo. Cada agente reinventa este trabalho de recolha, e cada organização estrutura-o de forma diferente.

O OKF formaliza um esquema já emergente que a Google chama o padrão «LLM-wiki»: uma biblioteca de conhecimento curada, escrita uma vez, que qualquer agente pode consultar. A ideia central é separar limpamente o produtor do consumidor: quem escreve o saber não tem de saber quem o vai ler, e vice-versa (Google Cloud Blog, How the Open Knowledge Format can improve data sharing).

A estrutura: só ficheiros, só Markdown

Um bundle OKF é um diretório de ficheiros Markdown, organizados por conceito. Um conceito é tudo o que quiseres capturar: uma tabela, um conjunto de dados, uma métrica, um runbook, uma API, uma personagem de romance. A regra fundadora: o caminho do ficheiro é a identidade do conceito.

sales/
├── index.md
├── datasets/
│   ├── index.md
│   └── orders_db.md
├── tables/
│   ├── index.md
│   ├── orders.md
│   └── customers.md
└── metrics/
    ├── index.md
    └── weekly_active_users.md

Daí decorrem três propriedades, e é tudo o que faz o OKF:

Só Markdown: legível em qualquer editor, renderizado no GitHub, indexável por qualquer ferramenta de pesquisa.
Só ficheiros: entregável como tarball, alojável num repositório git, montável num sistema de ficheiros.
Só frontmatter YAML: para os poucos campos estruturados que se querem poder consultar.

Sem compressão exótica, sem runtime, sem base de dados. Se sabes escrever um ficheiro .md, sabes produzir OKF.

O frontmatter: um único campo obrigatório

Cada documento de conceito traz um frontmatter YAML no cabeçalho. E aqui o OKF faz uma escolha radical de simplicidade: um único campo é obrigatório:

---
type: BigQuery Table
title: Orders
description: One row per completed customer order.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, revenue]
timestamp: 2026-05-28T14:30:00Z
---

type: o único campo obrigatório. Descreve a natureza do conceito (tabela, métrica, personagem, endpoint…). É o que permite a um agente saber o que está a ler sem adivinhar.
title, description, resource, tags, timestamp: campos padrão opcionais. resource aponta para o recurso real (URL), timestamp data a última atualização em ISO 8601.

Para além destes campos, os produtores definem os seus. A especificação não dita nem os tipos disponíveis, nem o modelo de conteúdo, nem as secções do corpo. É, nas palavras da Google, «minimamente opinativa».

As ligações cruzadas: um grafo com ligações Markdown comuns

É o elemento que transforma uma pasta de ficheiros numa base de conhecimento. Os conceitos ligam-se entre si com simples ligações Markdown:

| `customer_id` | STRING | Chave estrangeira para [customers](/tables/customers.md). |

Juntada com [customers](/tables/customers.md) por `customer_id`.

O resultado é um grafo de relações mais rico do que a simples hierarquia pai/filho do sistema de ficheiros. Um agente que lê orders.md descobre, seguindo a ligação, que existe uma tabela customers e como se juntam, sem que ninguém lho tenha tido de explicar no prompt.

Os ficheiros reservados: `index.md` e `log.md`

A especificação reserva dois nomes de ficheiro, ambos opcionais:

index.md: permite uma divulgação progressiva. À medida que um agente desce na hierarquia, o index.md de cada pasta dá-lhe uma visão de conjunto antes de mergulhar nos conceitos individuais.
log.md: um histórico cronológico das alterações feitas aos conceitos.

A especificação completa, critérios de conformidade, regras de ligação cruzada e nomes reservados incluídos, cabe numa única página (especificação oficial, GoogleCloudPlatform/knowledge-catalog).

«Format, not platform»

É o princípio orientador, e merece que nos detenhamos. A Google insiste: o OKF é vendor-neutral. Sem conta proprietária, sem cloud imposta, sem SDK obrigatório. Um bundle OKF:

sobrevive à mudança entre sistemas, organizações e ferramentas;
versiona-se com git, ao lado do código que descreve;
é legível por humanos e máquinas no mesmo ficheiro, sem camada de tradução.

A Google fornece ainda implementações de referência para arrancar o ecossistema: um enrichment agent que percorre bases de dados BigQuery para gerar OKF enriquecido por um LLM, um visualizador HTML estático (um único ficheiro autónomo, sem backend) que renderiza um bundle como um site navegável, e bundles de exemplo (GA4 e-commerce, Stack Overflow, Bitcoin).

OKF, grafo de conhecimento, NotebookLM: três coisas diferentes

A confusão é frequente. Desenredemos.

OKF vs grafo de conhecimento

Um grafo de conhecimento é um modelo de dados abstrato: entidades e relações, muitas vezes armazenadas numa base de dados de grafos (triplos RDF, propriedades, etc.). O OKF é um formato de ficheiros concreto que pode exprimir relações através de ligações Markdown. Um é uma teoria do dado, o outro é uma maneira de o escrever em disco. Pode-se serializar parte de um grafo de conhecimento em OKF, mas não são os mesmos objetos.

OKF vs NotebookLM (ou qualquer outra aplicação)

O NotebookLM é uma aplicação: carregas documentos, fazes perguntas na sua interface, e tudo fica na Google. O OKF é um formato: define como estruturar ficheiros para que qualquer ferramenta os possa ler.

Estas duas coisas são ortogonais. Podes perfeitamente depositar um bundle OKF dentro do NotebookLM. Mas também o podes dar ao Claude, ao GPT, a um agente caseiro, a um script Python, sem ficares fechado numa plataforma. A verdadeira pergunta é: queres uma sessão de perguntas e respostas interativa (uma aplicação fá-lo bem), ou uma base de conhecimento portátil e programática que os agentes possam percorrer, que versionas com git, e que vive ao lado do teu código ou dos teus textos? O OKF responde à segunda.

O momento certo, o nível de ambição certo

O OKF chega precisamente onde a necessidade se faz sentir: agentes de IA por toda a parte, e em lado nenhum uma forma simples de lhes dar contexto curado. A Google escolheu publicar cedo e leve, uma especificação de uma página em vez de um comité de normalização de três anos, e é uma boa notícia. O formato já é utilizável hoje, e concebido para crescer de forma limpa:

O catálogo dos type, livre por omissão, deixa cada domínio inventar o seu vocabulário antes de as convenções mais úteis se imporem por si.
A interoperabilidade é a promessa central: um wiki escrito por um, consumido por outro sem tradutor. É exatamente o que torna possível um formato de ficheiros nu.
O versionamento da especificação está pensado desde o início para continuar retrocompatível.

Em resumo

OKF = um diretório de ficheiros Markdown + frontmatter YAML, publicado pelo Google Cloud em 12 de junho de 2026 para dar contexto curado aos agentes de IA.
Um único campo obrigatório: type. O resto (title, description, resource, tags, timestamp) é opcional; os produtores acrescentam os seus próprios campos.
Os conceitos ligam-se através de simples ligações Markdown, formando um grafo. Ficheiros reservados opcionais: index.md, log.md.
Formato, não plataforma: sem SDK, versionável em git, legível por humanos e máquinas.
Diferente de um grafo de conhecimento (modelo abstrato) e de uma aplicação como o NotebookLM (plataforma): é um formato portátil de uma ferramenta para outra.

O OKF desloca a pergunta de «que ferramenta consome o meu saber?» para «está o meu saber escrito num formato que qualquer ferramenta possa ler?». E uma vez que esse formato não é mais do que Markdown bem arrumado, qualquer editor Markdown, como o Draft_, já pode servir para o produzir.