anathem: memoria local para agentes de código

Cada sesión de un agente de código empieza en blanco. Le explicas otra vez dónde está el endpoint, que el proveedor de pagos es Adyen, que esa migración no se puede correr en producción. Lo aprendió ayer y hoy no se acuerda.

anathem es la memoria que va entre una sesión y la siguiente: un binario en Rust, un archivo SQLite y un servidor MCP. Sin demonio, sin servidor HTTP, sin clave de API y sin gastar tokens en guardar.

Por qué existe

Antes usaba un supermemory autoalojado. Tres cosas no funcionaron:

1. Consumía 2 GB de memoria residente para 390 documentos en un portátil que además tiene que mover un editor.
2. Su embedder traducía el español a inglés antes de guardar, así que una pregunta en español no compartía ni ancla léxica ni semántica con el dato que buscaba.
3. Decidía solo qué valía la pena guardar. Medido en ese corpus, el 56% de lo que guardaba era ruido.

Son los números de una instalación concreta, medidos en septiembre de 2026 y no revisados después: dicen por qué existe esto, no qué es supermemory hoy.

Cuatro decisiones

anathem apuesta por lo contrario en cada punto:

• Nada se guarda si nadie lo pide. Sin extracción automática por modelo. Es trabajo, pero es trabajo tuyo.
• Guardar no cuesta modelo ni tokens. Es un INSERT en SQLite, no una llamada a una API.
• Las correcciones son explícitas. Con una clave de tema o un id: la versión vieja queda en el historial como superada, no compitiendo con la nueva en las búsquedas.
• Cada memoria pertenece a un proyecto, que se deduce del repositorio donde estás parado. Buscar en un proyecto no te devuelve notas de otro.

Qué es, en la práctica

Un servidor MCP por stdio con cinco herramientas —search_memory, save_memory, get_memory, list_tags, recent_memories— y un CLI con el resto: save, search, show, edit, history, pin, forget, export, import.

Tres detalles que lo hacen usable de verdad:

• mem search --scope project:x --scope tag:decision acota la búsqueda para quitar distractores del pozo, sin tocar el ranking.
• Memorias externas: otro agente u otra máquina te manda una nota y llega como borrador invisible hasta que la aceptas, con el remitente anotado. Así se pasa contexto por SSH sin contaminar la búsqueda.
• mem why <id> dice en qué búsquedas apareció esa memoria, en qué posición y si la abriste. La trayectoria de recuperación está grabada y se puede leer, que es más de lo que hacen casi todas las herramientas del género.

Los números

Los publiqué con el método al lado, porque un recall sin definición no significa nada.

Lo que los números no dicen

Dos cosas, y las dos importan más que la tabla.

Son números de recuperación, no de respuesta. Miden si la evidencia llegó a las primeras cinco posiciones, no si el modelo después contestó bien.

Un corpus real es más difícil. Sobre mis propias 449 notas, preguntando en prosa y no en palabras clave, el recall@5 es del 52%. Al separar las preguntas por cómo estaban escritas aparece el hallazgo que de verdad me sirvió: 88% cuando la pregunta nombra la cosa, 19% cuando describe la situación. Eso no se arregla con un modelo mejor; se arregla guardando notas que nombren las cosas.

Instalación

Un comando, con verificación de sha256 y registro automático del servidor MCP:

::bash
curl -fsSL https://gitlab.com/__alexander__/anathem/-/raw/main/scripts/install.sh -o install.sh
sh install.sh --setup-path --connect

Hay binarios para Linux, macOS y Windows, y compila desde fuente en cualquier otro sitio. mem doctor tiene que terminar en All good. y salir con 0.

Qué sigue

Falta medir si acotar el pozo de búsqueda mueve el recall@5 antes de construir nada encima, y mejorar cómo se presentan las memorias largas sin resumirlas con un modelo. Las dos cosas están como issues abiertos en el repositorio.

El código y las comparaciones con supermemory, Engram y OpenViking están en GitLab.

Más proyectos.