LLM Wiki en producción: 4 meses con el patrón de Karpathy y las reglas que lo hacen funcionar

Un LLM Wiki es una base de conocimiento que una IA escribe y mantiene por ti. Tú pones las fuentes y las preguntas. El modelo se encarga de archivar, de enlazar, de resumir y de limpiar. Andrej Karpathy describió el patrón en un gist corto, y la idea se difundió rápido porque resuelve lo que todo el mundo odia de “chatear con tus documentos”: cada respuesta empieza de cero.

En Bamboo Tech Studio operamos sobre uno desde la primavera. Es un vault de Obsidian que Claude Code y un puñado de agentes más mantienen junto a dos personas. Ahí viven nuestros clientes, proyectos, servidores, propuestas, decisiones y las reglas que siguen nuestros agentes. A hoy suma más de 660 commits desde que lo pusimos bajo git el 13 de junio de 2026, 29 skills reutilizables, 14 decisiones registradas y una memoria de agente con 81 notas, muchas de ellas lecciones que los propios agentes anotaron para sí mismos.

Casi todo lo que hoy posiciona para “LLM Wiki” explica la idea o muestra cómo montarlo en un fin de semana. Esta es la otra mitad: qué pasa cuando de verdad operas un negocio sobre él.

El patrón en un párrafo

La versión de Karpathy tiene tres piezas. Una carpeta de fuentes originales que nadie edita después de capturarlas. Un wiki de páginas Markdown que el modelo escribe y mantiene enlazadas. Y un esquema, un documento simple que le dice al agente qué forma tienen las páginas y qué operaciones existen: ingerir una fuente, consultar el wiki y pasarle un lint para encontrar enlaces rotos y contradicciones. Nuestra copia del esquema de referencia resume la diferencia con RAG en una línea: “el wiki es un artefacto persistente”. La síntesis se hace una vez y se queda.

Cómo lo adaptamos

No copiamos la estructura al pie de la letra. Nuestro vault ya tenía una taxonomía para operar una empresa, así que el mismo día que lo pusimos bajo git fusionamos ahí la maquinaria del wiki:

• Carpetas semánticas en lugar de una carpeta wiki/. Las personas y empresas viven en ENTITIES, el trabajo con clientes en PROJECTS, los servidores y cuentas en INFRASTRUCTURE, la síntesis en KNOWLEDGE y las decisiones que cruzan proyectos en DECISIONS. Cada nota vive donde su significado lo indica, así que un agente puede predecir dónde buscar.
• Una ficha por carpeta, con el nombre de la carpeta. PROJECTS/Some-Client/Some-Client.md. Los wikilinks se resuelven por nombre, y el grafo muestra nombres reales en lugar de decenas de archivos llamados project-card.md.
• .raw/ es inmutable. Las transcripciones, capturas de pantalla y exportaciones entran una vez y no cambian nunca. Todo lo que el agente escribe sobre ellas vive en otro lugar y enlaza de vuelta.
• Dos esquemas de frontmatter conviviendo. Las fichas operativas (cliente, servidor, proyecto) tienen una forma; las páginas de síntesis (concepto, comparación, decisión) tienen otra, con un estado de madurez.
• Un archivo de esquema por familia de agentes. CLAUDE.md para Claude Code, un AGENTS.md más corto y neutral para Codex y otros, y una carpeta STANDARDS/ que manda cada vez que no coinciden.

Lo que de verdad aporta el valor

El gist de Karpathy pone el foco en las páginas de síntesis: conceptos, comparaciones, preguntas archivadas. En un wiki que opera una empresa, la mayor parte del valor sale de la capa operativa:

1. Un registro de tareas que es la única puerta de entrada. Cada tarea recibe una fila y un enlace a la nota que la documenta, en la misma edición. Para cerrarla hace falta una línea que diga qué pasó, incluido “cerrada sin hacerla, porque X”.
2. Skills, no prompts. El trabajo recurrente (publicar un sitio, aprovisionar un servidor, limpiar un WordPress hackeado) es un SKILL.md que el agente carga y sigue. Las 29 skills son lo más parecido que tenemos a un manual de operaciones, y mejoran cada vez que alguien las corrige.
3. Decisiones con fecha y motivo. Cuando se vuelve a discutir algo, el agente encuentra el razonamiento anterior en lugar de abrir el debate desde cero.
4. La memoria del agente como archivos. (Más sobre cómo encaja esto con los otros tipos de memoria en memoria de agentes de IA en la práctica.) Cuando un agente aprende algo que vale la pena recordar, escribe una lección corta con el motivo y cómo aplicarla. Algunos ejemplos de las nuestras: los agentes no saben qué fecha es hoy; un resultado vacío puede significar “descartado”, no “inexistente”; que un proveedor diga “recibido” no significa que lo aceptó.
5. Un linter que falla de forma ruidosa. Un script de 391 líneas, sin dependencias, revisa enlaces muertos y ambiguos, tareas sin registrar, filas duplicadas, archivos demasiado grandes y alrededor de una docena de patrones de secretos. Es el sistema inmune del wiki.

Cinco modos de fallo de un LLM Wiki compartido, y la regla para cada uno

1. Una sola caché compartida termina sobrescrita. El esquema de referencia sugiere un único archivo de “caché caliente” con el contexto reciente. Con varias personas y sesiones de agentes, cada sesión lo reescribe completo y el contexto anterior se pierde. La regla: cada operador tiene su propia caché caliente y su propio log; todos leen los de todos, y cada uno escribe solo los suyos. Cuando una caché pasa de unas mil palabras con varios hilos activos, conviene dividirla en un índice corto más un archivo por hilo.

2. Los números de fila chocan. Cuando varias sesiones y personas agregan filas al mismo registro, los números se reutilizan, y una edición guiada por el número de fila puede caer sobre la fila de otro. La regla: editar filas por texto único, nunca por número, hacer pull antes de agregar y tomar el siguiente número libre en el momento de escribir.

3. Los fallos se archivan como estados normales. Algo falla y queda registrado como si hubiera funcionado. Un monitor que solo alerta cuando encuentra algo se ve idéntico a un monitor que se murió. Nuestro estándar para esto tiene doce reglas, entre ellas “el estado por defecto nunca es el optimista”, “confirma solo cuando el efecto ya ocurrió” y “una regla que vive solo en el prompt no es una regla”.

4. Una carpeta compartida lleva más de lo que querías compartir. Una parte de nuestro vault es un subtree de git que intercambiamos con un socio externo, en ambas direcciones. La regla: un guardia hace cumplir el límite, para que nunca dependa de que alguien se acuerde. Un hook de pre-commit rechaza cualquier cosa que pertenezca a entidades que no deben salir, y lo decide por campos de propiedad, no por carpeta ni por tipo de nota. Los guardias así crecen por capas: cada vez que una revisión resulta demasiado estrecha, se agrega otra.

5. Los agentes remotos entran por la misma puerta que los locales. La regla: los agentes que corren en servidores reciben una puerta más chica. Los nuestros no tienen permiso de escritura en el vault. Leen un espejo y solo pueden agregar archivos a su propia carpeta de propuestas, algo que el servidor hace cumplir con un hook atado a su llave SSH. Una persona fusiona lo que vale la pena conservar.

¿Es un segundo cerebro?

En parte. Quienes arman un “segundo cerebro en Obsidian” (los datos de Google Ads muestran que las búsquedas del término se multiplicaron más de ocho veces en un año) construyen casi siempre uno personal. El nuestro es compartido, y esa diferencia importa. Un segundo cerebro personal tolera el desorden porque una sola persona sabe qué quiso decir. Uno compartido necesita las reglas de arriba; si no, cada sesión nueva y cada persona nueva agregan ruido más rápido de lo que el agente alcanza a limpiar.

Lo que te da un wiki de empresa y no te da uno personal: continuidad entre personas y sesiones. Cualquiera de nuestros agentes puede retomar el hilo de un cliente, ver la última decisión, las tareas abiertas, el servidor donde corre y las lecciones registradas en trabajos parecidos, sin que nadie tenga que ponerlo al día.

Cómo empezar uno esta semana

1. Crea la carpeta y ponla bajo git desde el primer día. El historial es el registro de auditoría más barato que vas a conseguir. El nuestro tiene más de 660 commits, y es como averiguamos quién cambió qué, y por qué.
2. Escribe el esquema antes de la primera nota. Mapa de carpetas, frontmatter por tipo de nota y las tres operaciones. Mantenlo lo bastante corto como para que el agente de verdad lo lea.
3. Haz del registro de tareas la puerta de entrada desde el inicio. Agregarlo después es mucho más difícil.
4. Dale a cada operador sus propios archivos de trabajo. Lectura compartida, escritura privada.
5. Agrega un linter en la primera semana, aunque sea rudimentario. Los enlaces muertos y las tareas sin registrar son los primeros síntomas del desorden.
6. Deja que el agente escriba sus propias lecciones. Una carpeta de memoria donde cada error se convierte en una regla de un párrafo, con su motivo, vale más que cualquier prompt que vayas a escribir.

Lo que conviene tener desde el primer día

Separa la caché caliente por persona desde el principio. Escribe la regla de “los fallos no son estados normales” antes de necesitarla. Dedica las primeras horas a la capa operativa (registro, skills, decisiones, linter) y menos a páginas de síntesis que todavía nadie lee. El wiki que perdura es el que hace andar el trabajo.

Si quieres ver cómo se aplica esto a una operación real, o necesitas ayuda para montar uno para tu equipo, hablemos. Es el mismo sistema que usamos para construir y operar los agentes de IA y automatizaciones que entregamos a nuestros clientes, incluidos los agentes de WhatsApp de los que escribimos aquí.