Zwei Agenten denselben geprüften Speicherdatensatz geben

Die Speicher von Anthropics Managed Agents können Text über Sitzungen hinweg behalten. Soll eine Anwendung zwei Agenten dieselbe geprüfte Tatsache geben, ist dauerhafte Speicherung nur der erste Schritt. Die Anwendung muss die Eigentümerschaft bestimmen, den Originalbeleg prüfen, eine gespeicherte Revision auswählen und deren exakte Bytes sichern, bevor einer der Agenten sie sieht. Dieser Leitfaden richtet sich an Entwickler mit autorisiertem Zugang zur Beta von Managed Agents und Kontrolle über Anwendungsauthentifizierung, Speicherauswahl und Agentenkonfigurationen. Er beruht auf Anthropics aktueller Speicherdokumentation und am 20. Oktober 2026 geprüften API-Referenzen; BIG CHANGE hat keinen Konto- oder Modelltest ausgeführt.

Die große Veränderung

• Was sich geändert hat: Ein geprüfter typisierter JSON-Speicherinhalt kann in einem Managed Agents-Speicher bestehen bleiben. Die Anwendung prüft Quelle und exakte gespeicherte Bytes, fixiert einen privaten Schnappschuss und sendet dieselben genehmigten Bytes an zwei getrennte autorisierte Sitzungen ohne angebundenen Speicher.
• Warum das wichtig ist: Eine spätere Speicherbearbeitung kann die bereits für diese Sitzungen aufgebauten Eingaben nicht verändern.
• Worauf zu achten ist: Quellgenauigkeit, Benutzerberechtigung und Antwortqualität müssen weiterhin getrennt geprüft werden.

Vor dem Start

Bringe eine echte Tatsache, Präferenz oder Projektregel mit einem zur Nutzung freigegebenen Original, stabiler Quell-ID und Revision sowie einem Eigentümer mit, der Speicherung und Offenlegung gegenüber beiden Agentenrollen genehmigt. Lege vor der Prüfung eine passende Gültigkeitsgrenze für diese Überprüfung fest. Bestätige Beta-Zugang zu Managed Agents, einen privaten API-Schlüssel, einen autorisierten Arbeitsbereich, zwei konfigurierte Agenten-IDs, eine Umgebung und ein im Konto erlaubtes Modell. Prüfe aktuelle Nutzung und Preise, bevor du die vier begrenzten Verbrauchersitzungen dieses Verfahrens zulässt. Halte den Schlüssel aus Nachrichten und Nachweisen heraus.

Deine Anwendung braucht eine Zuordnung vom authentifizierten Akteur zum Geltungsbereich. Binde den Akteur im vertrauenswürdigen Anwendungszustand an eine genehmigte ownerScopeId, Arbeitsbereich-ID, Speicher-ID und die zwei erlaubten Agenten-IDs. Nutze getrennte Speicher für private Benutzer oder Projekte mit unterschiedlichen Zugriffsregeln. Ein Arbeitsbereich-API-Schlüssel authentifiziert keinen Endnutzer, ein Pfad ist keine Mandantengrenze und ein Prompt entfernt weder Werkzeug noch Zugangsdaten. Prüfe, dass beide Verbraucherkonfigurationen weder eine Speicheranbindung noch Konnektor, Umgebungszugangsdaten oder Werkzeugpfad zum veränderbaren Speicher haben. Kannst du diese Grenze nicht nachweisen, stoppe vor dem Versand des Datensatzes.

1. Datensatz anhand seiner Quelle genehmigen

Nutze diese Strukturvorlage und ersetze jeden Wert in Winkelklammern durch echte genehmigte Belege. Dies ist keine Beispieltatsache und kein behauptetes Ergebnis. Serialisiere das vollständige Objekt vor der Genehmigung in einen exakten UTF-8-JSON-Text. Der Validator soll genau diese Felder und Typen akzeptieren, unbekannte Felder ablehnen, nichtleere, nicht nur aus Leerzeichen bestehende Zeichenfolgen und gültige UTC-Zeitstempel verlangen, kind auf fact, preference oder project_rule sowie status auf active, disputed oder superseded beschränken. Nur Datensätze mit active dürfen eingespeist werden. Die genehmigte Aussage muss dem zitierten Original entsprechen, einschließlich Wirksamkeitsdatum und Geltungsbereich.

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

Der private Genehmigungsnachweis der Anwendung muss den tatsächlichen Genehmigenden, die Erlaubnis des Eigentümers, Originalquelle und Revision, Geltungsbereich und erlaubte Agenten, Aktualitätsregel und SHA-256 dieser exakten UTF-8-JSON-Bytes festhalten. Er dokumentiert eine menschliche Entscheidung über die tatsächliche Aussage. Eine reviewerId-Zeichenfolge im Datensatz ist keine Authentifizierung. Speichere keinen Datensatz mit ungelöstem Widerspruch oder fehlender Erlaubnis. Anthropic speichert Text, validiert aber weder dieses Schema noch die Wahrheit der Aussage.

2. Dauerhaft speichern und zurücklesen

Erstelle oder wähle im autorisierten Arbeitsbereich einen eng begrenzten Speicher und notiere seine tatsächliche memstore_...-ID. Nutze einen nicht sensiblen Pfad wie /records/{opaque-record-id}.json. Protokolliere vor der Anfrage Akteur, UTC-Zeit, Quellrevision, Hash der genehmigten Bytes, Speicher und Pfad sowie den Zustand pending. Für direkte Speicheraufrufe nutzt du agent-memory-2026-07-22, für Sitzungsaufrufe managed-agents-2026-04-01. Laut Anthropic liefert die Kombination dieser Beta-Header bei einer Speicheranfrage HTTP 400. Die Erstellungsreferenz und das Speicherhandbuch zeigen diese SDK-Form; gleiche das installierte SDK mit der aktuellen Referenz ab:

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

Das Anlegen überschreibt keinen bestehenden Pfad. Sichere die zurückgegebene mem_...-ID und liste anschließend /records/ im begrenzten Speicher auf, wobei jedes next_page als nächstes page dient. Die standardmäßige Basisliste enthält keinen Inhalt. Rufe den gewählten Speichereintrag ab, um über seine ID den vollständigen Text zu erhalten; vergleiche Speicher-ID, Eintrag-ID, Pfad, Inhalt und content_sha256 mit den genehmigten Bytes. Erfasse Antwort und direktes Zurücklesen im Protokoll und Register. Die Erstellungsantwort allein ist keine Abschlussprüfung. Ist sie unklar, untersuche exakten Pfad und direkten Datensatz, bevor du über den Ausgang entscheidest; ein fehlender Suchtreffer allein rechtfertigt keine Wiederholung.

3. Gewählte Revision fixieren

Authentifiziere bei jedem späteren Lauf den Aufrufer und ermittle Geltungsbereich, Speicher und gewählte Datensatz-ID aus dem vertrauenswürdigen Register. Falls Suche nötig ist, liste alle Seiten des begrenzten Präfixes auf und rufe dann den gewählten mem_... direkt ab. Berechne SHA-256 über die UTF-8-Kodierung des zurückgegebenen Inhalts, vergleiche es mit dem content_sha256 des Anbieters und dem exakten menschlich genehmigten Byte-Hash und validiere JSON erneut. Prüfe Datensatz-ID, Eigentümerbereich, Quellrevision, Status active, Aktualität der Quelle und die vorher festgelegte Frist. Schlägt eine Prüfung fehl, sende nichts.

Schreibe die exakt abgerufenen Bytes einmalig in privaten Speicher, der über ihren Hash adressiert wird, mit exklusivem Anlegen wie open(path, "xb") in Python. Lies und hashe die Datei sofort und vor jedem Versand erneut. Überschreibe niemals einen bestehenden Schnappschuss. Eine unvollständige Datei oder andere Bytes an derselben Adresse sind ein zu klärender Haltegrund. Bewahre ursprüngliche Genehmigung, Speicher-ID, Eintrag-ID, Anbieter-Hash, Schnappschuss-Hash und Bereichsentscheidung in einem privaten Abrufnachweis auf. Dieser einmalig geschriebene Schnappschuss ist Anwendungsdesign, kein versionsgebundener Anthropic-Mount.

4. Dieselben Bytes zwei neuen Sitzungen bereitstellen

Erstelle für Agent A eine neue Sitzung mit den echten autorisierten Agenten- und Umgebungs-IDs und ohne Speichereintrag in resources. Bestätige, dass Ressourcen der zurückgegebenen Sitzung sowie wirksame Werkzeuge und Zugangsdaten keinen anderen Speicherzugang lassen. Anthropics Sitzungsleitfaden dokumentiert Erstellung und Versand von user.message getrennt:

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

Vor events.send liest und hashst du den privaten Schnappschuss erneut. Erzeuge message_text deterministisch aus einer ausdrücklichen Kennzeichnung „geprüfte Daten“, Kennungen von Datensatz, Quelle und Prüfung, unverändertem JSON-Text und dessen SHA-256 sowie einer engen Frage, die das Original beantworten kann. Die gezeigten Felder sind ein Nachrichtenformat der Anwendung, keine Antwortfelder des Anbieters. Protokolliere vor dem Versand vollständige UTF-8-Nachrichtenbytes und Hash, gewählten Schnappschuss-Hash, autorisierte Agenten-ID, Sitzungs-ID und Versandzustand. Bewahre Ergebnis und echte gesendete Ereignis-ID oder verfügbare Ereignislisten-Rücklesung auf. Ein unbekannter Versandausgang verlangt Ereignisrücklesung, keine blinde Wiederholung.

Erstelle für Agent B eine zweite neue Sitzung mit seiner gesondert genehmigten Agenten-ID und ebenfalls ohne Speicherzugriff. Lies denselben einmalig geschriebenen Schnappschuss erneut, prüfe seinen Byte-Hash, erzeuge und protokolliere Bs vollständige Nachricht und sende sie. Aufgabenfragen oder Empfängermetadaten dürfen unterschiedlich sein; eingebettete JSON-Bytes und genehmigter Datensatz-Hash müssen identisch sein. Prüfe jede Antwort und Werkzeugereignisse am Original. Eine plausible Antwort oder Quellenangabe beweist nicht, dass das Modell intern den eingespeisten Text verwendet hat; Nachrichten- und Anbieterereignisnachweise belegen, was die Anwendung bereitstellte. Hat eine Sitzung einen aktiven Mount oder anderen Speicherpfad, sende ihr nichts.

5. Erst nach erneuter Quellenprüfung aktualisieren

Ändert sich das Original, rufe die aktuelle Erinnerung direkt ab und vergleiche alte und neue Belege mit dem Eigentümer. Lasse einen Menschen die exakten Ersatz-JSON-Bytes mit stabiler Datensatz-ID, korrigierter Aussage oder Quellverweis, neuer Quellrevision und Prüfzeiten genehmigen. Bewahre alten Nachweis und Hash auf. Protokolliere die mem_...-ID, den aktuell direkt gelesenen content_sha256, vorgesehenen Ersatz-Hash, Akteur, Genehmigung und ausstehenden Zustand. Die dokumentierte bedingte Aktualisierung lautet:

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

Der Anbieter hasht exakten UTF-8-Inhalt ohne Normalisierung. Bei Abweichung folgt HTTP 409 memory_precondition_failed_error. Rufe bei dieser Antwort oder unklarem Netzwerkergebnis den aktuellen Speicherinhalt erneut ab und prüfe nötigenfalls die Versionshistorie. Vergleiche konkurrierende Quellrevisionen und bitte den Eigentümer um Zusammenführung, Ablehnung oder Genehmigung eines neuen exakten Ersatzes; wiederhole den veralteten Schreibversuch niemals blind. Nach Erfolg muss ein direkter Abruf Pfad, vollständigen Ersatztext, Hash und Speicherversion-ID bestätigen, bevor das Protokoll auf confirmed wechselt.

Fixiere einen neuen genehmigten Schnappschuss aus dieser verifizierten Revision. Starte neue autorisierte Sitzungen A und B ohne Speichermounts und wiederhole beide Sendungen und Quellenprüfungen. Ändere keine alten Schnappschüsse und behaupte nicht, gesendete Nachrichten aktualisierten sich selbst. Sperre den früheren Schnappschuss für künftige Einspeisung. Zieht der Eigentümer einen Datensatz zurück, stoppe neue Sendungen und befolge seine Aufbewahrungs- und Schwärzungsregeln: Löschen der aktuellen Erinnerung entfernt nicht unbedingt gespeicherte Versionen. Archivierung oder Löschung des ganzen Speichers ist eine gesonderte Entscheidung.

Wann die Arbeit abgeschlossen ist

Deine privaten Nachweise müssen ursprüngliche Erlaubnis und Quellrevision mit dem exakten genehmigten JSON-Hash verbinden; echte Arbeitsbereich-, Speicher-, Pfad- und mem_...-Identität samt direkter Rücklesung nach Erstellung; einen unveränderlichen Schnappschuss; zwei unterschiedliche autorisierte Sitzungs-IDs ohne Mount mit Hashes gesendeter Nachrichten und quellengeprüften Antworten; sowie genehmigte bedingte Aktualisierung mit neuer direkter Rücklesung und Prüfungen neuer Sitzungen. Ist eine Verbindung unbekannt, kennzeichne die gesamte Übung als unvollständig und bewahre den genauen Haltegrund auf. Bei Ausführung erfasse tatsächliche Sitzungs- und Werkzeugnutzung und kontospezifische Kosten; dieser dokumentationsbasierte Leitfaden hat weder Einsparungen noch Modellleistung gemessen.

Für verwandte, aber andere Arbeit behandelt die Prüfung einer Dream-Ausgabe für eine spätere Sitzung einen erzeugten Speichervorschlag. Dieser Ablauf beginnt bei einem vom Eigentümer genehmigten Quelldatensatz und fixiert genau, was zwei Verbraucher erhalten.