উৎপাদনে ভেঙে না পড়া এজেন্টিক সিস্টেম ডিজাইন করা

চমকপ্রদ ডেমো থেকে ভঙ্গুর উৎপাদন এজেন্ট পর্যন্ত

এজেন্টিক সিস্টেমগুলো সেই অ্যাপ্লিকেশন যেখানে একটি LLM কেবল একটি প্রশ্নের উত্তর দেয় না, বরং পরবর্তী কী করা হবে তা সিদ্ধান্ত নিয়েই থাকে: কোন টুল কল করতে হবে, কোন ডেটা আনতে হবে, কোন ধাপ চালাতে হবে, এবং কখন কাজটি "সম্পন্ন" বলে মনে হবে। এগুলো একটি মডেল, টুলসেট (API, ডাটাবেস, সার্ভিস), পরিকল্পনা/নির্বাহী লুপ, এবং সবকিছুকে একত্রিত করার অবকাঠামো মিলিয়ে গঠিত।

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

কেন ডেমো কাজ করে আর উৎপাদন ভেঙে পড়ে

বাস্তব ওয়ার্কলোডে একই এজেন্ট এমনভাবে চাপের মধ্যে পড়ে যা ডেমো কখনো দেখেনি:

• API গুলো সময়সীমা লঙ্ঘন করে, আংশিক ডেটা দেয়, বা চুক্তি বদলে যায়।
• একাধিক অনুরোধ শেয়ার করা রিসোর্সের জন্য রেস করে এবং স্টেট কোরাপ্ট করে।
• দীর্ঘ সময় চলা কথোপকথন মেমোরি বাড়িয়ে প্রাসঙ্গিকতা হারায় এবং কনটেক্সট সীমা অতিক্রম করে।
• সূক্ষ্ম মডেল ভুলগুলো বহু টুল কল জুড়ে গুচ্ছগত প্রভাব ফেলে।

ফলাফল: ফ্লাকি আচরণ যা পুনরাবৃত্তিযোগ্য নয়, নীরব ডেটা করাপশন, এবং ব্যবহারকারী ফ্লো যা মাঝে মাঝে হ্যাং বা অনন্ত লুপে পড়ে।

বাস্তব ব্যবসায়িক প্রভাব

ফ্লাকি এজেন্ট কেবল "আনন্দ" নষ্ট করে না। এগুলো:

• ইনসিডেন্ট ও অন-কলে ট্রিগার করে।
• downstream সিস্টেমে ভুল উত্তর ঢুকিয়ে দেয়।
• ব্যবহারকারীর বিশ্বাস ক্ষয় করে: মানুষ ধীরে ধীরে ফিচারের উপর ভরসা করা বন্ধ করে দেয়।
• রিট্রাই ও রানঅ্যাওয়ে লুপের কারনে ক্লাউড বিল বাড়ায়।

এই গাইড কোন দিকে ফোকাস করে

এই আর্টিকেলটি ইঞ্জিনিয়ারিং প্যাটার্ন নিয়ে, "ভাল প্রম্পট" নয়। আমরা স্টেট মেশিন, স্পষ্ট টুল চুক্তি, রিট্রাই ও ব্যর্থতা-হ্যান্ডলিং কৌশল, মেমোরি ও কনকারেন্সি কন্ট্রোল, এবং এমন পর্যবেক্ষণযোগ্যতা প্যাটার্ন দেখব যা এজেন্টিক সিস্টেমকে লোডে পূর্বানুমানযোগ্য করে—কেবল স্টেজে চমৎকার নয়।

কেন বেশিরভাগ এজেন্ট আর্কিটেকচার স্কেলে ভেঙে যায়

অধিকাংশ এজেন্ট সিস্টেম সিঙ্গেল হ্যাপি-পাথ ডেমোতে ঠিক ই মনে হয়। কিন্তু যখন ট্রাফিক, টুলস ও এজ কেস একসাথে আসে, তখন এগুলো ব্যর্থ হয়।

ভঙ্গুর আচরণ: লুপ, স্টল, আংশিক কাজ, নীরব ত্রুটি

ভারে-অরক্ষিত অর্কেস্ট্রেশন ধরে নেয় মডেল এক বা দুই কলেই "ঠিক করবে"। বাস্তবে আপনি recurring প্যাটার্ন দেখবেন:

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

স্পষ্ট স্টেট ও শেষ শর্ত ছাড়া এই আচরণগুলো অনিবার্য।

লুকানো অ-ডিটারমিনিজম ও টুল অনিশ্চয়তা

LLM স্যাম্পলিং, ল্যাটেন্সি ভেরিয়েবিলিটি, এবং টুল টাইমিং লুকানো অ-ডিটারমিনিজম তৈরি করে। একই ইনপুট বিভিন্ন শাখা অতিক্রম করতে পারে, ভিন্ন টুল কল করতে পারে, বা টুল ফলাফল ভিন্নভাবে ব্যাখ্যা করতে পারে।

স্কেলে, টুল সমস্যা প্রাধান্য পায়:

• upstream API ও ডাটাবেস থেকে টাইমআউট ও ফ্লাকিনেস
• টুল চুক্তি ও বাস্তব আউটপুটের মধ্যে স্কিমা ড্রিফট
• অসামঞ্জস্যপূর্ণ এরর ফরম্যাট যা এজেন্ট শেখেনি কিভাবে হ্যান্ডল করতে

এই প্রত্যেকটি অবস্থা স্পিউরিয়াস লুপ, রিট্রাই, বা ভুল চূড়ান্ত উত্তরে রূপান্তরিত হয়।

কনকারেন্সি এজ কেস ও প্রোডাক্ট-মিসম্যাচকে বাড়িয়ে দেয়

10 RPS-এ যা বিরলভাবে ভেঙে, 1,000 RPS-এ সেটি নিয়মিত ভেঙে। কনকারেন্সি প্রকাশ করে:

• শেয়ার করা স্টেট বা ক্যাশে রেস কন্ডিশন
• রেট লিমিট খরচ হয়ে যাওয়া যা ক্যাসকেডিং টুল ফেল সৃষ্টি করে
• একটি নির্ভরশীলতা ব্লিপ থেকে থান্ডারিং হার্ড রিট্রাইয়ের স্রোত

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

যখন আর্কিটেকচার এই মিসম্যাচ উপেক্ষা করে—এজেন্টকে প্রচলিত সার্ভিসের মতো বিবেচনা করে বরং স্টোকাস্টিক প্ল্যানার হিসেবে নয়—তখন সিস্টেমগুলি সবচেয়ে বেশি প্রয়োজন তখনই অপ্রত্যাশিতভাবে আচরণ করে।

উৎপাদন-রেডি এজেন্টিক সিস্টেম ডিজাইনের নীতিসমূহ

উৎপাদন-রেডি এজেন্ট মানে "বুদ্ধিমান প্রম্পট" নয়, বরং শৃঙ্খলাবদ্ধ সিস্টেম ডিজাইন। একটি ব্যবহারযোগ্য ধারণা হলো: এগুলোকে ছোট, পূর্বানুমানযোগ্য মেশিন হিসেবে ভাবুন যা মাঝে মাঝে একটি LLM কল করে, কখনোই রহস্যময় LLM ব্লব হিসেবে নয় যা মাঝে মাঝে আপনার সিস্টেম স্পর্শ করে।

কী বিষয়গুলো এজেন্টকে উৎপাদন-রেডি করে?

চারটি বৈশিষ্ট্য সবচেয়ে গুরুত্বপূর্ণ:

• নিরাপত্তা (Safety): এজেন্টকে ডেটা অ্যাক্সেস, সাইড-এফেক্ট এবং ব্যবহারকারীর প্রতিশ্রুতি সংক্রান্ত শর্ত মেনে চলতে হবে। এর মানে স্পষ্ট অনুমতি, টুলগুলোর উপর গার্ডরেইল এবং অনট্রাস্টেড আউটপুটের সাবধানে হ্যান্ডলিং।
• পূর্বানুমানযোগ্যতা (Predictability): একই ইনপুট ও স্টেট দিলে এজেন্ট একটি সংকীর্ণ, প্রত্যাশিত ব্যান্ডের ভিতরে আচরণ করা উচিত। আপনি স্পষ্টভাবে বলতে সক্ষম হওয়া উচিত এটি কি পারে এবং কি করতে পারে না।
• ডিবাগগাবিলিটি (Debuggability): কিছু ভুল গেলে আপনি ট্রেস করতে পারবেন: কোন স্টেট, কোন সিদ্ধান্ত, কোন টুল, কোন মডেল কল। লুকানো লুপ নয়, কোন অস্পষ্ট "চিন্তা" ছাড়া।
• চেঞ্জ-টলারেন্স (Change-tolerance): আপনি মডেল, টুল, বা কৌশল আপগ্রেড করতে পারবেন পুরো সিস্টেম রিরাইট না করে।

এই বৈশিষ্ট্যগুলো প্রম্পট থেকে আসে না; এগুলো আসে কাঠামো থেকে।

ফ্রি-ফর্ম লুপের বদলে স্পষ্ট ওয়ার্কফ্লো পছন্দ করুন

অধিকাংশ দল শুরু করে এমন দিয়ে: "while not done, call the model, let it think, maybe call a tool, repeat"। এটি প্রোটোটাইপ করা সহজ কিন্তু চালানো কঠিন।

একটি নিরাপদ প্যাটার্ন হল এজেন্টকে একটি স্পষ্ট ওয়ার্কফ্লো হিসেবে উপস্থাপন করা:

• একটি সীমিত সেট স্টেট সংজ্ঞায়িত করুন (উদাহরণ: COLLECTING_INPUT, PLANNING, EXECUTING_STEP, WAITING_ON_HUMAN, DONE)।
• কোন স্টেটগুলোর মধ্যে ট্রানজিশন অনুমোদিত তা নির্ধারণ করুন।
• LLM-কে প্রধানত লোকাল সিদ্ধান্তের জন্য ব্যবহার করুন: পরের স্টেট নির্বাচন করা, একটি টুল নির্ধারণ করা, বা প্যারামিটার পূরণ করা।

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

“গড এজেন্ট”কে ছোট স্কিল-এ ভঙ্গ করুন

মোনোলিথিক এজেন্টগুলো যেগুলো "সবকিছু করে" আকর্ষণীয়, কিন্তু এগুলো অনাবশ্যকভাবে বিভিন্ন দায়িত্বের মধ্যে টাইট কাপলিং তৈরি করে: পরিকল্পনা, রিট্রিভাল, বিজনেস লজিক, UI অর্কেস্টেশন ইত্যাদি।

তার বদলে ছোট, ভাল-স্কোপড এজেন্ট বা স্কিলগুলো সংগঠিত করুন:

• একটি প্ল্যানার যা টাস্ক ভাঙে।
• একটি এক্সিকিউটর যা কংক্রিট ধাপগুলো চালায়।
• প্রতিটি ডোমেইনের জন্য একজন স্পেশালিস্ট (বিলিং, সাপোর্ট, অ্যানালিটিকস ইত্যাদি)।

প্রতিটি স্কিলের নিজস্ব স্টেট মেশিন, টুল এবং সেফটি রুল থাকতে পারে। কম্পোজিশন লজিক তখন উচ্চ-স্তরের ওয়ার্কফ্লো হয়ে যায়, একক এজেন্টের ভেতরের ক্রমবর্ধমান প্রম্পট নয়।

এই মডিউল্যারিটি প্রতিটি এজেন্টকে বোঝা সহজ রাখে এবং আপনি একটি ক্ষমতা বাড়লে অন্যগুলোকে স্থিতিশীলতা বিঘ্নিত না করে আপডেট করতে পারবেন।

নীতি, স্টেট ও টুল আলাদা রাখুন

একটি ব্যবহারযোগ্য মানসিক মডেল হলো এজেন্টকে তিনটি স্তরে ভাগ করে দেখা:

1. সিদ্ধান্ত নীতি (LLM প্রম্পট + মডেল)
   কীভাবে এজেন্ট পরবর্তী কাজ নির্বাচন করে তা ধারণ করে, কঠোর সীমার ভেতরে ব্যাখ্যাত। মডেল, টেম্পারেচার বা প্রম্পট বদলাতে পারবেন সিস্টেম তারের ছাড়াই।

2. স্টেট মেশিন / ওয়ার্কফ্লো ইঞ্জিন
   কোথায় আপনি প্রক্রিয়ায় আছেন, কোন ট্রানজিশন সম্ভব, এবং কিভাবে অগ্রগতি স্থায়ী হবে তা নিয়ন্ত্রণ করে। নীতি একটি পদক্ষেপ প্রস্তাব করে; স্টেট মেশিন সেটি যাচাই করে ও প্রয়োগ করে।

3. টুলিং লেয়ার
   বাস্তবে কি ঘটতে পারে তা বাস্তবায়ন করে: API, ডাটাবেস, কিউ, বাইরের সার্ভিস। টুলগুলো সংকীর্ণ, ভাল-টাইপ করা চুক্তি প্রকাশ করে এবং অনুমোদন, রেট লিমিট, ইনপুট ভ্যালিডেশন প্রয়োগ করে।

এই পৃথকীকরণ লুকানো বিজনেস লজিক প্রম্পটের ভেতরে বা টুল বর্ণনার ভেতরে লুকিয়ে রাখার ফাঁদ থেকে বাঁচায়। LLM হবে একটি সিদ্ধান্ত উপাদান, পরিষ্কার, ডিজিটাল শেলের ভিতরে নয়।

ছোটত্ব ও স্পষ্টতার দিকে ডিজাইন করুন

সর্বাধিক নির্ভরযোগ্য এজেন্টিক সিস্টেমগুলো সবচেয়ে চমকপ্রদ ডেমো নয়—এগুলো হলো সেইগুলো যার আচরণ আপনি সাদা বোর্ডে ব্যাখ্যা করতে পারেন।

কয়েকটি কনক্রিট নিয়ম:

• প্রতিটি এজেন্টকে একটি কাজ ও একটি প্রধান সাফল্য মেট্রিকে সীমাবদ্ধ রাখুন।
• ওয়ার্কফ্লো ও স্টেট ট্রানজিশনগুলো গদ্যতে নয়, স্পষ্টভাবে এনকোড করুন।
• LLM-কে ভাল-সংজ্ঞায়িত অপশনগুলোর মধ্যে বেছে নিতে দিন, পুরো পদ্ধতি শূন্য থেকে উদ্ভাবন করতে বলবেন না।

ছোট, কম্পোজেবল, ভাল-স্ট্রাকচার্ড এজেন্টের দিকে এই ঝোঁকই সিস্টেমকে বাড়তে দেয় জটিলতায় নিজেই ভেঙে পড়ার বদলে।

এজেন্ট ওয়ার্কফ্লো মডেল করা: স্পষ্ট স্টেট মেশিন হিসেবে

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

স্টেট ও ট্রানজিশন হিসেবে এজেন্ট ফ্লো উপস্থাপন

মডেলকে পরবর্তী সিদ্ধান্ত নিজের ইচ্ছায় নির্ধারণ করতে না দিয়ে, একটি ছোট স্টেট ডায়াগ্রাম সংজ্ঞায়িত করুন:

• PLAN – ব্যবহারকারীর অনুরোধ ব্যাখ্যা করে, ধাপগুলো ভাঙে, টুল বেছে নেয়।
• CALL_TOOL – যাচাই করা ইনপুট নিয়ে একটি টুল কল (বা ব্যাচ) চালান।
• VERIFY – টুল আউটপুট সহজ ইনভারিয়েন্ট বা অতিরিক্ত মডেল চেক দিয়ে যাচাই করুন।
• RECOVER – এরর হ্যান্ডলিং: রিট্রাই, ফলব্যাক, বা এসকালেট করা।
• DONE – চূড়ান্ত উত্তর রিটার্ন এবং ওয়ার্কফ্লো বন্ধ করা।
• FAILED – টার্মিনাল এরর স্পষ্ট কারণ ও প্রাসঙ্গিকতা সহ।

এই স্টেটগুলোর মধ্যে ট্রানজিশনগুলো টাইপ করা ইভেন্ট দ্বারা ট্রিগার হয় যেমন UserRequestReceived, ToolCallSucceeded, ToolValidationFailed, TimeoutExceeded, বা HumanOverride। প্রতিটি ইভেন্ট ও বর্তমান স্টেট মিলিয়ে পরবর্তী স্টেট ও করণীয় নির্ধারিত হয়।

এটা রিট্রাই ও টাইমআউটকে সরল করে: আপনি প্রতিটি স্টেটে পলিসি সংযুক্ত করবেন (উদা., CALL_TOOL 3 বার এক্সপোনেনশিয়াল ব্যাকঅফ সহ রিট্রাই করতে পারে, PLAN সাধারণত রিট্রাই নাও করা হতে পারে) তা কোডবেস জুড়ে ছড়িয়ে থাকা রিট্রাই লজিকের বদলে।

টিকে থাকার জন্য স্টেট এক্সটারনাল করা

বর্তমান স্টেট ও ন্যূনতম প্রাসঙ্গিক কনটেক্সট একটি বাহ্যিক স্টোরে (ডাটাবেস, কিউ, বা ওয়ার্কফ্লো ইঞ্জিন) পারসিস্ট করুন। এজেন্ট তখন একটি পিওর ফাংশন হয়ে যায়:

next_state, actions = transition(current_state, event, context)

এটি কী সহজ করে:

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

রিজনিং ও অডিটের সুবিধা

স্টেট মেশিন থাকলে এজেন্টের প্রতিটি ধাপ স্পষ্ট: কোন স্টেটে ছিল, কোন ইভেন্ট ঘটলো, কোন ট্রানজিশন fired হলো, এবং কোন সাইড-ইফেক্টসমূহ ঘটলো। এই স্বচ্ছতা ডিবাগিং দ্রুত করে, ইনসিডেন্ট ইনভেস্টিগেশন সহজ করে, এবং কমপ্লায়েন্স রিভিউর জন্য প্রাকৃতিক অডিট ট্রেইল তৈরি করে। লগ ও স্টেট ইতিহাস থেকে প্রমাণ দেখাতে পারবেন যে নির্দিষ্ট ঝুঁকিপূর্ণ অ্যাকশনগুলো কেবল নির্দিষ্ট স্টেট থেকেই ও নির্ধারিত শর্তে নেওয়া হয়।

এজেন্টের জন্য নির্ভরযোগ্য টুল চুক্তি ডিজাইন করা

টুলগুলো তখনই এজেন্টকে আরও পূর্বানুমানযোগ্য করে যখন তারা "প্রম্পটে লুকানো API" না হয়ে ভালভাবে ডিজাইন করা ইন্টারফেস হিসেবে থাকে।

কেবল প্রম্পট নয়, চুক্তি সংজ্ঞায়িত করুন

প্রতিটি টুলের কাছে থাকা উচিত:

• ইনপুট স্কিমা: প্রয়োজনীয় ক্ষেত্র, টাইপ, এনাম, কনস্ট্রেইন্ট, ডিফল্ট।
• আউটপুট স্কিমা: সাকসেস পে-লোড, নালেবল ফিল্ড, এবং "কোন ফলাফল নেই"-এর অর্থ।
• এরর মডেল: টাইপ করা এরর (যেমন InvalidInput, NotFound, RateLimited, TransientFailure) স্পষ্ট সেমান্টিকস সহ।
• SLA: ল্যাটেন্সি প্রত্যাশা, উপলব্ধতা টার্গেট, ও রেট লিমিট।

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

কঠোর JSON, কঠোর ভ্যালিডেশন

টুল I/O-কে যেকোনো প্রোডাকশন API-এর মতো হ্যান্ডল করুন:

• ইনপুট ও আউটপুটের জন্য কঠোর JSON স্কিমা (উদাহরণ: OpenAPI, JSON Schema) ব্যবহার করুন।
• কল করার আগে (মডেল মিস্টেক ধরতে) এবং পরে (টুল রিগ্রেশন ধরতে) ভ্যালিডেশন করুন।
• ছোটখাটো ইস্যু অটো-রিপেয়ার করুন (উদা., টাইপ কোঅর্শন) কিন্তু সেগুলো লগ করুন পরবর্তী টিউনিংয়ের জন্য।

এতে প্রম্পট সহজ হয়: বিস্তর নির্দেশনার বদলে স্কিমা-চালিত নির্দেশনা ব্যবহার করুন। স্পষ্ট সীমা হ্যালুসিনেটেড আর্গুমেন্ট ও অযৌক্তিক টুল সিকোয়েন্স কমায়।

ভার্সনিং ও কম্প্যাটিবিলিটি

টুলগুলো হয়তো বিকশিত হবে; এজেন্ট প্রতিবার ভাঙলে চলবে না।

• টুল চুক্তি ভার্সন করুন (v1, v1.1, v2) এবং এজেন্টকে একটি ভার্সনে পিন করুন।
• ক্ষেত্রগুলো ধীরে ধীরে ডিপ্রিকেট করুন; পুরোনো ক্ষেত্র কিছু সময় পড়াও রাখুন।
• ব্যাকওয়ার্ড-কম্প্যাটিবলভাবে নতুন ক্ষেত্র যোগ করুন; সেমান্টিক পরিবর্তন গোপনে করবেন না।

প্ল্যানিং লজিক তখন নিরাপদে বিভিন্ন মচ্যুরিটি স্তরের এজেন্ট ও টুল মিশাতে পারে।

ব্যর্থতা ও ডিগ্রেডেড মোড হ্যান্ডলিং

টুল চুক্তি পার্শিয়াল ফেলিউর মনে রেখে ডিজাইন করুন:

• প্রতিটি আইটেমের জন্য ত্রুটি-বিবরণ সহ পারশিয়াল রেজাল্ট অনুমোদিত করুন।
• একটি ডিগ্রেডড রেসপন্স সংজ্ঞায়িত করুন (উদা., ক্যাশেড, আনুমানিক, বা স্টেলে ডেটা) হার্ড ফেল নয়।
• কোন ফিল্ড "বেস্ট এফোর্ট" এবং কোনটি "মাস্ট-হ্যাভ" তা মার্ক করুন।

এজেন্ট তারপর অভিযোজিত হতে পারে: কম কার্যকারিতায় ফ্লো চালিয়ে যাওয়া, ব্যবহারকারীকে নিশ্চিতকরণ জিজ্ঞাসা করা, বা বিকল্প টুলে স্যুইচ করা।

নিরাপত্তা ও অথরাইজেশন সীমা

টুল চুক্তি হলো নিরাপত্তা সীমা এনকোড করার প্রাকৃতিক জায়গা:

• টুল কি পড়তে বা পরিবর্তন করতে পারে তা স্কোপ করুন।
• সংবেদনশীল অ্যাকশনের জন্য স্পষ্ট প্যারামিটার (যেমন confirm: true) চাওয়া।
• ইউজার-স্কোপড ও সিস্টেম-স্কোপড অপারেশন আলাদা করা।

সরভার-সাইড চেকের সঙ্গে এটা মিলিয়ে নিন; কেবল মডেলের আচরণের উপর নির্ভর করবেন না।

কেন ভাল চুক্তি এজেন্টকে সহজ করে

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

রিট্রাই, আইডেম্পোটেন্সি, এবং ব্যর্থতা-হ্যান্ডলিং প্যাটার্ন

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

আইডেম্পোটেন্সি: নিরাপদ রিট্রাইয়ের ভিত্তি

আইডেম্পোটেন্সি অর্থ: একই অনুরোধ বারবার করলে বাহ্যিকভাবে একই ফলাফল পাওয়া যায়। LLM এজেন্টরা প্রায়ই পারশিয়াল ফেলিউর বা অস্পষ্ট রেসপন্সের পরে টুল কল পুনরাবৃত্তি করে।

টুলগুলোকে আইডেম্পোটেন্ট করে তুলুন:

• রিকোয়েস্ট আইডি: প্রত্যেক টুল কল একটি স্থির request_id অন্তর্ভুক্ত করে। টুলটি এটি স্টোর করে এবং একই ID দেখলে একই ফলাফল রিটার্ন করে।
• আপসার্টস ইনস্টেড অফ ইনসার্টস: প্রাকৃতিক বা সিনথেটিক বিজনেস কী দিয়ে "create-or-update" সেমান্টিক ব্যবহার করুন, অটো-ইনক্রিমেন্ট আইডি নয়।
• চেকসাম ও ভার্সনিং: কন্টেন্ট হ্যাশ বা ভার্সন নম্বর সংযুক্ত করুন যাতে টুল ডুপ্লিকেট, স্টেল রাইট বা বিরোধপূর্ণ আপডেট শনাক্ত করতে পারে।

খরচ না বাড়ানোর রিট্রাই কৌশল

ট্রান্সিয়েন্ট ফেলিউরের (টাইমআউট, রেট লিমিট, 5xx) জন্য কাঠামোভুক্ত রিট্রাই ব্যবহার করুন: এক্সপোনেনশিয়াল ব্যাকঅফ, জিটার এবং কড়া ম্যাক্স অ্যাটেম্পটস। প্রত্যেক প্রচেষ্টা লগ করুন করিলেশন আইডি সহ যাতে এজেন্ট আচরণ ট্রেস করা যায়।

স্থায়ী ফেলিউরের (4xx, ভ্যালিডেশন এরর, ব্যবসায়িক নিয়ম লঙ্ঘন) জন্য রিট্রাই করবেন না। একটি স্ট্রাকচার্ড এরর এজেন্ট পলিসিকে জানানো উচিত যাতে এটি প্ল্যান পরিবর্তন করতে, ব্যবহারকারীকে জিজ্ঞাসা করতে, বা ভিন্ন টুল বেছে নিতে পারে।

সার্কিট ব্রেকার ও ফলব্যাক

এজেন্ট ও টুল লেয়ারে সার্কিট ব্রেকার বাস্তবায়ন করুন: বারবার ব্যর্থতার পরে অস্থায়ীভাবে সেই টুল কল ব্লক করুন এবং দ্রুত ব্যর্থ করুন। এটিকে সুস্পষ্ট ফালব্যাক—ডিগ্রেডেড মোড, ক্যাশড ডেটা, বা বিকল্প টুল—এর সঙ্গে জোড়া লাগান।

এজেন্ট লুপ থেকে ব্লাইন্ড রিট্রাই এড়ান। আইডেম্পোটেন্ট টুল ও স্পষ্ট ব্যর্থতা শ্রেণী ছাড়া, আপনি শুধু সাইড-এফেক্ট, ল্যাটেন্সি ও খরচ বাড়াবেন।

এজেন্টদের জন্য মেমোরি, স্টেট ও ডেটা সামঞ্জস্যতা পরিচালনা

নির্ভরযোগ্য এজেন্ট শুরু হয় পরিষ্কারভাবে চিন্তা করা থেকে: কি স্টেট এবং কোথায় থাকে।

স্বল্প-মেয়াদি স্টেট বনাম দীর্ঘমেয়াদি মেমোরি

একটি এজেন্টকে এমনভাবে বিবেচনা করুন যেমন একটি সার্ভিস একটি রিকোয়েস্ট হ্যান্ডেল করছে:

• শর্ট-টার্ম স্টেট: চলমান টাস্ক/সাবটাস্ক সম্পন্ন করার জন্য প্রয়োজনীয় সবকিছু—অ্যাকটিভ গোল, বর্তমান স্টেপ, টুল আউটপুট, পারশিয়াল সিদ্ধান্ত, কন্ট্রোল ভ্যারিয়েবল (বাকি রিট্রাই, বেছে নেওয়া ব্রাঞ্চ)। এগুলো টাইটলি স্কোপড এবং ওয়ার্কফ্লো শেষ হলে ডিলিট করা উচিত।
• লং-টার্ম মেমোরি: সেশন পার হয়ে টিকে থাকা তথ্য: ব্যবহারকারীর প্রোফাইল, পছন্দ, পূর্বের সিদ্ধান্ত, প্রজেক্ট ইতিহাস।

মিশ্রিত করলে বিভ্রান্তি ও বাগ হয়—উদা., ক্ষণস্থায়ী টুল ফলাফলগুলো মেমোরিতে রাখলে এজেন্ট ভবিষ্যত কথোপকথনে স্টেলে বা অনুপযুক্ত কনটেক্সট ব্যবহার করতে পারে।

স্টেট কোথায় সংরক্ষণ করবেন

প্রধান তিনটি অপশন:

1. ইন-কনটেক্সট (প্রম্পট-মাত্র) – সহজ, কম ল্যাটেন্সি, কিন্তু সীমিত ও অস্থিতিশীল। সংক্ষিপ্ত রান-এর জন্য ভাল।
2. বাহ্যিক স্টোর – ডাটাবেস, ক্যাশ, বা ভেক্টর স্টোর। দীর্ঘমেয়াদি মেমরি ও রিস্টার্ট টেকসই স্টেটের জন্য ব্যবহার করুন।
3. হাইব্রিড – অথরিটেটিভ স্টেট বাহ্যিক রাখুন; শুধুমাত্র প্রয়োজনীয় অংশ কনটেক্সটে লোড করুন পরবর্তী ধাপের জন্য।

ভাল নিয়ম: LLM একটি স্পষ্ট স্টেট অবজেক্টের ওপর স্ট্যাটলেস ফাংশন। সেই অবজেক্ট বাহ্যিকভাবে পারসিস্ট করুন এবং প্রম্পটগুলো সেখান থেকেই পুনর্নির্মাণ করুন।

"লগগুলোকে মেমোরি হিসেবে কাজে লাগানো" অ্যান্টি-প্যাটার্ন এড়ান

একটি সাধারণ ব্যর্থতা প্যাটার্ন হল কথোপকথনের লগ, ট্রেস বা কাঁচা প্রম্পটকে ডি-ফ্যাক্টো মেমোরি হিসেবে ব্যবহার করা।

সমস্যাগুলো:

• রিট্রাইভাল অ্যাড-হক ও ভঙ্গুর হয়ে যায়।
• গুরুত্বপূর্ণ তথ্য দীর্ঘ টেক্সটে চাবুকের নীচে চাপা পড়ে।
• বহু রান একে অপরকে contradict করতে পারে এবং কোনটি "লেট ওয়্রাইট উইন্স" তা অনিশ্চিত থাকে।

এর বদলে সংজ্ঞায়িত করুন স্ট্রাকচার্ড মেমোরি স্কিমা: user_profile, project, task_history ইত্যাদি। লগগুলো স্টেট হতে ডেরাইভ করুন, উল্টোভাবে নয়।

শেয়ার করা ডেটা ও টুলসের সঙ্গে সামঞ্জস্যতা

যখন বহু টুল বা এজেন্ট একই এন্টিটি (উদা., CRM রেকর্ড বা টাস্ক স্ট্যাটাস) আপডেট করে, তখন আপনাকে মৌলিক কনসিস্টেন্সি কন্ট্রোল প্রয়োগ করতে হবে:

• কী এন্টিটিগুলোর সিঙ্গেল সোর্স অফ ট্রুথ নির্ধারণ করুন (উদা., অর্ডার, টিকিট, ডকুমেন্ট)।
• আইডেম্পোটেন্ট টুল চুক্তি অগ্রাধিকার দিন: টুলগুলো রিট্রাই নিরাপদে হ্যান্ডল করবে স্থির ID ও আপসার্ট সেমান্টিক দিয়ে।
• যখন এজেন্টরা রেস করে একই রেকর্ড আপডেট করতে পারে, তখন অপটিমিস্টিক কনকারেন্সি (ভার্সন নম্বর, টাইমস্ট্যাম্প) প্রয়োগ করুন।

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

স্ন্যাপশট ও রিসিউমেবল এক্সিকিউশন

ক্র্যাশ, ডেপ্লয় বা রেট লিমিট সহ্য করতে, ওয়ার্কফ্লোগুলো হওয়া উচিত রিসিউমেবল:

• প্রতিটি উল্লেখযোগ্য ধাপের পরে একটি স্টেট স্ন্যাপশট পারসিস্ট করুন: বর্তমান ধাপ, ইনপুট, টুল ফলাফল, ও পেন্ডিং অ্যাকশন।
• প্রতিটি স্টেট মেশিন ট্রানজিশন স্ন্যাপশট থেকে রি-প্লেয়েবল হওয়া উচিত।
• ব্যর্থতা বা রিস্টার্টে, শেষ স্ন্যাপশট লোড করে পুনরায় চালায়—শুরু থেকে নয়।

এটি টাইম ট্রাভেল ডিবাগিং-ও যোগ্য করে: আপনি নির্দিষ্ট সেই স্টেট পরিদর্শন করে পুনরায় চালাতে পারবেন যা খারাপ সিদ্ধান্তের দিকে নিয়ে গিয়েছিল।

প্রাইভেসি, রিটেনশন ও ন্যূনতম মেমোরি

মেমোরি একটি দায়িত্ব যেমনটি একটি সম্পদ। উৎপাদন এজেন্টের জন্য:

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

মেমোরিকে একটি প্রোডাক্ট সারফেস হিসেবে আচরণ করুন: ডিজাইন করা, ভার্সনকৃত এবং গভর্ন করা — কেবল একটি বাড়তে থাকা টেক্সট ডাম্প নয়।

এজেন্ট সিস্টেমে কনকারেন্সি, রেট লিমিট ও ব্যাকপ্রেশার

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

এজেন্ট ওয়ার্কফ্লোতে কনকারেন্সি ঝুঁকি

সাধারণ ফেইলিওর মোড:

• রেস কন্ডিশন: দুটি এজেন্ট একসঙ্গে একই টিকেট, কার্ট, বা ডকুমেন্ট আপডেট করে একে অপরকে ওভাররাইট করে দেয়।
• ডুপ্লিকেট কাজ: রিট্রাই বা ভুল কনফিগারড ওয়ার্কার একই টাস্ক দুবার প্রসেস করে (উদা., দ্বিগুণ চার্জ)।
• আউট-অফ-অর্ডার ইফেক্ট: টুল কলগুলি অপ্রত্যাশিত অর্ডারে শেষ হয়, ফলে পুরোনো ফলাফল নতুনটিকে ওভাররাইট করে।

আপনি এগুলোকে আইডেম্পোটেন্ট টুল চুক্তি, স্পষ্ট ওয়ার্কফ্লো স্টেট, এবং ডাটা লেয়ারে অপটিমিস্টিক/পেসিমিস্টিক লক দিয়ে মোকাবেলা করবেন।

কিউ বনাম সিঙ্ক্রোনাস ফ্লো

সিঙ্ক্রোনাস রিকোয়েস্ট–রেসপন্স ফ্লো সহজ কিন্তু ভঙ্গুর: প্রত্যেক নির্ভরশীলতা আপ হতে হবে, রেট সীমার ভিতরে এবং দ্রুত হতে হবে। এজেন্ট যখন বহু টুলে ফ্যান-আউট করে বা প্যারালাল সাব-টাস্ক চালায়, তখন দীর্ঘ চলমান বা সাইড-এফেক্টফুল ধাপগুলোকে কিউ-র পিছনে সরে নিন।

কিউ-ভিত্তিক অর্কেস্ট্রেশন আপনাকে দেয়:

• ওয়ার্কার পুল দিয়ে কনকারেন্সি নিয়ন্ত্রণ করার ক্ষমতা
• কেন্দ্রীভূত রিট্রাই ও ডিডুপ্লিকেশন
• ব্যবহারকারী-ফেসিং ল্যাটেন্সি থেকে ধীর বা ফ্লাকি টুলগুলোকে বিচ্ছিন্ন করা

রেট লিমিট ও ব্যাকপ্রেশার

এজেন্টরা সাধারণত তিন ধরনের লিমিটে আঘাত পায়:

• মডেল: টোকেন প্রতি মিনিট, রিকোয়েস্ট প্রতি মিনিট, কনটেক্সট সাইজ
• টুল: অভ্যন্তরীণ সার্ভিসগুলোর QPS বা CPU সীমা
• আপস্ট্রিম API: তৃতীয় পক্ষ কোটা ও হার্ড ক্যাপ

আপনি একটি স্পষ্ট রেট-লিমিট লেয়ার লাগাবেন per-user, per-tenant, ও global থ্রোটল সহ। টোকেন বকেট বা লিকি বকেট ব্যবহার করুন নীতি প্রয়োগ করতে, এবং স্পষ্ট এরর টাইপ (RATE_LIMIT_SOFT, RATE_LIMIT_HARD) রিটার্ন করুন যাতে এজেন্ট গ্রেসফুলি ব্যাক-অফ নিতে পারে।

ব্যাকপ্রেশার হচ্ছে কিভাবে সিস্টেম নিজেকে সুরক্ষা করে চাপের মধ্যে। কৌশলগুলো:

• অপ্রধান ট্রাফিক প্রথমে বাদ দেওয়া
• ফিচার ডিগ্রেড করা (ছোট কনটেক্সট, কম টুল কল)
• নীম্ন-অগ্রাধিকার কিউ পজ করা যেটা সমালোচনামূলক ফ্লো বজায় রাখে

কিউ গভীরতা, ওয়ার্কার ইউটিলাইজেশন, মডেল/টুল এরর রেট এবং ল্যাটেন্সি শতাংশের মনিটরিং রাখুন। বাড়তে থাকা কিউ ও বাড়তে থাকা ল্যাটেন্সি বা 429/503 আপনার সতর্ক সংকেত।

পর্যবেক্ষণযোগ্যতা: ট্রেসিং, মেট্রিক্স ও লগ

যদি আপনি দ্রুত জবাব দিতে না পারেন যে: এটি কী করেছে? এবং এটি কেন করেছে? তাহলে আপনি এজেন্টকে নির্ভরযোগ্য করতে পারবেন না। এজেন্টিক সিস্টেমের পর্যবেক্ষণযোগ্যতা সেই উত্তরগুলোকে সস্তা ও নির্ভুল করে তোলার বিষয়ে।

কী দেখতে হবে

পর্যবেক্ষণ এমনভাবে ডিজাইন করুন যাতে একটি টাস্কের ট্রেস জুড়ে থাকে:

• প্রতিটি এজেন্ট ধাপ ও স্টেট ট্রানজিশন
• প্রতিটি টুল কল ও রেসপন্স
• প্রতিটি মডেল ইনভোকেশন ও প্রম্পট ভ্যারিয়্যান্ট

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

একটি ব্যবহারযোগ্য ট্রেসে সাধারণত থাকে:

• টাস্ক মেটাডাটা: টেন্যান্ট, ব্যবহারকারী, চ্যানেল, অগ্রাধিকার
• এজেন্ট স্টেট: বর্তমান স্টেট নাম, পরবর্তী স্টেট, রিট্রাই কাউন্ট
• টুল I/O: ইনপুট, আউটপুট, ল্যাটেন্সি, এরর, সার্কিট-ব্রেকার স্টেট
• মডেল কল: প্রম্পট টেমপ্লেট আইডি, মডেল নাম, টোকেন গণনা, ল্যাটেন্সি

লগিং ও রেডাকশন

প্রম্পট, টুল ইনপুট ও আউটপুট স্ট্রাকচার্ড ফর্মে লগ করুন, কিন্তু আগে একটি রেডাকশন লেয়ার দিয়ে পাঠান:

• PII ও সিক্রেট মাস্ক করুন
• অতি বড় পে-লোড ট্রাঙ্কেট করে হ্যাশ রেখে কোরিলেশন সক্ষম করুন
• ফিল্ডগুলিকে সেনসিটিভিটি লেভেল দিয়ে মার্ক করুন যাতে রিটেনশন ও অ্যাক্সেস নিয়ন্ত্রিত হয়

তিমধ্যন্ত কাঁচা কনটেন্ট নিচু পরিবেশে ফিচার ফ্ল্যাগের পেছনে রাখুন; প্রোডাকশনে ডিফল্ট রেডাক্টেড ভিউ রাখা উচিত।

কার্যকর মেট্রিক্স

কমপক্ষে ট্র্যাক করুন:

• টাস্ক সাফল্য/ব্যর্থতার হার এজেন্ট ও ইউজ কেস অনুযায়ী
• প্রতি টাস্ক গড় ও P95 স্টেপ সংখ্যা
• ল্যাটেন্সি: এন্ড-টু-এন্ড এবং প্রতিটি টুল/মডেল অনুযায়ী
• প্রতি টাস্ক কস্ট (টোকেন, টুল খরচ) এবং সফল আউটকামের কস্ট

ইনসিডেন্ট হলে, ভালো ট্রেস ও মেট্রিক আপনাকে বলবে: “এজেন্ট ফ্লাকি” থেকে সঠিক বিবৃতি যেমন: “P95 টাস্ক ToolSelection-এ 2 রিট্রাইয়ের পরে ব্যর্থ হচ্ছে কারণ billing_service-এ নতুন স্কিমা,” যা ডায়াগনসিসকে ঘণ্টা থেকে মিনিটে নামিয়ে আনে এবং কনক্রিট টোনিং লেভার দেয়।

এজেন্টিক সিস্টেমের জন্য টেস্টিং ও ইভালুয়েশন কৌশল

এজেন্ট টেস্ট করা মানে তাদের কল করা টুল এবং সবকিছুকে একসাথে জোড়া ফ্লো—উভয়কেই টেস্ট করা। এটিকে ডিস্ট্রিবিউটেড সিস্টেম টেস্টিং হিসেবে নিন, কেবল প্রম্পট টুইকিং হিসেবে নয়।

ইউনিট টেস্ট: টুল চুক্তি, প্রম্পট নয়

টুল বাউন্ডারিতে ইউনিট টেস্ট দিয়ে শুরু করুন:

• স্কিমা ভ্যালিডেট করুন: প্রয়োজনীয় ক্ষেত্র, এনাম, রেঞ্জ, ইনভারিয়েন্ট
• আইডেম্পোটেন্সি ও এরর সেমান্টিকস পরীক্ষা করুন (কোন এরর, কোন কোড, কোন রিট্রাইবিলিটি)
• টুল ম্যালফরম ইনপুট সুন্দরভাবে হ্যান্ডেল করে কিনা তা assert করুন

এই টেস্টগুলো কখনোই LLM-এ নির্ভর করবে না। আপনি সরাসরি টুল কল করে সিনথেটিক ইনপুট দিয়ে ঠিক আউটপুট বা এরর চেক করবেন।

ইন্টিগ্রেশন টেস্ট: ফ্লো ও মাল্টি-স্টেপ আচরণ

ইন্টিগ্রেশন টেস্টগুলো এজেন্ট ওয়ার্কফ্লো সম্পূর্ণভাবে এক্সারসাইজ করে: LLM + টুল + অর্কেস্ট্রেশন।

এগুলো সিনারিও-ভিত্তিক টেস্ট হিসেবে মডেল করুন:

• কৌশলগত হ্যাপি-পাথ (বুকিং, রিফান্ড, এসকালেশন ইত্যাদি)
• এজ-কেস: হরণ ডেটা, পারশিয়াল টুল ফেলিউর, টাইমআউট, রেট লিমিট
• ক্রস-টুল ইন্টারঅ্যাকশন: টুল A-র আউটপুট টুল B-কে খাওয়ায়

এই টেস্টগুলো assert করবে স্টেট ট্রানজিশন ও টুল কল—প্রতি টোকেন নয়। যাচাই করুন: কোন টুলগুলো কল হয়েছে, কী আর্গুমেন্টে, কোন অর্ডারে, এবং এজেন্ট কী চূড়ান্ত স্টেট/রেজাল্টে পৌঁছেছে।

LLM ও টুলের জন্য ডিটারমিনিস্টিক ফিক্সচার

টেস্টগুলো রিপিটেবল রাখতে, LLM রেসপন্স ও টুল আউটপুট দুইটাকেই ফিক্সচার করুন:

• প্রতিটি প্রম্পট + মডেল + কনফিগে একবার LLM রেসপন্স রেকর্ড করুন এবং JSON ফিক্সচারে রাখুন।
• টুলগুলোর পিছনে বাইরের সিস্টেমগুলিকে মক করুন যাতে টেস্টগুলো লাইভ সার্ভিস না হিট করে।
• টেস্টে এক্সপ্লিসিট সিড ও ফিক্সড-টেম্পারেচার কনফিগ ব্যবহার করুন।

একটি সাধারণ প্যাটার্ন:

with mocked_llm(fixtures_dir="fixtures/llm"), mocked_tools():
    result = run_agent_scenario(input_case)
    assert result.state == "COMPLETED"

প্রম্পট ও স্কিমার জন্য রিগ্রেশন স্যুট

প্রম্পট বা স্কিমা পরিবর্তন হলে অনিবার্যভাবে একটি রিগ্রেশন রান ট্রিগার করুন:

• ইনপুটের একটি কিউরেটেড কর্পাস রাখুন প্লাস প্রত্যাশিত স্টেট, টুল ট্রেস, বা ক্লাসিফিকেশন।
• এগুলোকে গোল্ডেন ফাইল হিসেবে লক করুন; ডিফগুলো আচরণগত পরিবর্তন হাইলাইট করে।
• ক্রিটিক্যাল ফ্লোতে কোনো ড্রিফট হলে স্পষ্ট অনুমোদন বা রোলব্যাক করুন।

স্কিমা ইভোলিউশন (ফিল্ড যোগ/টাইটেন টাইপ) এর নিজস্ব রিগ্রেশন কেস থাকা উচিত যাতে পুরোনো চুক্তিতে আশা করা এজেন্ট বা টুল ব্রেক না করে।

রোলআউটের আগে অফলাইন ইভালুয়েশন

নতুন মডেল, পলিসি, বা রাউটিং স্ট্র্যাটেজি সরাসরি প্রোডাকশনে পাঠাবেন না।

এর বদলে:

• আপনার রিগ্রেশন কর্পাস নতুন কনফিগে অফলাইন চালান।
• ইতিহাসিক ইন্টারঅ্যাকশনের স্যাম্পল নিয়ে রিপ্লে টেস্ট চালান।
• স্বয়ংক্রিয় মেট্রিক গণনা করুন (টাস্ক সাকসেস, টুল এরর রেট, ল্যাটেন্সি, কস্ট) এবং প্রয়োজনে নমুনাভিত্তিক মানব মূল্যায়ন।

অফলাইন গেট পাস করলে মাত্র নতুন ভেরিয়ান্ট প্রোডাকশনে ধাপে ধাপে রোল আউট করুন, আদর্শত ফিচার ফ্ল্যাগ ও গ্র্যাজুয়াল রোলআউটসহ।

টেস্ট ডেটা ব্যবস্থাপনা ও অ্যানোনিমাইজেশন

এজেন্ট লগগুলো প্রায়ই সংবেদনশীল ইউজার ডেটা রাখে। টেস্টিংতে এটি সম্মান করুন:

• টেস্ট ডাটাসেট অ্যানোনিমাইজড বা সিনথেটিক ইনপুট থেকে গঠন করুন।
• লগ বা ফিক্সচার স্টোর করার আগে আইডেন্টিফায়ার, ফ্রি-টেক্সট PII ও সিক্রেট স্ট্রিপ বা হ্যাশ করুন।
• অ্যাক্সেস সেগমেন্ট করুন: ইঞ্জিনিয়াররা আচরণিক ট্রেস দেখতে পারবে কিন্তু কাঁচা ব্যবহারকারী সিক্রেট নয়।

CI পাইপলাইনে এই নিয়মগুলো কোডিফাই করুন যাতে কোনো টেস্ট আর্টিফ্যাক্ট অ্যানোনিমাইজেশন ছাড়া তৈরি বা সংরক্ষিত না হতে পারে।

উৎপাদনে এজেন্টগুলো পরিচালনা, মনিটরিং ও বিকাশ

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

নিরাপদ রোলআউট কৌশল

নতুন এজেন্ট বা আচরণ ধাপে ধাপে চালু করুন:

• শ্যাডো মোড: এজেন্ট চলমান সিস্টেমের পাশে চালান, সিদ্ধান্ত লগ করুন, কিন্তু ব্যবহারকারীর ওপর প্রভাব ফেলবেন না। অফলাইন তুলনা করুন।
• কানারি: ট্র্যাফিকের ছোট অংশ (যেমন 1–5%) নতুন এজেন্ট ভার্সনে দিন। এরর রেট, ল্যাটেন্সি, কোয়ালিটি মনিটর করে পরে বর্ধিত করুন।
• A/B টেস্ট: ব্যবহারকারী-ফেসিং ফ্লোতে ব্যবসায়িক KPI-র উপর ভিত্তি করে তুলনা করুন, কেবল মডেল মেট্রিক নয়।

সবচেয়ে ভালো হলো ফিচার ফ্ল্যাগ ও কনফিগ-চালিত পলিস: রাউটিং নিয়ম, সক্ষম টুল, টেম্পারেচার, সেফটি সেটিংস—সবকিছু কনফিগ দিয়ে ডিপ্লয়যোগ্য ও তাৎক্ষণিকভাবে রিভার্টযোগ্য হওয়া উচিত।

SLO ও ইনসিডেন্ট ওয়ার্কফ্লো

ওভারঅল SLO সংজ্ঞায়িত করুন যা সিস্টেম হেলথ ও ব্যবহারকারী ভ্যালু দুটোই প্রতিফলিত করে:

• রিলায়েবিলিটি: টাস্ক, টুল কল ও এন্ড-টু-এন্ড ওয়ার্কফ্লোর সাকসেস রেট
• ল্যাটেন্সি: p50/p95 জন্য ক্রিটিক্যাল পথ
• কোয়ালিটি: অটো-ইভ্যাল স্কোর, মানব-রেটিং ডিসট্রিবিউশন, বা টাস্ক-স্পেসিফিক সাকসেস মেট্রিক

এগুলোকে অ্যালার্টে বুনুন এবং ইনসিডেন্ট পরিচালনা এমন করুন যেমন অন্য কোনো প্রোডাকশন সার্ভিসের জন্য করতেন: স্পষ্ট অউনারশিপ, ট্রায়েজ রানেরবুক, এবং স্ট্যান্ডার্ড মিটিগেশন স্টেপ (রোলব্যাক ফ্ল্যাগ, ট্র্যাফিক ড্রেন, সেফ-মোড)।

ধারাবাহিক উন্নতি ও পরিবর্তন নিয়ন্ত্রণ

লগ, ট্রেস ও কথোপকথনের ট্রান্সক্রিপ্ট ব্যবহার করে প্রম্পট, টুল ও পলিসি পরিমার্জন করুন। প্রতিটি পরিবর্তনকে ভার্সনকৃত আর্টিফ্যাক্ট হিসেবে বিবেচনা করুন: রিভিউ, অনুমোদন ও রোলব্যাক সক্ষম থাকুক।

নীরব প্রম্পট বা টুল পরিবর্তন এড়ান। নইলে আপনি রিগ্রেশনকে নির্দিষ্ট সম্পাদনার সাথে কোরেলেট করতে পারবেন না এবং ইনসিডেন্ট রেসপন্স অনুমানভিত্তিক হয়ে উঠবে।

নির্ভরযোগ্য এজেন্টিক সিস্টেমের রেফারেন্স আর্কিটেকচার

উৎপাদন-রেডি এজেন্টিক সিস্টেম স্পষ্ট দায়িত্ব বিভাজন থেকে সুবিধা পায়। লক্ষ্য: এজেন্টকে সিদ্ধান্তে বুদ্ধিমান কিন্তু অবকাঠামোতে নির্বোধ রাখাটা।

মূল উপাদান

1. গেটওয়ে / API এজ
ক্লায়েন্টদের জন্য একক এন্ট্রি পয়েন্ট (অ্যাপ, সার্ভিস, UI)। এখানে পরিচালিত হয়:

• অটেনটিকেশন ও অথরাইজেশন (ব্যবহারকারী, সার্ভিস, টেন্যান্ট)
• রেট লিমিট ও কোটাস
• রিকোয়েস্ট শেইপিং (স্কিমা, সাইজ লিমিট, বেসিক ভ্যালিডেশন)

2. অর্কেস্ট্রেটর
অর্কেস্ট্রেটর হল "ব্রেনস্টেম", ব্রেইন নয়। এটি কোঅর্ডিনেট করে:

• প্ল্যানার: ব্যবহারকারীর উদ্দেশ্যকে ওয়ার্কফ্লো/স্টেট-মেশিনে অনুবাদ করে
• স্টেট অর্কেস্ট্রেটর: ওয়ার্কফ্লো এক্সিকিউট করে, স্টেট ট্র্যাক করে, রিট্রাই ও টাইমআউট হ্যান্ডল করে
• পলিসি ইঞ্জিন: সেফটি, কমপ্লায়েন্স, অনুমোদিত টুল, PII রুল ও কস্ট বাজেট প্রয়োগ করে

LLM(গুলি) অর্কেস্ট্রেটরের পেছনে থাকে, প্ল্যানার ও নির্দিষ্ট টুলগুলোতে ভাষাগত বোঝাপড়ার জন্য ব্যবহার করা হয়।

3. টুলিং ও স্টোরেজ লেয়ার
বিজনেস লজিক বিদ্যমান মাইক্রোসার্ভিস, কিউ, ও ডেটা সিস্টেমেই থাকে। টুলগুলো পাতলা র‌্যাপার:

• অভ্যন্তরীণ HTTP/gRPC সার্ভিস
• ডাটাবেস, ভেক্টর স্টোর, ক্যাশ
• বাইরের API

অর্কেস্ট্রেটর কঠোর চুক্তি দিয়ে টুলগুলোকে ইনভোক করে, স্টোরেজ সিস্টেম সোর্স অফ ট্রুথ হিসেবে থাকে।

ইন্টিগ্রেশন, কন্ট্রোল ও টেলিমেট্রি

গেটওয়েতে অথ ও কোটা জোরদার করুন; অর্কেস্ট্রেটরে সেফটি, ডেটা অ্যাক্সেস ও পলিসি প্রয়োগ করুন। সব কল (LLM ও টুল) স্ট্রাকচার্ড টেলিমেট্রি এমিট করবে যা পায়পলাইনে যায়:

• ধাপে-ধাপে আচরণের ট্রেস
• SLO ও রেট লিমিটের জন্য মেট্রিক্স
• সিকিউরিটি ও কমপ্লায়েন্সের জন্য অডিট লগ
• ইউজার, প্রজেক্ট ও টুল অনুযায়ী কস্ট অ্যাকাউন্টিং

সরল আর্কিটেকচার (গেটওয়ে → সিঙ্গেল অর্কেস্ট্রেটর → টুলস) অপারেট করা সহজ; আলাদা প্ল্যানার, পলিসি ইঞ্জিন ও মডেল গেটওয়ে যোগ করলে নমনীয়তা বাড়ে কিন্তু সমন্বয়, ল্যাটেন্সি ও অপারেশনাল জটিলতা বাড়ে।

সবকিছু একসঙ্গে রাখুন এবং আপনার টিমের পরবর্তী ধাপ

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

মূল প্যাটার্নগুলো এক বাক্যে

প্রতিটি এজেন্টকে একটি স্টেটফুল ওয়ার্কফ্লো হিসেবে ভাবুন:

• একটি স্টেট মেশিন আইনি ধাপগুলো নির্ধারণ করে (plan → gather → act → summarize ইত্যাদি) এবং তাদের মধ্যে ট্রানজিশন।
• টুল চুক্তি সংজ্ঞায়িত করে প্রতিটি অ্যাকশনের ক্ষমতা, কঠোর স্কিমা, টাইমআউট ও এরর সারফেস।
• রিট্রাই ও আইডেম্পোটেন্সি প্রতিটি বহির্গামী ইন্টারঅ্যাকশনের দিকে রক্ষা দেয় যাতে রি-প্লে নিরাপদ হয় এবং সাইড-এফেক্ট দ্বিগুণ না হয়।
• পর্যবেক্ষণযোগ্যতা (ট্রেস, মেট্রিক্স, লগ) প্রতিটি সিদ্ধান্ত ও টুল কলকে ব্যাখ্যাযোগ্য ও ডিবাগযোগ্য করে।

এই উপাদানগুলো মিললে সিস্টেমগুলো gracefully degrade করে ভেঙে পড়ে না।

এজেন্ট প্রোডাকশনাইজ করার জন্য একটি হালকা চেকলিস্ট

প্রোটোটাইপ এজেন্ট বাস্তবে পাঠানোর আগে নিশ্চিত করুন:

• ওয়ার্কফ্লো: স্টেট ও ট্রানজিশন স্পষ্ট; লুকানো লুপ নেই, অ-সীমাবদ্ধ টুল চেইন নেই।
• চুক্তি: প্রতিটি টুলের টাইপ করা ইনপুট/আউটপুট, স্পষ্ট ফেলিউর মোড, ও টাইমআউট আছে।
• নিরাপত্তা: ইনপুট, আউটপুট ও অ্যাকশনের উপর গার্ডরেইল (রেট লিমিট, অ্যালাউলিস্ট, কোটা) আছে।
• রিট্রাই: টুল অনুযায়ী নীতি নির্ধারিত; সব সাইড-এফেক্টিং কলের জন্য আইডেম্পোটেন্সি কী আছে।
• স্টেট: মেমোরি ও পারসিস্টেন্ট স্টেট স্কোপড, ভার্সন্ড ও রিকভারেবল।
• পর্যবেক্ষণযোগ্যতা: কোন ইউজার সেশনের জন্যও আপনি একটি সিঙ্গেল ট্রেসে "কি ঘটল?" উত্তর দিতে পারেন।
• টেস্টিং: সিনারিও-ভিত্তিক টেস্ট ও প্রম্পট, টুল ও পলিসির জন্য রিগ্রেশন স্যুট আছে।

যদি কোনো আইটেম অনুপস্থিত থাকে, আপনি এখনও প্রোটোটাইপ মোডে আছেন।

টিমগুলো কীভাবে দায়িত্ব ভাগ করতে পারে

একটি টেকসই সেটআপ সাধারণত ভাগ করে:

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

এতে প্রোডাক্ট টিম দ্রুত বাড়তে পারে যখন প্ল্যাটফর্ম টিম গ্যারান্টি দেয় নির্ভরযোগ্যতা, সিকিউরিটি ও কস্ট কন্ট্রোল।

ভবিষ্যৎ সম্প্রসারণ ও নিরাপদ ইটারেশন

একবার স্থিতিশীল ভিত্তি পাওয়া গেলে আপনি পরীক্ষা করতে পারেন:

• লার্নিং-ভিত্তিক পলিসি: লগড ট্রেস থেকে রাউটিং, টুল সিলেকশন ও ফলব্যাক কৌশল উন্নত করা।
• রিইনফੋਰসমেন্ট লার্নিং: দীর্ঘ-মেয়াদী আউটকাম (টাস্ক সম্পন্ন বা রাজস্ব) অপ্টিমাইজ করা।
• সেল্ফ-টিউনিং ওয়ার্কফ্লো: পর্যবেক্ষিত পারফরম্যান্স দেখে টেম্পারেচার, টুল বা সাব-ফ্লো স্বয়ংক্রিয়ভাবে সামঞ্জস্য করা।

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

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