Volver a artículos
autoDream: cuando los agentes duermen para recordar mejor
04

autoDream: cuando los agentes duermen para recordar mejor

Memoria agéntica · · IA agéntica · memoria · Claude Code · autoDream · arquitectura

Antes de entrar en el detalle técnico, una nota de contexto: lo que voy a explicar en este artículo viene del leak accidental del código fuente de Claude Code que ocurrió el 31 de marzo de 2026. Anthropic publicó sin querer un source map de 59.8 MB en el paquete npm @anthropic-ai/claude-code versión 2.1.88, exponiendo ~1.900 archivos TypeScript y 512.000 líneas de código. Boris Cherny, head de Claude Code, lo confirmó como un error humano de build. Lo menciono porque importa para interpretar lo que sigue: nada de esto sale de documentación oficial, sino del código real con el que Anthropic ha construido la memoria de Claude Code.

Por qué dormimos para recordar

Los neurocientíficos llevan décadas documentando un fenómeno contraintuitivo: aprender algo justo antes de dormir produce mejor retención que aprenderlo y seguir despierto. La razón es que durante el sueño profundo de ondas lentas (no en el REM de los sueños vívidos, como se suele creer) el hipocampo reproduce las experiencias recientes y las transfiere a la corteza cerebral para su almacenamiento a largo plazo. El cerebro no “descansa”: aprovecha el tiempo sin input sensorial para reorganizar y consolidar lo que ha procesado durante el día. La consolidación diferida funciona mejor que la inmediata porque puede operar sin interferencia.

autoDream hace exactamente esto.

Qué es autoDream

Es un sub-agente background que Claude Code ejecuta durante tiempo idle para consolidar la memoria acumulada en sesiones anteriores. La memoria automática que mantiene (el directorio con MEMORY.md y los topic files) sí aparece en la documentación oficial; autoDream, el proceso que la conserva sana, no. Hasta el leak solo se podía intuir que algo así existía.

El sistema tiene tres condiciones que deben cumplirse antes de activarse, evaluadas en orden de menor a mayor coste computacional:

  1. Gate de tiempo: deben haber pasado al menos 24 horas desde la última consolidación.
  2. Gate de sesiones: deben existir al menos 5 sesiones nuevas desde entonces.
  3. Gate de lock: no puede haber otro proceso de consolidación en curso.

Si los tres gates están abiertos, autoDream arranca un agente forked con herramientas restringidas y ejecuta cuatro fases.

Las cuatro fases

Phase 1 — Orient. El agente inspecciona el estado actual: lista el directorio de memoria, lee el índice MEMORY.md, hojea los topic files existentes. Todavía no actúa; solo mapea el terreno para entender qué hay y qué falta.

Phase 2 — Gather. Recoge señal nueva de tres fuentes en orden de prioridad: primero los logs diarios (archivos append-only que registran actividad reciente), luego los memories que han quedado desactualizados respecto al estado actual del código, y finalmente los transcripts históricos mediante búsqueda por términos:

grep -rn "<term>" ${TRANSCRIPTS_DIR}/ --include="*.jsonl" | tail -50

Aquí es donde los JSONL de sesiones pasadas entran en juego. Nunca se cargan completos; se buscan selectivamente, de forma que la señal que importa se extrae sin contaminar el contexto con ruido.

Phase 3 — Consolidate. Con la señal recogida, el agente fusiona el conocimiento nuevo en los topic files existentes y elimina duplicados. Convierte fechas relativas (“ayer”, “la semana pasada”) en fechas absolutas para que los recuerdos no pierdan su coordenada temporal. Y resuelve contradicciones: si un hecho almacenado contradice el estado actual del código, el hecho desaparece.

Phase 4 — Prune. Actualiza el índice MEMORY.md para que no supere 200 líneas ni 25KB. Elimina punteros obsoletos y degrada entradas demasiado verbosas. El índice se carga en cada sesión, así que tiene que ser barato, y mantenerlo barato requiere podarlo de forma activa.

La decisión de diseño que más me interesa

autoDream opera con herramientas restringidas. El sub-agente forked puede ejecutar ls, find, grep, cat, stat, wc, head, tail para inspeccionar el estado, pero no puede tocar los archivos fuente del proyecto. Varios análisis del leak lo describen como un proceso de solo lectura, y ahí se quedan cortos: sí escribe, pero únicamente archivos de memoria (MEMORY.md y topic files). Exactamente lo que necesita para consolidar, y nada más.

La restricción tiene una lógica de diseño clara: si autoDream pudiera modificar código libremente, un bug en su razonamiento podría corromper el proyecto sin dejar rastro. Al aislar las escrituras de memoria de las modificaciones de código, se reduce el riesgo de corrupción accidental. Es el viejo principio de separación de privilegios, aplicado esta vez a lo que un agente puede hacer consigo mismo.

La arquitectura que autoDream sirve

Para entender qué consolida autoDream, hay que entender dónde consolida. Claude Code organiza la memoria en tres capas:

  • Índice (MEMORY.md): cargado en cada sesión, contiene solo punteros cortos (~150 caracteres por línea). Nunca se vuelca contenido aquí, solo referencias.
  • Topic files (debugging.md, api-conventions.md, etc.): conocimiento detallado, cargado bajo demanda cuando es relevante para la tarea.
  • Transcripts JSONL: historial completo de conversaciones, nunca cargado directamente, solo buscado mediante grep.

La disciplina de escritura es tan importante como la arquitectura: escribir siempre al topic file primero, actualizar el índice después, y no almacenar nada que pueda re-derivarse del código. Lo que no se guarda importa tanto como lo que sí.

autoDream es el mecanismo que mantiene esta arquitectura sana con el tiempo: detecta cuándo los topic files acumulan contradicciones o el índice crece demasiado, y rescata la señal útil que sigue enterrada en los transcripts.

Lo que revela el leak

Que autoDream esté en el código pero no en la documentación dice algo sobre cómo Anthropic gestiona la evolución de Claude Code. No parece un experimento abandonado: tiene configuración propia, gestión de locks y feature flags, la infraestructura de algo que se está probando en serio. Pero tampoco es algo que hayan querido explicar públicamente todavía.

Mi interpretación: autoDream es parte de una apuesta mayor sobre qué significa que un agente de codificación “aprenda” con el uso. La compactación que conocemos es reactiva: la activas tú cuando el contexto se infla. autoDream es proactivo: el sistema decide cuándo consolidar basándose en señales de uso. Es el paso de agentes que mejoras tú configurándolos a agentes que mejoran solos.

El código filtrado también incluye KAIROS, un framework de daemon background mucho más ambicioso que aparece mencionado más de 150 veces: operación persistente, notificaciones push, suscripción a cambios en GitHub. No engloba a autoDream; de hecho, cuando KAIROS está activo, autoDream se desactiva y la consolidación pasa por otro mecanismo. Pero apunta en la misma dirección: agentes que trabajan cuando tú no estás. Todo el framework permanece detrás de feature flags, sin fecha de lanzamiento confirmada. Territorio para otro artículo.

El tercer nivel de memoria

autoDream es un ejemplo concreto de lo que en el primer artículo de la serie describí como el tercer nivel de memoria: la memoria aprendida. Tiene limitaciones evidentes (depende de grep sobre texto plano, sin nada parecido a búsqueda semántica), pero cumple la definición: un agente que consolida su propio conocimiento sin que nadie se lo pida.

Compararlo con el enfoque de Hermes que vimos en el artículo anterior tiene menos interés que constatar hacia dónde convergen ambos: la memoria útil no es la que se acumula pasivamente, sino la que se consolida de forma activa. Y la consolidación más efectiva ocurre en background, sin interferir con el trabajo en curso.

Si usas Claude Code a diario, es posible que autoDream ya haya consolidado memoria en tus proyectos sin que lo sepas. Merece la pena abrir ~/.claude/projects/<tu-proyecto>/memory/ y leer qué ha decidido recordar: no hay forma más directa de entender qué hace un agente con tu contexto cuando no estás mirando.

Referencias