Anthropic-এর Managed Agents মেমোরি স্টোর সেশনের মধ্যে লেখা ধরে রাখতে পারে। কোনো অ্যাপকে দুই এজেন্টের কাছে একই পর্যালোচিত তথ্য দিতে হলে স্থায়ী সংরক্ষণ কেবল প্রথম ধাপ। অ্যাপকে রেকর্ডের মালিক ঠিক করতে, মূল প্রমাণ দেখতে, সংরক্ষিত একটি সংশোধন বাছতে এবং কোনো এজেন্ট দেখার আগেই তার হুবহু বাইট রাখতে হবে। এই নির্দেশিকা অনুমোদিত Managed Agents বেটা প্রবেশাধিকার এবং অ্যাপের প্রমাণীকরণ, স্টোর নির্বাচন ও এজেন্টের বিন্যাসের নিয়ন্ত্রণ থাকা ডেভেলপারদের জন্য। এর ভিত্তি Anthropic-এর বর্তমান মেমোরি নথি এবং ২০ অক্টোবর ২০২৬-এ যাচাই করা 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 আউটপুট পর্যালোচনা তৈরি করা স্টোর প্রস্তাব নিয়ে। এখানে প্রক্রিয়া শুরু মালিক-অনুমোদিত সোর্স রেকর্ড দিয়ে এবং দুই গ্রাহক হুবহু কী পায় তা স্থির করে।