Un wiki mantenido por agentes LLM para no perder el conocimiento del equipo

Todo proyecto de investigación acumula un tipo de conocimiento que casi nunca sobrevive: los experimentos fallidos, las hipótesis descartadas y las afirmaciones que se retiraron sobre la marcha. Las publicaciones y el código compartido los excluyen de forma sistemática, y la consecuencia se paga en tiempo: futuros colaboradores reintentan los mismos callejones sin salida porque no existe registro de que alguien ya pasó por ahí. Un paper publicado hoy, 30 de julio de 2026, en arXiv bajo el identificador arXiv:2607.24759, propone atacar ese problema con un wiki mantenido por agentes LLM que se coloca entre las fuentes en bruto y el propio agente.

Los autores parten de dos limitaciones que cualquiera que trabaje con agentes de código reconocerá al instante. La primera: los agentes LLM ya son participantes habituales en proyectos de investigación y trabajo de conocimiento, pero no conservan memoria persistente entre sesiones; cada conversación arranca de cero. La segunda: la generación aumentada por recuperación (RAG) sobre fuentes en bruto no acumula valor con el tiempo. Recuperar fragmentos de los documentos originales una y otra vez no construye una comprensión compartida del proyecto, solo la reconstruye parcialmente en cada consulta.

El patrón llm-wiki, convertido en plantilla

La respuesta del paper se apoya en el patrón llm-wiki, que los autores atribuyen a trabajos de Karpathy y del proyecto tonbi, ambos de 2026. La idea consiste en insertar un wiki interconectado y mantenido por el propio LLM entre las fuentes originales y el agente que las consume. En lugar de consultar papers, código y notas dispersas, el agente lee y escribe páginas de wiki que destilan hallazgos, decisiones y razonamientos.

La aportación concreta del trabajo es llm-wiki-memory-template, una instanciación reutilizable y consciente de agentes de ese patrón. Los autores la defienden como sustrato para trabajo de conocimiento colaborativo heterogéneo en tres ejes: varios humanos, varios agentes de IA y varios dominios a la vez. Según el paper, cada eje se apoya en un elemento arquitectónico distinto de la plantilla, detallado en su sección 4.

Append-only: conservar lo que no funcionó

La decisión de diseño más interesante es que el wiki es append-only por convención: las entradas se acumulan en lugar de editarse para reflejar solo la verdad del momento. Eso preserva lo que no funcionó junto a lo que sí, y ataca de frente lo que los autores llaman el problema de pérdida de resultados negativos. Una hipótesis retirada no desaparece; queda visible junto a su corrección, de modo que el siguiente colaborador, humano o agente, sabe que ese camino ya se exploró y por qué se abandonó.

Conviene subrayar el matiz: por convención significa que nada lo impone técnicamente. La plantilla propone la disciplina, pero no la garantiza, y ahí estará buena parte de la fricción real cuando varios equipos y varios agentes escriban a la vez.

Para quién es útil

El planteamiento resultará familiar a cualquier equipo que use Claude Code u otros agentes de código en sesiones largas. Muchos ya improvisan algo parecido: archivos CLAUDE.md, directorios de memoria, notas de sesión que el agente lee al arrancar. La diferencia es que esas soluciones suelen ser personales, sin estructura común y sin enlaces entre entradas. Una plantilla compartida, pensada desde el inicio para que la lean y la escriban tanto personas como agentes, formaliza esa práctica y la hace transferible entre proyectos.

Los candidatos naturales son grupos de investigación con rotación de miembros, proyectos educativos donde cada cohorte hereda el trabajo de la anterior y equipos de ingeniería que ya delegan tareas en agentes y pierden contexto cada vez que se cierra una sesión.

Queda por ver cómo se comporta la plantilla con volúmenes grandes de entradas y con agentes que escriben con criterios distintos. El paper es en buena parte una propuesta de arquitectura y un argumento de posición, no una evaluación empírica extensa, y conviene leerlo con esa expectativa.

En ElephantPink llevamos meses manteniendo memoria curada a mano para nuestros agentes, y el diagnóstico del paper nos parece acertado: lo que se pierde entre sesiones no son los aciertos, que acaban en el código, sino los descartes. Una plantilla común no resuelve por sí sola la disciplina que exige, pero es un punto de partida bastante más serio que las notas improvisadas.