¿Los multiagentes solo consumen muchísimos tokens y además pierden el contexto seguido? Por eso hice un LLM Wiki con una estructura de "redacción periodística".

• Últimamente están apareciendo muchos sistemas multiagente autónomos, pero cuando uno realmente los pone a correr terminan consumiendo entre 5 y 10 veces más tokens y además pierden el contexto con frecuencia. Por eso estructuré el sistema multiagente tomando como modelo la redacción de un periódico.
• Hay cinco roles de agentes, pero el único agente en el que el LLM decide por sí mismo es el desk (revisión). Los demás son tareas de escritura, o bien verificaciones en Python basadas en reglas (lint) en lugar de un LLM, además de la coordinación del trabajo (orquestación).
• Igual que en el concepto de LLM Wiki, se leen los documentos originales para crear páginas fuente, de ahí se extraen borradores de personas y conceptos, y luego se van apilando en resúmenes por tema, páginas de contradicciones y páginas integrales. El almacenamiento es simplemente en archivos Markdown con git, y todas las herramientas de Python corren en local. Con solo hacer clone, se puede ejecutar de inmediato el grafo de ejemplo sin necesidad de una API key.
• El ejemplo que hoy está en GitHub trata el debate sobre qué significa el open source en la IA, pero el framework en sí no está limitado por tema.

---

Por qué no simplemente solté varios agentes al mismo tiempo

• Los testimonios de quienes realmente lo han ejecutado gastando miles de dólares llegaban más o menos a la misma conclusión: solo se consumen montones de tokens, los agentes pierden el contexto mientras se pasan cosas entre sí, y marcan tareas incompletas como si ya estuvieran terminadas.
• Por eso, en vez de dejar que todo dependa de decisiones autónomas, le di más peso a reglas definidas y al aislamiento de contexto. Aunque use la metáfora de una redacción, el único LLM que realmente toma decisiones con libertad es el desk; los demás solo hacen tareas predefinidas.

Si respondo por adelantado a posibles objeciones

• Los documentos van a seguir creciendo hasta volverse inutilizables: me parece la preocupación más realista. Por eso separé por completo el rol de escritura del desk que decide si algo pasa o no. Al desk solo se le muestran los resultados y los criterios de evaluación, sin dejarle ver con qué intención escribió el autor. Además, un lint basado en reglas filtra mecánicamente los casos en que los documentos se inflan, se duplican o se alargan sin rumbo. Aun así, no diría que la hinchazón quede "resuelta".
• Si se repite la edición, los errores se acumulan, y si se corrige con retroalimentación generada por sí mismo, al final solo repite los mismos patrones: esta sospecha siempre acompaña cualquier idea de mejora autónoma, y me parece válida. Por eso, cuando los defectos que el desk detecta de forma reiterada se reincorporan a las guías, reemplazo cada vez los casos de fallo usados para validación, para evitar acostumbrarse solo al mismo examen (overfit). En otras palabras, siempre se verifica con casos nuevos. También agregué una comprobación en las páginas integrales para contrastar si no se están mezclando sin cuidado contenidos de fuentes distintas.
• Entonces al final no es más que un RAG con embeddings cambiados a mano: si el objetivo fuera buscar, sería una crítica válida. La diferencia es que el resultado no es un índice vectorial sino documentos conectados que una persona puede leer directamente, y además las partes donde las fuentes no coinciden no se tapan, sino que se exponen aparte en páginas de contradicciones. La apuesta no es volver a raspar los textos originales cada vez que se hace una pregunta, sino dejar acumulado el juicio construido.

Un concepto antiguo: Memex

• Lo hice teniendo presentes corrientes como el Memex de Vannevar Bush (una máquina de información conectada concebida en 1945) y "Man-Computer Symbiosis" de Licklider.
• Por eso incluí trails (rutas asociativas) que conectan páginas entre sí y una función discover para encontrar conexiones inesperadas. La idea no es extraer índices automáticamente, sino dejar caminos que una persona pueda recorrer por sí misma.

Consideraciones de uso

• Decir "no hace falta API key" es solo medio cierto: el Python dentro de tools corre en local, así que no necesita claves externas. Pero los agentes en sí funcionan con Claude Code, así que cada quien tiene que usar su propia clave (BYOK).
• El repositorio público contiene sobre todo la idea y ejemplos pequeños: incluye un ejemplo en inglés de 15 nodos, así que cualquiera puede reproducir el mismo grafo con solo hacer clone. La instancia real que yo he usado a diario, con alrededor de 2,300 nodos, la mantengo aparte como privada, así que conviene distinguirla del repositorio público.
• Modo coreano (WIKI_LANG=ko): solo cambia al coreano el cuerpo del texto y el frontmatter de la parte superior del documento, mientras que las marcas que indican la estructura del documento (## Summary, [fact], etc.) se dejan intencionalmente en inglés. Es decir, no es "coreano completo".

Cómo surgió y en qué estado está ahora

• Todo comenzó al agregar una implementación al gist de LLM Wiki que compartió Karpathy. Este concepto en sí ya había sido presentado antes en GeekNews: https://es.news.hada.io/topic?id=28208
• Aún sigue siendo una hipótesis en experimentación, no un resultado medido de forma rigurosa, si separar la parte de escritura de la de revisión realmente reduce los casos en que se aprueba algo de manera descuidada, o si el bucle de mejora autónoma de verdad ayuda.