এক জায়গায় যেখানে কার্যকর তথ্য নির্ধারিত হয়

একই তথ্য নিয়ে একাধিক এজেন্ট কাজ করলে তথ্যগুলো বদলায়, অথচ সব এজেন্ট একই সময়ে সেই পরিবর্তনের খবর পায় না। টাকা পরিশোধের শেষ তারিখ সমস্যাটি স্পষ্ট করে।

ধরা যাক, INV-2041 চালানে লেখা আছে টাকা দিতে হবে ২২ অক্টোবরের মধ্যে। পরে সরবরাহকারীর একটি ইমেইল সেই তারিখ বদলে ২৯ অক্টোবর করেছে। এক এজেন্ট চালানটি পড়েছে, আরেকজন ইমেইলটি পড়েছে, আর তৃতীয়জন যা পেয়েছে তার ভিত্তিতে সপ্তাহের পেমেন্ট তৈরি করছে। প্রথমজন বলছে ২২ অক্টোবর, দ্বিতীয়জন ২৯ অক্টোবর, আর তৃতীয়জন আগে যে তারিখটি পেয়েছে সেটিই বলছে। এই ব্যবস্থায় কোন তারিখটি কার্যকর তা নির্ধারিত নেই, তাই এজেন্টদের পরিচালনাকারী মানুষটিকেই যাচাই করতে হয়।

এই নির্দিষ্ট চালানের উদাহরণটি আমার বানানো, কিন্তু এর পেছনের ব্যবস্থাটি বাস্তব। আমি একটি Neotoma ইনস্ট্যান্সের সঙ্গে তিনটি টুলে এজেন্ট চালাই। একটি মেইল-পর্যবেক্ষক প্রক্রিয়া আসা বার্তাগুলো উৎসসহ সংরক্ষণ করে এবং যেগুলোর জন্য কাজ করা দরকার সেগুলোকে টাস্কে রূপান্তরিত করে; Claude Code, Codex ও Cursor-এর সেশনগুলো একই টাস্ক ও পরিকল্পনা গ্রহণ করে। এই ব্যবস্থাই, এবং Neotoma-কে একটি বিস্তৃত রেকর্ড ব্যবস্থা হিসেবে গড়ে তোলার কাজই, এই লেখার উৎস।

মনে রাখা অন্য কাজে ভালো

তথ্য পুনরুদ্ধার প্রশ্নটির সঙ্গে সম্পর্কিত বলে মনে হয় এমন উপাদান খুঁজে দেয়। ভেক্টর ইনডেক্স বা দীর্ঘ চ্যাট ইতিহাস এটি ভালোভাবে করে, এবং অনেক কাজের জন্য সেটাই যথেষ্ট। কিন্তু এতে কোন তথ্যটি এখন কার্যকর তা স্থির হয় না। শেষ তারিখ জানতে চাইলে পুনরুদ্ধার পদ্ধতি চালান ও ইমেইল দুটোই ফেরত দেবে, প্রশ্নের সঙ্গে মিলের ভিত্তিতে সাজিয়ে; কোনটি বর্তমান অবস্থা দেখাচ্ছে তার ভিত্তিতে নয়।

টুল ও এজেন্ট চালানোর পরিবেশ যত বাড়ে, সমস্যা তত কঠিন হয়। এক এজেন্ট Markdown ফাইলে নোট রাখে, অন্যজন নিজের চ্যাট পণ্যের মধ্যে শেখা বিষয় রাখে, আর তৃতীয়জন শেয়ার করা ফোল্ডার পড়ে। প্রতিটি কপি লেখার সময় সঠিক ছিল। তথ্য বদলালে কপিগুলো ভিন্ন ভিন্ন সময়ে বদলায়, অথবা একেবারেই বদলায় না। কোন কপিটি মানতে হবে, তা কোনো এজেন্ট জিজ্ঞেস করতে পারে না, কারণ এই প্রশ্নের উত্তর দেওয়ার মতো কোনো একক জায়গা নেই। রেকর্ড ব্যবস্থাটি কোনো একটি টুলের বাইরে, সবার নাগালের এক জায়গায় থাকতে হবে।

এ বছরের শুরুতে আমি Neotoma-কে মেমরি স্তর ও সত্যের স্তর বলেছিলাম। পরে বলা বন্ধ করেছি, কারণ আমার মনে হয়েছে Neotoma-র জন্য ‘মেমরি’ ভুল শ্রেণি: শব্দটি বিভ্রান্তি তৈরি করে, আর মানুষ Neotoma-কে মেমরি পণ্যের সঙ্গে তুলনা করতেই থাকে। আমার দরকার এজেন্ট যেন নানা ধরনের বিষয় নিয়ে নির্ভুল তথ্য এমনভাবে সংরক্ষণ করে যা নিরীক্ষা করা যায়। সেই তথ্য রাখার জায়গার সরল নাম রেকর্ড ব্যবস্থা।

রেকর্ড ব্যবস্থা বলতে আমি এমন জায়গা বুঝি যা বলে এখন কী কার্যকর, তা কোথা থেকে এসেছে এবং কিসের পরিবর্তে এসেছে। সাদৃশ্যভিত্তিক অনুসন্ধান এসব প্রশ্নের উত্তর দিতে পারে না, কারণ সাদৃশ্য সময় বা উৎস সম্পর্কে কিছুই বলে না।

Neotoma আজ কী করে

আমি AI এজেন্টদের জন্য রেকর্ড ব্যবস্থা Neotoma তৈরি করি। এটি MIT লাইসেন্সের অধীনে উন্মুক্ত উৎসের সফটওয়্যার এবং আপনার বেছে নেওয়া ডেটা ডিরেক্টরিতে স্থানীয়ভাবে চলে। নিচে প্রকাশিত প্যাকেজটি (npm-এ 0.25.0) আজ কী করে, তা বলা হয়েছে।

প্রতিটি লেখা একটি নতুন পর্যবেক্ষণ হিসেবে সংরক্ষিত হয়, তার উৎসের সঙ্গে যুক্ত থাকে। নতুন মান পুরোনো মানের পাশে যোগ হয়; পুরোনোটিকে মুছে লেখা হয় না। Neotoma মূল PDF বা ইমেইল তা থেকে তৈরি কাঠামোবদ্ধ সত্তাগুলোর সঙ্গে সংরক্ষণ করতে পারে, এবং পর্যবেক্ষণগুলোর সঙ্গে উৎসের সম্পর্ক বজায় রাখে।

পর্যবেক্ষণ সত্তার অন্তর্ভুক্ত। সত্তার ID নির্ধারিত হয় সত্তার ধরন এবং পরিচয় নির্ধারণকারী ক্ষেত্রগুলো থেকে। একই ইনস্ট্যান্সে এবং একই পরিচয়-নিয়মে একই পরিচয়মূলক মান নির্ধারিত নিয়মে একই ID তৈরি করে। ফলে দুই এজেন্ট একই চালান সংরক্ষণ করলে তারা একই সত্তায় লেখে।

সত্তাগুলোকে একে অন্যের সঙ্গে যুক্তও করা যায়: চালানকে তার সরবরাহকারীর সঙ্গে, অথবা পরবর্তী কাজের টাস্ককে সংশ্লিষ্ট চালানের সঙ্গে। এজেন্ট এসব সম্পর্ক স্পষ্টভাবে তৈরি করে। সম্পর্কগুলো দেখায় রেকর্ডগুলো কীভাবে যুক্ত, আর উৎসের লিংক দেখায় কোনো পর্যবেক্ষণের পেছনের PDF বা ইমেইল।

Neotoma প্রতিটি ক্ষেত্রের জন্য স্কিমার মার্জ নিয়ম স্বয়ংক্রিয়ভাবে প্রয়োগ করে পর্যবেক্ষণগুলো থেকে বর্তমান মান হিসাব করে। অধিকাংশ ক্ষেত্রেই সর্বশেষ পর্যবেক্ষণটি কার্যকর হয়। একই পর্যবেক্ষণ ও একই মার্জ নিয়ম দিলে রিডাকশন একই স্ন্যাপশট তৈরি করে; প্রতিবার পড়ার সময় মডেলকে আবার বেছে নিতে হয় না।

প্রতিটি বর্তমান ক্ষেত্র জানায় কোন পর্যবেক্ষণ তার মান নির্ধারণ করেছে, আর সংরক্ষিত পর্যবেক্ষণ জানায় তার উৎস। এটি প্রমাণের কাছে ফিরে যাওয়ার পথ, এজেন্ট প্রমাণটি ঠিকমতো পড়েছে তার নিশ্চয়তা নয়। সংশোধন আরেকটি পর্যবেক্ষণ, সম্পাদনা নয়; আগের মান তালিকায় থাকে। আগের কোনো সময়ে Neotoma যেভাবে একটি সত্তা রেকর্ড করেছিল, সেভাবেও সেটি পড়া যায়।

এবার চালানে ফিরি। দুই এজেন্টের লেখাই একটি সত্তায় যায়। এখন শেষ তারিখ ২৯ অক্টোবর, এবং তা ইমেইল থেকে আসা পর্যবেক্ষণটিকে নির্দেশ করে। টাকার পরিমাণ এখনো প্রথম পর্যবেক্ষণটিকে নির্দেশ করে, কারণ পরিমাণ বদলায়নি। পেমেন্ট এজেন্ট ২৯ অক্টোবর পড়ে, আর ২২ অক্টোবরের পর্যবেক্ষণটি তার উৎসসহ তালিকায় থেকে যায়।

এজেন্টরা MCP সার্ভার, REST API ও CLI দিয়ে Neotoma-তে পৌঁছায়। ইনস্টলেশন নির্দেশিকা সমর্থিত টুল ও পরিবেশ কীভাবে যুক্ত করতে হয় তা বোঝায়। রেকর্ড ভাগ করে নিতে প্রতিটি টুলকে একই ইনস্ট্যান্স ও ডেটা প্রোফাইল, অথবা একই MCP এন্ট্রিতে, যুক্ত করুন; আলাদা এন্ট্রি আলাদা ডেটাবেস ব্যবহার করতে পারে।

মানুষেরা সঙ্গে দেওয়া Neotoma অ্যাপে নিজেদের রেকর্ড দেখতে পারেন।

অনুমোদিত স্বাক্ষরিত অনুরোধ যাচাইকৃত এজেন্ট পরিচয় প্রতিষ্ঠা করতে পারে। সক্রিয় এবং নির্দিষ্ট পরিধির গ্র্যান্ট ঠিক করে কোন কাজগুলো অনুমোদিত; শুধু স্বাক্ষর থাকলেই অনুমতি মেলে না।

সামনে যে দিকে এগোচ্ছে

এ পর্যন্ত আমি এমন রেকর্ড ব্যবস্থার কথা বলেছি যা এজেন্টদের জন্য কার্যকর তথ্য স্থির করে। লক্ষ্য হলো মানুষ ও এজেন্ট মিলে রক্ষণাবেক্ষণ করে এমন ব্যবস্থা, যেখানে যে কেউ জানতে পারবে কোন মানটি এখন কার্যকর, কোন উৎস সেটি এনেছে, সেটি পর্যবেক্ষণ, অনুমান না সিদ্ধান্ত, কে তা সংশোধন করার অধিকারী ছিল, এবং কোন এজেন্ট আগের সংস্করণের ওপর নির্ভর করেছিল। পরিকল্পিত শাসনক্ষমতাগুলো আজকের স্বাক্ষরিত পরিচয়, নির্দিষ্ট পরিধির গ্র্যান্ট ও অ্যাপের বাইরে যায়:

• প্রতিটি ক্ষেত্রের জন্য স্পষ্ট দায়িত্বশীল ব্যক্তি নির্ধারণ করা, যার সংশোধনের ক্ষমতা সেই ক্ষেত্রের রেকর্ডেই সীমিত থাকবে।
• প্রতিদ্বন্দ্বী দাবি, অমীমাংসিত বিরোধ ও আনুষ্ঠানিক অবস্থান স্পষ্টভাবে দেখানো।
• কোনো মান কেন কার্যকর, কার কর্তৃত্ব অনুসরণ করে এবং পরিবর্তনে কী প্রভাব পড়বে তা দেখানো।

Ateles পরিচালনার দিক থেকে সেই লক্ষ্যকে এগিয়ে নেয়। Ateles-এর অ্যাডাপ্টার নকশায় অ্যাডাপ্টারগুলো মেইল, ক্যালেন্ডার ও কোড হোস্টের মতো ব্যবস্থা থেকে Neotoma-তে তথ্য আনে এবং অনুমোদিত কাজগুলো আবার সেই ব্যবস্থায় পৌঁছে দেয়। Neotoma রেকর্ড সংরক্ষণ করে; যুক্ত টুলগুলো কাজ সম্পন্ন করে।

সম্পূর্ণ পরিকল্পনা এবং প্রতিটি অংশের আজকের অবস্থা README-তে আছে।

রেকর্ড ব্যবস্থা, শুধু পুনরুদ্ধার নয়

সমাধান আরও ভালো ইনডেক্স নয়। পুনরুদ্ধার এজেন্টকে আগে যা বলা হয়েছে তা খুঁজে পেতে সাহায্য করে। রেকর্ড ব্যবস্থা জানায় এখন কী কার্যকর। একাধিক টুলে কাজ করা এজেন্টদের দ্বিতীয় কাজটি দরকার, এমন এক জায়গায় যেখানে তারা সবাই পৌঁছাতে পারে। আর এজেন্টরা এতে লিখে এবং এখান থেকে পড়লেই কেবল রেকর্ড ব্যবস্থা সাহায্য করে।

আপনি যদি একাধিক টুল বা পরিবেশে এজেন্ট চালান, এমন একটি কার্যপ্রবাহ দিয়ে শুরু করুন যার তথ্য ও সত্তাগুলো পরস্পর সম্পর্কিত:

npm install -g neotoma
neotoma init
neotoma setup --tool claude-code

আপনার টুল বা পরিবেশের সেটআপ বিকল্প ব্যবহার করুন; ইনস্টলেশন নির্দেশিকায় অন্য সমর্থিত সংযোগগুলোর কথা আছে। তারপর এক এজেন্ট দিয়ে কার্যপ্রবাহের পরস্পর সম্পর্কিত তথ্য ও সত্তা সংরক্ষণ করুন, এবং একই কনফিগার করা ইনস্ট্যান্স ও ডেটা প্রোফাইল বা MCP এন্ট্রিতে যুক্ত অন্য এজেন্ট দিয়ে সেগুলো পড়ুন।

ইনস্টলেশন নির্দেশিকা neotoma.io/install-এ আছে। কোড ও সমস্যা-ট্র্যাকার GitHub-এ github.com/markmhendrickson/neotoma-তে আছে।