Tu próximo agente de código no debería empezar de cero

Lo más caro de cambiar de agente de código no es la suscripción. Es la hora que te pasas explicando tu proyecto otra vez.

Qué archivos importan, qué enfoque ya falló, por qué los tests están armados así, qué está haciendo la rama a medio terminar. Claude Code no sabe nada de eso. Codex tampoco, ni Cursor ni Gemini CLI. Cada uno arranca con una ventana de contexto vacía y buena disposición para ayudar.

ai-memory es un binario en Rust que intenta arreglar eso, y sus decisiones de diseño son más interesantes que la lista de funciones.

Una memoria, muchos harness

La propuesta es que una veintena larga de harness de agentes —Claude Code, Codex, Cursor, Gemini CLI, OpenCode, Grok, Devin, Kimi, Kiro y el resto— lean de un mismo almacén de memoria compartido. Trabajas en uno, paras a mitad de tarea, abres otro en el mismo directorio y este sigue donde lo dejó el primero.

El mecanismo es un handoff tipado. No un resumen que el agente genera y espera que sea exacto, sino un registro explícito con un dueño que solo se puede reclamar una vez. Esa restricción es la parte útil: dos agentes no pueden creer los dos que están continuando el trabajo, y un handoff abandonado queda a la vista en vez de perderse en silencio.

También hay una capa entre proyectos. Tus preferencias de trabajo —gestor de paquetes, cómo están organizados los tests, cómo te gusta estructurar los módulos— te acompañan a repositorios nuevos, así que un checkout recién clonado no empieza de cero en lo que vale en todas partes.

Markdown como fuente de verdad

Aquí viene la decisión de diseño que vale la pena discutir.

Los sistemas de memoria para agentes suelen significar embeddings. Troceas el historial, lo embebes, lo guardas en una base de datos vectorial, recuperas por similitud. Funciona, y tiene tres problemas: no puedes leerlo, no puedes hacer diff, y la recuperación es tan opaca que cuando devuelve lo que no toca no tienes idea de por qué.

ai-memory lo invierte. La fuente de verdad es un wiki en Markdown plano, versionado con git. El índice SQLite —búsqueda de texto completo, entidades, embeddings— es derivado y reconstruible. Borra la base de datos y no pierdes nada.

Esa sola decisión rinde mucho. Puedes hacer grep en el wiki. Puedes abrirlo en Obsidian. Puedes corregir a mano una entrada equivocada. Puedes sincronizarlo con rsync. Puedes leer un diff y ver que la comprensión que el agente tenía de tu arquitectura cambió el martes. Y no hay ningún vector store al que quedarte atado.

También significa que la memoria es auditable de una forma que importa en equipos. «Por qué cree el agente que usamos pnpm» es una pregunta cuya respuesta es un archivo.

Envejecer sin borrar

El proyecto describe un sistema de envejecimiento de la memoria: decaimiento por niveles, retención ponderada por accesos, deduplicación y marcado de contradicciones. Las notas que no se usan bajan de prioridad sin desaparecer, y las entradas en conflicto se marcan en vez de sobrescribirse sin avisar.

El detalle importante es que nada se borra de forma definitiva. Las páginas viejas siguen en git y un comando de restauración las devuelve. Dado lo a menudo que la nota «obsoleta» de un agente resulta ser el único registro de por qué se tomó una decisión, es el valor por defecto correcto.

Hay una función opcional llamada dreaming, que usa un LLM para reescribir grupos de notas frías durante el tiempo muerto. Viene desactivada y el README dice explícitamente que nunca borra el material de origen. Que venga apagada por defecto es lo correcto para cualquier cosa que reescriba tus notas con un modelo.

La instalación es de verdad corta

Dos comandos en Linux o macOS: un instalador de curl a shell que verifica un checksum SHA-256, y luego ai-memory setup, que crea el directorio de datos, arranca un servicio a nivel de usuario y conecta los agentes que detecte. Hay un equivalente en PowerShell para Windows, más AUR, RPM, Nix, Docker y entradas en el marketplace de plugins para Claude Code y Codex.

El uso diario gira alrededor de un wrapper: ai-memory run claude en lugar de claude. Instala los hooks y el servidor MCP correctos en la primera ejecución y limita la sesión al proyecto actual. A partir de ahí, ai-memory continue retoma el último checkout gestionado, y resume --search auth elige entre tus workflows por nombre.

Hay un comando bootstrap que importa el historial existente del proyecto de una sola pasada, que es la diferencia entre una herramienta que adoptas y una que llevas tiempo pensando en adoptar.

Las partes incómodas

La captura silenciosa mediante hooks de ciclo de vida significa que el sistema registra prompts, llamadas a herramientas y límites de sesión mientras trabajas. Es la única forma de que esto funcione —no vas a llevar un diario a mano—, pero conviene tenerlo claro. Un registro de cada prompt que escribiste contra el código de un cliente es material sensible, y ahora está en un directorio versionado con git.

Las mitigaciones son razonables: por defecto solo escucha en loopback, y el setup genera un bearer token que se escribe en un archivo legible solo por el dueño, no en la configuración de tu agente. Pero el quickstart de Docker corre sin autenticación, y el README lo marca como solo para uso local. Si expones ese puerto sin un proxy inverso con TLS, has publicado tu historial de trabajo.

La parte de equipo está más madura de lo que esperaba para un proyecto tan joven: servidor compartido, compartición por proyecto, handoffs privados, autenticación multiusuario, atribución y un log de auditoría, todo fuera del plan de pago. Ese es el conjunto de funciones que decide si esto sobrevive al contacto con una organización de ingeniería real.

Si no quieres montar un servidor

Objeción justa: «mi propio servidor» es una frase que pierde a la mitad de la audiencia al instante.

No tiene que ser un servidor. El comando de setup arranca un servicio a nivel de usuario en la misma máquina, atado a loopback, y ese es el camino por defecto: sin homelab, sin VPS, sin DNS. Las funciones entre máquinas y de equipo solo importan cuando las quieres, y son separables del bucle principal.

También hay una app de barra de menús para macOS construida desde el repo, y una vista web de solo lectura por si prefieres navegar tu wiki en el navegador y no en el editor. La vía de Docker existe sobre todo para quien ya piensa en contenedores.

Así que la escalera de adopción honesta es: instálalo en tu portátil, deja que capture un proyecto y mira si el wiki que produce es algo que de verdad leerías. Si lo es, lo demás viene solo. Si el wiki es ruido, ninguna función de equipo lo va a salvar.

Por qué importa más de lo que parece

El mercado de agentes está hoy organizado alrededor de los proveedores, y los proveedores no tienen ningún incentivo para facilitar que te vayas. Tu contexto es el lock-in. Por eso el costo de cambiar se siente más alto de lo que sugiere el precio de la suscripción.

Una herramienta que se sienta debajo de todos ellos y guarda la memoria en un formato que es tuyo es un pequeño acto de estandarización del lado del usuario. Que ai-memory sea la que gane es casi lo de menos: la forma de la solución —texto plano portable con un índice reconstruible— es obviamente la correcta, y es la forma contra la que tarde o temprano tendrá que competir toda función de memoria propietaria.

Además, es un solo binario y no necesita API key para el bucle principal. Eso es raro en una categoría donde «memoria» suele significar «otra suscripción».