Open Knowledge Format: Google quiere estandarizar cómo le damos contexto a la IA (y varios dicen que reinventó la wiki)

El 12 de junio de 2026, Google Cloud publicó el Open Knowledge Format (OKF), una especificación abierta que intenta resolver un problema que suena aburrido pero es carísimo: cómo darle a un agente de IA el contexto que necesita para no inventar. La propuesta es tan simple que da un poco de desconfianza —una carpeta de archivos Markdown con un encabezado YAML— y esa simpleza es, al mismo tiempo, su mayor virtud y el blanco de todas las críticas.

Vale la pena entender qué anuncian, porque detrás del formato aparentemente trivial hay una apuesta bastante ambiciosa sobre cómo van a compartir conocimiento las empresas en la era de los agentes.

El problema: el conocimiento vive en silos

En casi cualquier organización, lo que un modelo necesita saber está desparramado y encerrado en formatos incompatibles: catálogos de metadatos con APIs propietarias, wikis internas, comentarios de código, docstrings, celdas de notebooks y —el clásico— la cabeza de dos o tres ingenieros senior.

Cuando un agente tiene que responder algo tan concreto como “¿cómo calculo los usuarios activos semanales a partir del stream de eventos?”, tiene que ensamblar la respuesta juntando pedacitos de superficies que no se hablan entre sí. El resultado: cada equipo que arma un agente resuelve el mismo rompecabezas desde cero, y el conocimiento queda preso del sistema que lo generó. No hay portabilidad.

La propuesta: un formato, no una plataforma

La respuesta de Google no es “otro servicio de conocimiento en la nube” —y ese es el punto que más recalcan—. Es un formato. OKF v0.1 representa el conocimiento como:

• Solo Markdown: legible en cualquier editor, renderizable en GitHub, indexable por cualquier buscador.
• Solo archivos: se transporta como un tarball, se hospeda en cualquier repo git, se monta en cualquier filesystem.
• Solo frontmatter YAML: campos consultables como type, title, description, resource, tags y timestamp.

Cada “concepto” (una tabla, un dataset, una métrica, un runbook) es un archivo. La ruta del archivo es su identidad, y los links de Markdown entre archivos arman un grafo de relaciones. Un bundle típico se ve así:

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

Lo llamativo es lo poco que el estándar obliga: hay un solo campo obligatorio, type. Todo lo demás lo decide quien produce el contenido. La idea de diseño es separar limpiamente al que escribe el conocimiento del que lo consume: un humano puede escribir un bundle a mano y un agente leerlo; un pipeline puede exportarlo y un visualizador mostrarlo. El formato es el contrato; las herramientas son intercambiables.

Google acompañó el lanzamiento con implementaciones de referencia: un agente de enriquecimiento que recorre un dataset de BigQuery y genera un documento OKF por cada tabla, y un visualizador HTML estático que convierte cualquier bundle en un grafo interactivo sin backend. Además, actualizaron su Knowledge Catalog para ingerir y servir OKF a sus propios agentes. Todo está en el repo GoogleCloudPlatform/knowledge-catalog.

La idea no salió de la nada

El propio Google reconoce la deuda intelectual: el patrón “LLM-wiki” viene del gist de Andrej Karpathy. Su argumento es elegante:

“Los LLM no se aburren, no se olvidan de actualizar una referencia cruzada y pueden tocar 15 archivos de una sola pasada. La contabilidad tediosa que hace que los humanos abandonen sus wikis personales es exactamente en lo que los LLM son buenos.”

Traducido: las wikis siempre fueron una buena idea que se moría de mantenimiento. Con agentes que no se cansan de actualizar links, quizás por fin funcionen.

Qué opina la gente: “esto ya existía y se llamaba Obsidian”

Acá es donde se pone interesante. El anuncio recibió una dosis considerable de escepticismo en Hacker News y Reddit, y las críticas apuntan casi todas al mismo lado:

• “Reinventaron la wiki”: varios ingenieros señalaron que un directorio de Markdown no es ninguna novedad —y que esta versión tiene menos funciones que una wiki tradicional, solo que ahora pensada para que la lean agentes.
• “Es Obsidian con logo de Google”: un arquitecto lo comparó directamente con un vault de Obsidian rebautizado. Y no le falta razón: el propio Google admite que OKF formaliza prácticas que ya existen, como los vaults de Obsidian conectados a agentes, los archivos AGENTS.md / CLAUDE.md y los repos de “metadata as code”.
• La deuda de mantenimiento no desaparece: otros advirtieron que estos sistemas de conocimiento terminan igual —con context bloat, referencias obsoletas y definiciones inconsistentes de las mismas entidades. Delegar el mantenimiento a un LLM es una apuesta, no una garantía.

La defensa razonable es que la novedad no está en usar Markdown —eso lo hace todo el mundo— sino en acordar las convenciones mínimas para que esos archivos sean interoperables entre productos y organizaciones. Un vault de Obsidian tuyo no lo entiende mi agente; un bundle OKF, en teoría, sí. El valor de un formato no viene de quién lo inventa, sino de cuántos lo hablan.

Por qué mirarlo con atención (aunque seas escéptico)

Que la crítica del “ya existía” sea cierta no lo vuelve irrelevante. Casi todos los estándares que triunfaron formalizaron algo que ya se hacía de forma desprolija: HTTP, Markdown, JSON, el propio Git. El punto no es la originalidad técnica sino la coordinación.

OKF ataca un cuello de botella real: cómo versionar y empaquetar conocimiento complejo para que un agente lo consuma sin reventar su ventana de contexto. Que Google lo publique abierto desde el día uno, sin cuenta ni SDK propietario, es la única forma de que un formato así se gane el nombre. Falta ver si el resto de la industria decide hablarlo o si queda como una nota al pie más en la larga historia de las wikis que iban a cambiarlo todo.

Por ahora es v0.1: un punto de partida, no un estándar terminado. Lo interesante va a ser ver quién más lo adopta.