আপনার প্রথম এজেন্ট ওয়ার্কফ্লো শুরু হয় একটি প্রম্পট এবং কয়েকটি টুল দিয়ে। এটি প্রশ্নের উত্তর দেয়। এটি অর্ডারের স্ট্যাটাস দেখে। এটি

আপনার প্রথম এজেন্ট ওয়ার্কফ্লো শুরু হয় একটি প্রম্পট এবং কয়েকটি টুল দিয়ে। এটি প্রশ্নের উত্তর দেয়। এটি অর্ডারের স্ট্যাটাস দেখে। এটি কাজ করে, তাই আপনি এটি শিপ (ship) করে দেন।

তারপর প্রোডাক্টটি বড় হতে থাকে। সেলস টিম মিটিং নোট সিঙ্ক করার জন্য একটি CRM আপডেটার চায়। সাপোর্ট টিমের এমন একটি রিফান্ড ওয়ার্কফ্লো প্রয়োজন যা তিনটি অভ্যন্তরীণ সিস্টেমের সাথে যুক্ত। ইঞ্জিনিয়ারিং টিম ভেন্ডর ফর্ম পূরণ করার জন্য ব্রাউজার অ্যাকশন যোগ করে। প্রতিটি অনুরোধই ছোট মনে হয়। প্রতিটি অনুরোধের জন্য আলাদা প্রম্পট ফাইল, আলাদা Slack থ্রেড এবং আলাদা "quick fix" তৈরি করা হয়। ছয় মাস পরে, আপনার এজেন্ট আর একটি একক সিস্টেম থাকে না। এটি হয়ে দাঁড়ায় কপি করা প্রম্পট, লুকানো বিজনেস রুলস এবং পুরনো চ্যাট থ্রেডে নেওয়া সিদ্ধান্তের একটি এলোমেলো স্তূপ যা কেউ খুঁজে পায় না। একেই বলা হয় 'প্রম্পট স্প্রল' (prompt sprawl)। এটি আপনার AI প্রোডাক্টকে টেস্ট করা কঠিন করে তোলে, রিভিউ করা কঠিন করে তোলে এবং আত্মবিশ্বাসের সাথে রোলব্যাক করা অসম্ভব করে তোলে।

এর সমাধান হলো একটি AI agent skill registry।

একটি Skill আসলে কী

একটি skill কেবল একটি ফোল্ডারে সেভ করা প্রম্পট নয়। এটি একটি ভার্সনড (versioned) এবং টেস্টযোগ্য প্যাকেজ যা নির্ধারণ করে এজেন্ট কী করবে, কোন টুলগুলো কল করতে পারে এবং কী করা তার জন্য নিষিদ্ধ। এটিকে আপনার টিম এবং মেশিনের মধ্যে একটি চুক্তি হিসেবে ভাবুন। যখন একটি এজেন্ট একটি skill লোড করে, তখন তার সীমানা ঠিক কোথায় এবং সাফল্যের মাপকাঠি কী, তা তার সুনির্দিষ্টভাবে জানা উচিত।

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

কেন শুধু প্রম্পট যথেষ্ট নয়

প্রম্পট দেখতে টেক্সটের মতো, তাই টিমগুলো সেগুলোকে কনফিগারেশনের মতো মনে করে। বাস্তবে, এগুলো যে কেউ স্বীকার করার চেয়ে কোডের অনেক বেশি কাছাকাছি। একটি প্রোডাকশন প্রম্পট সাধারণত সিকোয়েন্সিং, ফরম্যাটিং, এরর হ্যান্ডলিং এবং অ্যাক্সেস কন্ট্রোল সংক্রান্ত লজিক এনকোড করে। যখন সেই লজিক শুধুমাত্র ন্যাচারাল ল্যাঙ্গুয়েজে থাকে, তখন অস্পষ্টতা তৈরি হয়। এজেন্টের কি CRM আপডেট করার অনুমতি আছে, নাকি প্রম্পটটি কেবল তা করার পরামর্শ দিয়েছে? যদি বিলিং API ডাউন হয়ে যায়, তবে প্রম্পটটি কি নিরাপদে ফেইল (fail) করার পদ্ধতি জানে, নাকি এটি একটি সফলতার মেসেজ হ্যালুসিনেশন (hallucinate) করে?

খরচ হলো আরেকটি নীরব ঘাতক। একটি প্রম্পট যা এজেন্টকে "ধাপে ধাপে চিন্তা করতে এবং বিস্তারিতভাবে অনুসন্ধান করতে" বলে, তা প্রতিটি রান-এ প্রচুর টোকেন খরচ করে ফেলতে পারে। যখন সেই প্রম্পটটি একটি হাই-ট্রাফিক সাপোর্ট ফ্লোতে কপি করা হয়, তখন আপনার মাসিক ইনফারেন্স বিল দ্বিগুণ হয়ে যায় এবং কেউ বুঝতে পারে না কেন।

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

একটি প্রোডাকশন Skill-এর গঠন

আপনি যদি এই বিশৃঙ্খলা থেকে মুক্তি পেতে চান, তবে প্রতিটি skill-কে একটি সফটওয়্যার আর্টিফ্যাক্ট (artifact) হিসেবে বিবেচনা করুন। একটি কার্যকর প্রোডাকশন skill-এ কেবল টেক্সট নয়, আরও কিছু প্রয়োজন:

• নাম এবং উদ্দেশ্য। "prompt_v3_final" নয়, বরং ব্যবসার লক্ষ্যের একটি স্পষ্ট বিবরণসহ "process_standard_refund"।
• ইনপুট স্কিমা এবং প্রয়োজনীয় কনটেক্সট। skill-টি কোন কোন ফিল্ড আশা করে তা সুনির্দিষ্টভাবে নির্ধারণ করুন। এর কি ইউজার আইডি, কনভারসেশন হিস্ট্রি বা টেন্যান্ট আইডেন্টিফায়ার প্রয়োজন? এখানে স্ট্রং টাইপিং (strong typing) এজেন্টকে ভুল ধারণা বা অনুমান করা থেকে বিরত রাখে।
• টুল পারমিশন এবং সেফটি লিমিট। skill-টি কোন কোন টুল ব্যবহার করতে পারে তার একটি স্পষ্ট তালিকা দিন। রিট্রাই (retry), খরচের সীমা এবং রেট ক্যাপের ওপর গার্ডরেল (guardrails) সেট করুন। যদি skill-টি ইউজার ডিলিট করার API স্পর্শ না করে, তবে তা কেবল বর্ণনায় নয়, কোডেই লিখে দিন।
• সাফল্যের মানদণ্ড এবং টেস্ট কেস। একটি skill কেবল রান করলেই যে সেটি "কাজ করছে" তা নয়। আউটপুটে কী কী থাকতে হবে তা নির্ধারণ করুন। একটি রিফান্ড skill-এর ক্ষেত্রে সাফল্য বলতে একটি ভ্যালিডেটেড ট্রানজ্যাকশন রেকর্ড, একটি ইমেল কনফার্মেশন পাঠানো এবং একটি অডিট লগ এন্ট্রি তৈরি করা বোঝাতে পারে।
• ভার্সন হিস্ট্রি এবং ওনারশিপ। এর একজন মালিক থাকা প্রয়োজন। একটি চ্যানজলগ (changelog) ব্যাখ্যা করা উচিত কেন v2.3 তৈরি করা হয়েছে এবং v2.2-এ কী সমস্যা ছিল।

আপনার লেয়ারগুলো আলাদা করুন

টিমগুলোর করা সবচেয়ে বড় ভুল হলো সবকিছু একটি প্রম্পটের মধ্যে ঢুকিয়ে দেওয়া। তারা ফ্রেন্ডলি গাইডেন্স, টুল ডকুমেন্টেশন, সিকিউরিটি পলিসি এবং এরর হ্যান্ডলিং—সবকিছু একটি টেক্সটের স্তূপে মিশিয়ে ফেলে। এটি রক্ষণাবেক্ষণ করা অসম্ভব।

এটিকে আলাদা করুন:

• নির্দেশাবলী (Instructions) হলো এজেন্টের জন্য নির্দেশিকা। এগুলো টোন, ফরম্যাট এবং সাধারণ পদ্ধতি ব্যাখ্যা করে।
• টুলের নিয়মাবলী (Tool Rules) এজেন্টকে জানায় কোন কোন টুল আছে এবং সেগুলো কী কাজ করে। এটি আবিষ্কারের বিষয়, অনুমতির নয়।
• নীতিমালা (Policy) কোড দ্বারা কার্যকর করা হয়, কেবল আশার ওপর ভিত্তি করে নয়। যদি ৫০০ ডলারের বেশি রিফান্ডের জন্য দ্বিতীয়বার যাচাইয়ের প্রয়োজন হয়, তবে সেই যাচাইকরণ একটি ভ্যালিডেশন ফাংশনে থাকবে যা টুলটি কল করার আগেই রান করবে।
• Evals হলো এমন পরীক্ষা যা যেকোনো পরিবর্তনের পরেও প্রমাণ করে যে দক্ষতাটি এখনও কাজ করছে।

উদাহরণস্বরূপ, "দয়া করে গ্রাহকের সম্পূর্ণ ক্রেডিট কার্ড নম্বর প্রকাশ করবেন না" — এভাবে লিখবেন না। পরিবর্তে, এজেন্ট দেখার আগেই PAN মুছে ফেলার জন্য একটি ডেটা ফরম্যাটার তৈরি করুন। নীতিমালা কোডের মধ্যে থাকা উচিত কারণ একজন চতুর ব্যবহারকারীর ইনপুট দিয়ে কোডকে তার কাজ থেকে বিরত রাখা সম্ভব নয়।

প্রোডাকশনকে "Latest" ভার্সনে নির্দেশ করা বন্ধ করুন

একটি নীরব প্রম্পট আপডেট শুক্রবারের সন্ধ্যা নষ্ট করার জন্য যথেষ্ট। যদি আপনার প্রোডাকশন এজেন্ট সবসময় কোনো স্কিলের "latest" ভার্সন ব্যবহার করে, তবে main ব্রাঞ্চে প্রতিটি মার্জ একটি সম্ভাব্য লাইভ ইনসিডেন্ট হয়ে দাঁড়ায়। আপনার dev, staging, এবং prod-এর মতো এলিয়াস (aliases) প্রয়োজন। একটি পরিচিত, পরীক্ষিত ভার্সনকে এই ধাপগুলোর মাধ্যমে প্রমোট করুন। যখন prod ভার্সন v2.1.4-কে নির্দেশ করবে, তখন আপনি এটি চলতে দেখতে পারবেন, এর আচরণ পরিমাপ করতে পারবেন এবং নিশ্চিন্তে ঘুমাতে পারবেন। যদি কিছু ভুল হয়, আপনি এলিয়াসটি আগের ভার্সনে ফিরিয়ে নিতে পারেন। চাপের মুখে মাঝরাতে আপনি ন্যাচারাল ল্যাঙ্গুয়েজ ডিবাগ করবেন না।

এই শৃঙ্খলা আপনার টিমকে ব্যাকওয়ার্ড কম্প্যাটিবিলিটি (backwards compatibility) নিয়ে ভাবতে বাধ্য করে। v2.2 কি v2.1-এর মতো একই ইনপুট ফরম্যাট হ্যান্ডেল করতে পারে? যদি না পারে, তবে প্রমোশনটি স্টেজিংয়েই ব্যর্থ হবে এবং গ্রাহকের কাছে পৌঁছানোর আগেই আপনি তা ধরতে পারবেন।

নিরাপত্তা প্যাকেজের ভেতর থেকেই শুরু হয়

অডিটেড নয় এমন প্রম্পটে ভরা একটি রেজিস্ট্রি হলো একটি বড় ঝুঁকি। কোডের জন্য আপনি যে ধরণের ঝুঁকি স্ক্যান করেন, আপনার স্কিলগুলোর জন্যও সেই একই ধরণের স্ক্যান প্রয়োজন।

প্রম্পট টেমপ্লেটের মধ্যে লুকিয়ে থাকা হার্ডকোডেড সিক্রেট বা API কী খুঁজুন। ডেটা এক্সফিল্ট্রেট (exfiltrate) করে এমন এক্সটার্নাল ওয়েবহুক বা শেল কমান্ড চেক করুন। সিস্টেম পলিসি ওভাররাইড করার চেষ্টাগুলো লক্ষ্য করুন, যেমন প্রম্পট যাতে "ignore previous instructions" লেখা আছে বা এজেন্টকে তার নিজস্ব কনফিগারেশন প্রকাশ করতে বলছে। এগুলো কেবল তাত্ত্বিক বিষয় নয়। এগুলো প্রম্পট-ইনজেকশন অ্যাটাকের সাধারণ প্যাটার্ন এবং এগুলো বিপজ্জনক কারণ এগুলো প্রায়ই এমন কপি করা টেক্সটের সাথে আসে যা কেউ রিভিউ করেনি।

আপনার স্কিল প্যাকেজগুলো স্ট্যাটিক অ্যানালাইসিসের (static analysis) মাধ্যমে চালান। যদি কোনো স্কিল ফাইলে এমন কোনো URL থাকে যা অ্যালাউলিস্টে (allowlist) নেই, তবে বিল্ডটি ফেইল করুন। যদি এটি এমন কোনো টুলের রেফারেন্স দেয় যা অনুমোদিত ম্যানিফেস্টে নেই, তবে তা প্রত্যাখ্যান করুন।

যদি আপনি এটি পরীক্ষা করতে না পারেন, তবে আপনি এটি বিশ্বাস করতে পারবেন না

ইভ্যালুয়েশন ছাড়া একটি রেজিস্ট্রি হলো কেবল প্রম্পটের একটি ফোল্ডার। প্রতিটি স্কিলের জন্য একটি টেস্ট সেট প্রয়োজন যা হ্যাপি পাথ (happy path), এজ কেস (edge cases) এবং ফেইলর মোডগুলো (failure modes) পরীক্ষা করে। উচ্চ-ঝুঁকিপূর্ণ স্কিলগুলোর জন্য ফাংশনাল টেস্টের চেয়েও বেশি কিছু প্রয়োজন। এজেন্ট যেন অন্য ব্যবহারকারীর ডেটা দেখতে না পারে তা নিশ্চিত করতে আপনাকে পারমিশন বা অনুমতি সীমানা পরীক্ষা করতে হবে। পলিসি কোনো কাজ ব্লক করলে এজেন্ট যেন "না" বলে তা নিশ্চিত করতে রিফিউজাল বিহেভিয়ার (refusal behavior) চেক করতে হবে। আপনার কোড-লেভেল সুরক্ষাগুলো বাইপাস না করার জন্য প্রম্পট-ইনজেকশন রেজিস্ট্যান্স টেস্ট করতে হবে।

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

আসল লক্ষ্য হলো নিয়ন্ত্রণ

পুনরায় ব্যবহার করা ভালো, কিন্তু নিয়ন্ত্রণই আপনাকে কর্মসংস্থান টিকিয়ে রাখতে সাহায্য করে। একটি স্কিল রেজিস্ট্রি আপনার টিমকে নিশ্চিতভাবে বলতে দেয়: এটি একটি অনুমোদিত ওয়ার্কফ্লো। এটি প্রোডাকশনে চলা ভার্সন। এগুলো হলো সেই টুল যা এটি ব্যবহার করতে পারে। ঠিক এভাবেই আমরা এটি রোলব্যাক (roll back) করি।

সেই স্বচ্ছতা আপনাকে কেবল চতুর ডেমো তৈরি করা থেকে নির্ভরযোগ্য সফটওয়্যার পরিচালনায় নিয়ে যায়। ডেমো স্টেকহোল্ডারদের দশ মিনিটের জন্য মুগ্ধ করতে পারে। কিন্তু নির্ভরযোগ্য সফটওয়্যার রাত তিনটার সময়ও চলতে পারে, ব্যতিক্রমগুলো (exceptions) সুন্দরভাবে সামলাতে পারে এবং কেবল মঙ্গলবার বিকেলে কেউ একটি পুল রিকোয়েস্ট মার্জ করেছে বলে তার আচরণ পরিবর্তন করে না।

আপনার রেজিস্ট্রি তৈরি করুন। আপনার স্কিলগুলোর ভার্সন নিয়ন্ত্রণ করুন। কোডের মাধ্যমে আপনার নীতিমালা কার্যকর করুন। এমনভাবে পরীক্ষা করুন যেন আপনার ঘুমের শিডিউল এর ওপর নির্ভর করে। আপনার ভবিষ্যৎ সত্তা আপনাকে ধন্যবাদ জানাবে।