প্রতি কয়েক মাস অন্তর, শিল্পক্ষেত্রে এমন সফটওয়্যারের জন্য একটি নতুন শব্দ উদ্ভাবিত হয় যা আপাতদৃষ্টিতে নিজে নিজে চিন্তা করতে পারে। বর্তমানে সেই শব্দটি হলো "Agentic AI।" বিক্রেতারা তাদের ল্যান্ডিং পেজ এবং পিচ ডেকগুলোতে এটি ব্যবহার করতে খুব আগ্রহী। কিন্তু একটি লেবেল বা নাম কেবল মার্কেটিং কপি হিসেবেই থেকে যায় যতক্ষণ না সিস্টেমটি আপনার পরিবেশ, আপনার ডেটা এবং আপনার সিস্টেমের ত্রুটি বা 'failure modes'-এর মুখোমুখি হয়ে টিকে থাকে। এই শব্দটি নিজে থেকে নিরাপত্তা, নির্ভরযোগ্যতা বা উপযোগিতা সম্পর্কে কিছুই বলে না।

এখন ফিচার লিস্ট পড়া বন্ধ করে সক্ষমতা (capabilities) পরিমাপ করার সময় এসেছে।

লেবেলের সমস্যা

সেলস ইঞ্জিনিয়াররা একটি "agentic" আর্কিটেকচারের প্রমাণ হিসেবে আপনাকে ড্যাশবোর্ড, মাল্টি-মডেল ড্রপডাউন মেনু এবং মোবাইল অ্যাক্সেস দেখাবে। এগুলো হলো ইন্টারফেসের পছন্দ, আচরণের নিশ্চয়তা নয়। একটি প্রোডাক্ট দেখতে অত্যাধুনিক হতে পারে, কিন্তু একটি API টাইমআউটের পর যখন পরিকল্পনা সংশোধন করার প্রয়োজন হয়, তখন সেটি ভেঙে পড়তে পারে।

আসল বিষয় হলো সিস্টেমটি কি সত্যিই একটি স্বায়ত্তশাসিত এজেন্ট (autonomous agent) হিসেবে কাজ করে কি না। এটি কি কাজকে ধাপে ধাপে ভাগ করে? এটি কি কঠোর সীমার মধ্যে থেকে প্রকৃত সিস্টেমগুলোতে কাজ করে? যখন কিছু ভেঙে পড়ে বা ভুল হয়, তখন কি এটি নিজেকে মানিয়ে নেয়, নাকি কেবল ব্যর্থ হয়ে অপেক্ষা করে? যতক্ষণ না আপনি আপনার নিজস্ব টেক স্ট্যাকের (stack) নির্দিষ্ট প্রমাণের মাধ্যমে এই প্রশ্নগুলোর উত্তর দিচ্ছেন, ততক্ষণ আপনি কোনো প্রোডাক্ট নয়, বরং একটি ধারণা কিনছেন।

পাঁচটি সক্ষমতা পরীক্ষা যা আসলে গুরুত্বপূর্ণ

আমি প্রতিটি 'agentic' দাবিকে পাঁচটি নির্দিষ্ট সক্ষমতার ভিত্তিতে মূল্যায়ন করি। প্রতিটি ক্ষেত্রে, আমি একটি সহজ প্রশ্ন করি: এই আচরণটি কি নথিবদ্ধ (documented), পাইলট প্রজেক্টে যাচাইকৃত (verified), নাকি এখনও অজানা? 'অজানা' হওয়াটাই ডিফল্ট। এর উল্টোটা প্রমাণ করার দায়িত্ব প্রোডাক্টের।

পরিকল্পনা (Planning)। সিস্টেমটি কি একটি অস্পষ্ট লক্ষ্যকে সুশৃঙ্খল এবং যাচাইযোগ্য ধাপে বিভক্ত করতে পারে? যে কেউ একটি টু-ডু লিস্ট তৈরি করতে পারে। আসল পরীক্ষা হলো "এই কোয়ার্টারে আমাদের ক্লাউড খরচ ১৫ শতাংশ কমান" এর মতো একটি জটিল লক্ষ্য সামলানো। একটি প্রকৃত এজেন্ট বর্তমান ব্যবহারের একটি অডিট ম্যাপ করে, অব্যবহৃত রিসোর্সগুলো শনাক্ত করে, রাইটসাইজিং (rightsizing) সংক্রান্ত সুপারিশ তৈরি করে এবং সঠিক ক্রমে পরিবর্তনের অনুরোধগুলো (change requests) শিডিউল করে। যদি এটি আপনাকে কেবল পাঁচটি পয়েন্টের একটি সাধারণ প্রবন্ধ দিয়ে কাজ শেষ বলে দাবি করে, তবে সেটি পরিকল্পনা নয়; সেটি কেবল সারসংক্ষেপ (summarizing)।

টুলস (Tools)। এটি কি একটি নির্দিষ্ট সীমার মধ্যে থেকে প্রকৃত সিস্টেমগুলোতে কাজ করে? একটি চমৎকার ডেমোতে একটি মক (mock) API কল করা সহজ। কিন্তু আপনার প্রোডাকশন CRM-এ 'least-privilege' ক্রেডেনশিয়াল দিয়ে অথেন্টিকেট করা, একটি রেকর্ড লেখা এবং ট্রানজ্যাকশন লগ করা কঠিন। আপনাকে ঠিকভাবে জানতে হবে এটি কোন কোন সিস্টেম স্পর্শ করে, এর কাছে কী কী কী (keys) আছে এবং এর প্রভাবের ব্যাপ্তি (blast radius) কোথায় শেষ হয়। কাজের পরিধি অবশ্যই সীমাবদ্ধ হতে হবে। যদি এজেন্টের ডিফল্টভাবে প্রোডাকশনে 'write access' থাকে, তবে আপনার কাছে কোনো এজেন্ট নেই; বরং আপনার কাছে একটি দায়বদ্ধতা (liability) আছে।

সংশোধন (Correction)। কোনো ব্যর্থতার পর এটি কি তার পরবর্তী পদক্ষেপ পরিবর্তন করে? এখানেই বেশিরভাগ প্রোটোটাইপ ব্যর্থ হয়। যখন তৃতীয় ধাপে একটি 503 এরর বা স্কিমা মিসম্যাচ (schema mismatch) দেখা দেয়, তখন এজেন্টটি কি অনন্তকাল লুপে আটকে থাকে, একটি সফলতার মেসেজ কল্পনা (hallucinate) করে, নাকি তার পথ পরিবর্তন করে? প্রকৃত সংশোধন মানে হলো ব্যর্থতা পর্যবেক্ষণ করা, ওয়ার্কফ্লোর বাকি অংশের জন্য পুনরায় পরিকল্পনা করা এবং কোনো সীমাবদ্ধতা লঙ্ঘন না করে একটি নতুন পথ অনুসরণ করা। কেবল আশাবাদী হয়ে বারবার চেষ্টা করা (retry loop) সংশোধন নয়।

প্রসঙ্গ (Context)। এটি কি প্রতিটি ধাপে সীমাবদ্ধতাগুলো সক্রিয় রাখে? শুধু মেমরি থাকলেই চলে না। যদি প্রথম ধাপে "৫০০ ডলারের বাজেট অতিক্রম করবেন না" বা "EU গ্রাহকের ডেটা বাদ দিন" এর মতো কোনো কঠোর নিয়ম নির্ধারণ করা হয়, তবে সপ্তম ধাপে প্রম্পট কনটেক্সট বদলে যাওয়ার কারণে সেই নিয়মটি উপেক্ষা করা যাবে না। এটি কমপ্লায়েন্স রুলস, ব্র্যান্ড ভয়েস, অ্যাপ্রুভাল হায়ারার্কি এবং অ্যাক্সেস কন্ট্রোলের ক্ষেত্রেও প্রযোজ্য। লং-কনটেক্সট মডেল এবং ক্লাসিক্যাল স্টেট ম্যানেজমেন্টের মিলনস্থল হলো এই কনটেক্সট সংরক্ষণ।

তদারকি (Oversight)। একজন মানুষ কি প্রক্রিয়াটি থামানো বা পুনরায় শুরু করতে পারে? আপনার এমন 'সার্কিট ব্রেকার' প্রয়োজন যা সূক্ষ্মভাবে কাজ করে, কেবল ভার্চুয়াল মেশিনের একটি 'কিল সুইচ' নয়। কেউ কি দ্বিতীয় ধাপের পর পরিকল্পনাটি পরীক্ষা করে তৃতীয় ধাপটি অনুমোদন করতে পারে? যদি কোনো এক্সটার্নাল ডিপেন্ডেন্সি ব্যর্থ হয়, তবে একজন মানুষ কি স্টেট (state) না হারিয়ে সেটি ঠিক করে ওয়ার্কফ্লো পুনরায় শুরু করতে পারে? তদারকি মানে কোনো বিপর্যয় ঘটার পর পড়া একটি অডিট লগ নয়; এটি হস্তক্ষেপ করার একটি জীবন্ত ব্যবস্থা।

চেকবক্সের চেয়ে প্রমাণ বেশি কার্যকর

একটি ডেমো মানেই নির্ভরযোগ্যতার হার নয়। ভেন্ডর তুলনা করার শিটে একটি চেকবক্স কোনো প্রমাণ নয়। যখন একজন অ্যাকাউন্ট এক্সিকিউটিভ বলেন যে প্রোডাক্টটি "টেস্ট ফেইলরের পর সংশোধন করে," তখন আপনার পরবর্তী পদক্ষেপ হওয়া উচিত একটি 'এভিডেন্স কার্ড' (evidence card) চাওয়া।

একটি এভিডেন্স কার্ড চেকবক্সের পরিবর্তে সুনির্দিষ্ট তথ্য প্রদান করে। এটি দেখতে অনেকটা এরকম:

  • সক্ষমতা (Capability): সংশোধন (Correction)
  • দাবি (Claim): টেস্ট ফেইলরের পর সংশোধন করে
  • প্রমাণ (Evidence): নিয়ন্ত্রিত ফিক্সচারের অপেক্ষায় (Pending controlled fixture)
  • দায়িত্বপ্রাপ্ত (Owner): ডেভেলপার-এক্সপেরিয়েন্স টিম
  • থামুন যদি (Stop if): সংশোধনটি কোনো অনুমোদিত ইন্টারফেস পরিবর্তন করে

এই ফরম্যাটটি স্বচ্ছতা নিশ্চিত করে। এটি বিপণন দাবি (marketing claim) এবং প্রমাণের মধ্যে পার্থক্য তৈরি করে। এটি মালিকানা (ownership) নির্ধারণ করে দেয়, যাতে এজেন্ট যখন তার রিভিশন প্রচেষ্টার সময় কোনো অনুমোদিত ইন্টারফেস ভেঙে ফেলে, তখন আপনি ঠিকভাবে জানেন কোন টিমকে কল করতে হবে। মালিকানা ছাড়া জবাবদিহিতা নেই। স্টপ কন্ডিশন (stop conditions) ছাড়া কোনো সুরক্ষা ব্যবস্থা নেই।

যেকোনো পাইলট শুরু করার আগে, লিখিতভাবে তিনটি বিষয় নির্ধারণ করুন। প্রথমত, আপনার টাস্ক বা কাজগুলো। এগুলো বাস্তব ব্যবসায়িক লজিক (business logic) থেকে আসা উচিত, কৃত্রিম বেঞ্চমার্ক (synthetic benchmarks) থেকে নয়। দ্বিতীয়ত, আপনার ফেইলিওর টেস্ট (failure tests)। চলাকালীন কোনো API key বাতিল করে দিন, একটি ত্রুটিপূর্ণ (malformed) JSON রেসপন্স ইনজেক্ট করুন, অথবা প্রত্যাশিত ল্যাটেন্সি (latency) দ্বিগুণ করে দিন। তৃতীয়ত, আপনার স্টপ কন্ডিশন (stop conditions)। এগুলো অবশ্যই স্বয়ংক্রিয় হতে হবে, কোনো ম্যানুয়াল প্যানিক বাটন নয় যা আপনি আশা করেন কেউ লক্ষ্য করবে।

ভেন্ডরদের দাবি কীভাবে যাচাই করবেন

OpenAI প্রস্তাব করেছে যে এজেন্টদের পাঁচটি উপাদানের প্রয়োজন: models, tools, instructions, guardrails, এবং human intervention। আপনি তাদের নির্দিষ্ট আর্কিটেকচার গ্রহণ না করেই ভেন্ডরদের প্রশ্ন করার জন্য এই তালিকাটিকে একটি শব্দভাণ্ডার হিসেবে ব্যবহার করতে পারেন।

জিজ্ঞেস করুন কোন মডেলটি পরিকল্পনা (planning) এবং কোনটি কেবল জেনারেশন (generation) সামলায়। জিজ্ঞেস করুন কোন টুলের পারমিশনগুলো হার্ডকোডেড (hardcoded) এবং কোনগুলো ডাইনামিক (dynamic)। জিজ্ঞেস করুন গার্ডরেল (guardrails) কোথায় প্রয়োগ করা হয়েছে—প্রম্পট লেয়ারে নাকি অর্কেস্ট্রেশন ইঞ্জিনে (orchestration engine)। জিজ্ঞেস করুন হিউম্যান ইন্টারভেনশন (human intervention) কি একটি বিল্ট-ইন চেকপয়েন্ট নাকি এজেন্ট আপনার ডেটাবেস নষ্ট করার পর পাঠানো একটি পোস্ট-মর্টেম ইমেল। আপনি OpenAI-এর স্ট্যাক (stack) কিনছেন না। আপনি তাদের ফ্রেমওয়ার্ক ব্যবহার করছেন অন্য কারো কাজের ফাঁকফোকর খুঁজে বের করার জন্য।

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

একটি কেনার নিয়ম যা বাজেট বাঁচাবে

একটি এজেন্টিক পাইলটকে (agentic pilot) প্রোডাকশন কমিটমেন্টে রূপান্তর করার জন্য আমার নিয়মটি সহজ। আমি স্কোপ এবং বাজেট তখনই বাড়াই যখন গুরুত্বপূর্ণ সক্ষমতাগুলোর প্রমাণ থাকে এবং ব্যর্থতার জন্য একজন নির্দিষ্ট মালিক (owner) থাকে। কোনো রোডম্যাপ স্লাইড নয়। কোনো সাপোর্ট টিকিট কিউ (queue) নয়। প্রমাণ মানে আপনার এনভায়রনমেন্ট থেকে আসা লগ (logs)। মালিক মানে একজন নির্দিষ্ট ব্যক্তি যিনি সেই নির্দিষ্ট ধরণের ব্যর্থতার জন্য দায়বদ্ধ থাকবেন।

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

মনে রাখার বিষয়: "Agentic" শব্দটি আপনার মূল্যায়নের জন্য একটি শুরুর সংকেত মাত্র। এটি শেষ রেখা নয়। এটিকে আরও কঠিন প্রশ্ন করার, আরও কঠোর পাইলট চালানোর এবং আপনার প্রতিষ্ঠানের জন্য কার্যকর এমন প্রমাণের দাবি করার একটি প্রম্পট হিসেবে বিবেচনা করুন। যদি পণ্যটি আপনার নিজস্ব পরিবেশে এবং আপনার নিজস্ব ব্যর্থতার প্রেক্ষাপটে পাঁচটি সক্ষমতা পরীক্ষা (capability tests) পাস করতে না পারে, তবে এটি আসলে এজেন্টিক নয়। এটি কেবল আরেকটি ডেমো।

Source: https://dev.to/bestbee/is-it-really-agentic-ai-use-a-five-capability-product-gate-1c0h

Optional learning community: https://t.me/GyaanSetuAi