MemoryLake
Volver a todos los artículos
News20 de agosto de 2026·11 min de lectura

Almacenes de memoria para agentes de Claude: Qué hacen y dónde se detienen (2026)

Anthropic lanzó memoria persistente para Managed Agents de Claude, y la documentación comienza con la declaración del problema más clara que leerás de un proveedor: "Cada sesión de Managed Agents comienza con un contexto nuevo de forma predeterminada. Cuando una sesión termina, cualquier estado que el agente haya acumulado desaparece".

La solución se llama memory store (almacén de memoria), y es un diseño más interesante que simplemente "añadimos una API de memoria". Es un directorio. El agente lo lee y escribe con herramientas de archivos comunes. Cada escritura tiene un control de versiones inmutable. Y en sandboxes autohospedados (self-hosted) se comporta de manera diferente al caso administrado, algo que necesitas saber antes de depurar cualquier cosa.

Esta es una guía de cómo funciona realmente, qué es genuinamente bueno de su diseño y dónde se encuentran sus límites, porque estos límites se detallan en la documentación y son importantes para las decisiones de arquitectura.

Qué es un almacén de memoria (memory store)

Una colección de documentos de texto, montada como un directorio

La definición, textualmente: "Un almacén de memoria es una colección de documentos de texto con alcance de espacio de trabajo optimizada para Claude".

And el mecanismo, que es la parte que vale la pena apreciar: "Cuando asocias un almacén a una sesión, este se monta como un directorio dentro del sandbox de la sesión. El agente lo lee y escribe con las mismas herramientas de archivos que utiliza para el resto del sistema de archivos, y se añade automáticamente una nota que describe cada montaje al prompt del sistema, indicándole al agente dónde buscar".

No hay una nueva herramienta que el modelo deba aprender. No hay una API de recuperación que llamar. El agente ya sabe cómo leer y escribir archivos, por lo que la memoria se convierte en parte del sistema de archivos en el que ya está operando, y el prompt del sistema recibe un puntero para que sepa que el directorio existe. Esa es una forma de fricción notablemente baja para exponer la persistencia a un modelo.

Un requisito de configuración que romperá las cosas silenciosamente si lo pasas por alto: "Se requiere el conjunto de herramientas del agente (agent toolset) para estas interacciones; asegúrate de habilitarlo durante la creación del agente".

Lo que se supone que debe contener el almacén, según la documentación: "preferencias del usuario, convenciones del proyecto, errores previos y contexto del dominio".

Versiones inmutables y un registro de auditoría real

Esta es la parte del diseño que destacaría: "Cada cambio en una memoria crea una versión de memoria inmutable, lo que te brinda un registro de auditoría y recuperación a un punto en el tiempo para todo lo que escribe el agente".

Considera lo que esto resuelve. Cuando un agente autónomo mantiene su propia memoria, el modo de fallo que a todos les preocupa es que el agente escriba algo incorrecto y luego construya sobre ello con total confianza. El control de versiones inmutable significa que esto es diagnosticable y reversible: puedes ver cuándo cambió una entrada y revertirla al estado anterior. Muy pocos sistemas de memoria, incluido el nuestro, tratan el historial de escritura como un artefacto de primera clase. Es una excelente decisión y es el tipo de cosas que solo parecen importantes después de la primera mala escritura.

Cada memoria se direcciona por ruta y es directamente editable

"Cada memoria en un almacén se direcciona mediante una ruta y se puede leer y editar directamente a través de la API o de la consola de Claude, lo que permite el ajuste, la importación y la exportación".

Direccionado por ruta significa que puedes razonar sobre la organización: un diseño estable en lugar de un bloque opaco de datos. Y la lectura/edición directa a través de la API o la consola significa que el almacén no es de solo escritura desde el exterior: puedes sembrarlo, corregirlo y extraer el contenido. La importación y la exportación se mencionan explícitamente, lo cual vale la pena señalar porque la portabilidad suele ser lo primero que se pierde en una función de memoria.

El campo description es parte de la interfaz

Crear un almacén requiere un name y una description, y la descripción no es solo para tu panel de control: "La descripción se pasa al agente, indicándole qué contiene el almacén".

Por lo tanto, la descripción es parte de la superficie del prompt. "Preferencias por usuario y contexto del proyecto" (el propio ejemplo de la documentación) le indica al agente cuándo buscar allí. Una descripción vaga hace que un almacén bien poblado sea más difícil de usar correctamente para el agente. Trata ese campo como instrucciones, no como una simple etiqueta.

En sandboxes autohospedados es una copia sincronizada, no un montaje en vivo

La distinción que te costará una tarde de trabajo si no la conoces. En el caso administrado, el almacén está montado. En sandboxes autohospedados (self-hosted): "ese directorio no es un montaje en vivo. En su lugar, el trabajador de entorno (environment worker) del SDK descarga cada almacén asociado en tu sandbox antes de que se ejecuten las herramientas del agente y mantiene esa copia sincronizada con el almacén".

La documentación para entornos autohospedados describe el mismo límite desde el lado del flujo de datos: "Las habilidades del agente y el contenido de cualquier almacén de memoria asociado a la sesión son almacenados por Anthropic y copiados en tu sandbox para la sesión; los cambios que el agente realiza en los archivos de memoria se sincronizan de vuelta con el almacén". También señala, para completar la información sobre dónde ocurre el procesamiento, que "Las entradas y salidas de las herramientas siguen fluyendo hacia el plano de control de Anthropic (donde se ejecuta Claude) para que el modelo pueda ver los resultados y determinar qué hacer a continuación".

Lectura práctica: en infraestructura autohospedada, el agente trabaja con una copia local sincronizada. Ese es el diseño correcto para un sandbox que tú controlas, y significa que el modelo mental que debes tener es "descargar antes de que se ejecuten las herramientas, sincronizar de vuelta después de las escrituras", en lugar de "directorio compartido en vivo".

Las cabeceras beta te atraparán al menos una vez

No es un fallo de diseño, solo un detalle que produce un error confuso. Las solicitudes de Managed Agents utilizan la cabecera beta managed-agents-2026-04-01, "excepto los endpoints del almacén de memoria, que utilizan agent-memory-2026-07-22 en su lugar". Los SDK configuran la correcta por ti.

Si configuras las cabeceras a mano, ten en cuenta la advertencia explícita: "No combines agent-memory-2026-07-22 con managed-agents-2026-04-01 en una solicitud de almacén de memoria: enviar ambas devuelve un error 400". Reemplaza en lugar de añadir. Y asociar un almacén a una sesión es un endpoint de sesión, por lo que esa llamada sigue utilizando managed-agents-2026-04-01.

También hay una nota sobre la paginación que vale la pena leer antes de crear un proceso de sincronización: a partir del 22 de julio de 2026, la cabecera más antigua adopta el mismo comportamiento de lista en GET /v1/memory_stores/{memory_store_id}/memories, y "Los cursores de página de las solicitudes realizadas sin la cabecera no son válidos con ella, así que reinicia desde la primera página".

Dónde se detienen los almacenes de memoria

Nada de esto es una crítica; estas son decisiones de alcance declaradas, y conocerlas es cómo decides qué construir encima.

Con alcance de espacio de trabajo. La definición lo dice: un almacén de memoria es una colección con alcance de espacio de trabajo. Tu arquitectura hereda ese límite, por lo que el conocimiento entre diferentes espacios de trabajo necesita un plan.

Optimizado para Claude. También de la definición. El almacén consiste en documentos de texto estructurados para la forma en que Claude los lee, alojados en la plataforma de Anthropic. Eso es exactamente lo que deseas si Claude es el entorno de ejecución de tu agente, y significa que un segundo entorno de ejecución no leerá el mismo almacén.

Diseñado para el agente. El almacén se monta en una sesión para que lo use un agente. No está posicionado como una capa de conocimiento compartido para los asistentes y editores que tu equipo también utiliza en el día a día.

Beta. Las cabeceras lo indican. El comportamiento y los endpoints siguen cambiando, como lo demuestra la nota de paginación del 22 de julio.

Qué hará la gente con esto

Usarlo como está previsto, para la memoria de trabajo del agente. El paso obvio y correcto si estás construyendo sobre Managed Agents. Los errores previos y las convenciones del proyecto son exactamente el uso documentado.

Intentar convertir un único almacén en la base de conocimientos de la empresa. Tentador, pero choca con el alcance del espacio de trabajo y con el hecho de que solo los agentes de Claude lo leen. Tus editores y otros asistentes no lo harán.

Omitir el campo de descripción. Rápido, pero elimina el puntero que el agente utiliza para decidir si el almacén es relevante.

Dejar que el agente escriba libremente y nunca mirar. El control de versiones inmutable hace que esto sea recuperable en lugar de fatal, que es el propósito de la función, pero la recuperación aún requiere que alguien se dé cuenta.

Configurar las cabeceras a mano y perder una hora con un error 400. Evitable si usas el SDK, que las configura automáticamente.

Asumir que el autohospedado se comporta como el administrado. La distinción de la copia sincronizada está documentada precisamente porque no es así.

La solución: Decide qué pertenece al almacén de la plataforma y qué pertenece fuera

El enfoque útil no es "qué sistema de memoria gana". Es que la memoria de trabajo del agente y el conocimiento organizacional son cosas diferentes con ciclos de vida distintos, y es mejor mantenerlos por separado.

Coloca la memoria de trabajo del agente en el almacén. Errores previos, convenciones que el agente debe aplicar mientras opera, preferencias por usuario para ese espacio de trabajo. Organízalo por rutas, escribe una descripción real y utiliza el historial de versiones cuando una escritura parezca incorrecta.

Mantén portátil el conocimiento duradero. Las decisiones, las restricciones, los enfoques rechazados, el vocabulario del dominio: el material que sigue siendo válido en diferentes entornos de ejecución, sobrevive a cualquier agente individual y es igualmente útil para los humanos y editores de tu equipo. Esa es la capa que no debería estar limitada a un solo espacio de trabajo en una sola plataforma.

Eso es lo que es MemoryLake: una capa de memoria de la que tus asistentes y agentes leen a través de MCP o una API, que contiene el conocimiento que no es específico de un único entorno de ejecución de agentes. La configuración consta de tres pasos.

Paso 1: Crea una clave API

Inicia sesión en MemoryLake y crea una clave API. Una sola credencial para todas las herramientas que conectes.

Creación de una clave API de MemoryLake junto con los almacenes de memoria de agentes de Claude
Creación de una clave API de MemoryLake junto con los almacenes de memoria de agentes de Claude

Paso 2: Sube tus primeras memorias

Entradas cortas, una afirmación cada una. Lo que pertenece a una capa portátil en lugar de al almacén de trabajo de un agente:

Escritura de conocimiento independiente del entorno de ejecución en entradas de MemoryLake
Escritura de conocimiento independiente del entorno de ejecución en entradas de MemoryLake

Decisiones y la restricción detrás de ellas. El razonamiento que hace que una convención sea correcta, para que sobreviva a un cambio de framework de agentes.

Enfoques ya descartados. Costosos de volver a descubrir y útiles para cada agente y cada ingeniero, no solo para el que lo aprendió.

Conocimiento del dominio. Vocabulario y reglas de tu campo. No específico de un espacio de trabajo, no específico de un entorno de ejecución.

Correcciones que has hecho más de una vez. Ya sea que el error lo haya cometido el agente o una persona, la entrada es la misma.

Paso 3: Conecta tu IA y agentes

Conecta las herramientas que utilizas. Se puede acceder a MemoryLake a través de MCP y de una API, por lo que los agentes nativos de MCP (como Claude Code, Codex y OpenClaw) se conectan apuntando al servidor MCP, mientras que otros asistentes leen la misma memoria a través de la API.

Conexión de Claude Code, Codex y OpenClaw a través de MCP a una capa de memoria
Conexión de Claude Code, Codex y OpenClaw a través de MCP a una capa de memoria

Tres límites honestos. MemoryLake no se conecta a los almacenes de memoria de Anthropic: no es una integración con esa función, no puede leer ni escribir en un almacén de memoria, y si estás construyendo sobre Managed Agents, debes usar el almacén de la plataforma para la memoria de trabajo del agente como se documenta. Solo contiene lo que tú o tus agentes escriben en él. Y no es un sistema de cumplimiento o retención.

Qué cambia esto en la práctica

Los agentes en Managed Agents dejan de iniciar en frío. El problema documentado (una sesión que termina y se lleva su estado consigo) ahora tiene una solución nativa, y es muy buena.

Las malas escrituras de los agentes se vuelven recuperables. Las versiones inmutables con recuperación a un punto en el tiempo son una propiedad de seguridad significativa para los sistemas autónomos, y merece ser copiada más ampliamente.

La memoria se convierte en un asunto del sistema de archivos. Exponer la memoria como un directorio montado que el agente lee con herramientas de archivos normales elimina toda una categoría de fallos en el uso de herramientas. Arquitectónicamente, esa es la idea más interesante del lanzamiento.

Los despliegues autohospedados necesitan un modelo mental. Descargar antes de las herramientas, sincronizar de vuelta después de las escrituras. No un montaje en vivo.

Las decisiones de alcance se vuelven explícitas. El alcance de espacio de trabajo y la optimización para Claude son límites claros, lo cual es mejor que tener límites ambiguos. Conocerlos te indica qué debes mantener en otro lugar: la forma general en lo que significa la memoria persistente.

Mejores prácticas para los almacenes de memoria de agentes

Habilita el conjunto de herramientas del agente (agent toolset) al crear el agente. Requerido para que el agente interactúe con el almacén. Fácil de pasar por alto, confuso de depurar.

Escribe la descripción del almacén como si el agente fuera a leerla, porque lo hará. Di qué hay dentro y cuándo es relevante.

Usa las rutas deliberadamente. Las memorias se direccionan por ruta. Vale la pena diseñar un diseño de carpetas estable desde el primer día.

Deja que el SDK configure las cabeceras beta. Y si debes configurarlas manualmente, reemplaza en lugar de combinar: ambas en una solicitud de almacén de memoria devuelven un 400.

Siembra y corrige a través de la API o la consola. Se admite la lectura y edición directa, incluyendo la importación y exportación. Un almacén no tiene que empezar vacío ni permanecer incorrecto.

Revisa el historial de versiones después de ejecuciones desatendidas. El registro de auditoría existe para que puedas usarlo.

Reinicia la paginación después del cambio de cabecera. Los cursores de las solicitudes realizadas sin la cabecera más reciente no son válidos con ella.

Mantén el conocimiento independiente del entorno de ejecución fuera de este. Cualquier cosa que sea igualmente cierta para tu editor, tu asistente y tu próximo framework de agentes pertenece a una capa que ninguno de ellos posee: el razonamiento detrás de MCP y la memoria de agentes sin estado.

Conclusión

Los almacenes de memoria son una primitiva bien construida. Montar la memoria como un directorio que el agente lee con herramientas de archivos comunes evita mucha complejidad en el uso de herramientas; añadir una nota en el prompt del sistema sobre el montaje es un pequeño detalle que lo hace utilizable; y el control de versiones inmutable con recuperación a un punto en el tiempo es el tipo de función que convierte las escrituras autónomas de un riesgo a un proceso auditable. Si estás construyendo sobre Managed Agents de Claude, utilízalo, habilita el conjunto de herramientas del agente, escribe descripciones reales y recuerda que los sandboxes autohospedados obtienen una copia sincronizada en lugar de un montaje en vivo.

Los límites también se declaran claramente: con alcance de espacio de trabajo, optimizado para Claude, en beta. Eso no es una deficiencia, es un alcance, y te indica qué debes guardar en otro lugar. La memoria de trabajo del agente pertenece a la plataforma del agente. Las decisiones, restricciones y enfoques rechazados que siguen siendo válidos independientemente de en qué entorno de ejecución te encuentres el próximo trimestre pertenecen a una capa que no está vinculada a ninguno de ellos.

Preguntas frecuentes

¿Qué es un almacén de memoria (memory store) de un agente de Claude?

Según la documentación de Anthropic, es "una colección de documentos de texto con alcance de espacio de trabajo optimizada para Claude". Asociar uno a una sesión de Managed Agents lo monta como un directorio en el sandbox de la sesión, el cual el agente lee y escribe utilizando las mismas herramientas de archivos que usa en otros lugares, con una nota sobre el montaje añadida automáticamente al prompt del sistema.

¿Recuerdan algo por defecto las sesiones de Managed Agents?

No. La documentación establece que cada sesión comienza con un contexto nuevo de forma predeterminada, y cuando una sesión termina, cualquier estado que el agente haya acumulado desaparece. Los almacenes de memoria son el mecanismo para transferir información (preferencias del usuario, convenciones del proyecto, errores previos y contexto del dominio) entre sesiones.

¿Puedo editar lo que el agente escribió en la memoria?

Sí. Cada memoria se direcciona mediante una ruta y se puede leer y editar directamente a través de la API o de la consola de Claude, y la documentación menciona el ajuste, la importación y la exportación como usos admitidos. Cada cambio también crea una versión de memoria inmutable, lo que te brinda un registro de auditoría y recuperación a un punto en el tiempo.

¿Cómo funcionan los almacenes de memoria con sandboxes autohospedados?

De manera diferente al caso administrado, y la documentación es explícita: el directorio no es un montaje en vivo. El trabajador de entorno (environment worker) del SDK descarga cada almacén asociado en tu sandbox antes de que se ejecuten las herramientas del agente y mantiene esa copia sincronizada con el almacén, sincronizando los cambios de vuelta.

¿Por qué obtengo un error 400 en una solicitud de almacén de memoria?

Verifica tus cabeceras beta. Los endpoints del almacén de memoria utilizan agent-memory-2026-07-22 mientras que otras solicitudes de Managed Agents utilizan managed-agents-2026-04-01, y enviar ambas en una solicitud de almacén de memoria devuelve un 400. Asociar un almacén a una sesión es un endpoint de sesión y sigue utilizando la cabecera más antigua. Los SDK manejan esto automáticamente.

¿Se comparten los almacenes de memoria entre espacios de trabajo o con otras herramientas?

Tienen alcance de espacio de trabajo y se describen como optimizados para Claude, por lo que son un almacén para agentes de Claude dentro de un espacio de trabajo en lugar de una capa de conocimiento entre herramientas o entre espacios de trabajo. El conocimiento que necesita ser leído por otros asistentes, editores o un entorno de ejecución de agentes diferente debe residir en algún lugar fuera del almacén de la plataforma.