ভালো এজেন্ট পারফরম্যান্সের খোঁজে থাকা বেশিরভাগ AI টিম একই লিভার টানে: বড় কনটেক্সট উইন্ডো, বেশি ডকুমেন্ট, আরও বুদ্ধিমান প্রম্পট. এই নিবন্ধের দাবি, সেই প্রবৃত্তিটাই পুরোপুরি ভুল. যে উপাদানটি অনুপস্থিত, তা আরও তথ্য নয়. তা হলো নিয়ন্ত্রণ. ভালোভাবে নকশা করা নিয়ন্ত্রণ স্তরই ডেমোতে কাজ করা এজেন্টকে প্রোডাকশনে কাজ করা এজেন্ট থেকে আলাদা করে.
AI এজেন্টকে বড় মেমোরি, বেশি ডকুমেন্ট বা দীর্ঘ কনটেক্সট উইন্ডো দিলেই সে বুদ্ধিমান হয় না—শুধু ধীর ও বেশি ব্যয়বহুল হয়. আসল উন্নতি আসে এজেন্টকে একসঙ্গে সব খেতে না দিয়ে, কখন কী দরকার তা বেছে নিতে শেখানো থেকে.
নির্ভরযোগ্যতা আসে লুপ থেকে, মডেল থেকে নয়. ডেমোতে মুগ্ধ করা এজেন্ট আর প্রোডাকশনে টিকে থাকা এজেন্টের পার্থক্য AI-এর গুণমান নয়—সিস্টেম নিজের কাজ নিজে পরীক্ষা করে কিনা. যে এজেন্টরা প্রতিটি ধাপে পরিকল্পনা, কাজ, পর্যবেক্ষণ ও যাচাই করে, তারা আত্মবিশ্বাসের সঙ্গে ভুল না করে নিজের ভুল নিজেই ধরতে পারে.
আজকের বেশিরভাগ AI এজেন্ট মূলত বাড়তি ধাপসহ চ্যাটবট—তারা ঠিক পথে আছে কিনা, কখন থামবে, বা কখন ভিন্ন পথ নেবে তা জানার কোনো প্রক্রিয়া নেই. সঠিক নিয়ন্ত্রণ স্তর—স্পষ্ট সাফল্যের মানদণ্ড, কাঠামোবদ্ধ স্টেট, ও ভ্যালিডেশন চেক—এজেন্ট-আকৃতির বস্তুকে সত্যিই ভরসাযোগ্য কিছুরূপে বদলে দেয়.
গতকাল দুপুরে কী খেয়েছিলেন?
সম্ভবত “গতকাল + দুপুরের খাবার” না পাওয়া পর্যন্ত আপনি জীবনের সব স্মৃতি রিপ্লে করেননি. আপনার অভিজ্ঞতার যেখানে এসব ধারণা থাকে, সেখানেই সরাসরি গেছেন. এজেন্ট বানানোর জন্য এটি একটি দরকারি মানসিক মডেল:
বিশাল কনটেক্সট উইন্ডো মেমোরি নয়.
রিট্রিভ করা ডকুমেন্টের স্তূপ বোঝাপড়া নয়.
লম্বা চেইন-অফ-থট নির্ভরযোগ্যতা নয়.
এসব উপাদান মাত্র. কিন্তু যে জিনিসটি একটি এজেন্টকে সত্যিই এজেন্টের মতো করে তোলে, সেটিই আপনার মস্তিষ্ককে পুরো জীবনের ইতিহাস জোর করে খুঁজতে দেয় না: নিয়ন্ত্রণ.
সাম্প্রতিক একটি সার্ভে—Agentic Reasoning for Large Language Models—আমাদের অনেকের বিল্ড করার সময় অনুভূত পরিবর্তনটি সুন্দরভাবে সারসংক্ষেপ (ও নামকরণ) করেছে: মডেলের ভেতরে রিজনিং থেকে ইন্টারঅ্যাকশনের মাধ্যমে রিজনিংয়ে যাত্রা. এই পোস্ট সেই পেপারের সারসংক্ষেপ নয়. এটি সেই পরিবর্তনকে ব্যবহারিক সিস্টেম নকশায় অনুবাদ করার চেষ্টা:
আপনি যদি এজেন্টকে টুলসহ চ্যাটবটের মতো বানান, চ্যাটবট-ধাঁচের ব্যর্থতাই পেতে থাকবেন—শুধু ভুলগুলো আরও ব্যয়বহুল হবে.
কিছুদিন ধরে “মডেলকে আরও বুদ্ধিমান করা”-র আমাদের ডিফল্ট প্লেবুক ছিল মূলত: ভালো প্রম্পট, চেইন-অফ-থট, সেলফ-কনসিস্টেন্সি / স্যাম্পলিং-ভিত্তিক উন্নতি, আর হয়তো কিছু সার্চ.
ReAct ছিল এক মোড়-ঘোরানো মুহূর্ত, কারণ এটি “চিন্তা → কাজ → পর্যবেক্ষণ”-কে স্বাভাবিক মনে করিয়েছিল. কিন্তু অন্তর্নিহিত সীমাবদ্ধতাটি খেয়াল করুন: এর অনেকটাই শেষ পর্যন্ত দাঁড়ায় “ওয়ান-শট ইনফারেন্স, শুধু বেশি টোকেনসহ”. সার্ভের ফ্রেমিং আরও তীক্ষ্ণ: এজেন্টিক রিজনিং টেস্ট-টাইম ইন্টারঅ্যাকশন স্কেল করাকে গুরুত্ব দেয়—ইনফারেন্সকে এমন পুনরাবৃত্তিমূলক প্রক্রিয়ায় বদলে দেয় যেখানে মডেল, মেমোরি ও পরিবেশ সবই লুপে থাকে.
আপনি যদি এমন এজেন্ট বানিয়ে বা ব্যবহার করে থাকেন যা ডেমোতে দারুণ লাগে কিন্তু বাস্তব ওয়ার্কফ্লোতে ভঙ্গুর, তাহলে এটি আপনার জন্য.
আমি এমন একটি প্যাটার্নের কথা বলি, যা অনেক দেখেছি (এবং নিজেও যার সংস্করণ বানিয়েছি):
একটি ভালো চ্যাট মডেল নিন
কিছু টুল যোগ করুন (সার্চ, DB কুয়েরি, হয়তো কোড এক্সিকিউশন)
RAG যোগ করুন
একটি “আপনি একজন স্বয়ংক্রিয় এজেন্ট” সিস্টেম প্রম্পট যোগ করুন
থামা বা টাইম আউট হওয়া পর্যন্ত সবকিছু একটি while-loop-এ মুড়ে দিন
অভিনন্দন, আপনার কাছে একটি এজেন্ট-আকৃতির বস্তু আছে. কিন্তু এটি পূর্বানুমেয়ভাবে ব্যর্থ হয়:
কনটেক্সট ফুলে ওঠা: প্রতিটি পর্যবেক্ষণ যোগ হয়; প্রম্পট প্রত্নতাত্ত্বিক স্তরে পরিণত হয়.
টুল নিয়ে হোঁচট: “ভুল টুল, কিন্তু আত্মবিশ্বাসীভাবে” ডিফল্ট ব্যর্থতার ধরন হয়ে যায়.
থামার শর্ত নেই: এটি চালিয়ে যায় কারণ পারে, কারণ চালানো উচিত বলে নয়.
গ্রাউন্ডিং শৃঙ্খলা নেই: আপনি বাধ্য না করলে এটি বোঝে না যে সে ভুল.
মেমোরি = চ্যাট ইতিহাস: যা মূলত লগ লেখা এবং তাকে শেখা বলা.
এ কারণেই “এজেন্ট” প্রায়ই ডেমোতে জাদুর মতো, আর প্রোডাকশনে এলোমেলো লাগে. প্রোডাকশনে এজেন্টিক সিস্টেম চালুর আমাদের অভিজ্ঞতাও একই কথা বলে: যখন আপনি আর মডেল নয়, সিস্টেম মূল্যায়ন করছেন, তখন ব্যর্থতার ধরনে আসে ন্যাভিগেশন, টুল হাইজিন, কনটেক্সট ছাঁটাই, ও ইভ্যালুয়েশন ডিজাইন—শুধু “মডেল ঠিক উত্তর দিয়েছে কি না” নয়.
তাহলে প্রশ্ন হলো: উদ্দেশ্যপ্রণোদিত এজেন্ট কেমন?
বিষয়টা কম বিমূর্ত করতে, এমন একটি খেলনা-ধাঁচের ওয়ার্কফ্লো ধরা যাক যা বেশিরভাগ মানুষ কল্পনা করতে পারে: “আগামী মঙ্গলবার লন্ডন থেকে নিউ ইয়র্কের একটি ফ্লাইট বুক করে দাও. সন্ধ্যা ৬টার আগে পৌঁছাতে হবে. £900-এর মধ্যে রাখতে হবে. আইল সিট চাই.”
একটি সাধারণ “এজেন্ট-আকৃতির” বাস্তবায়ন দেখতে এমন:
সঙ্গে সঙ্গেই অনেক এয়ারলাইন / ভ্রমণনীতি ডক রিট্রিভ করে (এখনও দরকার না হলেও).
সার্চ টুল কল করে, ফলাফলের লম্বা তালিকা প্রম্পটে বসায়, এবং “একটি বেছে নেয়”.
শর্তগুলো যাচাই না করেই আগেভাগে বুক করে ফেলে (আগমনের সময় / ব্যাগেজ / সিট / নীতি).
ব্যর্থ হলে সামান্য ভিন্নভাবে আবার চেষ্টা করে—কিন্তু কী বদলেছে বা কী শিখেছে, তার স্পষ্ট ধারণা ছাড়া.
ব্যর্থতার কারণ মডেল যুক্তি করতে পারে না—এটা নয়; কারণ হলো সিস্টেম ওয়ার্কফ্লো নিয়ন্ত্রণ করে না.
আরও এজেন্টিক সংস্করণে কাজটিকে স্পষ্ট স্টেট ও চেকসহ একটি ইন্টারঅ্যাকটিভ প্রক্রিয়া হিসেবে দেখা হয়:
PLAN: শর্তগুলো আবার বলুন + অনুপস্থিত তথ্যের তালিকা করুন (যেমন, “কোন বিমানবন্দর পছন্দ?” / “১টি স্টপ চলবে?”).
ACT: স্ট্রাকচার্ড কুয়েরি দিয়ে ফ্লাইট সার্চ কল করুন (তারিখের উইন্ডো, আগমনের শর্ত, বাজেট).
OBSERVE: ফলাফল একটি কমপ্যাক্ট স্টেট অবজেক্টে রাখুন (দাম/আগমন/লেয়োভারসহ সেরা ৫ প্রার্থী), বিশাল পেস্ট করা ব্লব নয়.
UPDATE: শর্ত পূরণ না হলে কুয়েরি পরিমার্জন করুন (যেমন, “সন্ধ্যা ৬টার আগে পৌঁছানো খুব কঠোর—সময়ের উইন্ডো বাড়াব, নাকি বাজেট বাড়াব?”).
VERIFY: ভ্যালিডেটর চালান (“আগমন < 18:00,” “দাম ≤ £900,” “নীতিসঙ্গত,” “সিট নির্বাচন উপলব্ধ”).
STOP: শুধু তখনই, যখন বুকিং API কনফার্মেশন দেয় এবং সব ভ্যালিডেটর পাস করে.
যা বদলেছে তা সূক্ষ্ম, কিন্তু সিদ্ধান্তমূলক. রিট্রিভাল শর্তসাপেক্ষ (প্রতিক্রিয়া নয়), কনটেক্সট পরিচালিত (স্টেট কাঠামোবদ্ধ, জমে থাকা নয়), আর যাচাই লুপের ভেতরে (ব্যবহারকারীর ওপর ছেড়ে দেওয়া নয়). “ফ্লাইট বুক করা”-র জায়গায় “পারচেজ অর্ডার তৈরি”, “রিফান্ড ইস্যু”, “প্রোডাকশন কনফিগ বদলানো”, বা “PR শিপ করা” বসালেও গল্প একই: এজেন্ট একবার কাজ করতে পারলে, লুপ প্রম্পটের চেয়ে বেশি গুরুত্বপূর্ণ.
উপরের সার্ভেতে এজেন্টিক রিজনিংকে তিন স্তরে সাজানো হয়েছে: ভিত্তিমূলক (পরিকল্পনা/টুল ব্যবহার/সার্চ), স্ব-বিবর্তনশীল (ফিডব্যাক + মেমোরি), এবং সমষ্টিগত (মাল্টি-এজেন্ট সমন্বয়).
কিন্তু গভীর ভাবনাটি হলো: রিজনিং পরিকল্পনা, সিদ্ধান্ত নেওয়া এবং যাচাইয়ের সংগঠক নীতিতে পরিণত হয়—শুধু সম্ভাব্য চেইন-অফ-থট তৈরিতে নয়. এটা বিমূর্ত শোনায়, যতক্ষণ না আপনি দেখেন আপনার আর্কিটেকচারে কী বদলায়. মনে রাখার মতো তিনটি মূল বিষয় আছে:
ভালো এজেন্টের রিট্রিভালকে “সব সময় করো” হিসেবে দেখা উচিত নয়. রিট্রিভাল একটি সিদ্ধান্ত, প্রতিক্রিয়া নয়.
একটি ব্যবহারিক হিউরিস্টিক:
আপনার সিস্টেম যদি প্রতিটি টার্নে রিট্রিভ করে, আপনি রিট্রিভাল বানাননি—আপনি কনটেক্সট ট্যাক্স বানিয়েছেন.
বাস্তব কাজে এটা সব সময় দেখা যায়. প্রোডাকশন ইনসিডেন্ট ডিবাগ করার সময়: আপনি সব লগ কনটেক্সটে ঢেলে দেন না; বর্তমান অনুমানের ভিত্তিতে ঠিক করেন পরের কোন মেট্রিক/লগ আনবেন. এটাই “এজেন্টিক রিট্রিভাল”. আরও নির্দিষ্ট একটি প্যাটার্ন:
রিট্রিভাল দরকার কিনা সিদ্ধান্ত নিন
দরকার হলে: কুয়েরি খসড়া করুন, আনুন, দ্রুত দেখে নিন, সারাংশ বের করুন
প্রমাণে দ্বন্দ্ব থাকলে: আবার আনুন
তারপরই সংশ্লেষ করুন
এখানেই “এজেন্টিক RAG” প্রচলিত RAG থেকে আলাদা হতে শুরু করে: রিট্রিভাল ডিফল্ট পাইপলাইন ধাপ নয়, বরং সচেতন রিজনিং ধাপ হয়ে ওঠে.
যে মুহূর্তে আপনি “একটি মডেল” মূল্যায়ন না করে “একটি সিস্টেম” মূল্যায়ন শুরু করেন, তখনই স্টেট ট্র্যাকিং ও ট্রেসিং গুরুত্বপূর্ণ হয়ে ওঠে.
এখন পর্যন্ত ইন্ডাস্ট্রি এজেন্ট ওয়ার্কফ্লোর পর্যবেক্ষণযোগ্যতা নিয়ে অনেক বেশি স্পষ্ট হয়েছে. যেমন, OpenAI-এর Agents SDK-তে বিল্ট-ইন ট্রেসিং ও একটি Traces ড্যাশবোর্ড আছে, যা এজেন্ট রান (জেনারেশন, টুল কল, হ্যান্ডঅফ, গার্ডরেইল, কাস্টম ইভেন্ট) রেকর্ড করে, যাতে আপনি ধাপে ধাপে কী ঘটেছে ডিবাগ ও অডিট করতে পারেন.
এটা “থাকলে ভালো” ধরনের বিষয় নয়. এটিই ডিবাগ করা যায় এমন সিস্টেম আর শুধু আন্দাজে যাচাই করা যায় এমন সিস্টেমের পার্থক্য.
আমার মতে, সার্ভের সবচেয়ে কার্যকর অংশ হলো ফিডব্যাক নিয়ে এর সরাসরি অবস্থান. এটি ফিডব্যাককে তিন ভাগে ভাগ করে: প্রতিফলনমূলক ফিডব্যাক (তৈরি → সমালোচনা → সংশোধন), প্যারামেট্রিক অভিযোজন (ফাইন-টিউনিং / RL দিয়ে শেখা), এবং ভ্যালিডেটর-চালিত ফিডব্যাক (ভ্যালিডেটর পাস না করা পর্যন্ত পুনরায় চেষ্টা).
বেশিরভাগ টিমের ভ্যালিডেটর-চালিত ফিডব্যাক দিয়ে শুরু করা উচিত, কারণ এটি সাদামাটা হলেও কার্যকর. আপনি যদি যেকোনো ভ্যালিডেটর লিখতে পারেন যা ইউনিট টেস্ট চালায়, স্কিমা পরীক্ষা করে, ব্যবসায়িক নিয়ম / সীমাবদ্ধতা বসায় (“এস্কেলেশন ছাড়া X-এর বেশি রিফান্ড নয়”), বা তথ্যগত সত্যতা নিশ্চিত করে (“সাইটেশন আবশ্যক”), তাহলে আপনি অনির্ধারিত মডেল আউটপুটকে সত্যিই ভরসাযোগ্য কিছুতে বদলাতে পারেন.
এখানকার এক “অজানা অজানা” পরিবর্তন সহজ: এজেন্টের জগতে নির্ভরযোগ্যতা প্রায়ই মডেল থেকে নয়, লুপ থেকে বেশি আসে.
প্রশিক্ষণ ছাড়াই আচরণ নির্ভরযোগ্যভাবে উন্নত করতে যে সবচেয়ে ছোট লুপ-শৃঙ্খলা আমি পেয়েছি, তা হলো:
ধাপে ধাপে চালান: পরিকল্পনা → কাজ → পর্যবেক্ষণ → আপডেট,
প্রতিটি কাজের পর পর্যবেক্ষণ ১–৩টি বুলেটে সারসংক্ষেপ করুন,
সাফল্যের মানদণ্ড পূরণ হলে বা বাজেট শেষ হলে থামুন; সেরা জানা ফল + বাকি অনিশ্চয়তা জানান.
এটা মডেলকে বেশি কথাবার্তায় ভরিয়ে দেওয়ার জন্য নয়. এটা সিস্টেমকে বোধ্য করার জন্য, এবং প্রতিটি ধাপে “বাস্তবতার সংস্পর্শ” বাধ্য করার জন্য. ইঞ্জিনিয়ারদের কাছে খুব পরিচিত একটি উদাহরণ হলো CI-ধাঁচের ক্লোজড-লুপ গ্রাউন্ডিং:
পরিকল্পনা: পরিবর্তনের তালিকা প্রস্তাব করুন
কাজ: টেস্ট / লিন্ট চালান
পর্যবেক্ষণ: ব্যর্থতা পার্স করুন
আপডেট: প্যাচ করে আবার চেষ্টা করুন
কিছু প্রশ্ন আছে যা প্রায়ই অনিচ্ছাকৃত-এজেন্ট নকশা প্রকাশ করে:
“আমার এজেন্ট কি কী আনবে তা নিজে বেছে নেয়, নাকি আমি সব সময় রিট্রিভ করি?”
রিট্রিভাল যদি নিঃশর্ত হয়, আপনাকে মূল্য দিতে হবে: লেটেন্সি, খরচ, কনটেক্সট পাতলা হয়ে যাওয়া, এবং আবর্জনা ঢুকলে আবর্জনা বেরোনোর বেশি ঝুঁকি.
“আমার এজেন্ট কি বুঝতে পারে যে সে ভুল?”
আপনার এজেন্টের একমাত্র ফিডব্যাক সিগন্যাল যদি হয় “ব্যবহারকারী বিরক্ত হচ্ছে”, তাহলে আপনি মানুষের কষ্ট দিয়ে RL করছেন. ভ্যালিডেটর-চালিত রিট্রাই লুপই তাকে বাস্তবতা যাচাই করানোর সবচেয়ে পরিষ্কার উপায়.
“মেমোরিতে লেখা যায় কি, এবং সময়ের সঙ্গে তা কি উন্নত হয়?”
আপনার “মেমোরি” যদি শুধু চ্যাট ইতিহাস যোগ করে যাওয়া হয়, তাহলে আপনি মূলত লগ লিখছেন. সার্ভেতে মেমোরির ফ্রেমিং গুরুত্বপূর্ণ: মেমোরি একটি ক্রমবর্ধমান গতিশীল কনটেক্সটে পরিণত হয়, যা এজেন্টরা সময়ের সঙ্গে শাণিত করে—শুধু ট্রান্সক্রিপ্ট নয়.
লগ বলে কী ঘটেছিল, আর মেমোরি বলে পরের বার কী করতে হবে. চ্যাট ইতিহাস একটি ট্রান্সক্রিপ্ট. মেমোরি হলো কী এগিয়ে নিয়ে যাওয়ার মতো, সে বিষয়ে একটি বিবর্তনশীল নীতি.
ব্যবহারিক শুরু হতে পারে ছোট একটি “শিক্ষা” টেবিল: টাস্কের ধরন, টুল, ব্যর্থতার ধরনকে কী হিসেবে, আর কী কাজ করেছে ও কী এড়াতে হবে—এসবকে মান হিসেবে রাখা. লক্ষ্য নিখুঁত নলেজ গ্রাফ বানানো নয়. লক্ষ্য হলো এমন আচরণ তৈরি করা যা ধাপে ধাপে শক্তি পায়: মেমোরি + ফিডব্যাক এজেন্টদের “স্টেটহীন সহায়ক” থেকে সময়ের সঙ্গে উন্নত হওয়া সিস্টেমে বদলে দেয়.
সমস্যার দিকে আরও এজেন্ট ছুড়ে দেওয়ার প্রলোভন থাকে, কিন্তু এতে প্রায়ই সমন্বয়ের বাড়তি খরচ বহুগুণ হয়. একটি ভালো “ন্যূনতম কার্যকর টিম” প্যাটার্ন:
সমন্বয়কারী: ভেঙে ভাগ করে + দায়িত্ব দেয়
এক্সিকিউটর: টুল কল / পরিবর্তন করে
সমালোচক/মূল্যায়নকারী: সঠিকতা/ঝুঁকি পরীক্ষা করে
মেমোরি রক্ষক: শিক্ষা লেখে/পরিচর্যা করে
প্রতিটি এজেন্ট কীসের মালিক তা ব্যাখ্যা করতে না পারলে, সম্ভবত এখনও আপনার একাধিক এজেন্ট দরকার নেই.
আমরা যদি সত্যিই প্যারাডাইম বদল মেনে নিই, তাহলে সম্ভবত সবকিছু প্রম্পটে গুঁজে দেওয়া, ব্যর্থতাকে চূড়ান্ত আউটপুট ধরা, এবং এজেন্টকে চ্যাটবটের মতো মূল্যায়ন করা বন্ধ করব. আর এজেন্টদের তাদের প্রকৃত রূপে দেখব: সফটওয়্যার সিস্টেম, যেখানে ভাষা হলো কন্ট্রোল প্লেন—আর নির্ভরযোগ্যতা আসে লুপ থেকে.
আরেকটি মডেল যোগ করার আগে, আরেকটি ইভ্যালুয়েশন লুপ যোগ করুন. সবকিছু রিট্রিভ করার আগে, সেটাকে শর্তসাপেক্ষ করুন. দশটি পাঠানোর আগে একটি ভ্যালিডেটর শিপ করুন. মেমোরিকে ডাটাবেস নয়, নীতিগত সিদ্ধান্ত হিসেবে ধরুন. আর মাল্টি-এজেন্টে গেলে, বিশটি নয়, দুইটি এজেন্ট দিয়ে শুরু করুন. এসব নিয়ম নয়; এগুলো সেই প্যাটার্ন, যা প্রোডাকশনে টিকে গেছে.