Donner à deux agents le même enregistrement mémoire vérifié

Les espaces mémoire de Managed Agents d’Anthropic peuvent conserver du texte entre les sessions. Pour une application qui doit donner à deux agents le même fait vérifié, la persistance n’est que la première étape. L’application doit déterminer à qui appartient l’enregistrement, contrôler la preuve d’origine, sélectionner une révision stockée et préserver ses octets exacts avant de les montrer aux agents. Ce guide s’adresse aux développeurs ayant un accès autorisé à la bêta Managed Agents et la maîtrise de l’authentification de leur application, du choix des espaces et des configurations des agents. Il s’appuie sur la documentation mémoire actuelle d’Anthropic et les références API vérifiées le 20 octobre 2026 ; BIG CHANGE n’a effectué aucun test de compte ni de modèle.

Le grand changement

• Ce qui a changé : Un enregistrement mémoire JSON typé et vérifié peut persister dans un espace Managed Agents. L’application contrôle sa source et ses octets stockés exacts, fige un instantané privé, puis envoie les mêmes octets approuvés à deux sessions autorisées distinctes sans rattachement à l’espace mémoire.
• Pourquoi cela compte : Une modification ultérieure de l’espace ne peut pas changer les entrées déjà préparées pour ces sessions.
• À surveiller : L’exactitude de la source, l’autorisation de l’utilisateur et la qualité des réponses exigent toujours des contrôles séparés.

Avant de commencer

Préparez un fait réel, une préférence ou une règle de projet avec son original utilisable sous autorisation, son identifiant source stable et sa révision, ainsi qu’un responsable qui approuve le stockage et la divulgation aux deux rôles d’agents. Fixez avant la vérification une durée de validité adaptée à cet enregistrement. Confirmez l’accès à la bêta Managed Agents, une clé API privée, un espace de travail autorisé, deux identifiants d’agents configurés, un environnement et un modèle permis dans votre compte. Consultez l’usage et les tarifs actuels avant d’autoriser les quatre sessions consommatrices délimitées de cette procédure. Gardez la clé hors des messages et des justificatifs.

Votre application a besoin d’une correspondance entre l’identité authentifiée et le périmètre. Dans son état de confiance, associez cette identité à un ownerScopeId approuvé, à l’identifiant de l’espace de travail, à celui de l’espace mémoire et aux deux identifiants d’agents autorisés. Séparez les espaces des utilisateurs ou projets privés lorsque leurs règles d’accès diffèrent. Une clé API d’espace de travail n’authentifie pas l’utilisateur final, un chemin n’isole pas un locataire et un message ne peut pas retirer un outil ou un identifiant d’accès. Vérifiez que les deux configurations consommatrices n’ont ni espace mémoire rattaché, ni connecteur, ni identifiant d’environnement, ni outil permettant d’accéder à l’espace modifiable. Si vous ne pouvez pas établir cette frontière, arrêtez-vous avant d’envoyer l’enregistrement.

1. Approuver l’enregistrement à partir de sa source

Utilisez ce modèle structurel, en remplaçant chaque valeur entre chevrons par une preuve réelle approuvée. Ce n’est ni un fait d’exemple ni un résultat revendiqué. Sérialisez l’objet complété en un texte JSON UTF-8 exact avant approbation. Votre validateur doit accepter précisément ces champs et types, rejeter les champs inconnus, exiger des chaînes qui ne sont ni vides ni composées uniquement d’espaces et des horodatages UTC valides, limiter kind à fact, preference ou project_rule, et limiter status à active, disputed ou superseded. Seuls les enregistrements active peuvent être injectés. L’affirmation approuvée doit correspondre à l’original cité, notamment sa date d’effet et son périmètre.

{
  "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>"
}

Le justificatif privé d’approbation de l’application doit identifier le véritable approbateur, la permission du responsable, la source originale et sa révision, le périmètre et les agents autorisés, la règle de fraîcheur et le SHA-256 de ces octets JSON UTF-8 exacts. Il consigne une décision humaine sur l’affirmation réelle. Une chaîne reviewerId dans l’enregistrement n’est pas une authentification. Ne stockez pas d’enregistrement comportant une contradiction non résolue ou une permission manquante. Anthropic stocke le texte ; il ne valide pas ce schéma et n’établit pas la véracité de l’affirmation.

2. Stocker puis relire l’enregistrement

Créez ou sélectionnez un espace mémoire restreint dans l’espace de travail autorisé et notez son véritable identifiant memstore_.... Utilisez un chemin non sensible tel que /records/{opaque-record-id}.json. Avant la requête, consignez l’acteur, l’heure UTC, la révision source, l’empreinte des octets approuvés, l’espace et le chemin, ainsi que l’état pending. Pour les appels directs à l’espace mémoire, utilisez agent-memory-2026-07-22 ; les appels de session utilisent managed-agents-2026-04-01. Selon Anthropic, combiner ces en-têtes bêta dans une requête vers l’espace renvoie HTTP 400. La référence de création et le manuel mémoire présentent cette forme du SDK ; comparez le SDK installé à la référence actuelle :

mem = client.beta.memory_stores.memories.create(
    store.id,
    path="/records/<opaque-record-id>.json",
    content=approved_json_text,
)

La création n’écrase pas un chemin existant. Conservez l’identifiant mem_... renvoyé, puis listez /records/ dans l’espace délimité, en utilisant chaque next_page comme paramètre page suivant. La liste de base omet le contenu par défaut. Récupérez l’enregistrement mémoire sélectionné par son identifiant pour obtenir le texte complet ; comparez l’identifiant de l’espace, l’identifiant mémoire, le chemin, le contenu et content_sha256 aux octets approuvés. Consignez la réponse et la relecture directe dans le journal et le registre. La réponse de création seule ne prouve pas l’achèvement. Si elle est incertaine, inspectez le chemin exact et l’enregistrement direct avant de conclure ; une recherche sans résultat ne justifie pas à elle seule de répéter la création.

3. Figer la révision sélectionnée

À chaque exécution ultérieure, authentifiez l’appelant et déterminez son périmètre, son espace et l’identifiant de l’enregistrement sélectionné à partir du registre de confiance. Si une recherche est nécessaire, parcourez toutes les pages du préfixe délimité, puis récupérez directement le mem_... sélectionné. Calculez SHA-256 sur l’encodage UTF-8 du contenu renvoyé, comparez-le au content_sha256 du fournisseur et à l’empreinte exacte approuvée par l’humain, puis validez de nouveau le JSON. Vérifiez l’identifiant de l’enregistrement, le périmètre du propriétaire, la révision source, le statut active, l’actualité de la source et la limite de fraîcheur prédéfinie. Si un contrôle échoue, n’envoyez rien.

Écrivez une seule fois les octets exacts récupérés dans un stockage privé adressé par leur empreinte, avec une création exclusive telle que open(path, "xb") en Python. Relisez et hachez le fichier immédiatement et avant chaque envoi. N’écrasez jamais un instantané existant. Un fichier partiel ou des octets différents à cette adresse imposent une suspension et une résolution. Conservez l’approbation originale, les identifiants d’espace et de mémoire, l’empreinte du fournisseur, celle de l’instantané et la décision de périmètre dans un justificatif privé de récupération. Cet instantané écrit une seule fois est une conception de l’application, pas un montage Anthropic fixé à une version.

4. Fournir les mêmes octets à deux nouvelles sessions

Créez une nouvelle session pour l’agent A avec ses véritables identifiants autorisés d’agent et d’environnement, et aucune entrée d’espace mémoire dans resources. Confirmez que les ressources de la session retournée, les outils et les identifiants effectifs de l’agent ne laissent aucun autre accès à l’espace. Le guide des sessions d’Anthropic documente séparément la création et l’envoi 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}]}],
)

Avant events.send, relisez et hachez l’instantané privé. Construisez message_text de façon déterministe à partir d’une étiquette explicite « données vérifiées », des identifiants d’enregistrement, de source et de révision humaine, du texte JSON inchangé et de son SHA-256, puis d’une question précise à laquelle la source originale peut répondre. Les champs affichés constituent un format de message propre à l’application, pas des champs de réponse du fournisseur. Avant l’envoi, consignez les octets UTF-8 complets du message et leur empreinte, l’empreinte de l’instantané choisi, l’identifiant d’agent autorisé, l’identifiant de session et l’état d’envoi. Conservez le résultat et l’identifiant réel de l’événement envoyé, ou sa lecture dans la liste des événements si disponible. Un envoi au résultat inconnu exige une relecture des événements, pas une répétition aveugle.

Créez une deuxième nouvelle session pour l’agent B avec son identifiant d’agent approuvé séparément et la même absence d’accès à l’espace. Relisez le même instantané écrit une seule fois, vérifiez son empreinte, construisez et journalisez le message complet de B, puis envoyez-le. Les messages peuvent contenir des questions ou métadonnées de destinataire différentes ; vérifiez que les octets JSON incorporés et l’empreinte approuvée de l’enregistrement sont identiques. Contrôlez chaque réponse et tout événement d’outil à partir de la source originale. Une réponse plausible ou une citation ne prouve pas que le modèle s’est appuyé intérieurement sur le texte injecté ; les justificatifs des messages et événements du fournisseur établissent ce que l’application a fourni. Si une session possède un montage actif ou un autre accès à l’espace, ne lui envoyez rien.

5. Mettre à jour seulement après une nouvelle vérification de la source

Quand l’original change, récupérez directement la mémoire actuelle et comparez les anciennes et nouvelles preuves avec le responsable. Faites approuver par un humain les octets JSON exacts de remplacement avec l’identifiant stable de l’enregistrement, l’affirmation ou le pointeur source corrigé, la nouvelle révision source et les heures de contrôle et de revue. Conservez l’ancien justificatif et son empreinte. Journalisez l’identifiant mem_..., le content_sha256 actuel lu directement, l’empreinte de remplacement voulue, l’acteur, l’approbation et l’état en attente. La mise à jour conditionnelle documentée est :

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},
)

Le fournisseur calcule l’empreinte du contenu UTF-8 exact sans normalisation. Une différence renvoie HTTP 409 memory_precondition_failed_error. Face à cette réponse ou à un résultat réseau incertain, récupérez de nouveau la mémoire active et inspectez l’historique des versions au besoin. Comparez les révisions sources concurrentes et demandez au responsable de fusionner, rejeter ou approuver un nouveau remplacement exact ; ne répétez jamais aveuglément l’écriture périmée. En cas de succès, une récupération directe doit confirmer le chemin, tout le texte de remplacement, l’empreinte et l’identifiant de version mémoire avant de passer le journal à confirmed.

Figez un nouvel instantané approuvé à partir de cette révision vérifiée. Démarrez de nouvelles sessions A et B autorisées sans montage d’espace, puis répétez les deux envois et les contrôles de source. Ne modifiez pas les anciens instantanés et ne prétendez pas que les messages déjà envoyés se mettent à jour seuls. Rendez l’instantané antérieur inéligible aux injections futures. Si le responsable retire un enregistrement, arrêtez les nouveaux envois et appliquez sa politique de conservation et de suppression des données : supprimer la mémoire actuelle n’élimine pas nécessairement les versions conservées. Archiver ou supprimer tout l’espace est une décision distincte.

Ce qui constitue un résultat terminé

Vos justificatifs privés doivent relier la permission d’origine et la révision source à l’empreinte JSON exacte approuvée ; l’identité réelle de l’espace de travail, de l’espace mémoire, du chemin et du mem_... avec la relecture directe de création ; un instantané immuable ; deux identifiants de sessions distinctes, autorisées et sans montage, avec les empreintes des messages envoyés et les réponses contrôlées à partir de la source ; et la mise à jour conditionnelle approuvée avec nouvelle relecture directe et contrôles de nouvelles sessions. Si un lien est inconnu, marquez l’exercice entier incomplet et conservez le motif précis. Si vous l’exécutez, notez l’usage réel des sessions et outils ainsi que le coût propre au compte ; ce guide documentaire n’a mesuré ni économies ni performances du modèle.

Pour un travail lié mais différent, vérifier une sortie Dream pour une session ultérieure traite d’une proposition de mémoire générée. Le processus présenté ici part d’un enregistrement approuvé par son responsable et fixe exactement ce que reçoivent deux consommateurs.