Los almacenes de memoria de Managed Agents de Anthropic conservan texto entre sesiones. Para una aplicación que deba dar a dos agentes el mismo hecho revisado, la persistencia es solo el primer paso. La aplicación debe decidir a quién pertenece el registro, comprobar la evidencia original, seleccionar una revisión almacenada y conservar sus bytes exactos antes de que los vea cualquiera de los agentes. Esta guía se dirige a desarrolladores con acceso autorizado a la beta de Managed Agents y control de la autenticación de su aplicación, la selección de almacenes y las configuraciones de agentes. Se basa en la documentación actual de memoria de Anthropic y las referencias API comprobadas el 20 de octubre de 2026; BIG CHANGE no realizó pruebas de cuenta ni de modelo.
El gran cambio
- Qué ha cambiado: Una memoria JSON tipada y revisada puede persistir en un almacén de Managed Agents. La aplicación comprueba su fuente y los bytes exactos almacenados, fija una instantánea privada y envía esos mismos bytes aprobados a dos sesiones autorizadas distintas sin adjuntar un almacén de memoria.
- Por qué importa: Una edición posterior del almacén no puede cambiar las entradas ya construidas para esas sesiones.
- En qué fijarse: La exactitud de la fuente, la autorización del usuario y la calidad de las respuestas siguen necesitando comprobaciones separadas.
Antes de empezar
Prepara un hecho real, una preferencia o una regla de proyecto con un original que tengas permiso de usar, su ID de fuente estable y revisión, y un responsable que apruebe almacenarlo y revelarlo a ambos roles de agente. Antes de revisarlo, decide un límite de vigencia adecuado para ese registro. Confirma acceso a la beta de Managed Agents, una clave API privada, un espacio de trabajo autorizado, dos ID de agente configurados, un entorno y un modelo permitido en tu cuenta. Consulta el uso y los precios actuales antes de permitir las cuatro sesiones consumidoras acotadas del procedimiento. Mantén la clave fuera de los mensajes y justificantes.
Tu aplicación necesita una correspondencia entre la identidad autenticada y el ámbito. En el estado de confianza de la aplicación, vincula esa identidad con un ownerScopeId aprobado, el ID del espacio de trabajo, el del almacén y los dos ID de agente permitidos. Separa los almacenes de usuarios o proyectos privados cuando difieran sus reglas de acceso. Una clave API del espacio de trabajo no autentica al usuario final, una ruta no es una frontera entre clientes y un mensaje no puede retirar una herramienta ni una credencial. Verifica que ambas configuraciones consumidoras carecen de almacén adjunto y de cualquier conector, credencial de entorno o ruta de herramientas hacia el almacén mutable. Si no puedes establecer ese límite, detente antes de enviar el registro.
1. Aprueba el registro contra su fuente
Utiliza esta plantilla estructural y sustituye todos los valores entre corchetes angulares por evidencia real aprobada. No es un hecho de ejemplo ni un resultado declarado. Serializa el objeto terminado en un único texto JSON UTF-8 exacto antes de aprobarlo. El validador debe aceptar precisamente estos campos y tipos, rechazar campos desconocidos, exigir cadenas no vacías ni compuestas solo por espacios y marcas de tiempo UTC válidas, limitar kind a fact, preference o project_rule, y limitar status a active, disputed o superseded. Solo se pueden inyectar registros active. La afirmación aprobada debe coincidir con el original citado, incluida su fecha de efecto y su ámbito.
{
"schemaVersion": "memory-record/v1",
"recordId": "<opaque stable record ID>",
"ownerScopeId": "<trusted mapped scope ID>",
"kind": "<fact | preference | project_rule>",
"claim": "<precise source-supported claim>",
"sourceId": "<private original-source ID>",
"sourceRevision": "<original revision or exact source hash>",
"sourceQuoteOrPointer": "<minimal permitted quote or stable pointer>",
"validFrom": "<UTC timestamp>",
"checkedAt": "<UTC timestamp>",
"status": "active",
"reviewerId": "<approved human reviewer ID>",
"reviewedAt": "<UTC timestamp>"
}El justificante privado de aprobación de la aplicación debe identificar al aprobador real, el permiso del responsable, la fuente original y su revisión, el ámbito y los agentes permitidos, la regla de vigencia y el SHA-256 de esos bytes JSON UTF-8 exactos. Registra una decisión humana sobre la afirmación real. Una cadena reviewerId en el registro no constituye autenticación. No persistas un registro con una contradicción sin resolver o un permiso ausente. Anthropic almacena el texto; no valida este esquema ni demuestra la veracidad de la afirmación.
2. Persiste el registro y vuelve a leerlo
Crea o selecciona un almacén de memoria limitado en el espacio de trabajo autorizado y registra su ID real memstore_.... Utiliza una ruta no sensible, como /records/{opaque-record-id}.json. Antes de la solicitud, registra usuario, hora UTC, revisión de fuente, hash de bytes aprobados, almacén y ruta, y estado pending. En las llamadas directas al almacén utiliza agent-memory-2026-07-22; las llamadas de sesión utilizan managed-agents-2026-04-01. Anthropic indica que combinar esas cabeceras beta en una solicitud al almacén devuelve HTTP 400. La referencia de creación y el manual de memoria muestran esta forma del SDK; contrasta el SDK instalado con la referencia actual:
mem = client.beta.memory_stores.memories.create(
store.id,
path="/records/<opaque-record-id>.json",
content=approved_json_text,
)La creación no sobrescribe una ruta existente. Guarda el ID mem_... devuelto y enumera /records/ en el almacén delimitado, usando cada next_page como siguiente page. La lista básica predeterminada omite el contenido. Recupera la memoria seleccionada por ID para obtener todo el texto; compara ID del almacén, ID de memoria, ruta, contenido y content_sha256 con los bytes aprobados. Registra la respuesta y la lectura directa en el diario y el registro. La respuesta de creación por sí sola no demuestra la finalización. Si es incierta, examina la ruta exacta y el registro directo antes de decidir qué ocurrió; la ausencia de un resultado de búsqueda no justifica repetir la creación.
3. Fija la revisión seleccionada
En cada ejecución posterior, autentica al solicitante y resuelve su ámbito, almacén e ID del registro seleccionado desde el registro de confianza. Si necesitas localizarlo, enumera todas las páginas del prefijo delimitado y recupera directamente el mem_... seleccionado. Calcula SHA-256 sobre la codificación UTF-8 del contenido devuelto, compáralo con el content_sha256 del proveedor y el hash exacto aprobado por la persona, y vuelve a validar el JSON. Comprueba ID del registro, ámbito del propietario, revisión de fuente, estado active, actualidad de la fuente y límite de vigencia predeterminado. Si falla alguna comprobación, no envíes nada.
Escribe los bytes exactos recuperados una sola vez en un almacenamiento privado identificado por su hash, con creación exclusiva, como open(path, "xb") de Python. Vuelve a leer y calcular el hash del archivo de inmediato y antes de cada envío. Nunca sobrescribas una instantánea existente. Un archivo parcial o un archivo ya existente con otros bytes en esa dirección exige detenerse y conciliar. Conserva la aprobación original, ID de almacén y memoria, hash del proveedor, hash de la instantánea y decisión de ámbito en un justificante privado de recuperación. Esta instantánea de una sola escritura es un diseño de aplicación, no un montaje de Anthropic fijado a una versión.
4. Entrega los mismos bytes a dos sesiones nuevas
Crea una sesión nueva para el agente A con sus ID reales y autorizados de agente y entorno, y sin ninguna entrada del almacén de memoria en resources. Confirma que los recursos de la sesión devuelta y las herramientas y credenciales efectivas del agente no dejan otra ruta al almacén. La guía de sesiones de Anthropic documenta por separado la creación y el envío de user.message:
session = client.beta.sessions.create(
agent=approved_agent_id,
environment_id=approved_environment_id,
)
client.beta.sessions.events.send(
session.id,
events=[{"type": "user.message", "content": [{"type": "text", "text": message_text}]}],
)Antes de events.send, vuelve a leer y calcular el hash de la instantánea privada. Construye message_text de forma determinista con una etiqueta explícita de «datos revisados», los identificadores del registro, fuente y revisión humana, el texto JSON intacto y su SHA-256, seguidos de una pregunta concreta que la fuente original pueda responder. Los campos mostrados son un formato de mensaje de la aplicación, no campos de respuesta del proveedor. Antes de enviar, registra los bytes UTF-8 completos y el hash del mensaje, hash de la instantánea seleccionada, ID de agente autorizado, ID de sesión y estado de envío. Conserva el resultado y el ID real del evento enviado, o su lectura en la lista de eventos si está disponible. Un resultado desconocido exige leer los eventos, no reenviar a ciegas.
Crea una segunda sesión nueva para el agente B con su ID aprobado por separado y la misma ausencia de acceso al almacén. Vuelve a leer la misma instantánea de una sola escritura, verifica su hash, construye y registra el mensaje completo de B y envíalo. Los mensajes pueden tener preguntas o metadatos de destinatario distintos; verifica que los bytes JSON incrustados y el hash aprobado del registro sean idénticos. Contrasta cada respuesta y los eventos de herramientas con la fuente original. Una respuesta plausible o una cita no demuestra que el modelo se apoyara internamente en el texto inyectado; los justificantes del mensaje y los eventos del proveedor establecen lo que suministró la aplicación. Si alguna sesión tiene un montaje activo u otra ruta al almacén, no le envíes nada.
5. Actualiza solo tras revisar de nuevo la fuente
Cuando cambie el original, recupera directamente la memoria actual y compara las evidencias nuevas y antiguas con el responsable. Pide a una persona que apruebe los bytes JSON exactos de reemplazo con el ID estable del registro, afirmación o referencia de fuente corregida, nueva revisión de fuente y horas de comprobación y revisión. Conserva el justificante y hash anteriores. Registra el ID mem_..., el content_sha256 actual leído directamente, hash del reemplazo previsto, usuario, aprobación y estado pendiente. La actualización condicional documentada es:
client.beta.memory_stores.memories.update(
memory_id=memory_id,
memory_store_id=store_id,
content=approved_replacement_json_text,
precondition={"type": "content_sha256", "content_sha256": fresh_old_hash},
)El proveedor calcula el hash del contenido UTF-8 exacto sin normalización. Una discrepancia devuelve HTTP 409 memory_precondition_failed_error. Ante esa respuesta o un resultado de red incierto, recupera otra vez la memoria activa y examina el historial de versiones si hace falta. Compara las revisiones de fuente en conflicto y pide al responsable que combine, rechace o apruebe un nuevo reemplazo exacto; nunca reintentes a ciegas la escritura obsoleta. Tras el éxito, la recuperación directa debe confirmar ruta, texto completo de reemplazo, hash e ID de versión de memoria antes de que el diario pase a confirmed.
Fija una nueva instantánea aprobada de esa revisión verificada. Inicia sesiones A y B nuevas y autorizadas sin montajes del almacén y repite los dos envíos y las comprobaciones de fuente. No alteres las instantáneas antiguas ni afirmes que los mensajes ya enviados se actualizan solos. Marca la instantánea anterior como no apta para futuras inyecciones. Si el responsable retira un registro, detén los nuevos envíos y aplica su política de conservación y supresión de datos: borrar la memoria actual no elimina necesariamente las versiones retenidas. Archivar o borrar todo el almacén es otra decisión.
Qué cuenta como terminado
Tus justificantes privados deben conectar el permiso original y la revisión de fuente con el hash JSON exacto aprobado; la identidad real de espacio de trabajo, almacén, ruta y mem_... y la lectura directa tras crear; una instantánea inmutable; dos ID de sesión distintos, autorizados y sin montaje con hashes de mensajes enviados y respuestas contrastadas con la fuente; y la actualización condicional aprobada con nueva lectura directa y comprobaciones de sesiones nuevas. Si algún vínculo es desconocido, marca todo el ejercicio como incompleto y conserva el motivo preciso. Si lo ejecutas, registra el uso real de sesiones y herramientas y el coste de tu cuenta; esta guía documental no midió ahorros ni rendimiento del modelo.
Para un trabajo relacionado pero distinto, revisar una salida de Dream para una sesión posterior aborda una propuesta generada para el almacén. Este proceso parte de un registro de fuente aprobado por su responsable y fija exactamente lo que reciben dos consumidores.
