La guía definitiva al Open Knowledge Format (OKF) de Google • Antonio Rigó

El 12 de junio de 2026, Google Cloud publicó —casi en silencio para el ruido habitual del sector— una especificación que probablemente sea el cambio más importante del año para cualquier empresa que esté construyendo, alimentando o pensando en construir agentes de IA. Se llama Open Knowledge Format (OKF), viene firmada por Sam McVeety y Amir Hormati del equipo de Data Cloud, y formaliza un patrón que viene emergiendo desde hace un año en miles de equipos: el LLM Wiki¹.

Lo notable es lo poco notable que se ve. No es un nuevo SaaS. No es un schema gigantesco. Es —literalmente— un directorio de archivos Markdown con frontmatter YAML. Y sin embargo, si OKF tiene éxito como estándar, redefine cómo las empresas representan, comparten y mantienen el conocimiento que alimenta a sus sistemas de IA.

Este artículo es una guía completa: qué es OKF, de dónde viene, cómo funciona técnicamente, por qué se diseñó así, qué implica para tu empresa y para tu estrategia de contenido, y cómo empezar a implementarlo. Si en el artículo sobre Gemini Search y el fin de los 10 links azules hablamos del consumo de información por parte de los LLMs, este artículo trata del otro lado del problema: cómo se prepara y se sirve esa información.

En este artículo:

¿Qué es el Open Knowledge Format?

OKF es una especificación abierta, neutral respecto a proveedores, que define un formato común para representar conocimiento estructurado destinado a ser consumido tanto por humanos como por agentes de IA. La versión 0.1, publicada el 12 de junio de 2026, lo describe como un formato mínimo: un directorio de archivos Markdown con frontmatter YAML².

Sin embargo, esa simplicidad superficial esconde una ambición considerable. Lo que OKF intenta resolver no es un problema de almacenamiento, ni de búsqueda, ni de visualización. Es un problema de interoperabilidad del conocimiento. La premisa central: en una era donde cada equipo, cada vendor y cada agente de IA construye su propia versión de un «wiki para LLMs», lo que falta no es otra plataforma. Lo que falta es un formato.

Tres cualidades definen el diseño de OKF:

Es solo Markdown, legible en cualquier editor, renderizable en GitHub, indexable por cualquier herramienta de búsqueda.
Es solo archivos, distribuibles como tarball, alojables en cualquier repositorio git, montables en cualquier sistema de archivos.
Es solo frontmatter YAML, para el pequeño conjunto de campos estructurados que necesitan ser consultables: type, title, description, resource, tags, timestamp.

Si has trabajado con Obsidian, Notion, Hugo o cualquiera de los patrones de «LLM wiki» que emergieron durante el último año, la forma te resultará familiar. Lo que hace OKF es formalizar el pequeño conjunto de convenciones necesario para que esos patrones sean interoperables entre sí.

¿Cuál es el problema que OKF resuelve?

Para entender por qué OKF importa, hay que mirar primero qué se rompió. La promesa de los agentes de IA empresariales —»deja que el modelo conteste cualquier pregunta sobre tu negocio»— choca con una realidad: los modelos no son tontos, son ignorantes sobre tu organización en particular. Saben cómo es una factura en general, pero no saben cómo es la tuya. Saben qué es un funnel de marketing, pero no conocen tu definición específica de «lead calificado».

La información que un agente necesita para responder bien preguntas sobre tu negocio es abrumadoramente interna: el schema de una tabla, el significado preciso de una métrica, el runbook para resolver un incidente, los criterios de un descuento, la deprecación de una API antigua, los joins entre dos sistemas. Y hoy esa información vive en silos altamente fragmentados³:

Catálogos de metadatos, cada uno con su API
Wikis internos, sistemas de terceros o drives compartidos
Comentarios de código, docstrings o celdas de notebooks
Las cabezas de un puñado de ingenieros senior

Cuando un agente necesita responder «¿cómo calculamos los usuarios activos semanales desde nuestro event stream?», tiene que ensamblar la respuesta a partir de superficies dispersas y mutuamente incompatibles. Cada vendor ofrece su propio catálogo, su propio SDK, su propio esquema de knowledge graph, y nada del conocimiento es realmente portable entre productos u organizaciones.

El resultado es lo que el equipo de Google describe sin rodeos: cada constructor de agentes está resolviendo el mismo problema de ensamblaje de contexto desde cero, cada vendor de catálogos está reinventando los mismos modelos de datos, y el conocimiento queda atrapado en la superficie que lo creó.

Esto no es un problema solamente técnico. Es un problema de estrategia empresarial. Si decides cambiar de proveedor de cloud, ¿migra tu conocimiento? Si tu equipo de datos quiere alimentar un agente de Vertex AI hoy y uno de OpenAI mañana, ¿escribes el contexto dos veces? Si una empresa adquiere a otra, ¿cómo se fusionan dos catálogos de conocimiento? Hasta este momento, la respuesta a todas estas preguntas era: con dolor.

OKF apuesta a que la solución no es otro servicio. Es un formato. Y específicamente, un formato lo suficientemente simple y abierto como para que cualquiera pueda producirlo y cualquiera pueda consumirlo, sin SDK, sin integración propietaria, sin lock-in.

¿De dónde viene OKF? El patrón LLM Wiki de Karpathy

OKF no surgió de la nada. Formaliza un patrón que el ex-director de IA de Tesla y cofundador de OpenAI, Andrej Karpathy, articuló con extraordinaria claridad en un gist de GitHub publicado el 4 de abril de 2026⁴. El gist acumuló más de 5.000 stars en semanas y desencadenó docenas de implementaciones independientes que terminaron convergiendo en una arquitectura común.

La idea central de Karpathy es a la vez simple y subversiva. La mayoría de las interacciones actuales con LLMs sobre documentos siguen el patrón RAG (Retrieval-Augmented Generation): el modelo recupera trozos relevantes en cada consulta y genera la respuesta sobre la marcha. Funciona, pero el LLM está redescubriendo el conocimiento desde cero en cada pregunta. No hay acumulación. Pregúntale algo sutil que requiera sintetizar cinco documentos, y el modelo tiene que encontrar y unir los fragmentos cada vez. Nada se construye.

La propuesta de Karpathy es distinta: en lugar de solo recuperar desde documentos crudos en tiempo de consulta, el LLM mantiene incrementalmente un wiki persistente —una colección de archivos Markdown estructurados e interconectados, que vive entre tú y las fuentes crudas—. Cuando agregas una nueva fuente, el LLM no la indexa para recuperación futura: la lee, extrae lo relevante, y la integra en el wiki actualizando páginas de entidades, revisando síntesis, marcando contradicciones, fortaleciendo o desafiando la interpretación evolutiva. El conocimiento se compila una vez y luego se mantiene actualizado, no se re-deriva en cada consulta.

La frase clave de Karpathy es: «the wiki is a persistent, compounding artifact». El wiki es un artefacto que crece y se compone con el tiempo. Las referencias cruzadas ya están allí. Las contradicciones ya están marcadas. La síntesis ya refleja todo lo que se ha leído.

¿Por qué los humanos no hacen esto? Porque la parte tediosa no es leer ni pensar: es el bookkeeping. Mantener cross-references al día, asegurar consistencia entre páginas, marcar cuándo nuevos datos contradicen los viejos. Los humanos abandonan los wikis personales porque el costo de mantenimiento crece más rápido que el valor. En palabras de Karpathy: «LLMs don’t get bored, don’t forget to update a cross-reference». No se aburren, no olvidan actualizar una referencia cruzada, y pueden tocar 15 archivos en una sola pasada.

La arquitectura que propone Karpathy tiene tres capas:

Raw sources — la colección curada de documentos fuente. Inmutables. El LLM lee pero no modifica.
El wiki — un directorio de archivos Markdown generados por el LLM. El LLM es dueño absoluto de esta capa.
El schema — un documento (típicamente CLAUDE.md para Claude Code o AGENTS.md para otros agentes) que le dice al LLM cómo está estructurado el wiki y qué convenciones seguir.

Tres operaciones definen el ciclo de vida: ingest (leer una fuente nueva y actualizar el wiki), query (hacer preguntas que el LLM responde leyendo el wiki) y lint (revisar periódicamente la salud del wiki: contradicciones, páginas huérfanas, datos obsoletos).

El patrón apareció reiteradamente bajo otros nombres durante 2025-2026: vaults de Obsidian conectados a agentes de código, la familia de archivos convencionales AGENTS.md / CLAUDE.md, repositorios llenos de index.md y log.md que los agentes consultan antes de actuar, y la noción de «metadata as code» en equipos de datos. Pero cada instancia era artesanal e incompatible con las demás. El wiki de Karpathy, el wiki de tu equipo y el catálogo exportado por un vendor pueden lucir parecidos —Markdown, frontmatter, cross-links—, pero ninguno fue intencionalmente diseñado para cooperar con los otros.

Aquí entra OKF. La hipótesis es que el patrón ya funciona; lo que falta no es una mejor implementación, sino un acuerdo mínimo sobre qué campos lleva cada documento y qué significan ciertos nombres de archivo. Pin down lo suficiente para que dos wikis sean interoperables, deja todo lo demás libre.

¿Cómo funciona técnicamente OKF v0.1?

La especificación completa de OKF v0.1 cabe en una sola página y es deliberadamente minimalista. Lo más sorprendente al leerla por primera vez es cuán poco impone. A continuación, los elementos clave.

Estructura de un bundle

La unidad de distribución en OKF se llama knowledge bundle: una colección autocontenida y jerárquica de documentos de conocimiento. Un bundle es simplemente un árbol de directorios de archivos Markdown. La estructura es independiente del dominio; los productores organizan los conceptos como tenga sentido para el conocimiento que están capturando.

Un bundle puede distribuirse como:

Un repositorio git (recomendado: provee historia, atribución y diffs)
Un tarball o zip del directorio
Un subdirectorio dentro de un repo más grande

La estructura básica luce así:

path/to/bundle/
├── index.md                # Opcional. Listado para progressive disclosure.
├── log.md                  # Opcional. Historia cronológica de cambios.
├── <concept>.md            # Un concept a nivel raíz del bundle.
└── <subdirectory>/         # Subdirectorios agrupan concepts.
    ├── index.md
    ├── <concept>.md
    └── <subdirectory>/
        └── …

El documento concept: frontmatter + body

Cada archivo .md no reservado dentro del bundle es un concept —una unidad de conocimiento—. Un concept puede describir cualquier cosa: una tabla de base de datos, un endpoint de API, una métrica de negocio, un playbook de respuesta a incidentes, una idea abstracta, una decisión de producto. Su identidad es la ruta del archivo dentro del bundle (con el sufijo .md removido).

Todo concept tiene dos partes: un bloque de frontmatter YAML delimitado por ---, y un body Markdown libre.

El frontmatter es donde vive toda la imposición del estándar:

---
type: BigQuery Table              # REQUERIDO
title: Customer Orders
description: Una fila por orden completada.
resource: https://console.cloud.google.com/...
tags: [sales, revenue]
timestamp: 2026-05-28T14:30:00Z
---

Solo un campo es estrictamente obligatorio: type. Es un string corto que identifica la clase de concept (BigQuery Table, API Endpoint, Metric, Playbook, Reference, lo que sea). Los valores de type no están registrados centralmente. Los productores los eligen como les parezca descriptivo, y los consumidores deben tolerar tipos desconocidos sin romper (tratarlos como concepts genéricos).

Los campos recomendados —no obligatorios— son:

title: nombre humano para mostrar.
description: una oración resumen.
resource: URI canónica del activo subyacente (si lo hay).
tags: lista de etiquetas para categorización transversal.
timestamp: ISO 8601 del último cambio significativo.

Y los productores pueden agregar cualquier otro campo. Los consumidores deben preservarlos al round-tripping y no rechazar documentos por campos desconocidos.

El body es Markdown libre. La spec recomienda favorecer estructura —encabezados, listas, tablas, bloques de código— sobre prosa libre, porque ayuda tanto a la lectura humana como a la recuperación por agentes. Tres encabezados convencionales tienen significado especial cuando aplican:

# Schema: descripción estructurada de columnas/campos
# Examples: ejemplos concretos de uso
# Citations: fuentes externas que respaldan las afirmaciones del body

Cross-linking y la naturaleza de grafo

Los concepts se enlazan unos con otros mediante links Markdown estándar. No hay sintaxis especial, no hay wikilinks tipo [[entity]]. Solo [texto](ruta). Esto convierte al bundle, en su conjunto, en un grafo de relaciones más rico que la mera jerarquía parent/child que implica el filesystem.

Dos formas son soportadas:

Absolutos al bundle (recomendado): empiezan con /, interpretados relativos a la raíz del bundle. [customers](/tables/customers.md). Esto los hace estables cuando se mueven documentos.
Relativos: rutas Markdown estándar. [other](./other.md).

Un link de un concept A a un concept B asserta una relación. El tipo específico de relación (referencias, depende-de, joins-con, contradice) lo conduce la prosa circundante, no el link en sí. Los consumidores que construyen una vista de grafo típicamente tratan todos los links como aristas dirigidas de una relación sin tipar.

Una decisión deliberada del spec: los consumidores deben tolerar links rotos. Un enlace cuyo target no existe en el bundle no es malformado; puede simplemente representar conocimiento aún no escrito.

index.md, log.md y citaciones

Tres convenciones especiales merecen mención porque codifican el patrón de Karpathy en la spec:

index.md puede aparecer en cualquier directorio (incluida la raíz) y enumera el contenido del directorio para soportar progressive disclosure: permite a un humano o un agente ver qué hay disponible antes de abrir documentos individuales. No lleva frontmatter (con una excepción: el index.md de la raíz puede declarar okf_version: "0.1"). El body usa encabezados como agrupación lógica, con un bullet por concept enlazado y su descripción.

log.md registra la historia cronológica de cambios al directorio donde vive. El formato es una lista plana de entradas agrupadas por fecha (más reciente primero), con encabezados ISO 8601:

# Directory Update Log

## 2026-05-22
* **Update**: Added new BigQuery table reference...
* **Creation**: Established the Dataplex Playbook.

## 2026-05-15
* **Initialization**: Created foundational directory structure.

Citations son sources externos que respaldan afirmaciones en el body. Cuando un concept cita material externo, las fuentes deben listarse bajo un encabezado # Citations al final del documento, numeradas. Las citation links pueden ser URLs absolutas, rutas bundle-relativas, o rutas a un subdirectorio references/ que espeje material externo como concepts OKF de primera clase.

Conformidad

Un bundle es conformante con OKF v0.1 si:

Todo archivo .md no reservado en el árbol contiene un bloque de frontmatter YAML parseable.
Todo bloque de frontmatter contiene un campo type no vacío.
Los archivos reservados (index.md, log.md) siguen la estructura descrita cuando existen.

Eso es todo. El resto del spec es guía blanda. Y críticamente, los consumidores no deben rechazar un bundle por: campos opcionales faltantes, valores de type desconocidos, campos extra desconocidos, links rotos, index.md ausentes.

Este modelo permisivo es intencional. OKF está pensado para mantenerse útil a medida que los bundles crecen, se refactorizan y son parcialmente generados por agentes.

¿Cuáles son los principios de diseño detrás de OKF?

Tres principios atraviesan toda la spec. Vale la pena entenderlos porque explican por qué OKF se ve como se ve, y por qué probablemente lo veas adoptado en contextos muy lejanos al original de Google Cloud⁵.

1. Minimamente opinionado. OKF requiere exactamente una cosa de cada concept: un campo type. Todo lo demás —qué tipos existen, qué otros campos incluir, qué secciones tiene el body— queda librado al productor. El spec define la superficie de interoperabilidad, no el modelo de contenido. Esta es una decisión madura: los formatos que intentan estandarizar el contenido (Schema.org, OpenAPI) son útiles pero costosos de adoptar. Los que estandarizan la mínima superficie necesaria para interoperabilidad (HTML, Markdown, JSON) se adoptan masivamente.

2. Independencia productor/consumidor. OKF separa quién escribe el conocimiento de quién lo consume. Un bundle escrito a mano por un humano puede ser consumido por un agente de IA. Un bundle generado por un pipeline de exportación puede navegarse en un visualizador. Un bundle sintetizado por un LLM puede ser consultado por otro. El formato es el contrato; las herramientas en cada extremo son independientemente intercambiables.

Esto es lo que rompe el lock-in. Si tu organización mantiene su conocimiento en bundles OKF, puedes:

Cambiar de proveedor de cloud sin re-exportar nada
Alimentar agentes de OpenAI hoy y de Anthropic mañana
Fusionar bundles de dos empresas en una adquisición sin pipelines de transformación

3. Formato, no plataforma. OKF no está atado a ningún cloud, base de datos, proveedor de modelo o framework de agentes específico. Nunca requerirá una cuenta propietaria ni un SDK para leer, escribir o servir. Google publica el formato como estándar abierto porque, según ellos mismos lo admiten, el valor de un formato de conocimiento viene de cuántas partes lo hablan, no de quién lo posee.

Esto último merece subrayarse. Que Google publique una especificación abierta no es altruismo: es estrategia. Si OKF se convierte en el estándar de facto, los agentes de Google Cloud podrán consumir conocimiento de cualquier organización sin requerir migración. Pero el mismo beneficio aplica a cualquiera. El valor es multilateral, no unilateral.

¿Por qué OKF y no `llms.txt` o un schema propietario?

Esta pregunta es importante para cualquiera que haya seguido el debate sobre «optimización para LLMs» durante el último año. En el artículo sobre Gemini Search ya señalamos que Google es taxativo respecto a llms.txt: no lo necesitas, no lo usan, es marketing más que estándar.

OKF resuelve un problema distinto al que pretendía resolver llms.txt. Tres distinciones críticas:

llms.txt apunta a contenido público: es un archivo en la raíz de un sitio web que guía a los modelos hacia el contexto del sitio. OKF apunta a conocimiento estructurado interno que las organizaciones quieren que los agentes consuman, ya sea público o privado.
llms.txt es un archivo único: una lista de enlaces a documentación. OKF es un directorio de concepts tipados con relaciones explícitas, frontmatter, historia y citaciones.
llms.txt no es un estándar reconocido por Google. OKF es publicado y mantenido por Google Cloud, con compromiso explícito de seguir evolucionándolo en abierto.

Respecto a schemas propietarios (Dataplex, Unity Catalog, Atlan, Collibra), OKF no los reemplaza: los complementa. Cualquiera de esos catálogos puede exportar sus metadatos a un bundle OKF para alimentar agentes externos o intercambiar conocimiento entre equipos. Google ha actualizado su propio Knowledge Catalog para ingerir y servir bundles OKF, y se espera que otros vendors hagan lo mismo⁶.

Y respecto a Schema.org: OKF lo complementa. Schema.org define un vocabulario compartido de tipos y propiedades para datos en la web; OKF define una estructura de archivos y directorios y referencia esquemas externos en lugar de reemplazarlos⁷.

¿Qué implicaciones tiene OKF para marketers y empresas?

Aquí es donde la conversación se vuelve concreta. Si tu empresa no está construyendo agentes de IA hoy, ¿debería importarte OKF? La respuesta corta: sí, y por al menos cuatro razones.

1. Tu conocimiento empresarial se está volviendo un activo de IA. En los próximos 24 meses, prácticamente toda función corporativa va a tener agentes de IA que necesitan contexto: ventas, soporte, marketing, finanzas, RRHH, operaciones. La pregunta no es si tendrás conocimiento estructurado para alimentarlos, sino en qué formato lo tendrás. Si lo tienes en silos propietarios, vas a pagar el costo de migración varias veces. Si lo tienes en OKF, lo escribiste una vez.

2. Tu contenido de marketing se beneficia del mismo patrón. Si publicas contenido editorial —artículos, casos de estudio, documentación técnica, guías— el formato OKF es trivialmente cercano a lo que ya tienes (Markdown con frontmatter). Adoptar la estructura formal te da: portabilidad entre headless CMS, ingesta limpia por agentes de IA externos cuando consulten tu contenido público, y la disciplina de mantener metadata consistente (type, tags, timestamp).

3. El equipo de datos se vuelve más estratégico. Tradicionalmente, el catálogo de datos era una herramienta de «compliance y gobierno» —importante, pero alejada del valor de negocio—. Con OKF y agentes alimentados por él, el catálogo se convierte en infraestructura de inteligencia: cuánto mejor esté documentado tu data warehouse en OKF, mejor responde tu agente preguntas de negocio.

4. El ecosistema producer/consumer va a explotar. Como pasó con HTTP, RSS, Markdown o JSON, formatos verdaderamente abiertos generan tooling rápido. Vamos a ver visualizadores, motores de búsqueda, agentes especializados, conectores entre OKF y herramientas existentes (Notion, Confluence, Obsidian, Slack). Estar temprano en ese ecosistema da ventaja.

Una nota específica para marketers de contenido: el patrón «knowledge as wiki» descrito por Karpathy y formalizado por OKF cambia la pregunta sobre estrategia editorial. Hasta ayer, la pregunta era «¿qué artículos publicamos este mes?». Mañana, la pregunta es «¿qué bundle de conocimiento mantenemos vivo y cómo lo alimentamos?». En lugar de un calendario editorial, un grafo de concepts que crece y se actualiza incrementalmente, con el LLM haciendo el bookkeeping. Es un cambio de paradigma editorial cuyo alcance todavía no se ha procesado en la industria.

¿Cómo se implementa OKF en la práctica?

Una de las virtudes prácticas de OKF es que la barrera de entrada es ridículamente baja. No hay que instalar nada. No hay que aprender una sintaxis nueva. Si puedes escribir Markdown, puedes producir OKF.

Una ruta razonable para una organización mediana:

Paso 1: Auditar lo que ya tienes en forma cercana a OKF. Probablemente más de lo que crees. Repositorios con README.md, vaults de Obsidian, exports de Notion en Markdown, documentación de APIs con frontmatter. La mayor parte ya es Markdown con metadata; solo le falta consistencia en los campos.

Paso 2: Definir un mínimo de type para tu dominio. No intentes diseñar la taxonomía completa de entrada. Empieza con cinco o seis tipos relevantes para tu caso: API Endpoint, Database Table, Metric, Playbook, Customer Profile, Product Feature. Los nombres no necesitan validación central; lo único que importa es que el productor y el consumidor del bundle los entiendan.

Paso 3: Establecer convenciones del body para cada type. Por ejemplo, para API Endpoint: secciones de # Schema, # Examples, # Errors, # Citations. Documentar esto en un archivo CONVENTIONS.md dentro del bundle.

Paso 4: Migrar un dominio piloto. Elegir uno donde el ROI sea visible: típicamente algo que alimente un agente concreto que ya existe o está por construirse. Por ejemplo, el catálogo de productos para un agente de soporte. Producir el bundle a mano, no automatizar de entrada.

Paso 5: Versionar en git. El bundle vive en un repo. Esto te da historial, diff, code review en los cambios de conocimiento, y la posibilidad de integrar checks automáticos (un linter de conformidad OKF, por ejemplo).

Paso 6: Conectar productores y consumidores. Una vez que tienes un bundle vivo, los pasos naturales son:

Escribir un agente de enriquecimiento que extienda y mantenga el bundle a partir de fuentes (similar al patrón de Karpathy).
Conectar un visualizador para que humanos navegen el grafo.
Apuntar un agente conversacional al bundle como su fuente primaria de contexto.

Paso 7: Iterar con lint. Periódicamente, ejecutar un proceso (asistido por LLM) que revise el bundle en busca de: contradicciones entre concepts, concepts huérfanos sin links entrantes, claims obsoletos contradichos por fuentes más nuevas, conceptos importantes mencionados pero sin página propia. Esto es exactamente lo que Karpathy describe como lint en su gist.

Una decisión arquitectónica que merece pensarse: ¿debe el bundle ser público o privado? Para conocimiento empresarial sensible (datos internos, runbooks, IP), un repo privado en GitHub/GitLab con acceso controlado. Para conocimiento que quieres que LLMs externos consuman (documentación pública de tu producto, base de conocimiento de soporte), un repo público. Nada en OKF impone una u otra.

¿Qué herramientas oficiales ofrece Google?

Junto con la spec, Google publicó implementaciones de referencia tanto del lado productor como del consumidor⁸.

Agente de enriquecimiento: un agente que recorre un dataset de BigQuery, redacta un concept document OKF para cada tabla y vista, y luego ejecuta una segunda pasada con LLM que crawlea documentación autoritativa y enriquece cada concept con citaciones, schemas y rutas de join.

Visualizador HTML estático: convierte cualquier bundle OKF en una vista de grafo interactiva en un único archivo HTML autocontenido. No requiere backend, no se instala nada del lado de quien lo visualiza, ningún dato sale de la página. Esto último es relevante para casos sensibles a privacidad o compliance.

Tres sample bundles listos para explorar: GA4 e-commerce, Stack Overflow y Bitcoin public datasets, producidos por el agente de referencia y commiteados al repo como ejemplos vivos de OKF conformante. Son útiles para entender cómo luce un bundle real, no solo el ejemplo mínimo de la spec.

Una aclaración importante: estas herramientas son proof of concept deliberados. El agente demuestra una manera de producir OKF; nada en el formato requiere un framework o LLM específico. El visualizador demuestra una manera de consumirlo; nada en el formato requiere HTML o vista de grafo. El equipo de Google esperaba —y deseaba— que el ecosistema de productores y consumidores creciera mucho más allá de lo que ellos publicaron.

Adicionalmente, Google actualizó su propio Knowledge Catalog para ingerir bundles OKF y servirlos a agentes de Google Cloud, lo que ofrece un camino enterprise para equipos que ya están en GCP⁹.

¿Qué no resuelve OKF? Limitaciones y preguntas abiertas

OKF v0.1 es explícitamente un punto de partida, no un estándar terminado. El propio equipo de Google lo señala así, e invita a la comunidad a contribuir con extensiones backward-compatible.

Hay cuestiones que la spec deja deliberadamente abiertas y que probablemente generen debate y extensiones en los próximos meses:

Relaciones tipadas: los links Markdown en OKF son untyped. Un link de A a B no dice si A «depende de» B, «contradice» B, «extiende» B o «supersede» B. Esto es adecuado para muchos dominios técnicos pero puede ser limitante en dominios donde la relación entre concepts es central (literatura, filosofía, investigación académica). Algunos comentaristas en la discusión del gist de Karpathy ya propusieron typed edges como extensión.
Vocabulario controlado de type: la decisión de no registrar tipos centralmente es liberadora pero puede llevar a fragmentación (BigQuery Table vs bigquery_table vs Table (BigQuery)). Es probable que emerjan convenciones de facto por dominio.
Concurrencia y merge: cuando múltiples agentes escriben sobre el mismo bundle, ¿cómo se resuelven conflictos? La spec confía en git, pero git merge resuelve conflictos textuales, no semánticos. Dos agentes que escriben el mismo hecho con palabras distintas producen un merge limpio pero duplicado.
Provenance y trust: el spec sugiere usar el bloque de Citations para fuentes externas, pero no estandariza cómo expresar nivel de confianza, atribución de quién agregó qué claim, ni cómo manejar claims contradictorios entre fuentes.
Multilingüismo: la spec asume un body en un solo lenguaje por concept. Para organizaciones multinacionales con conocimiento en varios idiomas, las convenciones no están especificadas.
Ingest a escala: con bundles que crecen a miles de concepts, la cuestión de cómo se organiza el árbol de directorios sin que se convierta en un cementerio no está resuelta. Los index.md ayudan pero no eliminan el problema.

Ninguna de estas limitaciones invalida OKF. Pero conviene ir con los ojos abiertos: estás adoptando un estándar joven, no uno maduro. La ventaja es la baja barrera de entrada; la contraparte es que vas a participar de la evolución del estándar en lugar de consumir uno estable.

¿Qué hacer ahora? Próximos pasos

Si has llegado hasta acá, ya tienes el mapa completo. Lo que queda es decisión y ejecución. Una ruta razonable según el rol que ocupes:

Si eres CTO o líder técnico: lee la spec completa (cabe en 20 minutos), corre el visualizador de referencia contra uno de los sample bundles, y piensa en qué dominio interno te daría más leverage tener documentado como bundle OKF. Empieza un piloto antes del Q3.

Si lideras un equipo de datos: el catálogo de tu data warehouse es el primer candidato natural. Hay un agente de referencia que lo hace por ti contra BigQuery. Si estás en otro warehouse, escribir un productor equivalente es un proyecto de una semana, no de un trimestre.

Si lideras marketing o contenido: piensa en cómo tu base de conocimiento editorial (artículos, casos de estudio, documentación de producto) podría estructurarse como bundle. La estructura misma te va a forzar a clarificar tipologías, descripciones y timestamps que mejoran el contenido independientemente de si lo consume un LLM.

Si construyes agentes de IA: empieza a consumir OKF en lugar de tu formato propietario. Cuanto antes hagas la transición, antes tu agente sirve a más fuentes de conocimiento sin reescritura.

Si eres consultor o estás en un rol asesor: este es el momento para entender OKF en profundidad. Va a ser una conversación recurrente con clientes en los próximos 12-18 meses, y la mayoría no va a saber de qué se trata.

Una nota final, y quizá la más importante. Lo que está pasando con OKF es parte de un patrón más amplio que vale la pena ver con claridad: el conocimiento empresarial deja de ser un activo pasivo (catálogos para compliance, documentación que nadie lee) para convertirse en infraestructura activa de inteligencia. Los agentes de IA son tan buenos como el contexto que se les da. OKF apuesta a que el contexto sea portable, abierto y mantenido por LLMs. Y a esa apuesta vale la pena prestarle atención, esté o no Google detrás.

El formato es la contribución. Las herramientas existirán o no, los vendors adoptarán o no. Pero la idea de que el conocimiento empresarial debe ser un grafo de archivos Markdown versionados en git, que humanos y agentes pueden leer y escribir indistintamente, es una idea con la fuerza suficiente para mantenerse incluso si la implementación específica de Google muere mañana. Y esa, al final, es probablemente la razón por la que OKF importa.

Introducing the Open Knowledge Format, Google Cloud Blog ↩︎
Open Knowledge Format SPEC.md v0.1, GoogleCloudPlatform/knowledge-catalog ↩︎
Introducing the Open Knowledge Format, Google Cloud Blog ↩︎
llm-wiki gist, Andrej Karpathy ↩︎
Introducing the Open Knowledge Format, Google Cloud Blog ↩︎
Google Cloud’s Open Knowledge Format turns scattered docs into Markdown files for AI agents, The Decoder ↩︎
Open Knowledge Format Grounding Page, Grounding Page ↩︎
Google Cloud Announces The Open Knowledge Format, Search Engine Journal ↩︎
Open Knowledge Format: Google AI Agent Standard, explainx.ai ↩︎