Open Knowledge Format (OKF): qué es y cómo usarlo con agentes de IA

Llevamos un año coleccionando ficheros con punto eme de para hablarle a los agentes. CLAUDE.md para Claude Code, AGENTS.md para Codex, SKILL.md para empaquetar conocimiento, DESIGN.md para la identidad visual. Cada herramienta inventando su propio dialecto para explicarle al modelo cómo es tu mundo.

El 12 de junio de 2026 Google Cloud soltó otro: Open Knowledge Format, OKF para los amigos.

Y aquí podrías pensar “ya está el típico, otro formato más para la pila”. Lo entiendo. Pero este tiene una gracia distinta, y es que no intenta venderte una plataforma. Te vende una convención de carpetas. Literalmente una carpeta de archivos Markdown que un agente puede recorrer como si fuera un mapa de tu proyecto.

Esto es lo que vamos a ver:

Qué es OKF y qué problema concreto resuelve para los agentes de IA
Cómo se ve un bundle por dentro, con un dibujo en ASCII para que lo visualices de un vistazo
Las cuatro reglas del formato que de verdad importan
En qué se parece y en qué se diferencia de la familia CLAUDE.md / AGENTS.md / SKILL.md
Cómo implementarlo con tu agente paso a paso, con una demo de cuatro conceptos enlazados
Qué no resuelve OKF todavía, porque es una v0.1 y conviene saberlo

Qué es OKF en una frase ¶

OKF es una carpeta de archivos Markdown con frontmatter YAML que convierte el conocimiento de un proyecto en algo que un agente puede navegar sin reconstruirlo desde cero.

Esa es la idea entera. No hay base de datos vectorial. No hay framework de RAG. No hay runtime propietario ni SDK obligatorio.

Google lo define como una especificación abierta y vendor-neutral, y lo dice sin pudor en el SPEC: si puedes hacer cat a un fichero, puedes leer OKF; si puedes hacer git clone a un repo, puedes distribuirlo (Google Cloud, knowledge-catalog/okf/SPEC.md).

Un detalle importante antes de seguir, porque hay confusión: OKF, en esta acepción, no es la Open Knowledge Foundation, la organización sin ánimo de lucro que promueve los datos abiertos desde hace años. Comparten siglas y nada más.

Cuando alguien habla de OKF en blogs, GitHub o Hacker News desde junio de 2026, casi seguro se refiere al formato de Google.

El equipo detrás es el de Data Cloud de Google, con Sam McVeety y Amir Hormati al frente (Sam McVeety y Amir Hormati, “Introducing the Open Knowledge Format”, Google Cloud Blog).

Pero la raíz conceptual la puso antes Andrej Karpathy en su gist sobre las “LLM Wikis”, con miles de estrellas. Su intuición: un modelo no se aburre, no se olvida de actualizar una referencia cruzada y puede tocar quince ficheros de una pasada.

Ese trabajo de bibliotecario, que a los humanos nos da pereza, es justo en lo que un agente brilla.

El problema que de verdad resuelve ¶

Hay un nombre técnico para el dolor que ataca OKF: el context assembly problem.

Tú lo conoces aunque no lo llames así.

Le pides a tu agente “calcula los usuarios activos semanales desde el stream de eventos” y el pobre tiene que ensamblar la respuesta a partir de un catálogo de datos con su API, una wiki de Confluence, tres comentarios en el código, un Google Doc que alguien escribió en 2024 y lo que sabe el senior que está de vacaciones.

El contexto real de una organización vive desperdigado. Y cada proveedor te ofrece su propio catálogo, su propio SDK y su propio esquema de grafo de conocimiento, ninguno portable entre productos.

Cuanto más le metes a un agente, peor: es el context rot que destripamos en la guía de GSD, donde la calidad cae en picado a partir del 70% de la ventana ocupada.

🔑 La apuesta de OKF es contundente: lo que falta no es otro servicio, es un formato. Un mínimo común denominador para que una wiki escrita por un productor la consuma un agente distinto sin traducción.

Si esto te suena, es porque el problema del contexto disperso es el mismo que ya tratamos al hablar de cómo configurar la memoria de tu proyecto en Claude Code. Un CLAUDE.md bien dimensionado hace explícito el conocimiento tácito de un repo. OKF generaliza esa idea: en vez de un fichero gigante, una carpeta navegable de conceptos enlazados.

Curso gratis · paso a paso

Dale método a tu agente para que deje de improvisar

El mismo principio de OKF — conocimiento en Markdown versionado, sin plataforma — sostiene el SDD. Este curso gratis te lleva por un ciclo completo de Spec Driven Development con OpenSpec sobre un proyecto de juguete, para que lo veas funcionar entero antes de coger tú el volante.

Entra en el curso gratis →

Cómo se ve un bundle por dentro ¶

A un paquete OKF se le llama bundle. Dentro hay documentos Markdown y cada documento representa un concepto: una tabla, una métrica, una API, una decisión, un runbook o una práctica de equipo. Un concepto, un fichero.

Imagínate un second-brain de cómo trabajas tú con IA. Aquí está el giro que lo hace útil: no documentas qué es RAG o MCP (eso ya lo sabe el modelo), sino cómo los usáis vosotros. Tu política, tus decisiones, tus runbooks. Eso es justo lo que un agente no puede adivinar. Su bundle podría verse así:

second-brain/
└── okf/
    ├── index.md                       # el mapa: qué hay aquí dentro
    ├── log.md                         # historial de cambios
    ├── practicas/
    │   ├── politica-de-contexto.md    # cómo gestionamos la ventana
    │   └── cuando-usar-rag.md         # nuestra decisión: RAG sí/no
    └── runbooks/
        ├── detectar-context-rot.md    # señales y qué hacemos
        └── conectar-mcp.md            # cómo cableamos MCP en agentes

Hasta aquí parece una carpeta docs/ de toda la vida. La diferencia está en lo que pasa cuando enlazas unos ficheros con otros usando enlaces Markdown normales. La carpeta deja de ser una lista plana y se convierte en un grafo. Visualízalo así:

        [Práctica: Cuándo usar RAG]
                  │
                  │ se rige por
                  ▼
[Runbook: Detectar context rot] ──previene──► [Práctica: Política de contexto]
                                                       ▲
                                                       │ limita
                                                       │
                                            [Runbook: Conectar MCP]

Cada flecha es un enlace Markdown dentro de un fichero. La decisión de cuándo usar RAG se rige por vuestra política de contexto. El runbook de context rot existe para prevenir lo que esa política busca evitar. Y el de MCP apunta a la misma política porque cada herramienta que conectas consume parte del presupuesto.

Un agente que aterrice en cualquier nodo puede caminar el grafo y entender cómo trabajáis, sin que tú le pegues tus notas enteras en el prompt.

Esa es la jugada. El sistema de ficheros es la API.

Si te interesa cómo los agentes dejan de improvisar cuando les das el contexto bien estructurado, cada domingo comparto lo que voy aprendiendo sobre IA en el desarrollo. Gratis y ya somos +6.700.

Apúntate gratis →

Las cuatro reglas que importan ¶

El SPEC de OKF v0.1 cabe en una idea: ponte de acuerdo en lo mínimo y deja lo demás al productor. Estas son las reglas que necesitas tener en la cabeza.

1. Un concepto por fichero, y la ruta es la identidad.

El identificador de un concepto es la ruta de su fichero dentro del bundle, sin el sufijo .md. Así, practicas/cuando-usar-rag.md tiene el concept ID practicas/cuando-usar-rag. No hay registro central de IDs ni base de datos: el árbol de carpetas hace ese trabajo.

2. Frontmatter YAML con un único campo obligatorio.

Cada concepto abre con un bloque YAML. Lo único que el SPEC exige es type. El resto son recomendados, en este orden de prioridad: title, description, resource, tags y timestamp.

---
type: Convention                   # único campo OBLIGATORIO
title: Política de ventana de contexto
description: Cómo gestionamos el presupuesto de tokens en nuestros agentes.
tags: [contexto, agentes, convenciones]
timestamp: 2026-06-29T10:00:00+02:00
---

El valor de type no está registrado en ningún sitio. Tú eliges algo descriptivo (Convention, Playbook, Decision, Runbook) y el consumidor tiene la obligación de tolerar tipos que no conozca, tratándolos como conceptos genéricos.

¿Te suena al frontmatter de un SKILL.md? Vas bien encaminado: es la misma filosofía de metadatos mínimos que ya viste en la guía de skills para agentes.

3. Los enlaces crean relaciones, pero sin tipar.

Un enlace de A a B afirma que hay una relación. ¿De qué tipo? Eso lo dice el texto alrededor del enlace, no el enlace en sí.

El SPEC recomienda los enlaces absolutos (que empiezan por /, relativos a la raíz del bundle) porque sobreviven si mueves el fichero de subcarpeta.

Y ojo a un detalle elegante: un consumidor debe tolerar enlaces rotos. Un enlace a un concepto que aún no existe no es un error, es conocimiento que todavía no has escrito.

4. Dos nombres de fichero reservados.

index.md y log.md tienen significado especial y no pueden ser conceptos:

index.md enumera lo que hay en una carpeta para permitir progressive disclosure: que el agente vea el mapa antes de abrir documento por documento, en vez de tragarse el repo entero y quemar tu presupuesto de tokens (ese ahorro lo desarrollamos en las 21 técnicas para ahorrar tokens en Claude Code). No lleva frontmatter (con una excepción: el index.md raíz puede declarar okf_version: "0.1").
log.md registra el historial de cambios, agrupado por fecha en formato ISO, lo más reciente primero.

💡 La regla de conformidad de OKF v0.1 es de las más relajadas que verás: basta con que cada fichero no reservado tenga frontmatter parseable y un type no vacío. Lo demás es guía blanda. Un consumidor no puede rechazar tu bundle por campos opcionales ausentes, tipos desconocidos, claves extra o enlaces rotos. Está pensado para que aguante mientras el bundle crece y se refactoriza.

OKF frente a la familia de ficheros para agentes ¶

Aquí es donde conviene aterrizar, porque ya tienes varios formatos rondando y la pregunta lógica es “¿esto sustituye a mi CLAUDE.md?”. La respuesta corta es no. Resuelven cosas distintas.

CLAUDE.md y AGENTS.md le dicen a un agente cómo comportarse dentro de un repo: cómo construir el proyecto, qué convenciones seguir, cómo lanzar los tests.

Son el onboarding para máquinas, y ya analizamos sus riesgos en el post sobre para qué sirve AGENTS.md y el comando /init, donde un estudio de ETH Zurich avisa de que un fichero mal dimensionado puede perjudicar más que ayudar.

SKILL.md empaqueta un método repetible que el agente carga bajo demanda. DESIGN.md describe la identidad visual de tu marca para los agentes de diseño, con la misma lógica de terreno común que vimos en la guía de DESIGN.md.

OKF juega en otra liga: describe un cuerpo de conocimiento, no un comportamiento ni una habilidad. Comparte, eso sí, la misma apuesta vendor-neutral que ya viste en el Spec-Driven Development con OpenSpec: el conocimiento vive en Markdown versionado en Git, no atado a un servicio. Esta tabla lo resume:

Formato	Ámbito	Unidad	Para qué sirve
CLAUDE.md / AGENTS.md	Un repo	Un fichero raíz	Cómo debe comportarse el agente
SKILL.md	Un método	Una carpeta con SKILL.md	Conocimiento procedimental reutilizable
DESIGN.md	Una marca	Un fichero	Cómo debe verse lo que el agente genera
OKF	Un dominio o dataset	Una carpeta de conceptos	Qué sabe el agente sobre tu proyecto

La comparación más cercana por forma es AGENTS.md, que OpenAI publicó en agosto de 2025 y que ya supera los 60.000 proyectos en GitHub (Marc Bara, “Google’s New Format for Agent Context”, Medium). Pero AGENTS.md le habla al agente sobre el repo; OKF le entrega un mapa del conocimiento. Stack, no competencia.

Del conocimiento al método

OKF guarda el qué; una skill empaqueta el cómo para reutilizarlo

Verás cómo escribir un SKILL.md que tu agente carga solo cuando hace falta — en Claude Code, OpenCode, Gemini CLI y 25+ agentes más — con plantillas listas para copiar.

Abrir la guía →

Incluye plantillas SKILL.md descargables · Suscripción Web Reactiva Premium · 15€/mes · sin permanencia

Cómo se implementa con agentes de IA ¶

OKF define dos roles, y entenderlos es la mitad del trabajo:

Productores: las personas y sistemas que crean y mantienen el conocimiento. Puedes ser tú escribiendo a mano, o un agente generándolo a partir de tu repo (el tutorial de Claude Code y el tutorial de OpenCode te ponen al día si aún no trabajas con agentes en la terminal).
Consumidores: los sistemas que lo usan. Un agente de IA, un índice de búsqueda, un visualizador.

La gracia es que productor y consumidor son independientes. Un bundle escrito a mano lo lee un agente. Un bundle generado por un pipeline lo navegas en un visualizador.

El formato es el contrato; las herramientas en cada extremo son intercambiables. Visto de lado, el flujo es así:

  PRODUCTORES                EL FORMATO               CONSUMIDORES
  (escriben)                 (el contrato)            (leen)

  tú a mano ──────┐                                ┌──► agente de IA
                  │          ┌──────────────┐      │
  agente de  ─────┼────────► │  bundle OKF  │ ─────┼──► índice búsqueda
  enriquecim.     │          │  .md + YAML  │      │
                  │          └──────────────┘      │
  pipeline  ──────┘            carpeta en Git      └──► visualizador

Cambia quién escribe o quién lee y el bundle sigue valiendo. Esa es la diferencia entre un formato y una plataforma.

Para que la idea no quedara en humo, Google publicó dos implementaciones de referencia.

La primera es un agente de enriquecimiento construido sobre su Agent Development Kit y Gemini: recorre un dataset de BigQuery, escribe un concepto por tabla y luego hace una segunda pasada cruzando documentación para enriquecer cada ficha. La segunda es un visualizador que renderiza cualquier bundle como una página HTML interactiva.

Son pruebas de concepto a propósito: nada en el formato obliga a usar un framework concreto ni HTML. De hecho, Google rebautizó su antiguo Dataplex como Knowledge Catalog y lo preparó para ingerir OKF.

Pero a ti y a mí lo que nos interesa es montarlo en un proyecto real con el agente que ya usas. Vamos a ello.

El flujo práctico con tu agente ¶

La tentación es decirle al agente “vuelca todas mis notas en OKF” y marcharte a por un café. Mala idea. Te volverá con una carpeta docs/ muerta más, de esas que nadie abre.

El patrón que funciona es empezar por un grafo pequeño y dejar que crezca por necesidad. Cuatro conceptos conectados, y a partir de ahí cada documento nuevo tiene que justificar su existencia porque otro documento lo necesita.

🛡️ Antes de generar nada, dile al agente que documente cómo trabajáis de verdad, no definiciones de manual que el modelo ya conoce. Si algo no lo tiene claro, que abra una sección # Open questions dentro del concepto en vez de inventárselo. El conocimiento inventado es peor que la ausencia de conocimiento.

Este es un prompt directo que puedes pegarle a Claude Code, OpenCode, Codex o el agente que tengas a mano:

Crea una demo OKF v0.1 en `okf/` para un second-brain de cómo trabajamos
con IA, con 4 conceptos relacionados. No documentes definiciones de manual:
documenta nuestras prácticas, decisiones y runbooks.

1. Una práctica central (por ejemplo, "nuestra política de ventana de contexto").
2. Una decisión que se rija por la primera (por ejemplo, "cuándo usamos RAG").
3. Un runbook que prevenga un fallo (por ejemplo, "detectar context rot").
4. Un runbook de una herramienta (por ejemplo, "cómo conectamos MCP").

Reglas:
- Un concepto por fichero Markdown, con frontmatter YAML.
- El campo `type` es obligatorio; añade title, description, tags y timestamp.
- Crea un `index.md` raíz SIN frontmatter que liste los conceptos por secciones.
- Crea un `log.md` raíz con la entrada inicial.
- Enlaza los conceptos entre sí con enlaces Markdown relativos a la raíz.
- Documenta solo lo que hacemos de verdad; si afirmas un dato externo, cítalo.
- Si algo no lo tienes claro, abre una sección `# Open questions`.

Si trabajas con agentes desde la terminal y este flujo te resulta natural, en esos mismos tutoriales verás cómo encajan los ficheros de contexto en el día a día.

Demo: los cuatro ficheros ¶

Para que no quede abstracto, así quedaría la práctica central, vuestra política de contexto. Fíjate en cómo el frontmatter da los metadatos y el cuerpo enlaza a los otros conceptos:

---
type: Convention
title: Política de ventana de contexto
description: Cómo gestionamos el presupuesto de tokens en nuestros agentes.
tags: [contexto, agentes, convenciones]
timestamp: 2026-06-29T10:00:00+02:00
---

# Rule

Mantenemos la ventana por debajo del 70% antes de compactar. A partir de
ahí, la calidad cae y preferimos resumir el hilo a seguir acumulando.

# Related concepts

La rellenamos con [RAG cuando toca](/practicas/cuando-usar-rag.md), la
vigilamos con el [runbook de context rot](/runbooks/detectar-context-rot.md)
y limitamos lo que mete [MCP](/runbooks/conectar-mcp.md).

Una segunda ficha enlaza de vuelta a la política y recoge una decisión vuestra. Aquí la sección # Citations muestra el patrón recomendado por el SPEC para sostener un dato externo con su fuente:

---
type: Decision
title: Cuándo usamos RAG (y cuándo no)
description: Criterio del equipo para recurrir a RAG en lugar de meter todo en el prompt.
tags: [rag, decision, contexto]
timestamp: 2026-06-29T10:00:00+02:00
---

# Decision

Usamos RAG solo cuando la fuente no cabe entera y cambia a menudo. Para
documentación estable preferimos un bundle OKF curado.

# Why

Recuperar trozos cuesta presupuesto en la
[política de contexto](/practicas/politica-de-contexto.md): cada chunk
inyectado es contexto que ya no usamos para razonar.

# Citations

[1] [Lewis et al., "Retrieval-Augmented Generation"](https://arxiv.org/abs/2005.11401)

Y el index.md raíz, que es el mapa por el que el agente entra antes de abrir nada. Recuerda: sin frontmatter, solo secciones con enlaces y descripciones:

# Second-brain: cómo trabajamos con IA

## Prácticas
* [Política de ventana de contexto](/practicas/politica-de-contexto.md) - Cómo gestionamos el presupuesto de tokens.
* [Cuándo usamos RAG](/practicas/cuando-usar-rag.md) - Nuestro criterio: RAG sí/no.

## Runbooks
* [Detectar context rot](/runbooks/detectar-context-rot.md) - Señales y qué hacemos.
* [Conectar MCP](/runbooks/conectar-mcp.md) - Cómo cableamos MCP en agentes.

Con esos cuatro ficheros más el índice ya tienes un mini-bundle válido: conceptos, frontmatter, enlaces y un mapa de entrada. Y ahora viene el truco para que no se pudra. La siguiente orden al agente es quirúrgica:

Amplía el bundle OKF añadiendo SOLO conceptos que estén enlazados
desde los 4 documentos iniciales y que aún no existan.

Así el grafo crece por tracción real, no por relleno. Cada documento nuevo cubre un hueco que otro documento ya estaba pidiendo.

Progressive disclosure: por qué esto cuida tu presupuesto de tokens ¶

Aquí hay un punto que se entiende mejor si has sufrido el contexto lleno alguna vez. Un agente no debería tragarse tu proyecto entero para responder a una pregunta.

Eso quema tokens, ralentiza la respuesta y, lo peor, degrada la calidad: el context rot que ya mencionamos, con la ventana llenándose hasta volver torpe al modelo.

El index.md de OKF es la respuesta de este formato a ese problema. El agente lee primero el mapa, decide qué conceptos necesita y abre solo esos. En lugar de cargar el repo entero, recorre el bundle por capas:

  1. lee el mapa        2. elige lo que           3. abre SOLO
     (index.md)            necesita                  esos conceptos

  ┌──────────────┐      ¿"por qué se          ┌──────────────────────┐
  │ Prácticas ...│ ───► degrada mi      ───►  │ detectar-context-rot │ ✔ abre
  │ Runbooks  ...│      agente?"               │ politica-de-contexto │ ✔ abre
  │              │                             │ cuando-usar-rag      │ ✘ ignora
  │              │                             │ conectar-mcp         │ ✘ ignora
  └──────────────┘                             └──────────────────────┘
   el índice cabe         razona sobre              el resto NO
   en pocos tokens        títulos, no cuerpos       toca el contexto

Es el patrón que defiende la comunidad para gestionar el contexto: dejar el conocimiento en disco y cargarlo bajo demanda, no meterlo siempre en el prompt inicial. La misma idea que sostiene el ahorro de tokens del que ya hablamos.

⚠️ Cuidado con confundir OKF con una memoria que el agente actualiza solo y sin supervisión. El bundle es tan bueno como lo mantengas. Si nadie revisa los conceptos, en seis meses tendrás contradicciones y datos caducos sirviéndose como si fueran verdad. La curación sigue siendo tuya.

Y si vienes del mundo de las especificaciones como código, esta filosofía de “el conocimiento vive en Markdown versionado en Git, no en un servicio” es la misma del SDD que comentábamos antes. Tus specs sobreviven al cambio de agente porque son ficheros. Tu bundle OKF, igual.

El presupuesto de tokens y el context rot son el pan de cada día trabajando con agentes. Cada domingo +6.700 developers compartimos cómo lo gestionamos en la práctica. Gratis, desde 2018.

Suscríbete gratis →

Lo que OKF no resuelve todavía ¶

Sería deshonesto venderte esto como la solución definitiva. Es una v0.1, está etiquetada como Draft y tiene agujeros que conviene mirar de frente.

El más importante lo señaló bien Marc Bara: OKF avanza en interoperabilidad estructural pero deja casi intacta la semántica. Te fija el contenedor (carpeta, ficheros Markdown, frontmatter YAML, dos nombres reservados, un campo obligatorio) y poco más.

El SPEC tiene 451 líneas, así que lo de “cabe en una página” es más retórica que realidad. Pero la idea de fondo se sostiene: estandariza el paquete antes de discutir el vocabulario.

¿Qué queda fuera y duele?

Relaciones sin tipar. Un enlace dice que A y B se relacionan, pero no si A depende de B, lo expone o lo contradice. El significado vive en la prosa, frágil para una máquina.
Sin señales de frescura ni confianza. El timestamp te dice cuándo se tocó el fichero, no si la información sigue siendo cierta. No hay forma estándar de marcar un concepto como dudoso o deprecado.
Markdown como techo y como suelo. En Hacker News lo compararon con DBML, LikeC4 o Mermaid, y aparece la crítica razonable: cualquier documento Markdown se convierte en OKF con solo añadir un type al frontmatter. Eso lo hace facilísimo de adoptar y, a la vez, muy poco semántico.
Selección de contexto bajo límite de tokens. El index.md ayuda, pero el formato no resuelve cómo elegir qué conceptos entran cuando el presupuesto aprieta. Eso sigue siendo problema del consumidor.

OKF no es una señal de SEO (aunque te lo cuenten) ¶

Un aviso porque la confusión ya está rodando. La comunidad SEO ha empezado a reinterpretar OKF como un formato público para que los agentes lean tu web, y hay quien lo vende como el nuevo truco de posicionamiento.

Cuidado ahí. Google planteó OKF sobre todo para conocimiento organizacional e interno, no como una señal de ranking.

Las propias guías técnicas lo dicen sin rodeos: los sistemas de búsqueda de Google no leen tu bundle para posicionarte (WitsCode, “The Open Knowledge Format explained”). Que puedas servir un okf/ en tu dominio no significa que vaya a moverte en la SERP.

Es una herramienta de contexto para agentes, no un sustituto del SEO.

Mi lectura ¶

OKF me gusta justo por lo que no intenta ser. No vende la plataforma definitiva de conocimiento. Estandariza el mínimo común denominador de una wiki para agentes, y ya.

Lo veo útil de verdad en cuatro sitios: un second-brain de cómo trabaja tu equipo (tus prácticas, decisiones y runbooks, no definiciones de manual), repos con mucha convención no escrita, equipos que ya trabajan con Claude Code, OpenCode o Codex, y documentación de dominio que quieres más portable que un CLAUDE.md de mil líneas.

El precio de entrada es ridículo: una carpeta y unos cuantos ficheros Markdown.

¿Te lanzo el guante? Coge un tema que domines, monta los cuatro conceptos de la demo y deja que el agente camine el grafo. No te llevará más de un café.

Y si te quedas con ganas de más sobre cómo los agentes están dejando de ser un chat con tools para convertirse en sistemas con memoria y criterio, cada domingo lo desmenuzo con +6.700 developers en la newsletter de Web Reactiva.

Preguntas frecuentes ¶

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

OKF es una especificación abierta publicada por Google Cloud el 12 de junio de 2026 que representa el conocimiento como una carpeta de archivos Markdown con frontmatter YAML. Cada fichero es un concepto y los enlaces entre ficheros forman un grafo que humanos y agentes de IA pueden navegar sin necesidad de un SDK.

¿OKF es lo mismo que la Open Knowledge Foundation? ¶

No. Comparten las siglas y nada más. La Open Knowledge Foundation es una organización sin ánimo de lucro centrada en datos abiertos. El Open Knowledge Format es un formato de fichero para conocimiento legible por agentes. Son entidades sin relación.

¿Qué campos son obligatorios en un concepto OKF? ¶

Solo uno: type, un texto corto que identifica la clase de concepto. Los recomendados, por orden de prioridad, son title, description, resource, tags y timestamp. Puedes añadir las claves que quieras y un consumidor conforme no debe rechazar tu documento por campos extra o desconocidos.

¿OKF sustituye a mi CLAUDE.md o AGENTS.md? ¶

No. CLAUDE.md y AGENTS.md le dicen al agente cómo comportarse dentro de un repo. OKF describe un cuerpo de conocimiento: tablas, métricas, APIs, decisiones. Conviven: uno define comportamiento, el otro entrega contexto.

¿Necesito un producto de Google para usar OKF? ¶

No. El formato es vendor-neutral y no requiere cuenta, SDK ni runtime. Google publicó herramientas de referencia (un agente de enriquecimiento para BigQuery y un visualizador HTML), pero son opcionales. Cualquier agente que sepa leer Markdown puede consumir un bundle.

¿Cómo genero un bundle OKF con mi agente de IA? ¶

Pídele que cree una carpeta okf/ con cuatro conceptos relacionados, pero centrados en cómo trabajáis, no en definiciones de manual (por ejemplo: vuestra política de ventana de contexto, cuándo usáis RAG, un runbook para detectar context rot y otro para conectar MCP). Cada uno con frontmatter y type obligatorio, más un index.md y un log.md. Indícale que documente solo lo que hacéis de verdad. Luego amplíalo solo con conceptos enlazados desde los iniciales.

¿Qué son index.md y log.md en OKF? ¶

Son los dos nombres de fichero reservados. index.md lista el contenido de una carpeta para permitir progressive disclosure, es decir, que el agente vea el mapa antes de abrir documentos. log.md registra el historial de cambios agrupado por fecha ISO, lo más reciente primero.

¿OKF mejora mi posicionamiento en Google? ¶

No es una señal de ranking. Google lo diseñó para conocimiento interno y organizacional, no para SEO. Los sistemas de búsqueda no leen tu bundle para posicionarte. Servir un okf/ en tu web puede ayudar a que un agente entienda tu contenido, pero no mueve tu posición en resultados.

¿En qué se diferencia OKF de un sistema RAG? ¶

En un sistema RAG el agente busca una y otra vez sobre documentos en bruto. Con OKF el conocimiento vive como conceptos curados, enlazados y versionados en control de versiones, que el agente lee y mantiene de forma incremental. Es la diferencia entre buscar cada vez y consultar una wiki construida a propósito.

¿Está OKF listo para producción? ¶

Es una v0.1 marcada como borrador. Su fuerte es la interoperabilidad estructural; lo semántico (relaciones tipadas, señales de frescura y confianza) queda pendiente. Para demos, documentación de dominio y memoria de proyecto es perfectamente usable hoy, sabiendo que el formato evolucionará.

Fuentes ¶

Sam McVeety y Amir Hormati, “Introducing the Open Knowledge Format” — Google Cloud Blog
GoogleCloudPlatform, “OKF v0.1 SPEC” — repositorio knowledge-catalog en GitHub
Marc Bara, “Google’s New Format for Agent Context: A Standard, or Just a Folder?” — Medium
WitsCode, “The Open Knowledge Format (OKF), explained”
MarkTechPost, “Google Cloud Introduces Open Knowledge Format (OKF)”
Search Engine Journal, “Google Cloud Announces The Open Knowledge Format”

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter