Su agente de IA no necesita más contexto. Necesita un cerebro en el que pueda confiar.

Imagínese que un pager suena a las 02:14. Abre el manual de procedimientos y parece excelente: pasos numerados, un diagrama, señales claras de que alguien se preocupó por ello. Sigue el paso 4 y falla. En la parte inferior de la página ve la fecha de la última edición: hace catorce meses.

Cada oración estaba correcta el día en que se escribió. Pero no había ninguna indicación de que ya estuviera desactualizada.

Ese es el verdadero problema. No se trata de que falten documentos o de que sean de mala calidad. Se trata de documentos que parecen igual de fiables en su peor momento que en el primero. Durante cuarenta años, el software se distribuyó bajo la premisa de que la documentación es prosa y que el lector debe juzgarla. Luego, los repositorios pasaron a manos de agentes que no pueden juzgar nada y que leen cada palabra con total confianza.

Qué cambió

Un agente de IA no tiene memoria propia. Es sin estado, y en cada turno toda la conversación se envía de nuevo desde el principio. La documentación de Anthropic lo expresa claramente: hay que enviar toda la historia de la conversación cada vez.

Por lo tanto, un documento de arquitectura de 4,000 tokens que se pega en el archivo que un agente carga siempre no se lee una sola vez. En una sesión de cuarenta turnos se lee cuarenta veces. Y cargarlo puede empeorar el rendimiento del agente.

La investigación sobre la pérdida de contexto de Chroma probó 18 modelos de vanguardia, entre ellos GPT, Claude, Gemini y Qwen, y determinó que la precisión disminuye a medida que la entrada se alarga, en algunos casos de un 95 % a un 60 %. Lo que debería hacer que cambie sus hábitos es que este no es un efecto cercano al límite máximo. La degradación se observó en cada nivel de longitud que midieron. Si estos resultados son válidos, incluso una ventana de un millón de tokens comienza a verse afectada a los cincuenta mil, porque el problema es el ruido y no la capacidad.

Anthropic lo describe como un presupuesto de atención: el contexto es un recurso finito con rendimientos marginales decrecientes, y el objetivo es utilizar el conjunto más pequeño posible de tokens de alta calidad. Eso deja solo dos opciones malas.

• Cargar todo. El agente conoce el sistema, pero su rendimiento es notablemente peor en cada tarea, y cada edición de documento invalida todo el caché de instrucciones y lo vuelve a procesar.
• No cargar nada. El agente mantiene su agudeza pero no sabe nada, por lo que debe improvisar. Inventa un paso de implementación o ejecuta una orden que ya fue retirada en marzo.

Los equipos eligen una de estas opciones, sufren las consecuencias y luego pasan a la otra. Más o menos así está la industria hoy en día.

Ya existe un diagnóstico en una sola oración

En abril de 2026, Andrej Karpathy publicó un resumen breve al que llamó un archivo de ideas. No se trataba de un producto ni de una biblioteca. En él se esbozaba un enfoque: el modelo procesa la información bruta para convertirla en una wiki de Markdown ordenada y estructurada, y a partir de entonces las consultas se dirigen a esa wiki en lugar de a los documentos originales.

La frase importante de ese texto no tiene nada que ver con la IA: las personas abandonan las wikis porque la carga de mantenimiento crece más rápido que su valor.

Cualquiera que haya visto cómo moría un espacio de Confluence lo reconocerá. La gente no lo abandonó porque escribir fuera difícil; lo dejaron porque el mantenimiento era complicado, y ese mantenimiento consiste principalmente en tareas administrativas: actualizar el enlace, modificar el resumen, señalar que esta página ahora contradice a otra, arreglar el índice. Ese es exactamente el tipo de trabajo que dejó de ser costoso, ya que un LLM no se aburre, no olvida las referencias cruzadas y puede procesar quince archivos de una sola vez. Su división del trabajo es sencilla: tú lo lees, el LLM lo escribe.

La idea se difundió rápidamente. Dos meses después, Google Cloud publicó una especificación que, según su propio anuncio, formaliza el patrón de wiki con LLM en un formato portátil e interoperable. El diagnóstico subyacente sigue siendo el de Karpathy, y esa es la razón por la cual todo esto funciona ahora y no en 2019.

OKF en medio minuto

OKF, el formato de conocimiento abierto, fue publicado por el equipo Data Cloud de Google Cloud en junio de 2026 como un borrador (v0.2) y constituye explícitamente una formalización de dicho patrón. Técnicamente se trata de un directorio de archivos Markdown con frontmatter en YAML, y eso es todo.

La especificación resume su propuesta de la siguiente manera: cualquier herramienta capaz de usar cat con un archivo puede leer OKF, y cualquiera que pueda ejecutar git clone en un repositorio puede distribuirlo.

Solo hay un campo obligatorio: type. Un archivo que contenga únicamente type ya se considera conforme. No se requiere registro de esquemas, base de datos, pipeline de incrustación, bloqueo por proveedor ni SDK alguno.

okf/
  index.md                  ← table of contents
  billing/
    index.md
    invoice-retries.md      ← one file, one answerable question
  flows/
    customer-offboarding.md

Si tu reacción es “entonces, una carpeta de Markdown”, eso es exacto. El formato no es la parte interesante, y una objeción válida es que una carpeta no necesita una especificación. El anuncio de Google tiene una respuesta: la wiki de Karpathy, la wiki de un equipo y la exportación del catálogo de un proveedor pueden parecerse, con Markdown, frontmatter y enlaces cruzados, pero ninguno fue diseñado para cooperar. Ese es el motivo principal para tener una especificación. Todos llegaron de forma independiente a la misma estructura, lo que generalmente significa que esa estructura es la correcta, y luego cada implementación inventó sus propios nombres de campos. Un formato convierte varias convenciones privadas en algo que un agente puede leer en cualquier lugar.

La idea central: la documentación se convierte en estado

He aquí un documento de ejemplo:

---
type: Playbook
title: Invoice retry policy
status: stable                      # draft | stable | deprecated
stale_after: 2026-11-01             # stale when today >= this date
generated: { by: "human:dana", at: 2026-08-10 }
verified:  [{ by: "human:sam",  at: 2026-08-11 }]
sources:
  - resource: services/billing/retry.go
    last_modified: 2026-07-15
not:
  - term: "restart the worker to clear the queue"
    why: "in-flight jobs are lost, they are not re-queued"
    instead: "drain first, then restart"
---

Cinco de los campos que se muestran provienen de la especificación. El sexto es el más valioso y vuelve a aparecer más abajo.

Un archivador simplemente almacena documentos. Un cerebro también sabe qué contiene, cuán seguro está y qué errores le han enseñado algo. Los elementos a continuación se corresponden con eso:

Ahora lea ese frontmatter como lo haría una máquina. stale_after es una fecha de vencimiento. No se trata de un sello de “última actualización” que la gente tenga que interpretar. Es una fecha absoluta, lo que convierte la obsolescencia en una comparación sencilla: today >= stale_after. Cualquier cosa puede realizar esa comprobación: el agente que lee el archivo, un trabajo programado, su sistema de integración continua.

Deténgase a pensar en eso. El deterioro de la documentación ha sido un problema cultural desde que se inventaron las wikis. Recordatorios constantes, días dedicados a la documentación, auditorías trimestrales, además de una página de “Estándares de Documentación” que también se ha vuelto obsoleta. Todo esto se basa en la presión social, y nada de ello puede hacerse cumplir. Con stale_after, el deterioro se convierte en una prueba fallida, de la misma categoría que una compilación defectuosa. O pasa o no pasa, y nadie tiene que sentirse mal.

Los otros campos funcionan de la misma manera. sources enumera las rutas de código que describe un documento, de modo que un script puede finalmente responder a una pregunta que las wikis nunca pudieron resolver: esta solicitud de integración modificó un archivo que tres documentos afirman explicar, ¿alguien los actualizó? verified registra a quienes confirmaron un documento, por separado de quienes lo escribieron, porque, según las especificaciones, quienquiera que haya escrito un concepto no necesariamente es quien lo haya confirmado. Un borrador elaborado por un agente y la aprobación de un ingeniero senior son dos eventos distintos, una distinción que la mayoría de las herramientas de documentación nunca registran. Los niveles de confianza se derivan del prefijo del actor y no se almacenan, ya que una puntuación almacenada es subjetiva, no se puede transferir entre usuarios y se vuelve obsoleta.

status: deprecated permite mantener una definición antigua en lugar de eliminarla. Cuando dos paneles de control difieren en cuanto a “ingresos”, la causa a menudo no son datos defectuosos, sino dos definiciones distintas, una de las cuales fue reemplazada silenciosamente sin que se etiquetara. Mantenga ambas, marque una y los números del último trimestre seguirán siendo reproducibles.

Ese es el cambio: no se trata de un formato más atractivo para el texto, sino de texto acompañado de un estado que puede consultarse. Los documentos pueden ser interrogados, probados y fallar.

La aritmética de tokens

Estas cifras se midieron en comparación con el conjunto de ejemplos publicado por Google, por lo que se pueden verificar:

Seguir un hecho de principio a fin cuesta unos 950 tokens, y solo se cobra en las solicitudes que lo necesitan. La parte siempre activa corresponde al nivel 0: sesenta tokens, una oración.

Compárelo con el enfoque típico: una guía de 1,600 tokens que se incluye en cada solicitud, aunque quizás solo una de cada diez la necesite. El conocimiento es el mismo, la factura promedio es aproximadamente una décima parte, y el documento puede crecer libremente, ya que la longitud adicional ya no afecta a conversaciones no relacionadas en el repositorio. La especificación desarrolló index.md con ese objetivo y le dio un nombre: divulgación progresiva: primero se examina lo que ya existe y luego se abren los documentos.

Qué no es OKF

OKF no funciona como barrera de protección. Un archivo Markdown no puede impedir que un agente ejecute algo destructivo. La aplicación real de medidas de seguridad debe realizarse mediante código, como listas de denegación y ganchos de pre-ejecución que bloquean una acción sin importar qué elige el modelo. Sea lo que sea que recuerdes, no concluyas que haber anotado los peligros significa que estás protegido.

Lo que realmente te ofrece OKF es un agente que sabe. La especificación también define un tipo de cálculo Atested Computation, en el cual un agente puede pasar parámetros pero nunca debe escribir ni modificar el cálculo en sí, lo cual es lo más cercano que hay a prohibir la reescritura de la verificación de seguridad. Mantén un ojo en ello, pero aún no lo uses: la especificación indica que esa interfaz se dejará para una revisión posterior.

Tenga también en cuenta que se trata de un borrador. El salto de v0.1 a v0.2 ya cambió el nombre de dos constructos, así que adopte solo los ocho campos que necesite. Cualquier cambio de nombre posterior se realizará mediante buscar y reemplazar.

Comience con poco y añada controles cuando sea necesario

Esto no es un proyecto; es un solo archivo.

1. Escriba un documento sobre lo que más recientemente le costó a alguien una tarde entera, incluyendo los campos type, title, description y stale_after.
2. Escriba un archivo index.md que lo enumere, con una columna de “cuándo leer esto”, y añada okf_version: "0.2". El índice raíz es el único lugar donde debe estar ese campo, y según las especificaciones es el único frontmatter que puede contener un índice.

Agregue el puntero al archivo siempre activo. Cuesta alrededor de sesenta tokens y contiene una ruta además de un desencadenante, nunca un resumen, ya que un resumen no solo incrementa el costo del archivo siempre activo sino que también hace que el agente abra el archivo.

Eso es suficiente para comenzar. Dado que today >= stale_after es solo una comparación, el agente puede evaluarla tan pronto como se abra el archivo. Qué hacer con un documento obsoleto depende de usted, algo que la especificación deja intencionalmente abierto.

Agregue automatización en el momento en que una segunda persona pueda invalidar su documento sin leerlo. Ese es el verdadero umbral, y concierne más al tamaño del equipo que a la corrección. Con solo cinco documentos, se dará cuenta de que la verificación de vencimiento por parte del agente es suficiente. En un equipo, quienquiera que invalide su documento es, por definición, alguien que nunca lo abrió; por lo tanto, las buenas intenciones no pueden llegar hasta ellos, y algo en el proceso de solicitud de integración debe hacerlo. La versión económica es un trabajo programado que informa sobre los documentos vencidos. La versión avanzada es una barrera en la solicitud de integración que bloquea la integración si hay un documento vencido y emite una advertencia si se modificó el código descrito en dicho documento. Comience con la opción económica.

La versión breve

Lo que necesita un agente no es una ventana de contexto más grande. Necesita saber dónde buscar, y cualquier archivo que abra debe ser honesto sobre su antigüedad. Sesenta tokens de antemano, todo lo demás bajo demanda, y un documento que puede arruinar un proceso de construcción en cuanto deja de ser verdadero, algo que antes no era posible.

Leer más: la especificación OKF v0.2 y los paquetes de ejemplos, la publicación de Google Cloud sobre el formato, los artículos de Anthropic sobre ingeniería de contexto, habilidades de agentes y caché de prompts, y el estudio de Chroma sobre la rotación de contexto.

Leer relacionado

• Notas prácticas: Tu agente de programación no necesita más contexto. Necesita un mapa. — Guía paso a paso de las Notas prácticas: Tu agente de programación no necesita más contexto. Necesita un mapa.: contratos, verificaciones y espacios para código listo para usar para los equipos que implementan este patrón.
• Notas prácticas: Tu agente de programación no necesita un prompt mejor — Guía paso a paso de las Notas prácticas: Tu agente de programación no necesita un prompt mejor: contratos, verificaciones y espacios para código listo para usar para los equipos que implementan este patrón.

Notas prácticas: Israeli Tech Radar 2026-27: Ingeniería en la era de los agentes — Guía detallada de las Notas prácticas: Israeli Tech Radar 2026-27: Ingeniería en la era de los agentes: contratos, verificaciones y espacios para código listo para usar para los equipos que implementan este patrón.