Édition Markdown

AI-translated from English; not yet reviewed by a fluent editor.

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

> Stockez un enregistrement mémoire typé approuvé à partir de sa source, fournissez ses octets exacts à deux sessions autorisées, puis vérifiez une mise à jour conditionnelle et résolvez les conflits.

By BIG CHANGE Editorial

Published: 2026-10-20T13:57:38.593Z
Updated: 2026-10-20T13:57:38.593Z
Canonical: https://bigchange.ai/blog/managed-agents-reviewed-memory-snapshot-guide

![Conceptual charcoal illustration of two separate laptops on a round table, each displaying the same five abstract text strokes with the third row orange.](https://bigchange.ai/api/media/file/reviewed-memory-two-sessions-hero-v3.png)
AI-generated conceptual illustration by BIG CHANGE.

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](https://platform.claude.com/docs/en/managed-agents/memory) 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.

```json
{
  "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](https://platform.claude.com/docs/en/api/beta/memory_stores/memories/create) et le manuel mémoire présentent cette forme du SDK ; comparez le SDK installé à la référence actuelle :

```python
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é](https://platform.claude.com/docs/en/api/beta/memory_stores/memories/retrieve) 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](https://platform.claude.com/docs/en/managed-agents/sessions) d’Anthropic documente séparément la création et l’envoi de `user.message` :

```python
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](https://platform.claude.com/docs/en/api/beta/memory_stores/memories/update) documentée est :

```python
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](https://bigchange.ai/blog/claude-managed-agents-reviewed-dream-memory-guide) 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.

## Sources

- [Manuel mémoire Anthropic Managed Agents](https://platform.claude.com/docs/en/managed-agents/memory) — Documente les en-têtes bêta, espaces texte de travail, montages modifiables, versions et limites. Il n’authentifie pas l’utilisateur final, ne valide pas la véracité d’une affirmation et ne fixe pas un espace monté à une révision approuvée.
- [API Anthropic de création d’une mémoire](https://platform.claude.com/docs/en/api/beta/memory_stores/memories/create) — Documente la création par chemin et contenu et l’identité renvoyée. Aucune création n’a été exécutée pour ce guide ; validation et approbation de l’application restent distinctes.
- [API Anthropic de liste des mémoires](https://platform.claude.com/docs/en/api/beta/memory_stores/memories/list) — Documente path_prefix, la pagination next_page et les résultats de base sans contenu. Une récupération directe complète de l’enregistrement choisi reste nécessaire.
- [API Anthropic de récupération d’une mémoire](https://platform.claude.com/docs/en/api/beta/memory_stores/memories/retrieve) — Documente la récupération complète de la mémoire sélectionnée pour relire contenu et empreinte ; exactitude de la source et périmètre sont contrôlés par l’application.
- [API Anthropic de mise à jour d’une mémoire](https://platform.claude.com/docs/en/api/beta/memory_stores/memories/update) — Documente la condition exacte UTF-8 content_sha256 et HTTP 409 memory_precondition_failed_error. La résolution humaine des conflits est la politique d’application proposée par le guide.
- [Anthropic : démarrer une session](https://platform.claude.com/docs/en/managed-agents/sessions) — Documente la création des sessions avec agent et environnement et user.message via events.send. Ce guide n’a exécuté aucune session ; instantané privé sans montage et journal des messages sont des contrôles de l’application.
- [BIG CHANGE : vérifier un espace mémoire Claude Managed Agent avec un Dream](https://bigchange.ai/blog/claude-managed-agents-reviewed-dream-memory-guide) — Guide lié de revue d’une seule sortie. Il ne démontre pas le cycle typé d’instantané exact pour deux agents décrit ici.