Open Knowledge Format: il Markdown di Google per gli agenti

Il 12 giugno 2026, Google Cloud ha pubblicato una specifica su come gli agenti AI dovrebbero leggere e scambiare conoscenza curata. Ti aspetteresti un database a grafo, un registro di schemi, un SDK e un servizio per farlo girare.

Invece, l’Open Knowledge Format è questo: una cartella di file Markdown con frontmatter YAML.

Questo è tutto il formato. Ed è proprio questa sobrietà la parte interessante.

Lo Spec È Più Piccolo di Quanto Pensi

La maggior parte di chi ha scritto di OKF si è limitata a riassumere l’annuncio. Vale la pena leggere la spec originale, perché la superficie del formato è sorprendentemente ridotta.

OKF v0.1 richiede esattamente un campo su ogni documento di concetto:

---
type: BigQuery Table
---

Tutto qui. type è una stringa breve che identifica il tipo di concetto descritto dal documento, usata per instradamento e filtraggio. I valori non sono registrati centralmente — non esiste un comitato che approva la lista dei tipi validi. I produttori scelgono descrittori autoesplicativi e vanno avanti.

Altri cinque campi sono consigliati, nessuno obbligatorio:

CampoScopo
titleNome visualizzato. I consumer possono derivarlo dal nome del file se assente.
descriptionRiepilogo in una frase.
resourceUn URI che identifica in modo univoco l’asset sottostante.
tagsUna lista YAML, per categorizzazione trasversale.
timestampData e ora ISO 8601 dell’ultima modifica.

I produttori possono aggiungere qualsiasi chiave personalizzata desiderino. I consumer devono preservare i campi sconosciuti invece di rifiutarli.

Un documento di concetto completo e conforme ha questo aspetto:

---
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, orders]
timestamp: 2026-05-28T00:00:00Z
---

# Schema

| Column | Type | Description |
|--------|------|-------------|
| order_id | STRING | Unique identifier |

Se hai mai scritto una nota in Obsidian con il frontmatter, hai già scritto qualcosa di molto vicino a un concetto OKF valido.

Il Knowledge Graph Senza un Database a Grafo

Ecco la decisione di design che vale la pena rubare, che tu adotti OKF o no.

Le relazioni tra concetti sono espresse come normali link Markdown. Non archi in un database. Non un blocco relationships: nel frontmatter. Solo link:

Each order references a [customer](/tables/customers.md).

I percorsi assoluti relativi al bundle (che iniziano con /) sono consigliati per stabilità; funzionano anche i normali percorsi relativi come ./other.md.

E poi la parte che fa funzionare tutto: il tipo di relazione è veicolato dal testo circostante, non dal link. “Each order references a customer” è l’etichetta dell’arco. Non c’è un’ontologia da mantenere, nessun vocabolario di predicati su cui mettersi d’accordo, perché il linguaggio naturale ne ha già uno e il consumer è un language model.

Un decennio di strumenti per knowledge graph è stato investito nel formalizzare i tipi di relazione perché le macchine potessero interpretarli. La scommessa di OKF è che tutto questo non sia più necessario — ora la macchina legge l’inglese.

Due Nomi di File Riservati

Solo due nomi di file hanno un significato speciale all’interno di un bundle:

  • index.md — un elenco della directory che abilita la progressive disclosure. Non porta frontmatter. Un agente legge prima l’indice e segue solo i link di cui ha bisogno, invece di caricare ogni concetto nel contesto.
  • log.md — una cronologia degli aggiornamenti in ordine cronologico, con intestazioni di data ISO 8601, dal più recente.

Ogni altro file .md è un documento di concetto. Un bundle finisce per somigliare a una normale cartella navigabile:

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

index.md è quello silenziosamente importante. È lo stesso istinto dietro un CLAUDE.md scritto bene: non riversare l’intera libreria nella finestra di contesto, dai all’agente un indice e lascia che vada a recuperare quello che gli serve.

Cosa OKF Non È

Non è RAG. Il RAG ri-deriva la conoscenza al momento della query recuperando chunk grezzi e sperando che quelli rilevanti emergano. Un bundle OKF conserva concetti curati e collegati tra loro, che un agente legge e aggiorna direttamente. La curation avviene una volta sola, deliberatamente, invece di essere approssimata a ogni query.

Non è AGENTS.md o CLAUDE.md. Quelli sono file di istruzioni — dicono a un agente come comportarsi in un repository. OKF descrive conoscenza di dominio: cosa significa questa tabella, come è definita questa metrica, perché questo dataset ha un buco a marzo. Compito diverso, complementare.

Non è MCP. MCP è un protocollo runtime per collegare un agente a sistemi live. OKF è un formato di file fermo su disco. È plausibile usarli entrambi: MCP per raggiungere il data warehouse, OKF per spiegare cosa contiene.

Le Regole di Conformità Sono Deliberatamente Permissive

Un bundle è conforme a OKF v0.1 se ogni file .md non riservato ha un frontmatter YAML analizzabile, ogni blocco di frontmatter ha un type non vuoto, e i file riservati seguono le loro strutture quando presenti.

Ancora più rivelatore è ciò che la spec vieta ai consumer di fare. Un consumer non deve rifiutare un bundle per campi opzionali mancanti, valori di type sconosciuti, chiavi sconosciute, cross-link rotti, o un index.md mancante.

È un formato progettato da persone che si aspettano bundle incompleti, generati in parte da macchine e in continuo cambiamento — che è esattamente l’aspetto reale delle knowledge base vere. I formati rigidi muoiono della propria rigidità. Questo è costruito per sopravvivere al contatto con una cartella disordinata.

Google ha rilasciato insieme alla spec anche degli strumenti di riferimento: un agente di arricchimento per BigQuery, un visualizzatore HTML statico e tre bundle di esempio.

Un avvertimento da dire chiaramente: OKF è v0.1, ed esplicitamente una bozza. La spec è versionata e progettata per una crescita retrocompatibile, ma i nomi dei campi e le convenzioni possono ancora cambiare. Non ricostruire oggi la tua knowledge base attorno a questo formato. Ma tieni d’occhio la direzione verso cui punta lo standard.

Perché Questo Conta Oltre Google Cloud

Togli di mezzo gli esempi su BigQuery e OKF è una scommessa dal raggio d’azione molto più ampio: che il formato duraturo per la conoscenza leggibile dalle macchine sia semplici file Markdown in una cartella che possiedi tu.

Non un catalogo proprietario con un’API. Non embedding in un vector store che non puoi leggere. Non un wiki con un pulsante di esportazione che ti rovina le tabelle. File. Su disco. Diffabili, greppabili, portabili tra vendor diversi, leggibili da un umano e da qualsiasi modello sul mercato.

È la stessa conclusione a cui sono arrivati indipendentemente Claude Code, Cursor, Copilot e Windsurf quando hanno scelto Markdown come formato per le loro istruzioni. Che Google Cloud l’abbia messo per iscritto in una spec è una conferma, non un’invenzione.

Dove Si Inserisce Minibase

Se mantieni un Minibase Vault, stai già gestendo qualcosa strutturalmente molto vicino a un bundle OKF: una cartella di file Markdown con frontmatter, sul tuo disco, letta da Claude e ChatGPT.

Renderlo formalmente conforme è una piccola modifica — aggiungi un type al tuo frontmatter, e lascia che siano i link a fare il resto:

---
type: Article
title: How the Open Knowledge Format can improve data sharing
resource: https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing/
tags: [okf, agents, markdown]
timestamp: 2026-07-19T00:00:00Z
---

Questa è la forma pratica di questo annuncio. La parte difficile di una knowledge base per agenti non è mai stata il formato del file — era farci entrare del buon materiale sorgente. Una specifica ti dice come dare forma alla cartella. Non la riempie.

Minibase è la parte che la riempie: un click trasforma qualsiasi pagina web — documentazione, un README di GitHub, una spec, un thread, un paper di ricerca — in Markdown pulito nella tua cartella, pronto per il prossimo agente che lanci.

Il formato è ormai uno standard. Quello che ci metti dentro resta il tuo vantaggio.


Minibase trasforma qualsiasi pagina web in Markdown pulito che i tuoi agenti possono leggere — installa l’estensione e inizia a costruire il bundle che rende i tuoi agenti più intelligenti.

Continue reading

Pronto a salvare in modo più intelligente?

Converti qualsiasi pagina web in Markdown con un clic.

Aggiungi a Chrome