Anthropic के Managed Agents मेमोरी स्टोर सत्रों के बीच टेक्स्ट रख सकते हैं। जिस ऐप को दो एजेंटों को एक ही जाँचा हुआ तथ्य देना है, उसके लिए स्थायी भंडारण केवल पहला कदम है। ऐप को तय करना होगा कि रिकॉर्ड किसका है, मूल प्रमाण जाँचना होगा, सहेजा हुआ एक संशोधन चुनना होगा और किसी भी एजेंट के देखने से पहले उसके सटीक बाइट सुरक्षित रखने होंगे। यह मार्गदर्शिका उन डेवलपरों के लिए है जिनके पास अधिकृत Managed Agents बीटा पहुँच और ऐप प्रमाणीकरण, स्टोर चयन तथा एजेंट कॉन्फ़िगरेशन का नियंत्रण है। इसका आधार है Anthropic का वर्तमान मेमोरी दस्तावेज और 20 अक्टूबर 2026 को जाँचे गए API संदर्भ; BIG CHANGE ने खाते या मॉडल का परीक्षण नहीं चलाया।

बड़ा बदलाव

  • क्या बदला:समीक्षा किया गया, तय डेटा प्रकारों वाला JSON मेमोरी रिकॉर्ड Managed Agents स्टोर में रह सकता है। ऐप उसका स्रोत और सहेजे गए सटीक बाइट जाँचता है, एक निजी स्नैपशॉट स्थिर करता है और मेमोरी स्टोर जोड़े बिना वही स्वीकृत बाइट दो अलग अधिकृत सत्रों को भेजता है।
  • यह क्यों मायने रखता है: स्टोर का बाद का संपादन उन सत्रों के लिए पहले से बने इनपुट नहीं बदल सकता।
  • किन बातों पर ध्यान दें: स्रोत की सटीकता, उपयोगकर्ता की अनुमति और उत्तर की गुणवत्ता की अलग जाँच अब भी जरूरी है।

शुरू करने से पहले

एक वास्तविक तथ्य, पसंद या परियोजना नियम तैयार रखें, जिसका मूल उपयोग की अनुमति सहित उपलब्ध हो, स्थायी स्रोत ID और संशोधन हो तथा स्वामी दोनों एजेंट भूमिकाओं को देने और भंडारण की स्वीकृति दे। समीक्षा से पहले रिकॉर्ड के लिए उपयुक्त समीक्षा-वैधता सीमा तय करें। Managed Agents बीटा पहुँच, निजी API कुंजी, अधिकृत कार्यक्षेत्र, दो कॉन्फ़िगर किए गए एजेंट ID, वातावरण और खाते में अनुमत मॉडल की पुष्टि करें। इस प्रक्रिया के चार सीमित उपभोक्ता सत्रों को अनुमति देने से पहले वर्तमान उपयोग और कीमतें देखें। कुंजी प्रॉम्प्ट या प्रमाण रिकॉर्ड में न रखें।

ऐप में प्रमाणित पहचान से दायरे का मिलान होना चाहिए। विश्वसनीय ऐप स्थिति में उस पहचान को स्वीकृत ownerScopeId, कार्यक्षेत्र ID, स्टोर ID और दो अनुमत एजेंट ID से बाँधें। निजी उपयोगकर्ताओं या परियोजनाओं के पहुँच नियम अलग हों तो अलग स्टोर दें। कार्यक्षेत्र API कुंजी अंतिम उपयोगकर्ता को प्रमाणित नहीं करती, पथ किरायेदारों की सुरक्षा सीमा नहीं है और प्रॉम्प्ट उपकरण या क्रेडेंशियल नहीं हटा सकता। सुनिश्चित करें कि दोनों उपभोक्ता कॉन्फ़िगरेशन में स्टोर जुड़ा न हो और बदलते स्टोर तक कनेक्टर, वातावरण क्रेडेंशियल या उपकरण का कोई रास्ता न हो। यह सीमा स्थापित न कर सकें तो रिकॉर्ड भेजने से पहले रुकें।

1. रिकॉर्ड को स्रोत से मिलाकर स्वीकृत करें

यह संरचनात्मक टेम्पलेट इस्तेमाल करें और कोणीय कोष्ठकों की हर वैल्यू वास्तविक स्वीकृत प्रमाण से बदलें। यह नमूना तथ्य या दावा किया गया परिणाम नहीं है। स्वीकृति से पहले पूरे ऑब्जेक्ट को एक सटीक UTF-8 JSON टेक्स्ट में क्रमबद्ध करें। वैलिडेटर केवल इन्हीं फ़ील्ड और प्रकारों को स्वीकार करे, अनजान फ़ील्ड अस्वीकार करे, खाली या सिर्फ खाली जगहों वाली स्ट्रिंग न माने, वैध UTC टाइमस्टैम्प माँगे और kind को fact, preference या project_rule तथा status को active, disputed या superseded तक सीमित रखे। केवल active रिकॉर्ड दिए जा सकते हैं। स्वीकृत दावा उद्धृत मूल से मेल खाना चाहिए, प्रभावी तारीख और दायरे सहित।

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

ऐप के निजी स्वीकृति प्रमाण में वास्तविक स्वीकर्ता, स्वामी की अनुमति, मूल स्रोत और संशोधन, दायरा और अनुमत एजेंट, वैधता नियम और इन सटीक UTF-8 JSON बाइट का SHA-256 दर्ज होना चाहिए। यह वास्तविक दावे पर मानवीय निर्णय लिखता है। रिकॉर्ड की reviewerId स्ट्रिंग प्रमाणीकरण नहीं है। अनसुलझे विरोधाभास या गायब अनुमति वाला रिकॉर्ड न सहेजें। Anthropic टेक्स्ट रखता है; वह यह स्कीमा सत्यापित नहीं करता या दावे की सच्चाई स्थापित नहीं करता।

2. सहेजें और दोबारा पढ़ें

अधिकृत कार्यक्षेत्र में सीमित मेमोरी स्टोर बनाएँ या चुनें और उसका वास्तविक memstore_... ID दर्ज करें। असंवेदनशील पथ इस्तेमाल करें, जैसे /records/{opaque-record-id}.json। अनुरोध से पहले उपयोगकर्ता, UTC समय, स्रोत संशोधन, स्वीकृत बाइट का हैश, स्टोर और पथ तथा pending स्थिति दर्ज करें। सीधे मेमोरी स्टोर कॉल में agent-memory-2026-07-22 इस्तेमाल करें; सत्र कॉल में managed-agents-2026-04-01 इस्तेमाल होता है। Anthropic के अनुसार स्टोर अनुरोध में दोनों बीटा हेडर मिलाने पर HTTP 400 आता है। निर्माण संदर्भ और मेमोरी मैनुअल SDK का यह रूप दिखाते हैं; स्थापित SDK को वर्तमान संदर्भ से मिलाएँ:

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

निर्माण मौजूदा पथ पर नहीं लिखता। लौटाया गया mem_... ID सहेजें, फिर सीमित स्टोर में /records/ सूचीबद्ध करें और हर next_page को अगले page की तरह इस्तेमाल करें। डिफ़ॉल्ट मूल सूची में सामग्री नहीं होती। चुनी मेमोरी प्राप्त करें और ID से पूरा टेक्स्ट लें; स्टोर ID, मेमोरी ID, पथ, सामग्री और content_sha256 को स्वीकृत बाइट से मिलाएँ। उत्तर और प्रत्यक्ष दोबारा पठन जर्नल तथा रजिस्ट्री में लिखें। केवल निर्माण उत्तर पूर्णता जाँच नहीं है। उत्तर अनिश्चित हो तो परिणाम तय करने से पहले सटीक पथ और रिकॉर्ड सीधे देखें; खोज में न मिलना अकेले दोबारा बनाने का कारण नहीं है।

3. चुना संशोधन स्थिर करें

हर अगली रन में कॉलर को प्रमाणित करें और विश्वसनीय रजिस्ट्री से दायरा, स्टोर और चुने रिकॉर्ड की ID लें। तलाश जरूरी हो तो सीमित प्रीफ़िक्स के हर पृष्ठ की सूची लें और चुना हुआ mem_... सीधे प्राप्त करें। लौटी सामग्री के UTF-8 एन्कोडिंग का SHA-256 निकालें, उसे प्रदाता के content_sha256 और मनुष्य द्वारा स्वीकृत सटीक बाइट हैश से मिलाएँ तथा JSON दोबारा सत्यापित करें। रिकॉर्ड ID, स्वामी का दायरा, स्रोत संशोधन, active स्थिति, स्रोत की वर्तमान वैधता और पहले से तय वैधता सीमा जाँचें। कोई जाँच विफल हो तो कुछ न भेजें।

प्राप्त सटीक बाइट उनके हैश से संबोधित निजी भंडारण में एक ही बार लिखें। अनन्य निर्माण पद्धति अपनाएँ, जैसे Python का open(path, "xb")। फ़ाइल तुरंत दोबारा पढ़कर हैश निकालें और हर भेजने से पहले ऐसा करें। मौजूदा स्नैपशॉट पर कभी न लिखें। आंशिक फ़ाइल या उसी पते पर अलग बाइट वाली फ़ाइल मिलने पर रोककर मिलान करना जरूरी है। मूल स्वीकृति, स्टोर ID, मेमोरी ID, प्रदाता हैश, स्नैपशॉट हैश और दायरा निर्णय निजी प्राप्ति प्रमाण में रखें। यह एक बार लिखा स्नैपशॉट ऐप की रचना है, किसी संस्करण पर बँधा Anthropic माउंट नहीं।

4. समान बाइट दो नए सत्रों को दें

वास्तविक अधिकृत एजेंट और वातावरण ID से एजेंट A का नया सत्र बनाएँ और इस फ़ील्ड में कोई मेमोरी स्टोर प्रविष्टि न रखें: resources। जाँचें कि लौटे सत्र के संसाधन और एजेंट के प्रभावी उपकरण तथा क्रेडेंशियल स्टोर तक कोई वैकल्पिक रास्ता न देते हों। Anthropic की सत्र मार्गदर्शिका निर्माण और 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}]}],
)

इस कॉल events.send से पहले निजी स्नैपशॉट दोबारा पढ़ें और हैश जाँचें। message_text को स्पष्ट “समीक्षा किया डेटा” लेबल, रिकॉर्ड, स्रोत और समीक्षा पहचान, अपरिवर्तित JSON टेक्स्ट और SHA-256, फिर मूल स्रोत से उत्तर मिलने वाले सीमित प्रश्न से निश्चित तरीके से बनाएँ। दिखाए फ़ील्ड ऐप संदेश प्रारूप हैं, प्रदाता के उत्तर फ़ील्ड नहीं। भेजने से पहले पूरा UTF-8 संदेश और हैश, चुना स्नैपशॉट हैश, अधिकृत एजेंट ID, सत्र ID और भेजने की स्थिति लिखें। परिणाम और वास्तविक भेजे इवेंट ID या उपलब्ध होने पर इवेंट सूची का दोबारा पठन रखें। अज्ञात परिणाम पर इवेंट पढ़ें, अंधाधुंध फिर न भेजें।

एजेंट B के अलग स्वीकृत ID से दूसरा नया सत्र बनाएँ और उसमें भी स्टोर पहुँच न हो। वही एक बार लिखा स्नैपशॉट दोबारा पढ़ें, बाइट हैश जाँचें, B का पूरा संदेश बनाएँ और दर्ज करके भेजें। सवाल या प्राप्तकर्ता मेटाडेटा अलग हो सकते हैं; भीतर दिए JSON बाइट और स्वीकृत रिकॉर्ड हैश समान होने चाहिए। हर उत्तर और उपकरण इवेंट को मूल स्रोत से जाँचें। संभावित सही उत्तर या उद्धरण मॉडल के अंदर दिए टेक्स्ट पर निर्भर होने का प्रमाण नहीं है; संदेश और प्रदाता इवेंट रिकॉर्ड बताते हैं कि ऐप ने क्या दिया। किसी सत्र में लाइव माउंट या स्टोर का दूसरा रास्ता हो तो उसे न भेजें।

5. स्रोत की नई समीक्षा के बाद ही अपडेट करें

मूल बदले तो वर्तमान मेमोरी सीधे लें और स्वामी के साथ पुराने तथा नए प्रमाण मिलाएँ। मनुष्य से स्थायी रिकॉर्ड ID, सुधरे दावे या स्रोत संदर्भ, नए स्रोत संशोधन और जाँच व समीक्षा समय वाले सटीक प्रतिस्थापन JSON बाइट स्वीकृत कराएँ। पुराना प्रमाण और हैश रखें। mem_... ID, वर्तमान सीधे पढ़ा content_sha256, अपेक्षित प्रतिस्थापन हैश, उपयोगकर्ता, स्वीकृति और लंबित स्थिति दर्ज करें। दस्तावेज में सशर्त अपडेट इस प्रकार है:

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

प्रदाता बिना सामान्यीकरण सटीक UTF-8 सामग्री का हैश बनाता है। मेल न खाने पर HTTP 409 memory_precondition_failed_error लौटता है। इस उत्तर या अनिश्चित नेटवर्क परिणाम पर लाइव मेमोरी फिर लें और जरूरत हो तो संस्करण इतिहास देखें। विरोधी स्रोत संशोधन मिलाएँ और स्वामी से जोड़ने, अस्वीकार करने या नया सटीक प्रतिस्थापन स्वीकृत करने को कहें; पुराने लेखन को अंधाधुंध न दोहराएँ। सफलता पर प्रत्यक्ष प्राप्ति से पथ, पूरा प्रतिस्थापन टेक्स्ट, हैश और मेमोरी संस्करण ID पुष्ट हों, तभी जर्नल confirmed बने।

सत्यापित संशोधन से नया स्वीकृत स्नैपशॉट स्थिर करें। स्टोर माउंट रहित नए अधिकृत A और B सत्र शुरू करें तथा दोनों भेजने और स्रोत जाँच दोहराएँ। पुराने स्नैपशॉट न बदलें और न कहें कि भेजे संदेश अपने आप अपडेट होते हैं। पुराने स्नैपशॉट को आगे दिए जाने के लिए अयोग्य चिह्नित करें। स्वामी रिकॉर्ड वापस ले तो नए भेजना रोकें और उसकी संरक्षण तथा डेटा हटाने की नीति लागू करें: वर्तमान मेमोरी मिटाने से रखे संस्करण जरूरी नहीं मिटते। पूरा स्टोर संग्रहित करना या मिटाना अलग निर्णय है।

कब काम पूरा माना जाए

निजी प्रमाण मूल अनुमति और स्रोत संशोधन को सटीक स्वीकृत JSON हैश से जोड़ें; वास्तविक कार्यक्षेत्र, स्टोर, पथ और mem_... पहचान तथा निर्माण का प्रत्यक्ष दोबारा पठन; एक अपरिवर्तनीय स्नैपशॉट; दो अलग अधिकृत, माउंट रहित सत्र ID जिनके भेजे संदेश हैश और स्रोत से जाँचे उत्तर हों; तथा स्वीकृत सशर्त अपडेट, नई प्रत्यक्ष प्राप्ति और नए सत्रों की जाँच। कोई कड़ी अज्ञात हो तो पूरे अभ्यास को अधूरा लिखें और सटीक रोक कारण रखें। चलाएँ तो वास्तविक सत्र व उपकरण उपयोग और खाते की लागत लिखें; इस दस्तावेज-आधारित मार्गदर्शिका ने बचत या मॉडल प्रदर्शन नहीं मापा।

संबंधित लेकिन अलग काम में अगले सत्र के लिए एक Dream आउटपुट की समीक्षा बनाए गए स्टोर प्रस्ताव को देखती है। यहाँ प्रक्रिया स्वामी-स्वीकृत स्रोत रिकॉर्ड से शुरू होती है और निश्चित करती है कि दोनों उपभोक्ता ठीक क्या पाते हैं।