Proyecto Cedar: Prueba para determinar si los agentes de IA pueden mantener un wiki en formato Markdown de la empresa.

Obsidian puede transferir contexto entre los proyectos de una persona y sus agentes de programación. Los planes, decisiones, requisitos y restricciones sobreviven a las sesiones individuales; Claude, Codex o cualquier otra herramienta de agente puede leer los mismos archivos del proyecto, y un humano puede inspeccionar y corregir esos archivos así como cambiar de modelo sin que el conocimiento del proyecto quede atrapado en el historial de chats. Esto funciona bien dentro de los proyectos de una sola persona, ya que esa persona toma la mayoría de las decisiones y conoce cómo está organizado todo.

Dentro de una empresa la situación cambia. El conocimiento está disperso en repositorios, tickets, reuniones, documentos y entre muchas personas diferentes. Las fuentes se contradicen entre sí y las decisiones se revierten. Un conjunto de notas de reunión puede describir una idea que el equipo descartó posteriormente, mientras que un documento de arquitectura aprobado contiene la decisión que realmente se mantiene. Por lo tanto, la pregunta abierta es si una práctica específica para cada proyecto puede aplicarse a toda una organización, y si el Markdown compartido podría servir como acuerdo entre empleados y agentes.

La idea de la LLM Wiki

Este modelo proviene de una propuesta reciente de Andrej Karpathy, quien la denominó LLM Wiki. Tiene tres capas:

• Fuentes en bruto que nunca se modifican
• Una wiki en Markdown, interconectada y mantenida por un agente
• Un esquema que indica al agente cómo organizar y mantener esa wiki

Tres operaciones actúan sobre esas capas. Ingest introduce nuevas fuentes de información. Query utiliza el conocimiento ya almacenado. Lint verifica la wiki en busca de lagunas, material obsoleto, conflictos y mala organización.

Las fuentes posibles mencionadas en la propuesta incluyen conversaciones de Slack, reuniones, documentos del proyecto y llamadas a clientes; el agente compila todo esto en conocimiento que se mantiene de una tarea a otra. Esto difiere de un sistema de recuperación que busca solo unos pocos fragmentos relevantes cada vez que alguien hace una pregunta. Aquí, el agente conserva un registro que evoluciona a medida que llega nueva información.

Una primera arquitectura que resultó incorrecta

Una interpretación inicial lógica de la Wiki del LLM sugiere dos capas de conocimiento separadas: una wiki generada por el agente y archivos de Obsidian colocados encima de ella. Eso era innecesario, ya que duplica el contenido y genera un problema de sincronización.

El Markdown generado puede ser él mismo la wiki, y Obsidian es simplemente una ventana para acceder a ella, un lugar donde se pueden navegar, leer y editar páginas. Markdown es el contrato compartido, mientras que Obsidian funciona como el banco de trabajo humano. Si se cambia la ventana por otra, el conocimiento que se encuentra debajo permanece igual, tal como ocurre en una wiki real. Una organización podría publicar páginas aprobadas a través de SharePoint, Confluence o un portal interno, mientras que los ingenieros y agentes siguen trabajando con la fuente mantenida.

El flujo propuesto es el siguiente: la empresa obtiene pruebas brutas e inmutables. Un agente encargado del wiki utiliza el esquema y las reglas de gobernanza para proponer cambios, y los cambios aprobados se incorporan a un wiki en Markdown respaldado por Git tras su revisión. Una capa de servicios se encarga de la autenticación, los permisos, la búsqueda y el historial de auditoría. Las personas acceden al conocimiento a través de Obsidian o un wiki corporativo, mientras que los agentes utilizan la misma capa de servicios con sus propias identidades y permisos.

El conocimiento empresarial necesita algo más que enlaces entre notas

Un archivo personal funciona en parte porque su propietario recuerda el contexto de los archivos: qué nota de reunión era especulativa, cuándo cambió un requisito aunque no se actualizara cada página relacionada, y qué dos archivos describen una misma decisión con nombres diferentes. Una empresa no puede depender de que una sola persona se encargue de todo eso.

Su sistema de conocimiento debe poder distinguir:

• una mera propuesta frente a una decisión que ya fue aprobada
• lo que existe hoy frente a lo que es solo historia
• una política oficial frente a una observación casual en una reunión
• una contradicción ya resuelta frente a una que sigue abierta
• una laguna en los registros frente a una elección que aún nadie ha hecho

Más allá de eso existen propietarios designados, pasos de revisión, referencias a fuentes, reglas sobre actualidad, límites de acceso y un registro que muestra los cambios realizados por un agente. La base de conocimientos de una persona puede tolerar la ambigüedad porque el propietario recuerda lo que falta. Sin embargo, una capa compartida por toda la empresa nunca debe permitir que una observación casual se convierta silenciosamente en una decisión aprobada.

Por eso es importante el esquema. Hace más que simplemente nombrar carpetas y archivos. A través de él, el agente comprende cómo esta empresa codifica su conocimiento. Los metadatos de una página wiki podrían verse así:

status: verified
owner: platform-team
last-reviewed: 2026-08-02
review-after: 2026-11-02
sources:
  - adr-014
  - meeting-2026-07-29
supersedes:
  - authentication-proposal-v1

Es fácil hacer que un agente genere Markdown. Lo difícil es definir qué puede considerarse como verdad organizacional.

Una empresa ficticia como entorno de pruebas

Un repositorio público de software no posee la suficiente complejidad organizacional para abordar esta cuestión. Un repositorio bien estructurado puede manejar la ingesta de datos, los enlaces y preguntas básicas, pero no contiene de forma natural requisitos cambiantes de los clientes, desacuerdos entre las partes interesadas, notas informales, arquitecturas obsoletas ni fuentes de autoridad desigual.

Para solucionar eso, el experimento ideó el Proyecto Cedar: un acuerdo ficticio en el que Northstar AI Consulting trabaja para Prairie Health Network. Todo al respecto es falso. La consultora está desarrollando un sistema que convierte documentos normativos y grabaciones de revisiones de calidad en resúmenes preliminares vinculados a sus fuentes, además de una función de búsqueda interna. Este escenario refleja preocupaciones reales como la confidencialidad de los datos, la inferencia local frente a la en la nube, la revisión humana, la evaluación de modelos, las elecciones arquitectónicas, la trazabilidad de las fuentes y los requisitos que siguen cambiando.

El corpus sintético contiene 25 artefactos iniciales en formato Markdown. En la vida real estos llegarían en muchos formatos diferentes, pero la prueba acepta ese compromiso. El material incluye información de fondo sobre las empresas, las políticas y requisitos del cliente, decisiones arquitectónicas, notas de reuniones, evaluaciones de modelos, registros del trabajo de implementación, informes de estado y entradas relacionadas con riesgos.

Un segundo conjunto de ocho artefactos posteriores modifica el proyecto. Los requisitos de seguridad se vuelven más estrictos, una evaluación de modelo invalida una suposición anterior, los criterios de aceptación cambian, y una nueva decisión arquitectónica reemplaza al diseño original, mientras que una nota informal de reunión sigue describiendo partes del diseño antiguo. Estos cambios prueban si una aplicación puede evolucionar el conocimiento almacenado.

Existen dos archivos adicionales exclusivos para el evaluador. Uno es un mapa de conocimientos que registra los hechos, decisiones, conflictos y relaciones introducidos deliberadamente en el corpus, el cual funciona como fuente de verdad. El otro es un conjunto de preguntas de evaluación con respuestas esperadas y pruebas de fuente requeridas, utilizadas para determinar si el conocimiento se actualizó correctamente. El agente encargado del mantenimiento de la wiki nunca debe verlos durante el proceso de construcción, por lo que la prueba verifica si realmente reconstruyó lo que sabía la empresa ficticia y no simplemente escribió una wiki que suene convincente.

Un experimento que puede fallar

El protocolo planeado consta de dos etapas.

En la etapa A, el agente recibe el corpus inicial y crea la primera wiki en Markdown. Debe indicar qué está desarrollando la empresa, qué restricciones rigen el sistema, las razones detrás de la arquitectura original, qué riesgos siguen sin resolverse, qué decisiones aún no están definidas y qué fuentes respaldan cada respuesta. La wiki y sus respuestas se guardan antes de que aparezcan pruebas posteriores.

En la etapa B, se publica el corpus con los cambios. Ahora el agente debe revisar cada página afectada, conservar las decisiones obsoletas como parte de la historia, hacer visibles las discrepancias pendientes y resistir la tentación de considerar el documento más reciente como la versión definitiva. La diferencia generada por Git también se convierte en evidencia: revela si el conocimiento existente se mantuvo coherente o simplemente fue reemplazado por otro resumen más.

Ese era el protocolo completo. La primera implementación real siguió un camino diferente, ya que se desarrolló como parte de otro experimento en el cual un agente de IA creó un proyecto de software durante un largo viaje en automóvil.

La primera versión

La primera versión de Cedar surgió de ese experimento con el coche, cuyos detalles no son relevantes. Lo importante es lo que entregó el agente. Sus entradas provenían del corpus de Cedar, las instrucciones para el proyecto y un conjunto de evaluación que se mantuvo fuera de su vista. El Proyecto ChatGPT en uso limitaba las subidas a 25 archivos, por lo que solo ocho de los 25 artefactos iniciales llegaron al agente, y el corpus con cambios se reservó para entregárselo más tarde como prueba de si podía incorporar dichos cambios en los documentos.

Lo que se obtuvo fue un programa local de línea de comandos escrito en Python. Leía fuentes en Markdown y su frontmatter, extraía las pruebas etiquetadas con las líneas exactas de donde provenían, y evaluaba cuán fiable era una fuente independientemente de cuándo se publicó. Los documentos con versiones explícitas se clasificaban como actuales o históricos. La herramienta también podía generar un informe de conocimiento en Markdown, buscar pruebas relevantes para una pregunta y auditar el wiki en busca de defectos estructurales. Los documentos de origen se guardaban por separado de la carpeta wiki/ generada, y el repositorio conservaba las instrucciones para el mantenedor, los registros de ejecución, el material de evaluación y los resultados en lugares específicos. Se superaron los 26 tests. Era una primera versión funcional, aunque el corpus reducido significaba que solo se podía probar una parte del protocolo Cedar.

¿Podría mantener lo que sabía la empresa?

En la evaluación restringida, el sistema obtuvo un 50% de puntaje. Fue bueno al conservar las pruebas: las referencias de origen y la procedencia a nivel de línea mostraban con exactitud dónde se originaban los hechos extraídos. La dificultad radicaba en encontrar y leer las pruebas adecuadas cuando surgía una pregunta realista.

Una verdadera pregunta empresarial puede requerir la combinación de datos de varios archivos, priorizando una decisión respaldada sobre una anotación casual, detectando que un documento más reciente podría tener menos autoridad, diferenciando una pregunta abierta de una laguna en los registros y manteniendo la incertidumbre mientras no se haya tomado una decisión final. La preservación de pruebas resultó más importante que su selección. La auditoría estructural identificó defectos mecánicos como la falta de metadatos o un diseño defectuoso, pero los conflictos semánticos pasaron desapercibidos con mayor facilidad, ya que dos documentos podían contener opiniones incompatibles en redacciones no relacionadas y el sistema no siempre detectaba esa discrepancia.

En resumen, se conservaron las citas sin comprender cuáles tenían relevancia. Para el conocimiento empresarial, eso representa una verdadera debilidad, ya que una respuesta bien citada puede seguir siendo incorrecta si se basa en una fuente de poca autoridad, ignora una decisión aprobada posteriormente o combina hechos que no deberían ir juntos.

El corpus incompleto también limita las conclusiones. El agente nunca recibió el corpus actualizado, por lo que esta prueba no evaluó la parte más difícil del diseño original: actualizar el conocimiento actual cuando cambian las fuentes autorizadas, manteniendo al mismo tiempo el estado anterior como historial. La respuesta parcial es que un agente puede crear una representación estructurada y vinculada a fuentes del conocimiento empresarial, pero aún no hay suficientes pruebas de que pueda mantenerla de manera fiable a medida que la empresa evoluciona.

La wiki necesita una interfaz empresarial

El experimento también aclaró un punto importante sobre la arquitectura. Obsidian es útil para revisar el Markdown generado, seguir enlaces, verificar metadatos y corregir páginas manualmente. Eso es suficiente para una configuración personal o un prototipo, pero ninguna empresa puede dar a cada empleado y agente acceso directo a un mismo repositorio. Entre la wiki de Markdown y sus usuarios, un sistema real necesita una capa intermedia que incluya:

• el inicio de sesión gestionado por el proveedor de identidades de la empresa
• reglas de acceso vinculadas a usuarios, equipos, proyectos y roles
• identidades distintas con sus propios derechos para cada agente
• un paso de revisión y aprobación para cada edición propuesta por un agente
• resultados de búsqueda filtrados según lo que pueda ver quien realiza la consulta
• comentarios, notificaciones y atribución de propiedad
• ediciones simultáneas y conflictos de versiones
• un registro de auditoría que indique quién o qué modificó cada página

políticas de retención y eliminación

una interfaz que el personal no técnico pueda utilizar realmente

La autenticación determina quién realiza la solicitud, mientras que la autorización decide a qué puede acceder esa identidad en cuanto a fuentes, páginas y operaciones. Los agentes se rigen por la misma división. El agente de un equipo financiero no debería poder acceder a registros clínicos solo porque ambos conjuntos de archivos se encuentran en la misma wiki; por lo tanto, los agentes necesitan sus propias identidades de servicio, permisos limitados y las obligaciones de auditoría que tienen los humanos. Los permisos también deben seguir a la información a medida que un agente la modifica: un resumen de proyecto extraído de un documento público de arquitectura y una revisión de seguridad restringida podrían exponer detalles confidenciales incluso si la página parece inofensiva.

Obsidian puede seguir siendo el entorno de trabajo para los mantenedores y revisores técnicos, mientras que la mayoría de los empleados acceden al conocimiento a través de un sitio web tipo wiki o un portal interno que muestra el mismo conocimiento mantenido mediante un servicio controlado, sin crear otra copia. La arquitectura consta entonces de cuatro partes:

1. Capa de evidencias: fuentes de la empresa inmutables con sus permisos originales
2. Capa de conocimiento: el wiki en Markdown respaldado por Git y sus relaciones de origen
3. Capa de control: identidad, permisos, revisión, historial de auditoría y búsqueda
4. Capa de interfaz: Obsidian para quienes mantienen el wiki, un sitio web de wiki para los empleados y APIs restringidas para los agentes

La interfaz de la empresa no duplica el conocimiento; controla cómo las personas y los agentes interactúan con él.

Qué probar a continuación

La próxima ejecución debe utilizar el corpus completo de Cedar: incorporar los 25 artefactos iniciales, calificar la wiki inicial y guardarla, luego introducir los ocho artefactos de cambios y verificar si el agente actualiza cada página afectada, marca las decisiones antiguas como sustituidas, conserva la historia que merece guardarse, sigue las reglas de autoridad de origen, pone de manifiesto las discrepancias sin resolver, se abstiene de tomar decisiones arbitrarias y genera un diff de Git que cualquier persona pueda revisar.

La recuperación de información también debe evaluarse por separado de su mantenimiento. Un sistema podría contener el conocimiento adecuado pero obtener pruebas incorrectas para una pregunta, o responder correctamente al buscar fuentes originales mientras su wiki mantenida se vuelve obsoleta; esos fallos requieren evaluaciones distintas. Una ronda posterior debería incluir las identidades de los usuarios y agentes en el corpus, para que las preguntas puedan verificar que un revisor autorizado reciba la respuesta correcta, mientras a otro usuario se le niegue información restringida. Eso acerca el experimento a una implementación real en una empresa.

¿Pueden los agentes mantener lo que sabe una empresa?

La primera versión de Cedar solo admite una respuesta calificada. El agente entregó un sistema funcional que aceptaba documentos similares a los de una empresa, conservaba las referencias de origen, etiquetaba las versiones de los documentos, generaba una wiki en Markdown y auditaba su estructura. Sin embargo, la evaluación mostró que esas habilidades son insuficientes, ya que mantener el conocimiento de la empresa también requiere seleccionar adecuadamente las pruebas, razonar sobre la autoridad, detectar conflictos, manejar la incertidumbre, así como realizar revisiones y control de acceso.

Markdown puede servir como el formato común, pero la empresa aún necesita una interfaz regulada alrededor de él. Tanto las personas como los agentes necesitan identidades, los permisos deben trasladarse desde la fuente original a las páginas generadas, las ediciones realizadas por los agentes requieren revisión, y cada cambio aceptado necesita un historial. Crear la wiki fue la parte fácil. Lo que realmente requiere esfuerzo es decidir qué considera la empresa como conocimiento, quién puede verlo y cómo se permite a un agente modificarlo.