Producto
Investigación y fundamentos
Cada parte de ai-memory tiene un motivo que puedes comprobar: una idea de la que viene, un bug de una herramienta anterior que evita o una cifra contra la que se midió. Esta página los recorre en seis capítulos cortos.
Construye la wiki mientras trabajas
En abril de 2026, Andrej Karpathy publicó un breve “idea file” sobre lo que llamó una LLM wiki. ai-memory es esa idea, adaptada a agentes de programación que nunca dejan de producir material.
“El conocimiento se compila una vez y después se mantiene al día, en lugar de volver a derivarse en cada consulta.”
Tres capas
Fuentes en bruto que nunca cambian, una wiki de páginas markdown que mantiene el LLM y un archivo de esquema que le dice al agente cómo funciona la wiki.
Tres operaciones
Ingerir una fuente y actualizar las páginas que toca. Consultar la wiki. Pasarle lint en busca de contradicciones y páginas huérfanas.
Fuentes en bruto
Observaciones de hooks
Wiki
Markdown en git
Esquema
Bloque en AGENTS.md
Qué conservó ai-memory
- Archivos markdown en un repositorio git, como aquello que una persona puede abrir, comparar con diff y leer.
- Compilar el conocimiento cuando llega, con una sesión que se reparte en varias páginas.
- Los wikilinks entre páginas como grafo.
- Lint para contradicciones, páginas obsoletas, huérfanas y títulos duplicados.
- Un bloque de esquema instalado en CLAUDE.md o AGENTS.md para que el agente sepa usar la wiki.
Qué cambió
El patrón de Karpathy lo cura una persona, fuente por fuente. Un agente de programación produce material sin parar y nadie lo está mirando.
| En el gist | En ai-memory |
|---|---|
| Le pasas al LLM una fuente cada vez | Los hooks de ciclo de vida capturan cada sesión por su cuenta |
| El agente lee primero index.md | Un índice fusionado: texto completo, entidades, enlaces y vectores |
| Un LLM hace todo el mantenimiento | Resúmenes basados en reglas por defecto. El LLM es opt-in |
| Una persona, una wiki | Traspasos entre agentes, varios usuarios, alcance por proyecto |
| Las páginas viven para siempre | Niveles, decaimiento, reemplazo y TTL dejan fuera las páginas obsoletas |
Los niveles, el decaimiento y el reemplazo no están en el gist de Karpathy. Vienen de agentmemory y de los textos sobre “LLM Wiki v2” que lo rodean. Las notas de lectura completas están en el repositorio.
Tu memoria ya está en un formato abierto
Open Knowledge Format es una especificación que Google Cloud publicó en junio de 2026. Describe el conocimiento como un directorio plano de archivos markdown con frontmatter YAML, un concepto por archivo y un único campo obligatorio: type. No hay SDK ni runtime.
- Desde la 2.0, la wiki es de forma nativa un bundle OKF v0.2. Los archivos con los que trabaja ai-memory son los archivos OKF, así que no hay un paso de exportación que pueda desviarse de la verdad.
- Un proyecto es un bundle, con un
index.mdgenerado en su raíz. - Cada página tiene frontmatter YAML con un
type, derivado de la carpeta en la que vive. - Actualizar desde la 1.x reescribe el frontmatter en el sitio después de una copia de seguridad verificada. Si la copia falla, la migración se detiene.
ai-memory export-okf --project myproject -o myproject-bundle.tar.gz
No hay comando de importación. Descomprime un bundle en el directorio de la wiki de un proyecto y el file watcher lo indexa. El mapeo a OKF está documentado campo por campo, y la especificación vive en el repositorio knowledge-catalog de Google Cloud.
| Carpeta | Tipo OKF |
|---|---|
sessions/ | Session Summary |
decisions/ | Decision |
gotchas/ | Gotcha |
procedures/ | Procedure |
concepts/ | Concept |
_rules/ | Rule |
notes/ | Note |
runbooks/ | Runbook |
_slots/ | Invariant o State |
Un proyecto
index.md
Decisión
Gotcha
Procedimiento
Obsidian
grep
Otra herramienta OKF
“El modelo y el harness son alquilados, la memoria del proyecto es tuya.”
Ocho decisiones, y el motivo de cada una
La mayoría se remonta a un issue concreto de una herramienta de memoria anterior.
Elegimos
Markdown en git como la verdad
porque las herramientas habituales de Markdown pueden leer las páginas. Su índice de búsqueda se reconstruye, pero sesiones, traspasos y cuentas también requieren una copia de la base.
Elegimos
Un solo archivo SQLite
porque el texto completo, los vectores empaquetados y las tablas de enlaces viven en un único archivo embebido. Los issue trackers de otros proyectos mostraron cuántos bugs de corrección cuesta sincronizar tres almacenes.
Elegimos
Cero llamadas a LLM por defecto
porque los resúmenes de sesión se basan en reglas, así que una instalación nueva no gasta nada. La lección vino de funciones con LLM activadas por defecto en otros proyectos, que sorprendieron a sus usuarios con facturas de tokens.
Elegimos
Un solo binario
porque SQLite va incluido, libgit2 va vendorizado y el embedder es Rust puro. Un motor sidecar aparte fue el mayor foco de problemas para los usuarios del proyecto al que este sucede.
Elegimos
Sin base de datos de grafos
porque el grafo son tablas SQL: una tabla de enlaces y consultas recursivas. Eso cubre la expansión a un salto y las aristas tipadas sin un motor de grafos embebido que mantener vivo.
Elegimos
Los vectores son opcionales
porque los embeddings locales vienen activados desde la 2.0 y siguen sin ser obligatorios. La búsqueda es coseno por fuerza bruta dentro de SQLite; una extensión vectorial espera hasta que el número de páginas o la latencia la pidan.
Elegimos
Traspasos como protocolo tipado que se reclama una sola vez
porque cada ronda de investigación señaló la transferencia entre agentes como el punto débil de las herramientas anteriores. Un traspaso es un registro tipado que se asocia por directorio, y exactamente una sesión puede aceptarlo.
Elegimos
Páginas en vez de filas de hechos
porque una página sobre una decisión se puede leer, editar y explicar en prosa. Una tabla de hechos extraídos no se puede abrir en Obsidian ni revisar en un diff.
A hombros de otros
El proyecto leyó el código y los issue trackers de las herramientas que llegaron antes, se quedó con las ideas que aguantaron y dejó fuera las partes que se rompían una y otra vez.
Karpathy wiki
agentmemory
basic-memory
cognee
Hermes Agent
A-MEM
Hindsight
ai-memory
- Karpathy LLM Wiki
- Compila, no recuperes. La wiki en disco es el artefacto.
- agentmemory
- Captura automática con hooks, niveles de memoria, reemplazo, decaimiento como fórmula y ranking fusionado. ai-memory es su sucesor en Rust: las ideas se quedaron, el sustrato cambió.
- basic-memory
- Los archivos como fuente de verdad con un índice derivado, y enlaces hacia páginas que todavía no existen.
- cognee
- La forma del pipeline de tareas, los sellos de procedencia en cada página y el feedback que ajusta el ranking.
- Hermes Agent
- El diseño del bucle de automejora que revisa en segundo plano las sesiones terminadas.
- A-MEM
- Notas atómicas al estilo Zettelkasten que se enlazan entre sí automáticamente.
- Hindsight
- Etiquetas de redacción tipadas, recuentos de evidencia por página y un resumen que abre con las reglas ya asentadas.
- Honcho
- Las respuestas con citas, los niveles de razonamiento y la planificación de la pasada de sueño: disparo por inactividad, cancelación ante actividad, lo más novedoso primero.
Ninguno de estos proyectos avala ai-memory. Para saber dónde va por delante cada uno, mira la comparación.
Qué se midió
La ejecución de la versión 3.3.3 evaluó 470 preguntas respondibles de LongMemEval-S con captura y búsqueda reales. El texto completo alcanzó 0.951 en hit@5; los embeddings locales, 0.943. Estas cifras miden recuperación, no exactitud de las respuestas. El hit@10 local volvió a 0.977, y el informe sigue la variación entre ejecuciones del modo local.
- Solo texto completo, antes de la 2.00,617
- Texto completo con stopwords filtradas0,666
- Más embeddings locales0,815
- 3.3.3: texto completo, con el flujo de observaciones0,951
- 3.3.3: embeddings locales, con el flujo de observaciones0,943
Qué fue cada paso
- Quitar las stopwords de las consultas de texto completo sumó 4,9 puntos de hit@5.
- El modelo de embeddings dentro del proceso sumó más, sin clave de API.
- El flujo de observaciones, activado por defecto desde la 3.0, deja que las observaciones en bruto de una sesión voten por su página. Subió el texto completo de 0,662 a 0,951.
- En ninguna fila intervienen una clave de API ni un LLM.
| Métrica | Antes de la 2.0 | Texto completo filtrado | Embeddings locales | 3.3.3, texto completo | 3.3.3, embeddings locales |
|---|---|---|---|---|---|
| hit@5 | 0,617 | 0,666 | 0,815 | 0,951 | 0,943 |
| hit@1 | 0,449 | 0,532 | 0,536 | 0,857 | 0,760 |
Ejecútalo tú mismo
Añade --candidate-embeddings local al segundo comando para ejecutar texto completo y embeddings locales lado a lado. Las ejecuciones publicadas son del 3 de noviembre de 2026, en un Ryzen 9 7950X3D.
cargo build --release -p ai-memory-cli
cargo run --release -p ai-memory-eval -- retrieval --fetch
Resultados completos, por tipo de pregunta
También se midió el rendimiento de escritura. Los números están en la página de arquitectura.
Qué recuperó el flujo de observaciones
Una página de sesión guarda solo un extracto corto de cada turno, así que el detalle por el que pregunta una pregunta a menudo vive solo en las observaciones de la sesión. Con el flujo activado, cada sesión que coincide vota una sola vez, a través de su mejor observación, por su propia página. Las mismas 470 preguntas, la misma build, con el flujo desactivado y luego activado.
| Métrica | Texto completo, sin LLM | Embeddings locales |
|---|---|---|
| hit@5 | 0,662 → 0,951 | 0,796 → 0,936 |
| hit@1 | 0,511 → 0,857 | 0,536 → 0,757 |
| hit@10 | 0,687 → 0,972 | 0,881 → 0,970 |
| recall@5 | 0,533 → 0,893 | 0,657 → 0,871 |
| Tiempo de consulta, percentil 95 | 90 ms → 112 ms | 264 ms → 234 ms |
| Tokens de contexto, cinco primeros resultados | 256,3 → 266,1 | 225,7 → 264,1 |
- Esta comparación de flujos es el experimento de descomposición del 12 de octubre. La ejecución separada de la versión 3.3.3 midió 0,943 con embeddings locales. No repite este experimento de activar y desactivar el flujo.
- Con el flujo activado, el texto completo por sí solo puntúa un poco por encima de los embeddings locales. El vector de la página, igual que su fila de texto completo, sigue viendo solo un cuerpo que contiene únicamente el título.
- Dentro de una misma ejecución el harness es determinista. Entre ejecuciones separadas, los tipos de pregunta más pequeños se mueven hasta 0,03 en cualquier dirección, así que una caída en uno de ellos en una sola ejecución significa poco.
- Las cifras que otras herramientas publican sobre este dataset salen de sus propios harnesses, que a menudo indexan sesiones en bruto completas sin paso de captura. No son comparables punto por punto, y no se afirma ningún ranking entre herramientas.
Qué viene después, y dónde va por detrás
Son recomendaciones documentadas en el repositorio. Ninguna tiene fecha.
Lo siguiente recomendado
Precisión de las respuestas a escala completa
El segundo harness ya tiene una ejecución completa de recuperación, con precisión, tiempo de consulta y tokens de contexto. Su modo de precisión de respuestas solo cuenta por ahora con una muestra de 20 preguntas, y los puntos de abajo dependen de él.
Un reranker local
Un cross-encoder que corre dentro del proceso, sin LLM. En un conjunto de 102 preguntas de un contribuidor, un adaptador documentado a un modelo juez local ya igualó al reranker alojado con una fracción de la latencia.
Valores por defecto respaldados por cifras
El ranking por confianza, la compactación de páginas frías, la deduplicación y el dream pass necesitan configuración explícita. La retención basada en lecturas ya funciona por defecto. Otros cambios de valores predeterminados requieren mediciones; los enlaces tipados aún no tienen peso extra en el ranking.
Un arranque más fácil para quien usa Claude Code
Un importador para quien viene de la memoria integrada de Claude.
No está previsto: una base de datos de grafos, un sistema operativo de memoria que se edita a sí mismo, conectores a la nube ni aumentar el número de herramientas porque sí.
Dónde va por detrás hoy
Todavía no hay un reranker local, y el envejecimiento de la memoria no tiene ningún resultado medido. La lista completa está en la página de comparación.
“La 1.x demostró que la idea funcionaba. La 2.0 es la versión que recomendaría sin asterisco a otra persona para ponerla en un equipo.”
Preguntas y respuestas
¿Qué es la idea de la LLM Wiki de Karpathy que hay detrás de ai-memory?
El gist de Andrej Karpathy de abril de 2026 describe un LLM que construye y mantiene una wiki persistente de archivos markdown entre tú y tus fuentes en bruto, de modo que el conocimiento se compila una vez y se mantiene al día. ai-memory aplica eso a los agentes de programación, con captura automática desde los hooks de ciclo de vida y una ruta por defecto que no hace llamadas a un LLM.
¿ai-memory es compatible con el Open Knowledge Format?
Desde la 2.0, cada proyecto de la wiki es de forma nativa un bundle OKF v0.2. Cada página tiene frontmatter YAML con un type, cada proyecto tiene un index.md generado, y ai-memory export-okf empaqueta un proyecto en un tarball validado.
¿Qué mide el benchmark LongMemEval-S en ai-memory?
Solo recuperación: si una sesión que contiene la evidencia aparece entre los primeros resultados, sobre 470 preguntas. hit@5 es 0,951 con texto completo y el flujo de observaciones, y 0,943 con embeddings locales. No mide la precisión de las respuestas.
Lee el razonamiento. Después, pruébalo.
Gratis y de código abierto. La instalación por defecto no hace llamadas a un LLM y solo escucha en tu máquina.