Open Knowledge Format de Google: una primera mirada desde la práctica

Open Knowledge Format de Google: una primera mirada desde la práctica a OKF

Casi lo ignoré. Otra especificación, otro acrónimo, otro comunicado de prensa sobre un "estándar independiente de proveedores" que aparecía en mi feed un viernes. Google Cloud publicó el Open Knowledge Format — OKF v0.1 — el 12 de junio de 2026, y mi primera reacción honesta fue encogerme de hombros. Hemos visto una docena de formatos que "cambian todo" llegar y desaparecer silenciosamente.

Luego abrí la especificación. Y me di cuenta de que todo el asunto son simplemente archivos markdown con unas pocas líneas de YAML arriba, agrupados en una carpeta. Sin SDK. Sin runtime. Sin esquema de compresión. Sin API que llamar. Un "paquete de conocimiento" en el Open Knowledge Format es, casi insultantemente, solo archivos que podrías escribir en un editor de texto.

Esa fue la parte que me hizo dejar de hacer scroll y crear una carpeta de prueba. Porque he pasado el último año construyendo flujos de trabajo con agentes, y lo único contra lo que sigo chocando es la misma pared: mis agentes son brillantes razonando y terribles recordando. Re-scrapean, re-resumen, re-derivan el mismo contexto en cada sesión. Si un formato tan tontamente simple pudiera darle a un agente un lugar limpio y estructurado para leer conocimiento — en vez de re-derivarlo de HTML crudo cada vez — eso vale una tarde.

Así que pasé esa tarde en ello. Construí un pequeño paquete a mano desde la especificación publicada, ejecuté mi propio sitio a través de un generador comunitario, y abrí el resultado en Obsidian para ver si la afirmación de "amigable para humanos" sobrevive al contacto con la realidad. Esto es lo que encontré — qué es realmente OKF, las partes que los anuncios aciertan, y la pila mucho mayor de cosas que son promesas orientadas al futuro en lugar de realidad entregada. Seré claro sobre qué es qué, porque la brecha entre ambos es donde vive la mayor parte del hype.

¿Qué es el Open Knowledge Format, realmente?

El Open Knowledge Format es una especificación abierta e independiente de proveedores de Google Cloud para almacenar conocimiento como un directorio de archivos markdown, cada uno con YAML front matter, diseñado para ser leído tanto por humanos como por agentes de IA. Eso es todo. Una oración lo cubre.

Quitando el lenguaje de los anuncios, OKF toma exactamente tres decisiones estructurales:

• El conocimiento es una carpeta de archivos markdown. Google llama a una carpeta un paquete de conocimiento. Es un directorio — posiblemente con subdirectorios — lleno de archivos .md.
• Cada archivo es un concepto. No una página web. No un documento completo. Una unidad discreta de conocimiento: un playbook, una definición de métrica, un runbook, una descripción de API, una entidad individual. La intuición de Karpathy de que el conocimiento debería atomizarse en páginas de conceptos en lugar de volcarse como documentos largos está incorporada directamente en el formato.
• Cada concepto declara un type. La especificación requiere exactamente un campo de front matter en cada archivo: type. Todo lo demás — title, description, resource, tags, timestamp — es recomendado pero opcional.

Aquí hay un archivo de concepto que escribí a mano para probar el formato, modelado a partir de uno de mis propios playbooks internos:

---
type: playbook
title: Client Onboarding Sequence
description: The exact steps I run when a new AI automation client signs.
tags: [onboarding, process, clients]
resource: https://mejba.me/onboarding
timestamp: 2026-06-18
---

# Client Onboarding Sequence

When a new client signs, I run these steps in order. Each one has a
trigger and a definition of done — agents reading this should treat the
"done" condition as the success check.

## 1. Access provisioning
Grant repo + cloud read access within 24h of signature...

## 2. Context capture call
A 45-minute recorded call. The recording becomes its own concept file...

Eso es un concepto OKF completo y válido según la especificación. Ninguna herramienta lo produjo. Lo escribí yo. Y aquí está la parte silenciosamente importante: se renderiza limpiamente en cualquier aplicación markdown donde lo probé — GitHub lo previsualizó, Obsidian indexó el front matter como propiedades, y encajaría en Notion sin problemas. El formato no te pide que adoptes nada. Describe lo que probablemente ya estás haciendo, solo con una forma acordada.

Pero un archivo individual no es la unidad interesante. El paquete lo es. Así que déjame mostrarte cómo un paquete está realmente conectado — porque aquí es donde OKF deja de ser "un archivo markdown" y empieza a ser un sistema.

Cómo se estructura un paquete de conocimiento

Un paquete de conocimiento es un directorio de conceptos, y la especificación le da dos archivos organizadores opcionales pero poderosos que convierten una carpeta plana en algo por lo que un agente puede navegar inteligentemente.

La estructura se ve así:

my-knowledge-bundle/
├── index.md          # descripción general + listado del directorio (opcional)
├── log.md            # historial cronológico de cambios (opcional)
├── onboarding.md     # un concepto en la raíz del paquete
├── pricing.md        # otro concepto
└── playbooks/        # un subdirectorio agrupa conceptos relacionados
    ├── index.md      # los subdirectorios pueden tener su propio índice
    ├── refunds.md
    └── escalation.md

Los dos archivos especiales son donde el diseño se vuelve inteligente.

index.md es el mapa del paquete. Enumera lo que hay en el directorio para que un agente pueda inspeccionar el paquete antes de leer nada. Esto es revelación progresiva — exactamente el mismo patrón que hace eficientes a las habilidades de agentes bien diseñadas. Un agente lee el índice, decide cuáles tres de cuarenta archivos de concepto realmente necesita, y carga solo esos. No vuelca toda la carpeta en el contexto. Si has luchado con la inflación de tokens que viene de volcar todo en la ventana de contexto, reconocerás por qué esto importa — es el mismo principio sobre el que escribí en mi análisis de por qué la gestión de contexto supera a la configuración para agentes de IA. El índice es el foco; los conceptos son a lo que apunta.

log.md es la memoria del paquete sobre sus propios cambios. Un historial cronológico de actualizaciones. ¿Por qué necesita un formato de conocimiento un registro de cambios? Porque OKF asume que el conocimiento vive — que se revisa, se contradice y se corrige con el tiempo. El log es cómo un agente (o un humano) entiende no solo lo que dice el conocimiento hoy, sino cómo llegó aquí.

Cuando construí mi paquete de prueba, el archivo de índice fue lo que me convenció. Escribí cinco archivos de concepto, luego escribí un index.md que listaba cada uno con una descripción de una línea. Luego apunté a Claude hacia la carpeta y le hice una pregunta que solo un concepto podía responder. Leyó primero el índice, abrió exactamente un archivo y respondió. Nunca tocó los otros cuatro. Esa es la diferencia entre darle a un agente un catálogo de fichas de biblioteca versus volcar cada libro en su escritorio.

Ahora — antes de que esto suene demasiado pulido — déjame ser honesto sobre dónde la simplicidad se convierte en una limitación. No hay aplicación obligatoria. Nada te impide escribir cuarenta archivos de concepto sin índice, con valores de type inconsistentes, y un log.md que es una mentira. El formato es una convención, no una garantía. Lo cual me lleva a la comparación que todos siguen haciendo, y entendiendo ligeramente mal.

OKF vs llms.txt vs schema.org: ¿dónde encaja?

Esta es la pregunta que tuve a los diez minutos de leer la especificación, y es la que los anuncios responden con menor claridad. Ya tenemos llms.txt. Ya tenemos schema.org. ¿Necesitamos una tercera cosa? La respuesta corta: están en diferentes capas, y OKF es la más profunda.

Así mapearía yo el stack para visibilidad de IA en 2026:

Piensa en ello como un restaurante. llms.txt es el menú que le dice al agente qué está disponible. Schema.org es el etiquetado de alérgenos e ingredientes que elimina la ambigüedad sobre cada plato. OKF es la comida real, emplatada y lista para comer — el conocimiento mismo, entregado como un concepto markdown limpio en lugar de forzar al agente a hacer ingeniería inversa desde HTML scrapeado.

Esa enmarcación importa por una comparación que la especificación hace implícitamente y yo haré explícitamente: OKF es a lo que recurres cuando schema.org se queda sin espacio. Schema.org es brillante para las cosas para las que tiene tipos — productos, recetas, eventos, organizaciones. Pero en el momento en que tu conocimiento es un playbook matizado, un proceso propietario, una definición de métrica ganada con esfuerzo, o una estrategia que no mapea a ningún @type en el vocabulario, schema.org no tiene nada para ti. OKF no te restringe a un vocabulario predefinido. Tu type puede ser playbook, runbook, case-study, pricing-logic — lo que tu dominio necesite. Ese es el intercambio: schema.org te da rigor validado por máquina dentro de un vocabulario fijo; OKF te da flexibilidad abierta con casi ninguna validación.

Y el probable tejido conectivo entre estas capas es llms.txt de nuevo. La expectativa orientada al futuro — y quiero señalar esto claramente como esperado, no entregado — es que los sitios señalarán la existencia de un paquete OKF a través de un puntero estilo llms.txt, de la misma manera que los sitemaps XML y los datos estructurados llegaron después de robots.txt. A partir de v0.1, no hay un protocolo de descubrimiento formalizado incorporado en OKF mismo. Eso es una brecha, y es el tipo de brecha que un v0.1 debe tener.

Si estás construyendo sistemas de contenido y prefieres tener esta capa automatizada en lugar de mantenida manualmente, esto es exactamente el tipo de pipeline que yo construyo — convertir el conocimiento de un sitio en estructura legible por agentes se está convirtiendo en una disciplina propia, y puedes ver cómo lo abordo en mi trabajo sobre automatizar flujos de trabajo de contenido SEO con Claude Code. Pero no me necesitas para empezar. Puedes construir tu primer paquete hoy, y deberías hacerlo, porque leer una especificación no te enseña casi nada comparado con escribir un paquete malo.

Cómo construí mi primer paquete OKF (y qué se rompió)

Tomé dos caminos a propósito: construir un paquete a mano para entender el formato, y ejecutar un sitio existente a través de un generador para ver qué produce la automatización. El contraste me enseñó más que cualquiera por separado.

Camino uno: a mano. Creé una carpeta, escribí cinco archivos de concepto basándome en documentos internos reales — mi secuencia de onboarding, mi lógica de precios, dos playbooks y un glosario de términos que uso con clientes. El front matter fue la única fricción. Decidir el type para cada concepto tomó más tiempo que escribir el contenido, porque la especificación deliberadamente no te dice qué tipos usar. ¿Mi documento de precios es un pricing? ¿Una policy? ¿Una reference? La libertad es real, y también la fatiga de decisión. Mi conclusión: elige tu vocabulario de tipos primero, escríbelo como su propio concepto, y apégate a él. Los tipos inconsistentes son la forma más rápida de crear un paquete por el que un agente navega mal.

Luego escribí el index.md a mano e inmediatamente entendí por qué es opcional en la especificación pero obligatorio en la práctica. Sin él, un paquete es una pila. Con él, es un grafo.

Camino dos: un generador. La comunidad se movió rápido aquí. Suganthan Mohanadasan — un SEO que, notablemente, tenía su propio sitio hablando un formato de concepto markdown antes de que Google lanzara OKF — construyó un OKF Bundle Generator gratuito que toma una URL o sitemap y produce un paquete descargable más un mapa de tu contenido. Ejecuté una sección de mi propio sitio a través de él.

El resultado fue genuinamente útil y genuinamente limitado al mismo tiempo, y la limitación es toda la lección. El generador hizo bien lo obvio: cada página se convirtió en un archivo markdown limpio con front matter sensato, con enlaces cruzados, sin basura HTML. Pero produjo un concepto por página — y eso realmente no es para lo que está OKF. La unidad de OKF es el concepto, no la página. Un solo post largo de mi blog podría contener cuatro conceptos distintos que, en un paquete apropiado, deberían ser cuatro archivos separados que un agente puede referenciar independientemente. El generador tradujo fielmente mi estructura de páginas; no pudo realizar el acto más difícil de extracción de conceptos — leer una página y decidir que en realidad contiene tres ideas que merecen sus propios archivos.

Esa brecha es la oportunidad real, y lo diré claramente: el tooling valioso de OKF aún no se ha construido. Los conversores de página a markdown son un problema resuelto y comoditizado. Las herramientas que importarán son las que lean tu contenido desordenado y superpuesto y lo descompongan en conceptos limpios y deduplicados que reflejen tu estructura empresarial real. El término de Suganthan para lo que OKF permite — "deshornear semánticamente", romper conocimiento horneado junto de vuelta en elementos estructurados e interoperables — es exactamente la parte que la automatización no ha resuelto. Un modelo de lenguaje es adecuado para esa extracción, pero apuntar uno ingenuamente a "convierte este sitio en conceptos" todavía produce archivos de concepto que se superponen y contradicen. Hacerlo bien está sin resolver.

Si prefieres que alguien construya esta pipeline de extracción de conceptos para tu negocio en lugar de luchar con ella tú mismo, ese es un proyecto que acepto — puedes ver el tipo de sistemas que construyo en fiverr.com/s/EgxYmWD. Pero genuinamente, construye primero un paquete de cinco archivos a mano. Tomará veinte minutos y te enseñará lo que ninguna herramienta puede.

La conexión con Karpathy: conocimiento que se mantiene a sí mismo

OKF no viene de la nada. Es la formalización de una idea que Andrej Karpathy propuso — lo que él llamó el patrón LLM Wiki — y entender ese origen te dice hacia dónde se dirige realmente esto.

El argumento de Karpathy iba contra la corriente de cómo hacemos retrieval hoy. El patrón dominante, RAG, funciona dividiendo documentos no estructurados en chunks, embebbiéndolos, y recuperando los chunks más cercanos en el momento de la consulta. Es poderoso, pero es fundamentalmente una búsqueda sobre una pila estática. La pila no aprende. No reconcilia. Si dos documentos se contradicen, RAG recupera felizmente ambos y deja que el modelo lo resuelva.

El LLM Wiki de Karpathy invierte el modelo: en lugar de una pila estática que buscas, mantienes un wiki viviente que el propio modelo construye y revisa. La nueva información no se añade simplemente — se integra. El modelo actualiza la página de entidad relevante, revisa un resumen, y cuando datos nuevos contradicen una afirmación antigua, reconcilia la contradicción en lugar de almacenar ambas. La base de conocimiento es algo dinámico y en evolución, y el modelo hace la mayor parte del mantenimiento. Esa última parte es el desbloqueo: la razón por la que los wikis usualmente no escalan es que los humanos tienen que mantenerlos. Un agente que mantiene su propio wiki elimina el cuello de botella.

Puedes ver el log.md de OKF y el diseño de concepto por archivo como el formato en disco para exactamente esta visión. Un archivo de concepto es una página de entidad. El log es el historial de revisiones. La estructura es deliberadamente lo suficientemente simple para que un agente no solo pueda leerla sino escribirla — abrir un concepto, revisar una afirmación, añadir al log, guardar. Eso es un grafo de conocimiento vivo que una máquina puede realmente mantener actualizado.

He estado persiguiendo una versión casera de esto durante un tiempo usando Obsidian como almacén y Claude como mantenedor — escribí todo ese experimento en mi setup de memoria persistente con Obsidian + Claude Code y un análisis profundo relacionado sobre construir una base de conocimiento RAG al estilo Karpathy en Obsidian. La contribución de OKF no es una idea nueva sobre eso. Es una forma compartida. La razón por la que un estándar importa aquí es la interoperabilidad: si mi agente y tu agente ambos hablan OKF, mi paquete de onboarding podría ser leído por tu agente sin traducción alguna. Lo cual lleva a la parte que es o la más emocionante o la más sobre-prometida, dependiendo de tu escepticismo.

Optimización de búsqueda agéntica y conocimiento vendible

Aquí es donde los anuncios se ponen ruidosos, así que aquí es donde seré cuidadoso. Dos grandes afirmaciones viajan con OKF, y ambas son direcciones plausibles en lugar de realidades actuales. Separaré el mecanismo del marketing.

Afirmación uno: OKF reformula el SEO en "optimización de búsqueda agéntica." La lógica: a medida que los agentes de IA median cada vez más entre las personas y la información, el objetivo cambia de ser encontrable por un crawler de búsqueda a ser utilizable por un agente. En lugar de optimizar una página para que un humano haga clic en ella, publicas conocimiento para que un agente pueda leerlo, citarlo y actuar sobre él directamente. Cuando Google mismo comienza a describir tu contenido como "contexto para ser servido a agentes," servirlo en la forma que Google describe es una cobertura racional.

Creo que la dirección es real. La ejecución no está probada. No hay, a mediados de 2026, ningún mecanismo confirmado por el cual publicar un paquete OKF mejore tu visibilidad en las superficies mediadas por agentes de Google. Google lanzó un formato; no ha entregado — ni prometido — un beneficio de ranking por usarlo. Trata a cualquiera que venda "OKF para rankings" con la misma sospecha que tendrías con alguien que te vendió una etiqueta meta keyword. La jugada honesta es: OKF hace tu conocimiento más limpio y más utilizable para cualquier agente que lo lea, y esa es una apuesta defendible por sus propios méritos independientemente de si Google alguna vez lo recompensa.

Afirmación dos: la gente empaquetará y venderá paquetes de conocimiento OKF. Un abogado vende un paquete de playbooks legales curados. Un contador vende conceptos de estrategia fiscal. Un SEO vende un paquete de heurísticas de ranking. Una empresa compra estos y los monta en el contexto de sus propios agentes. Porque un paquete es solo un tarball de markdown, es trivialmente enviable, hosteable en cualquier repositorio git, y licenciable como cualquier producto digital.

Esta la encuentro más convincente, porque el mecanismo es sólido — un paquete genuinamente es una unidad portátil y autocontenida de expertise, y hay demanda real de contexto curado que los agentes puedan consumir. Pero es un mercado que aún no existe, no algo que está sucediendo a escala hoy. La misma fricción que hace que los buenos paquetes sean difíciles de generar (extracción de conceptos, consistencia, mantener el log honesto) hace que los buenos paquetes vendibles sean aún más difíciles, porque ahora la calidad es una característica del producto. Apostaría a que este mercado emerge. No apostaría por el cronograma, y sería escéptico de la primera ola de "paquetes de expertise" de la misma manera que soy escéptico de cualquier primera ola.

Entonces, ¿dónde deja eso a un constructor ahora mismo? Con un movimiento claro y de bajo riesgo y mucha paciencia para el resto.

Lo que realmente haría con OKF hoy

Déjame hacer esto concreto, porque "experimenta con ello" es el tipo de consejo que suena bien y no cambia nada. Aquí está la secuencia específica que ejecutaría, y qué esperar de cada paso.

1. Lee la especificación real, no los resúmenes. La OKF SPEC.md en GitHub es corta y legible en quince minutos. Cada resumen de segunda mano (incluyendo este) pierde fidelidad. La fuente es la fuente.

2. Construye un paquete de cinco archivos a mano. Elige un trozo real de tu propio conocimiento — tus procesos, tu documentación de producto, tus heurísticas ganadas con esfuerzo. Escribe cinco archivos de concepto, un index.md, y un log.md. No uses una herramienta. La fricción es la educación. Aprenderás más sobre tu propia estructura de conocimiento en veinte minutos de lo que un generador te dirá jamás.

3. Ábrelo en las herramientas que ya usas. Coloca la carpeta en Obsidian, súbelo a un repositorio de GitHub, pega un archivo en Notion. Confirma por ti mismo que "amigable para humanos" se sostiene. Esta es la propiedad que hace que OKF sea seguro de adoptar: en el peor caso, has escrito algo de markdown bien organizado, que tiene valor con o sin ningún agente.

4. Apunta un agente al paquete y haz una pregunta. Dale a Claude o Gemini la carpeta y pregunta algo que solo un concepto pueda responder. Observa si usa el índice para navegar. Este es el momento en que OKF deja de ser abstracto — cuando ves a un agente inspeccionar el mapa y abrir exactamente el archivo correcto, el diseño hace clic.

5. Escribe tu vocabulario de type como su propio concepto. Este es el hábito individual de mayor apalancamiento. La libertad de la especificación en cuanto a tipos es un arma de doble filo; los paquetes que envejecen bien son los que tienen un sistema de tipos deliberado y documentado. Toma esa decisión una vez, a propósito, y refiérete a ella.

Lo que no haría hoy: reestructurar toda mi operación de contenido alrededor de OKF, pagar por servicios de "OKF SEO", o tratar v0.1 como un estándar terminado. Google mismo llamó a v0.1 un punto de partida, no una especificación terminada. Construir sobre él es inteligente; apostar tu negocio en su forma actual no lo es.

Preguntas frecuentes

¿Qué es el Open Knowledge Format (OKF)?

El Open Knowledge Format es una especificación abierta e independiente de proveedores de Google Cloud, publicada como v0.1 el 12 de junio de 2026, para almacenar conocimiento como un directorio de archivos markdown con YAML front matter — legible tanto por humanos como por agentes de IA. Cada archivo representa un concepto y debe declarar un campo type. Para el desglose completo de la estructura, consulta la sección de paquetes arriba.

¿Cómo se diferencia OKF de llms.txt?

OKF y llms.txt operan en diferentes capas: llms.txt es un archivo de descubrimiento que apunta a los agentes hacia tus recursos importantes, mientras que OKF entrega el conocimiento curado mismo como documentos markdown a nivel de concepto. llms.txt es el menú; OKF es la comida. Son complementarios, y los paquetes OKF probablemente serán señalados a través de un puntero estilo llms.txt en el futuro.

¿Es OKF un factor de ranking SEO?

No — a mediados de 2026, Google no ha anunciado ningún beneficio de ranking por publicar paquetes OKF. OKF hace tu conocimiento más limpio y más utilizable para agentes de IA que lo leen, lo cual es una razón defendible para adoptarlo, pero trata cualquier afirmación de que OKF mejora directamente los rankings con escepticismo. Consulta la sección de búsqueda agéntica arriba para la advertencia completa.

¿Qué herramientas puedo usar para crear paquetes OKF?

Puedes escribir paquetes OKF a mano en cualquier editor de texto, ya que son solo markdown más YAML. Generadores comunitarios como el OKF Bundle Generator de Suganthan pueden convertir un sitio en un paquete básico, pero actualmente producen un concepto por página en lugar de verdadera extracción de conceptos — el tooling más valioso para descomponer contenido en conceptos limpios aún no se ha construido.

¿Qué es el LLM Wiki de Karpathy y cómo se relaciona con OKF?

El LLM Wiki es el concepto de Andrej Karpathy de una base de conocimiento viva que un modelo de IA construye y mantiene por sí mismo — integrando nueva información, revisando afirmaciones y reconciliando contradicciones, en lugar de buscar en una pila estática como el RAG tradicional. OKF es esencialmente el formato de archivo en disco para esa visión, con archivos de concepto como páginas de entidad y un archivo de log como historial de revisiones.

La verdadera razón por la que me alegro de no haberlo ignorado

Entré esperando otra especificación para archivar bajo "interesante, nunca usado." Salí habiendo cambiado cómo almaceno mi propio conocimiento — no porque OKF esté terminado, sino porque apuntó a algo verdadero.

Lo que hace bien es humilde: el conocimiento para agentes debería ser curado, atomizado y entregado, no scrapeado, dividido en chunks e ingenierizado en reversa. Eso es correcto independientemente de si el formato específico de Google gana. El paquete que construí a mano sobrevivirá cualquier predicción sobre la adopción de OKF, porque es simplemente markdown bien estructurado que ahora entiendo mejor que esta mañana.

Así que aquí está lo único que realmente te pediría que hagas antes de que esta semana termine: abre una carpeta, escribe cinco archivos de concepto sobre algo que conoces a la perfección, añade un índice, y apunta un agente hacia ella. Veinte minutos. Luego forma tu propio juicio sobre si el futuro es una carpeta. El mío es que el formato casi seguramente evolucionará más allá de v0.1 — pero la forma que describe, conocimiento como conceptos que un agente puede leer y mantener, es la dirección en la que todo ya se está moviendo. Mejor aprender la forma ahora que scrapearte hacia ella después.

Trabajemos juntos

¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudar.

• Fiverr (construcciones personalizadas e integraciones): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluciones empresariales): ramlit.com
• ColorPark (diseño y branding): colorpark.io
• xCyberSecurity (servicios de seguridad): xcybersecurity.io