Contribuyo a una base de datos cognitiva para agentes de IA llamada MuninnDB. Almacena todo: notas de sesiones, contexto del proyecto, observaciones de trabajo, documentación legal. Después de unas semanas de uso diario, las entradas se acumulan. Encontrar cosas sigue funcionando. La búsqueda semántica es buena para la recuperación. Pero el almacén mismo se estaba pudriendo. Entradas casi duplicadas de sesiones que cubrían el mismo terreno. Hechos obsoletos sustituidos por otros más recientes. No había un sistema para distinguir “nota legal crítica” de “comentario informal sobre la red Docker”.
El problema no es la captura. Cada sistema de memoria domina la captura. El problema es lo que ocurre entre sesiones, que normalmente es nada.
Los agentes de IA acumulan recuerdos como los acumuladores acumulan periódicos. La solución no es una mejor búsqueda. Es el sueño.
Lo que realmente hace el sueño
La consolidación de la memoria humana durante el sueño no es una copia de seguridad. Es un proceso activo y destructivo. El hipocampo reproduce experiencias recientes, la neocorteza las integra en las estructuras de conocimiento existentes, y el cerebro debilita activamente los recuerdos que no fueron reforzados. Te despiertas con menos recuerdos de los que tenías al acostarte, y ese es el objetivo.
Tres propiedades son importantes para el diseño de sistemas de IA. Primero, la consolidación es selectiva. Los recuerdos importantes se fortalecen, el ruido se debilita. Segundo, descubre conexiones. El cerebro enlaza conceptos entre dominios durante el sueño REM. Tercero, resuelve conflictos. Los recuerdos contradictorios son adjudicados, quedando vencedoras las versiones más recientes o más reforzadas.
Ningún sistema de memoria de IA convencional hace nada de esto. La mayoría apenas realiza deduplicación.
Prior art
La idea no es nueva. Los investigadores la han estado abordando desde múltiples direcciones.
Zhong et al. introdujeron MemoryBank (2023), un sistema de memoria LLM con curvas de olvido de Ebbinghaus que degradan los recuerdos con el tiempo a menos que se refuercen. El modelo ACT‑R existente de MuninnDB se basa en este fundamento.
El artículo “Language Models Need Sleep” en OpenReview (2025) propuso un proceso explícito de “Dreaming” para transferir memorias frágiles a corto plazo a conocimientos estables a largo plazo. Esta es la estructuración teórica más cercana a lo que estamos construyendo.
El marco SleepGate de Xie (2026) añadió etiquetado temporal consciente de conflictos y una puerta de olvido, reduciendo la interferencia proactiva de O(n) a O(log n). La idea clave: necesitas saber cuándo se aprendió algo para resolver contradicciones, no solo qué se aprendió.
Y Anthropic ha estado probando Auto Dream para Claude Code, un proceso en segundo plano que consolida archivos de memoria entre sesiones. Funciona con archivos de texto plano. Razonable para un asistente de codificación. No es suficiente para una base de datos cognitiva.
The gap
MuninnDB ya tenía cubierta la parte de captura: embeddings vectoriales, decaimiento de Ebbinghaus, aprendizaje asociativo hebbiano y un trabajador de consolidación en segundo plano que realizaba deduplicación algorítmica cada 6 horas. Lo que no podía hacer: razonar sobre por qué dos entradas son similares, resolver contradicciones o descubrir conexiones inter‑dominio. Tenía memoria. No tenía sueño.
The Dream Engine
The Dream Engine extiende la canalización de consolidación existente con inteligencia LLM. Se ejecuta entre sesiones, activado automáticamente al iniciar el servidor (la metáfora de “despertar”) o manualmente vía CLI.
Trigger gates
Deben cumplirse ambas condiciones antes de que se ejecute un sueño: al menos 12 horas desde el último sueño y al menos 3 nuevas entradas escritas desde el último sueño. Esto evita el consumo de recursos en un almacén inactivo. Las puertas pueden ser eludidas con --force para ejecuciones manuales.
The pipeline
The Dream Engine reutiliza cuatro fases de consolidación existentes, agrega tres nuevas y modifica una. La fase 0 y el umbral configurable de deduplicación se incluyeron en el PR #306. Las fases LLM (2b, 4, 6) están diseñadas y especificadas para un PR posterior.
Phase 0 (new, shipped): Orient. Escaneo de solo lectura de cada bóveda. Cuenta entradas, verifica la cobertura de embeddings, calcula puntuaciones promedio de relevancia y estabilidad, detecta bóvedas legales. Esto construye el mapa antes de tocar cualquier cosa.
Phase 1 (existing): Replay. Reproducción de activación para actualizaciones de pesos de asociación Hebbiana. Sin cambios.
Phase 2 (existing, modified, shipped): Dedup. La fase algorítmica de deduplicación, pero con un umbral dividido. En modo de consolidación normal, las entradas con similitud de coseno ≥ 0.95 se fusionan automáticamente como antes. En modo sueño, el umbral baja a 0.85. Las entradas en el rango 0.85‑0.95 no se fusionan automáticamente. En su lugar, se marcan como clústeres de casi‑duplicados y se pasan a la siguiente fase para revisión LLM. Esta es la decisión arquitectónica clave: dejar que el algoritmo maneje los casos obvios y que el LLM maneje los ambiguos.
Phase 2b (new, a follow-up PR): LLM Consolidation. Los clústeres de casi‑duplicados y cualquier contradicción detectada se envían a un LLM configurado. El LLM devuelve JSON estructurado: operaciones de fusión, resoluciones de contradicciones, sugerencias de conexiones entre bóvedas, recomendaciones de estabilidad y una entrada de diario narrativo. El LLM no enlaza automáticamente nada entre bóvedas. Solo sugiere. Un humano revisa las sugerencias en el diario del sueño.
Phase 3 (existing): Schema Promotion. Sin cambios.
Phase 4 (new, a follow-up PR): Bidirectional Stability. Aquí ocurre el olvido. Las entradas de alta señal (accedidas frecuentemente, reforzadas recientemente mediante co‑activación Hebbiana o recomendadas por el LLM) reciben un impulso de estabilidad de 1.2x. Las entradas de baja señal (raramente accedidas, antiguas, con baja relevancia, no promovidas por el LLM) se debilitan a 0.8x con un límite mínimo de 14 días, lo que significa que nunca caen por debajo de la estabilidad predeterminada. Las recomendaciones del LLM sobrescriben los ajustes basados en reglas. Esto modela el efecto del espaciamiento: las entradas que se recuperan permanecen fuertes, las que no se desvanecen gradualmente.
Phase 5 (existing): Transitive Inference. Sin cambios.
Phase 6 (new, a follow-up PR): Dream Journal. La narrativa del LLM más el informe de consolidación se formatean en una entrada legible para humanos y se añaden a ~/.muninn/dream.journal.md. Esta es la salida que realmente lees. Informa qué conexiones se descubrieron, qué se reforzó, qué se limpió y qué se omitió.
Vault trust tiers
No todas las bóvedas son iguales y no todos los proveedores de LLM lo son. MuninnDB aplica niveles de confianza por bóveda:
Las bóvedas legales omiten completamente la Phase 2b. Nunca se envían a ningún LLM, ni siquiera a uno local. Las entradas legales se conservan literalmente y nunca son tocadas por la consolidación.
Las bóvedas de trabajo y personales están restringidas a Ollama local o a la API de Anthropic. Nunca se envían a OpenAI u otros proveedores.
Las bóvedas globales y de proyecto pueden usar cualquier proveedor configurado.
Esto se configura, no está codificado. El orden de resolución verifica primero Ollama (local, sin salida de datos de la máquina), luego Anthropic y, por último, OpenAI donde la política de la bóveda lo permite.
Runtime model
La metáfora de sueño/despertar se corresponde directamente con el ciclo de vida del servidor. Cuando MuninnDB se detiene (muninn stop), escribe un archivo lateral dream.due en el directorio de datos. Cuando se inicia de nuevo (muninn start), verifica el archivo y las puertas de activación. Si ambas pasan, ejecuta un sueño antes de abrir puertos. Si el sueño supera un tiempo de espera configurable (por defecto 60 s), se aborta y se inicia normalmente. El servidor nunca se bloquea indefinidamente por un sueño.
Para uso manual: muninn dream --dry-run muestra lo que ocurriría sin escribir nada. El modo de prueba aún genera la narrativa completa del diario y la imprime en stdout con un encabezado [DRY RUN]. Esto es esencial para la confianza. Puedes ver exactamente qué haría el motor antes de permitir que escriba.
Lo que omití
Enlace automático de sugerencias entre bóvedas. El Dream Engine sugiere conexiones pero nunca las crea automáticamente. Un humano lee el diario y decide. Confianza antes que automatización.
Compartir memoria entre múltiples agentes. MuninnDB es un usuario, una instancia. La memoria compartida entre agentes es un modelo de amenaza totalmente diferente.
Alertas temporales. El LLM podría notar “esta clave API expira en 4 días”, pero rastrear fechas de vencimiento es una funcionalidad, no una consolidación. Fuera del alcance de la v1.
Modelado de emociones. La puntuación de relevancia es un sustituto. El ponderado emocional real necesita una señal que un sistema basado en texto no posee. Diferido.
El diario de sueños
Aquí está lo que producirá una ejecución de sueño una vez que las fases LLM se publiquen en una PR posterior:
---
## 2026-03-28T06:00:00Z -- Sueño
**Conexiones descubiertas:**
- Tu nota sobre el tiempo de espera de DNS en el clúster k8s comparte la misma
causa raíz que el incidente de producción del 21 de marzo. (enlace sugerido)
**Fortalecido:**
- 3 recuerdos sobre patrones de autenticación reforzados (accedidos 8+ veces)
**Limpieza:**
- Fusionadas 2 notas casi duplicadas sobre redes Docker
- Resuelta 1 contradicción: endpoint de API antiguo sustituido por uno nuevo
*Escaneados 47 entradas en 3 bóvedas (legales: 8 omitidas) en 4,2 s*
Cada mañana, lees lo que tu sistema de memoria soñó. Las conexiones que notó. El ruido que limpió. Las contradicciones que resolvió. Es un registro de cambios para tu conocimiento, escrito en prosa. MuninnDB es el backend de memoria cognitiva para Hrafn, un entorno de ejecución de agentes IA ligero y modular.
Pruébalo
La fundación de solo lectura (Fase 0 + deduplicación configurable + CLI de ejecución en seco) se envió en el PR #306 y ya está fusionada. Las fases de escritura (estabilidad bidireccional, consolidación LLM, diario) seguirán en un PR separado. La especificación completa del diseño se encuentra en el repositorio en docs/superpowers/specs/2026-03-28-dream-engine-design.md.
git clone https://github.com/scrypster/muninndb
cd muninndb && go build ./cmd/muninn/
muninn dream --dry-run
Christian Pojoni construye la infraestructura de agentes de IA. Hrafn es el runtime. MuninnDB es la memoria.