Che cos'è l'Open Knowledge Format (OKF)? Lo standard Markdown di Google per gli agenti IA

Il 12 giugno 2026, il team data di Google Cloud ha pubblicato l’Open Knowledge Format (OKF), una specifica aperta per rappresentare un corpo di conoscenza come una directory di file Markdown. Nessun nuovo prodotto, nessun SaaS, nessun SDK: ed è esattamente ciò che lo rende interessante. In un’epoca in cui ogni fornitore cerca di rinchiuderti nella sua piattaforma, Google pubblica un formato che nessuno possiede: Markdown, file, punto.

Questo articolo spiega che cos’è l’OKF, com’è strutturato, perché arriva proprio al momento giusto per gli agenti IA, e che cosa lo distingue da un knowledge graph o da uno strumento come NotebookLM.

Il problema che l’OKF cerca di risolvere

Quando un agente IA deve rispondere a una domanda di business («calcola gli utenti attivi settimanali»), assembla la sua risposta a partire da fonti frammentate: un catalogo di metadati qui, un wiki là, commenti nel codice, una definizione di metrica in un foglio di calcolo. Ogni agente reinventa questo lavoro di raccolta, e ogni organizzazione lo struttura in modo diverso.

L’OKF formalizza uno schema già emergente che Google chiama il pattern «LLM-wiki»: una biblioteca di conoscenza curata, scritta una volta, che qualsiasi agente può consultare. L’idea centrale è separare nettamente il produttore dal consumatore: chi scrive il sapere non deve sapere chi lo leggerà, e viceversa (Google Cloud Blog, How the Open Knowledge Format can improve data sharing).

La struttura: solo file, solo Markdown

Un bundle OKF è una directory di file Markdown, organizzati per concetto. Un concetto è tutto ciò che vuoi catturare: una tabella, un dataset, una metrica, un runbook, un’API, un personaggio di romanzo. La regola fondante: il percorso del file è l’identità del concetto.

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

Ne derivano tre proprietà, ed è tutto ciò che fa l’OKF:

• Solo Markdown: leggibile in qualsiasi editor, renderizzato su GitHub, indicizzabile da qualsiasi strumento di ricerca.
• Solo file: consegnabile come tarball, ospitabile in un repository git, montabile su un filesystem.
• Solo frontmatter YAML: per i pochi campi strutturati che si vogliono poter interrogare.

Nessuna compressione esotica, nessun runtime, nessun database. Se sai scrivere un file .md, sai produrre OKF.

Il frontmatter: un solo campo obbligatorio

Ogni documento di concetto porta un frontmatter YAML in testa. E qui l’OKF fa una scelta radicale di semplicità: un solo campo è richiesto:

---
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: l’unico campo obbligatorio. Descrive la natura del concetto (tabella, metrica, personaggio, endpoint…). È ciò che permette a un agente di sapere cosa sta leggendo senza indovinare.
• title, description, resource, tags, timestamp: campi standard opzionali. resource punta alla risorsa reale (URL), timestamp data l’ultimo aggiornamento in ISO 8601.

Oltre a questi campi, i produttori definiscono i propri. La specifica non detta né i tipi disponibili, né il modello di contenuto, né le sezioni del corpo. È, nelle parole di Google, «minimamente opinata».

I link incrociati: un grafo con normali link Markdown

È l’elemento che trasforma una cartella di file in una base di conoscenza. I concetti si collegano tra loro con semplici link Markdown:

| `customer_id` | STRING | Chiave esterna verso [customers](/tables/customers.md). |

Unita con [customers](/tables/customers.md) su `customer_id`.

Il risultato è un grafo di relazioni più ricco della semplice gerarchia padre/figlio del filesystem. Un agente che legge orders.md scopre, seguendo il link, che esiste una tabella customers e come si uniscono, senza che nessuno glielo abbia dovuto spiegare nel prompt.

I file riservati: index.md e log.md

La specifica riserva due nomi di file, entrambi opzionali:

• index.md: consente una divulgazione progressiva. Man mano che un agente scende nella gerarchia, l’index.md di ogni cartella gli dà una visione d’insieme prima di immergersi nei singoli concetti.
• log.md: una cronologia dei cambiamenti apportati ai concetti.

La specifica completa, criteri di conformità, regole di collegamento incrociato e nomi riservati compresi, sta su una sola pagina (specifica ufficiale, GoogleCloudPlatform/knowledge-catalog).

«Format, not platform»

È il principio guida, e merita di soffermarsi. Google insiste: l’OKF è vendor-neutral. Nessun account proprietario, nessun cloud imposto, nessun SDK richiesto. Un bundle OKF:

• sopravvive allo spostamento tra sistemi, organizzazioni e strumenti;
• si versiona con git, accanto al codice che descrive;
• è leggibile da umani e macchine nello stesso file, senza strato di traduzione.

Google fornisce inoltre implementazioni di riferimento per avviare l’ecosistema: un enrichment agent che percorre database BigQuery per generare OKF arricchito da un LLM, un visualizzatore HTML statico (un singolo file autonomo, senza backend) che rende un bundle come un sito navigabile, e bundle di esempio (GA4 e-commerce, Stack Overflow, Bitcoin).

OKF, knowledge graph, NotebookLM: tre cose diverse

La confusione è frequente. Sbrogliamola.

OKF vs knowledge graph

Un knowledge graph è un modello di dati astratto: entità e relazioni, spesso memorizzate in un database a grafo (triple RDF, proprietà, ecc.). L’OKF è un formato di file concreto che può esprimere relazioni tramite link Markdown. Uno è una teoria del dato, l’altro è un modo di scriverlo su disco. Si può serializzare parte di un knowledge graph in OKF, ma non sono gli stessi oggetti.

OKF vs NotebookLM (o qualsiasi altra applicazione)

NotebookLM è un’applicazione: carichi documenti, poni domande nella sua interfaccia, e tutto resta da Google. L’OKF è un formato: definisce come strutturare i file affinché qualsiasi strumento possa leggerli.

Queste due cose sono ortogonali. Puoi benissimo depositare un bundle OKF dentro NotebookLM. Ma puoi anche darlo a Claude, a GPT, a un agente fatto in casa, a uno script Python, senza restare rinchiuso in una piattaforma. La vera domanda è: vuoi una sessione di domande e risposte interattiva (un’applicazione lo fa bene), o una base di conoscenza portabile e programmatica che gli agenti possano percorrere, che versioni con git, e che viva accanto al tuo codice o ai tuoi testi? L’OKF risponde alla seconda.

Il momento giusto, il giusto livello di ambizione

L’OKF arriva precisamente dove se ne sente il bisogno: agenti IA ovunque, e da nessuna parte un modo semplice per dar loro contesto curato. Google ha scelto di pubblicare presto e leggero, una specifica di una pagina anziché un comitato di standardizzazione di tre anni, ed è una buona notizia. Il formato è già utilizzabile oggi, e progettato per crescere in modo pulito:

• Il catalogo dei type, libero per impostazione predefinita, lascia che ogni dominio inventi il proprio vocabolario prima che le convenzioni più utili si impongano da sole.
• L’interoperabilità è la promessa centrale: un wiki scritto da uno, consumato da un altro senza traduttore. È esattamente ciò che rende possibile un formato di file nudo.
• Il versionamento della specifica è pensato fin dall’inizio per restare retrocompatibile.

In breve

• OKF = una directory di file Markdown + frontmatter YAML, pubblicata da Google Cloud il 12 giugno 2026 per dare contesto curato agli agenti IA.
• Un solo campo obbligatorio: type. Il resto (title, description, resource, tags, timestamp) è opzionale; i produttori aggiungono i propri campi.
• I concetti si collegano tramite semplici link Markdown, formando un grafo. File riservati opzionali: index.md, log.md.
• Formato, non piattaforma: nessun SDK, versionabile in git, leggibile da umani e macchine.
• Diverso da un knowledge graph (modello astratto) e da un’applicazione come NotebookLM (piattaforma): è un formato portabile da uno strumento all’altro.

L’OKF sposta la domanda da «quale strumento consuma il mio sapere?» a «il mio sapere è scritto in un formato che qualsiasi strumento può leggere?». E poiché quel formato non è altro che Markdown ben ordinato, qualsiasi editor Markdown, come Draft_, può già servire a produrlo.