De 3 a 5 capas: la memoria jerárquica que todo agente necesita — y cómo evolucionamos la nuestra en producción

Ayer, nuestro agente aprendió dos cosas que cambian la definición de "memoria" en IA: aprendió a recordar el futuro y aprendió a soñar. No es una metáfora. El 19 de agosto de 2026 implementamos las capas 4 y 5 de la memoria agéntica de Shiva — memoria prospectiva (intents: "cuando X ocurra, haz Y") y consolidación (dreaming: revisión nocturna de sesiones para extraer lo que importa). En 48 horas, nuestro agente pasó de tener 3 capas de memoria a tener 5, y todo el proceso quedó documentado con datos reales de producción.

Este es el segundo artículo de nuestra serie semanal sobre memoria jerárquica para agentes. En el post anterior explicamos por qué tu agente olvida: porque su memoria no tiene estructura. Hoy vamos un paso más allá y mostramos la arquitectura completa — las 5 capas que todo agente necesita — con la evidencia de un sistema que no está en un paper, sino corriendo en producción con 391 sesiones, 27 skills y un grafo vivo de 727 tripletes.

1. El consenso de la industria: 3-4 capas (y el vacío que nadie ve)

Si buscas "agent memory architecture" en 2026, encuentras un consenso emergente que viene de Mem0, Letta, Zep, Anthropic y la literatura académica. La taxonomía estándar es esta:

Hasta aquí, todo claro. Pero mira lo que falta en esa lista — y lo que ningún survey mainstream incluye:

2. La evolución real: de 3 a 5 capas en 48 horas

Nuestro agente (Shiva) llevaba meses con tres capas cognitivas separadas — algo que ya era inusual: la mayoría de los agentes guarda todo en un solo almacén (SQLite con cajones, un vector store, un archivo JSON). Nosotros siempre tuvimos tres sistemas independientes, cada uno con su tecnología óptima:

Y el 19 de agosto, en una sola sesión de trabajo, agregamos las dos que faltaban:

La tabla completa, con los números reales de producción verificados hoy:

3. Capa 4: la memoria prospectiva (recordar el futuro)

Piensa en todo lo que un agente de producción necesita hacer condicionalmente: "cuando el cliente mencione la Ley 21.719, verifica que el checklist esté publicado", "cuando Aidan responda el correo, coordina el feedback de MillenniumDB", "cuando se hable de riego, presenta el estudio de mercado de AquaPalto". Eso es memoria prospectiva: no recordar lo que pasó, sino recordar qué hacer cuando algo ocurra.

La implementación es elegante en su simplicidad: un archivo intents.json con reglas condicionadas, y un método _check_standing_intents() que se ejecuta en cada mensaje, inyectando los intents relevantes directamente en el contexto del sistema. El agente no tiene que "recordar" revisar sus pendientes: el sistema se lo recuerda a él, siempre.

La memoria prospectiva resuelve el problema más caro de los agentes en producción: la pérdida de compromisos. Un agente sin intents puede tener 391 sesiones de memoria y aún así olvidar que prometió hacer un follow-up cuando el cliente mencionara X. Con intents, el compromiso sobrevive — no vive en el contexto de una conversación, vive como una regla activa del sistema.

4. Capa 5: la consolidación (el agente que sueña)

Aquí viene lo que más nos gusta: el 6 de mayo de 2026, Anthropic anunció "dreaming" en Claude Managed Agents — un proceso asíncrono que revisa sesiones pasadas para encontrar patrones y auto-mejorarse. Lo llamaron "research preview". Nosotros lo leímos en mayo, lo anotamos como roadmap… y el 19 de agosto lo implementamos en producción con nuestra propia arquitectura.

Nuestra versión (dreaming.py) funciona así: se ejecuta al cierre del día, analiza las notas de sesión, extrae patrones de frecuencia (¿de qué hablamos más esta semana?), identifica hechos durables, y con la bandera --apply-graph inserta las entidades detectadas directamente en el grafo MillenniumDB vía SPARQL UPDATE. O sea: el sueño del agente alimenta su conocimiento relacional.

La diferencia con Anthropic es estructural y vale la pena nombrarla: ellos ofrecen dreaming como feature de su plataforma de agentes gestionados. Nosotros lo tenemos como skill de primera clase, conectado a nuestro grafo RDF/SPARQL estándar, ejecutable bajo demanda o (próximamente) por cron nocturno. No es un feature de un producto: es una capa de una arquitectura que controlamos completa.

5. El ciclo completo: cómo fluye la memoria en 24 horas

La potencia de las 5 capas no está en cada capa por separado: está en el ciclo. Así funciona en producción un día cualquiera:

1. Durante la sesión: el agente trabaja con su working memory (contexto) + notas episódicas (qué pasó antes) + skills (cómo hacer las cosas) + grafo (cómo se conecta todo) + intents (qué hacer cuando ocurra X).
2. Al cerrar: se guarda la nota de sesión (capa episódica crece: 391 sesiones y sumando).
3. De noche (dreaming): el agente revisa las notas, detecta patrones, extrae hechos durables.
4. Con --apply-graph: los hechos detectados se insertan en MillenniumDB (el grafo crece: 727 tripletes y sumando).
5. Al día siguiente: el agente despierta con el grafo enriquecido, los intents activos y las notas consolidadas. Es un agente que literalmente es más inteligente que ayer.

6. Por qué esto importa ahora (y por qué nadie más lo está contando)

En la sesión del 19 de agosto hicimos una verificación honesta contra el mercado: OpenClaw tiene más "cajones" nominales (SQLite con vector search, knowledge graph, standing intents, daily logs), pero es un solo mueble: todo vive en un archivo SQLite. Nosotros tenemos tres sistemas independientes y especializados (notas → archivos, skills → markdown, grafo → MillenniumDB), y ahora cinco capas cognitivas con las dos que faltaban en la taxonomía estándar.

Y ojo con un dato que nos gusta especialmente: la búsqueda de "memoria prospectiva para agentes" en la literatura pública de 2026 devuelve casi nada. Es territorio virgen. Mientras el mercado discute si son 3 o 4 capas, nosotros ya estamos operando con 5 — y documentando todo con números reales.

7. Lo que viene en la serie

Esta serie tiene un plan de 10 posts. Ya publicamos el post 1 (el problema: la memoria sin estructura) y este post 2 (la arquitectura: las 5 capas). Lo que viene:

• Post 3: El grafo que le faltaba a tu agente — por qué MillenniumDB y no otra graphDB.
• Posts 4-6: La construcción — de 0 a grafo en producción, multi-hop en acción, y nuestro benchmark honesto vector vs grafo.
• Posts 7-10: El ecosistema — MillenniumDB vs otras graphDB, cómo contribuir a un proyecto chileno de clase mundial (7 PRs y contando), el futuro de la memoria agéntica distribuida, y por qué publicamos todo en open source.

Lo más honesto que podemos decir: la capa de grafo es real pero modesta (160 entidades, 727 tripletes). No somos un laboratorio con 50 millones de tripletes. Somos un equipo que construyó un agente con cinco capas de memoria cognitiva separadas, en producción, con tecnología abierta, y que crece cada sesión. Eso — con toda la humildad — es más de lo que la mayoría de las plataformas de agentes pueden mostrar hoy.