Qué hace realmente un dream
Dos entradas, una nueva salida
Un dream es "un trabajo asíncrono" que toma exactamente dos tipos de entrada: "un almacén de memoria preexistente: el almacén que Claude verifica, deduplica y reorganiza, y de 1 a 100 sesiones: transcripciones pasadas que Claude analiza en busca de patrones e información para incorporar en la salida".
Lo que produce se describe con la misma precisión: "un nuevo almacén de memoria reorganizado: duplicados fusionados, entradas obsoletas o contradichas reemplazadas con el valor más reciente y nuevas ideas reveladas".
Nota el tercer elemento. Fusionar duplicados y reemplazar entradas obsoletas es limpieza. Revelar nuevas ideas a partir de transcripciones es algo más: lee sesiones que el almacén nunca capturó y escribe lo que implican. Si tienes transcripciones pero aún no tienes un almacén, la documentación ofrece una solución alternativa: "crea primero un almacén de memoria vacío y pásalo como la entrada memory_store".
La entrada nunca se modifica
Esta es la decisión de diseño que hace que todo lo demás sea seguro de usar:
"El almacén de entrada nunca se modifica, por lo que puedes revisar la salida y descartarla si no te gusta el resultado".
Reiterado más adelante, en términos más contundentes: "El dream en sí nunca elimina ni modifica sus entradas". Y esto se mantiene incluso en caso de fallo: en un dream con estado failed o canceled, "el almacén de memoria de salida se deja tal como está con lo que se haya escrito antes del fallo", y "el almacén de salida persiste con contenido parcial para que puedas inspeccionar lo que se produjo antes de detenerlo".
Así que el modo de fallo de un mal dream es un almacén que eliminas. No un almacén que tienes que reconstruir.
Dirige, pero no es un editor
El campo opcional instructions, limitado a 4,096 caracteres, "dirige lo que sintetiza el pipeline de dreaming. Se aplica a lo largo de todo el pipeline: qué leer de cerca, qué fusionar o descartar, y cómo estructurar el almacén de salida". El propio ejemplo de Anthropic es una declaración de enfoque: "Enfocarse en las preferencias de estilo de código; ignorar las notas de depuración puntuales".
Luego viene la advertencia que evitará que la gente pierda una ejecución:
"El pipeline es un paso de síntesis sobre las entradas, no un editor aplicado al texto del almacén, por lo que las directivas imperativas que apuntan a líneas específicas ("cambiar la frase X por Y", "corregir el recuento en la sección Z") generalmente no producen ningún cambio".
Para cambios específicos, la documentación te dirige a otra parte: "utiliza la API de Memory Stores directamente en el almacén de salida". Los Dreams sirven para dar forma al almacén, no para editar líneas.
Tarda lo que tenga que tardar, y puedes observarlo
"Los dreams se ejecutan de forma asíncrona y normalmente tardan de minutos a unas pocas horas, dependiendo del número de transcripciones de entrada". El ciclo de vida es pending, running, y luego uno de completed, failed o canceled.
Hay un pequeño detalle operativo que vale la pena conocer: "El ID del almacén de salida aparece en el outputs[] del dream poco después de que el dream comience a ejecutarse (running), una vez que el flujo de trabajo ha clonado el almacén de entrada; un dream en ejecución puede reportar brevemente un outputs[] vacío". Un array vacío al principio no es un error.
And you can observe the work: a running dream's session_id "points at the underlying session running the pipeline," whose events you can stream "to observe what the dream is reading and writing in real time." That session "is archived (not deleted) when the dream reaches a terminal state, so the transcript remains available afterward."
Y puedes observar el trabajo: el session_id de un dream en ejecución "apunta a la sesión subyacente que ejecuta el pipeline", cuyos eventos puedes transmitir en streaming "para observar lo que el dream está leyendo y escribiendo en tiempo real". Esa sesión "se archiva (no se elimina) cuando el dream alcanza un estado terminal, por lo que la transcripción sigue estando disponible después".
Dos formas de terminar
Cuando un dream se completa, su salida "es un almacén de memoria ordinario en tu espacio de trabajo". A partir de ahí, hay dos caminos documentados. Aprovecharlo: "adjuntarlo a futuras sesiones como un recurso memory_store en lugar de (o junto con) el almacén de memoria de entrada". Descartarlo: eliminar o archivar el almacén.
Junto con es la opción silenciosa en esa frase. No estás obligado a elegir entre el almacén curado y el original.
Qué cambia y qué no cambia esto
Sí aborda un problema estructural real. Las escrituras incrementales acumulan contradicciones. Eso no es un error en la implementación de Anthropic; es lo que hacen los almacenes que son principalmente de adición. Un paso de síntesis periódico con una puerta de revisión es una respuesta razonable, y la mecánica de los almacenes sobre los que opera se cubre en Claude's agent memory stores.
No se ejecuta solo. No hay programación ni activador en segundo plano. Creas un dream, eliges el modelo, consultas el estado, revisas la salida y lo adjuntas o lo descartas. Cada uno de estos pasos es una llamada explícita.
Tiene doble restricción de acceso, y la restricción es específica. "Dreaming es una función de vista previa de investigación (research preview)", con acceso bajo solicitud. Y las cabeceras importan: "Los endpoints de Dream están restringidos por la cabecera beta dreaming-2026-04-21; la cabecera managed-agents-2026-04-01 por sí sola no otorga acceso a los dreams". Las llamadas de sesión y de almacén de memoria solo necesitan esta última.
Cuesta tokens, proporcionalmente. "Los dreams se facturan a las tarifas estándar de tokens de API para el modelo que selecciones", y "el costo escala de forma aproximadamente lineal con el número y la duración de las sesiones de entrada". La propia recomendación de Anthropic es empezar poco a poco: "Comienza con un lote pequeño de sesiones y escala una vez que estés satisfecho con la calidad de la curación".
No te protege de eliminar sus entradas a mitad de la ejecución. Una advertencia documentada: "Archivar o eliminar un almacén de memoria de entrada a mitad de la ejecución (o eliminar una sesión de entrada) hará que el dream falle con input_memory_store_unavailable o input_session_unavailable". Las entradas son de solo lectura para el dream, no están bloqueadas para ti.
Tiene límites de tamaño que puedes alcanzar. La lista de errores incluye input_memory_store_too_large, memory_store_org_limit_exceeded para organizaciones que han alcanzado su límite de almacenes, y timeout cuando "el pipeline excedió su presupuesto de tiempo de ejecución".
Lo que la gente asumirá de esto, y no debería
"Claude ahora mantiene su propia memoria automáticamente". Para Managed Agents, no a través de Dreams. Este es un trabajo que invocas con entradas explícitas, una elección de modelo y una decisión al final.
"Corrige memorias erróneas". Reemplaza "entradas obsoletas o contradichas" con el valor más reciente según lo que admitan las entradas. Si deseas cambiar una frase específica, para eso está la API de Memory Stores en el almacén de salida; la documentación indica que las directivas imperativas a nivel de línea "generalmente no producen ningún cambio".
"La revisión es opcional". La revisión es la característica clave. Un dream no revisado adjuntado directamente a sesiones de producción descarta la única propiedad que hace que el diseño sea seguro, y la razón principal por la que se conserva la entrada.
"Cuantas más sesiones, mejor". Más sesiones cuestan más y tardan más, y la guía es escalar después de que te guste la calidad, no antes. Tanto el costo como el tiempo de ejecución dependen del volumen de las transcripciones.
"Es lo mismo que hace ChatGPT". Diferente capa, diferente ergonomía. Dreaming de OpenAI cura una memoria de consumo en segundo plano. Los Dreams de Anthropic son un trabajo de síntesis activado por el desarrollador que emite un artefacto revisable y nunca modifica su origen.
"Cancelar lo deshace". Cancelar detiene la ejecución; no limpia. Un dream cancelado deja su almacén de salida parcial en su lugar para que lo inspecciones o lo elimines. Archivar un dream tampoco "toca su almacén de memoria de salida", y para los dreams en sí "no existe la opción de desarchivar".
La solución: Tratar la curación como un hábito, no como una función
Paso 1: Decide qué significa "obsoleto" para tu almacén antes de curarlo
Un paso de síntesis es tan bueno como el criterio que le proporciones. Antes de ejecutar cualquier cosa, escribe qué categorías de entradas en tu almacén tienen permitido cambiar y cuáles deben preservarse.
El campo instructions es donde va ese criterio, y funciona mejor como una guía de alto nivel: "áreas de enfoque... contenido a preservar sin cambios, o convenciones de salida que deseas aplicar en todo el almacén", según la frase de Anthropic. "Preferir la declaración más reciente de una preferencia de codificación" es la altitud correcta. "Corregir el número en la sección tres" no lo es.
Paso 2: Construye un paso de revisión que realmente vayas a realizar
El almacén de entrada se conserva para que la revisión sea posible. Haz que suceda en la práctica decidiendo dos cosas de antemano: qué vas a comparar (diff) y qué te haría descartarlo.
Una opción predeterminada útil es adjuntar la salida junto con la entrada durante un período en lugar de reemplazarla, algo que la documentación permite explícitamente, y observar si el comportamiento del agente mejora. Los conflictos entre las entradas recordadas son lo que debes buscar, y el hábito general se cubre en detecting conflicts in AI memory.
Mientras se ejecuta un dream, la transmisión en streaming de los eventos de su sesión te indica qué está leyendo y escribiendo. Vale la pena hacer esto al menos una vez, porque ver en qué transcripciones se apoya es la forma más rápida de saber si tu selección de sesiones fue la correcta.
Paso 3: Mantén el almacén que curas independiente del pipeline de cualquier proveedor
Aquí está el punto estructural, y no es una crítica a Dreams. El mecanismo es sólido y la puerta de revisión es el diseño correcto. También está limitado a almacenes de memoria en una sola plataforma, detrás de una bandera de vista previa de investigación, para agentes creados de una sola manera.
Mientras tanto, las memorias que se deterioran más rápido son las que están distribuidas en todo lo que usas: la preferencia que expresaste en un chat, la corrección que le diste a un agente de codificación, la decisión registrada en la transcripción de una sesión en otro lugar. Los duplicados y las contradicciones se acumulan entre herramientas incluso más rápido que dentro de un solo almacén, y el paso de curación de ningún proveedor individual puede verlos.
Una capa de memoria de tu propiedad es donde vive ese almacén consolidado, y donde se aplica el mismo hábito: leerlo, corregirlo, podarlo, mantener el historial de versiones. MemoryLake se configura en tres pasos.
Paso 1: Crea una clave de API
Inicia sesión y genera una clave de API desde tu panel de control. Tu propio almacén es el que puedes abrir e inspeccionar directamente, lo que hace que el hábito de revisión anterior sea práctico en lugar de aspiracional. Los almacenes de memoria de Anthropic se quedan donde están, gestionados a través de la propia API de Anthropic.

Paso 2: Sube tus primeras memorias
Introduce los datos duraderos: decisiones y sus motivos, vocabulario del dominio, preferencias permanentes, las correcciones que has dado más de una vez. El mismo material que sintetizaría un dream, guardado donde cada herramienta que utilices pueda acceder a él.

Paso 3: Conecta tu IA y tus agentes
Apunta tus agentes al almacén. La curación se convierte entonces en algo que haces una vez para el conocimiento en sí, en lugar de una vez por cada sistema de memoria de cada proveedor, el argumento expuesto en syncing AI memory across your tools.

Qué cambia esto en la práctica
El primer cambio es que "la memoria de mi agente empeoró con el tiempo" se convierte en una condición diagnosticable en lugar de una queja vaga. Anthropic le puso un nombre y un mecanismo: escrituras incrementales, duplicados, contradicciones, entradas obsoletas.
El segundo es que la revisión se convierte en la expectativa predeterminada para cualquier función de curación. Dreams sentó un buen precedente al no modificar nunca la entrada. Es algo razonable de pedir a cada sistema de memoria que adoptes.
El tercero es que la cuestión del alcance se vuelve más nítida. Un paso de curación por plataforma ayuda al almacén que puede ver. Lo que no puede ver es todo lo que la misma persona le dijo a otras cuatro herramientas, que es el argumento para auditing what your AI remembers como un solo ejercicio en lugar de varios.
Buenas prácticas para curar un almacén de memoria de agentes
- Comienza con un lote pequeño de sesiones. Tanto el costo como el tiempo de ejecución escalan con el volumen de las transcripciones, y Anthropic recomienda escalar solo después de que te guste la calidad.
- Escribe las
instructionsa la altitud correcta. Las áreas de enfoque y las convenciones de salida funcionan; las directivas a nivel de línea generalmente no producen ningún cambio. - Adjunta junto con antes de reemplazar. La salida puede situarse al lado del almacén de entrada en lugar de sustituirlo.
- No toques las entradas a mitad de la ejecución. Archivar o eliminar un almacén de entrada o una sesión hace que el dream falle por completo.
- Espera un
outputs[]vacío brevemente. El ID del almacén de salida aparece poco después de que el dream comience a ejecutarse, una vez que se ha clonado la entrada. - Utiliza la API de Memory Stores para ediciones precisas. Los Dreams remodelan; la API edita.
- Limpia después de una cancelación. Los dreams cancelados y fallidos dejan almacenes de salida parciales en su lugar a propósito.
- Vuelve a verificar a medida que sale de la vista previa. Dreaming es una función de vista previa de investigación con su propia cabecera beta, y el comportamiento de la vista previa cambia.
Conclusión
El mecanismo que vale la pena copiar aquí no es la síntesis. Es la garantía que lo rodea: leer el almacén, leer las transcripciones, escribir un nuevo almacén y dejar el original intacto para que un humano pueda decir que no.
Ese es un diseño que se toma la memoria en serio como algo en lo que te puedes equivocar. Tanto si tienes acceso a Dreams como si no, el hábito se generaliza: cura deliberadamente, revisa antes de adoptar y mantén el conocimiento que importa en un lugar donde puedas leerlo tú mismo.