Aleph aprende a acordarse (sin la nube)
Un agente que cierra la sesión y se olvida de todo no es muy distinto de un chatbot con amnesia. Le dimos a Aleph una memoria persistente, chica y curada, que sobrevive entre sesiones.
Cada sesión de Aleph terminaba en cero. Cerrás la app, la volvés a abrir, y el agente no tiene idea de qué convenciones usa tu proyecto, ni de que ya le dijiste tres veces que preferís explicaciones en español y breves. Todo lo que "aprendía" durante una tarea larga vivía y moría con esa conversación.
Miramos cómo lo resuelven otros agentes — Claude Code, Codex/OpenCode, y en particular Hermes Agent de NousResearch, que tiene un diseño de memoria bastante explícito — y terminamos con una versión propia, adaptada a algo que esos agentes no siempre tienen que enfrentar: modelos locales chicos, que generalizan peor y necesitan una capa de seguridad extra antes de confiar en lo que deciden guardar.
Dos archivos, dos alcances
.agent-aleph/, dentro de la carpeta del proyecto. Se puede commitear y compartir con el equipo, igual que AGENTS.md.Un solo tool: memory
En vez de tener un tool por cada combinación de acción y alcance, hay uno solo: memory, con dos argumentos explícitos — scope ("project" o "user") y action ("add", "replace" o "remove"). Con modelos chicos, menos nombres de herramienta para recordar es mejor que muchos nombres específicos.
{"action": "add", "scope": "project", "content": "Este proyecto usa 2 espacios de indentación"}Presupuesto duro, no memoria infinita
MEMORY.md tiene un tope de 2200 caracteres, USER.md de 1375. Cuando una escritura lo supera, el tool no trunca en silencio — devuelve un error pidiendo consolidar entradas viejas con replace o remove antes de seguir agregando. La memoria es conocimiento curado, no un log que crece para siempre.
Permisos: por qué no es automático
write_file o edit); en modo Plan queda directamente denegado.Lo decidimos así a propósito: un modelo grande en la nube casi no se equivoca eligiendo qué vale la pena recordar; uno chico local sí, con más frecuencia. Si el agente pudiera escribir memoria sin que nadie la revise, un error de hoy contamina todas las sesiones futuras en silencio.
La memoria que nadie revisa no es memoria, es ruido acumulado.
Reglas de prioridad (y nada de secretos)
Como MEMORY.md se puede compartir por git, el prompt del agente incluye instrucciones explícitas: las reglas de seguridad y permisos siempre ganan, las instrucciones del proyecto (AGENTS.md/CLAUDE.md) le ganan a la memoria si hay conflicto técnico, la memoria de proyecto le gana a la de usuario para convenciones del repo, y nunca — bajo ninguna circunstancia — se guardan credenciales, tokens o claves ahí.
Lo que aprendimos probándolo
La primera prueba real fue con un modelo muy chico (0.8B parámetros). Le pedimos que guardara una preferencia personal ("explicame en español y sé breve") y el agente la guardó… en la memoria del proyecto, no la del usuario, con el contenido parafraseado y una palabra mezclada en portugués que nadie pidió. Con un modelo más grande y orientado a código, el mismo pedido salió perfecto: alcance correcto, contenido fiel.
No fue un bug del sistema — fue exactamente la razón por la que el permiso de escritura no es automático. El tool hizo lo que le pidieron; lo que falló fue el criterio del modelo. Con modelos locales imperfectos, cualquier feature que dependa de que el modelo "decida bien" solo necesita ese freno de mano.
El resultado es una memoria chica, explícita y revisable — no un vector store gigante tratando de adivinar qué es relevante. Para un agente que corre sobre modelos que a veces se equivocan, elegimos previsibilidad por sobre magia.