প্রতিটি প্রোডাক্ট রোডম্যাপে একটি বুলেট পয়েন্ট থাকে যেখানে লেখা থাকে "AI Agent"। শব্দটি শুনলে মনে হয় এটি অগ্রগতির লক্ষণ। এটি নেতৃত্বকে সংকেত দেয় যে আপনার টিম কেবল বর্তমানকে বজায় রাখছে না, বরং ভবিষ্যৎ তৈরি করছে। কিন্তু এখানে একটি অস্বস্তিকর সত্য রয়েছে যা বেশিরভাগ ডেমো ভিডিওতে দেখানো হয় না: একটি কাজ শেষ করার জন্য 'এজেন্ট' হলো সবচেয়ে ব্যয়বহুল এবং সবচেয়ে কম অনুমানযোগ্য উপায়। অধিকাংশ ব্যবসায়িক কাজের জন্য এটি সম্পূর্ণ ভুল একটি টুল। সেরা ইঞ্জিনিয়াররা তারা নন যারা দ্রুত একটি এজেন্ট তৈরি করতে মরিয়া হয়ে ওঠেন। তারা হলেন তারা যারা জানেন কখন থামতে হবে।
The Classification Trap
একটি টিম যখন তাদের প্রথম এজেন্টের পরিধি নির্ধারণ করে, তখন আপনি সাধারণত এমন কিছু দেখতে পাবেন। একটি সাপোর্ট ইমেল আসে। একটি Large Language Model বিষয় এবং মূল অংশটি পড়ে সিদ্ধান্ত নেয় এটি বিলিং সংক্রান্ত প্রশ্ন নাকি টেকনিক্যাল বাগ, এবং তারপর এটিকে সঠিক কিউতে (queue) পাঠিয়ে দেয়। টিম এটিকে এজেন্ট বলে। কিন্তু এটি আসলে এজেন্ট নয়।
তারা যা তৈরি করেছে তা হলো একটি ডিটারমিনিস্টিক ফ্লো (deterministic flow), যার ভেতরে একটি মাত্র মডেল কল রয়েছে। ধাপগুলো নির্দিষ্ট: ইমেল গ্রহণ করা, মডেল কল করা, কিউতে রুট করা। এখানে কোনো লুপ নেই, কোনো টুল ব্যবহার নেই, এমনকি প্রথম প্রচেষ্টায় ব্যর্থ হওয়ার কারণে সিস্টেমটি তার পরিকল্পনা পুনরায় বিবেচনা করার মতো কোনো মুহূর্তও নেই। এটি কোনো নলেজ বেস ব্রাউজ করে না, কোড লেখে না বা কাজের মাঝপথে কোনো অর্ডারের স্ট্যাটাস চেক করে না। এটি একটি সিদ্ধান্ত নেয় এবং এগিয়ে যায়। সেই একটি মাত্র কলকে একটি মাইক্রোসার্ভিসের মধ্যে মুড়িয়ে ফেললেই সেটি এজেন্ট হয়ে যায় না।
একটি ফ্লো-কে এজেন্ট মনে করার আসল খরচ কেবল অতিরিক্ত ইনফ্রাস্ট্রাকচার নয়। এটি হলো সেই 'নন-ডিটারমিনিজম' (non-determinism) যা আপনি কোনো লাভ ছাড়াই আমন্ত্রণ জানিয়েছেন। একই ইমেল মঙ্গলবার সকালে যেভাবে রুট করা হয়েছে, বুধবার বিকেলে সেভাবে নাও হতে পারে, কারণ টেম্পারেচার (temperature) শূন্য নয় অথবা প্রম্পটটি কিছুটা বিচ্যুত (drift) হয়েছে। আপনি ল্যাটেন্সি (latency), টোকেন খরচ এবং ইভ্যালুয়েশন ওভারহেডের জন্য এজেন্টের মতো দাম দিচ্ছেন, যেখানে একটি ক্লাসিফিকেশন ধাপসহ একটি ফ্লো সেই সমস্যাটি আরও দ্রুত এবং সস্তায় সমাধান করতে পারে।
Work Down the Ladder
বেশিরভাগ সমস্যারই আরও সহজ সমাধান রয়েছে যা একইভাবে কাজ করে। এটিকে একটি মই হিসেবে ভাবুন এবং নিচের ধাপ থেকে শুরু করুন।
প্রসেস ঠিক করুন। মাঝে মাঝে কাজটির অস্তিত্ব থাকে কেবল কারণ দুটি সিস্টেমের মধ্যে অমিল রয়েছে। আপনার CRM-এ থাকা একটি কাস্টমার রেকর্ড আপনার টিকেটিং প্ল্যাটফর্মের সাথে সিঙ্ক (sync) হয় না, তাই প্রতিদিন সকালে একজন মানুষকে ম্যানুয়ালি সেই ব্যবধান পূরণ করতে হয়। সেই ব্যবধান পূরণের জন্য একটি এজেন্ট দিয়ে অটোমেশন করবেন না। বরং সেটি দূর করুন। যদি ডেটা পাইপলাইনটি ঠিক থাকতো, তবে এই কাজের প্রয়োজনই থাকতো না।
একটি কুয়েরি ব্যবহার করুন। যদি উত্তরটি একটি সাধারণ লুকআপ বা অ্যাগ্রিগেশন হয়, তবে সেটিকে সেভাবেই বিবেচনা করুন। "গত মঙ্গলবার আমরা কতগুলো রিফান্ড প্রসেস করেছি?" - এর জন্য কোনো রিজনিং বা যুক্তির প্রয়োজন নেই। এর জন্য প্রয়োজন SQL। একটি এজেন্ট যা ন্যাচারাল ল্যাঙ্গুয়েজকে SQL-এ অনুবাদ করে তা শুনতে চমৎকার মনে হতে পারে, যতক্ষণ না আপনি বুঝতে পারেন যে এর রক্ষণাবেক্ষণের বোঝা আপনার টিমের ড্যাশবোর্ড থেকে চালানো তিনটি ডকুমেন্ট করা কুয়েরি লেখার চেয়ে অনেক বেশি।
একটি ডিটারমিনিস্টিক ফ্লো তৈরি করুন। যখন নিয়মগুলো নির্দিষ্ট থাকে এবং ফলাফল পুনরাবৃত্তিযোগ্য হয়, তখন স্পষ্ট লজিক ব্যবহার করুন। যদি কোনো অর্ডারের মান একটি নির্দিষ্ট সীমা অতিক্রম করে, তবে তা ফাইন্যান্স বিভাগে পাঠিয়ে দিন। যদি কোনো ব্যবহারকারী ৩০ দিন নিষ্ক্রিয় থাকে, তবে তাকে একটি রি-এনগেজমেন্ট ইমেল পাঠান। কোড এটি শূন্য ভ্যারিয়েন্স (zero variance) এবং পূর্ণ অবজারভেবিলিটি (observability) সহ হ্যান্ডেল করে। আপনি এটি ইউনিট-টেস্ট করতে পারেন। আপনি কোনো 'ভাইব' (vibe) ইউনিট-টেস্ট করতে পারেন না।
একটি মডেল কলসহ একটি ফ্লো ব্যবহার করুন। ক্লাসিফিকেশন, সেন্টিমেন্ট ট্যাগিং বা ডেটা এক্সট্রাকশন এই পর্যায়ে থাকে। মডেলটি একটি কঠোর স্ক্রিপ্টের ভেতরে একটি মাত্র সিদ্ধান্ত নেয়। আপনি একটি ডকুমেন্ট ইনজেস্ট করেন, ইনভয়েস নম্বরটি এক্সট্রাক্ট করেন এবং একটি ডেটাবেসে লিখে ফেলেন। আশেপাশের ধাপগুলো হার্ডকোডেড থাকে। মডেলটি পরবর্তী কী করতে হবে তা বেছে নেয় না; এটি কেবল যা দেখে তা লেবেল করে। এটি একটি শক্তিশালী প্যাটার্ন, তবে এটি এখনও একটি ফ্লো।
সবশেষে একটি এজেন্ট তৈরি করুন। এই ধাপটি কেবল সেইসব কাজের জন্য রাখুন যেখানে পরবর্তী পদক্ষেপটি সত্যিই নির্ভর করে মডেলটি চলাকালীন কী আবিষ্কার করে তার ওপর। যদি সিস্টেমটিকে একটি ইমেল পড়তে হয়, বুঝতে হয় যে লজিস্টিকস API থেকে একটি শিপমেন্ট চেক করা প্রয়োজন, দেখতে পায় যে শিপমেন্টটি বিলম্বিত হয়েছে এবং তারপর সেই নতুন তথ্যের ভিত্তিতে একটি কাস্টম রেসপন্স ড্রাফট করতে হয়, তবে আপনি এজেন্টের সীমানায় আছেন। এই পথটি আগে থেকে আঁকা সম্ভব নয় কারণ প্রতিটি নতুন তথ্যের পরে মডেলটি সিদ্ধান্ত নেয় কী করতে হবে।
The Whiteboard Test
মিটিংয়ে বিতর্ক মেটানোর একটি দ্রুত উপায় আছে। আপনার টিমকে একটি হোয়াইটবোর্ডে সিদ্ধান্তের শাখাগুলো (decision branches) আঁকতে বলুন।
যদি মডেলটি চলার আগেই আপনি প্রতিটি পথ ম্যাপ করতে পারেন, তবে একটি ফ্লো তৈরি করুন। ডায়মন্ড শেপ আঁকুন, if-statements লিখুন এবং কাজ শেষ করুন। প্রেডিক্টেবিলিটি (predictability) একটি ফিচার, কোনো সীমাবদ্ধতা নয়।
যদি মডেলটিকেই সিদ্ধান্ত নিতে হয় যে পরবর্তী পদক্ষেপটি কী হবে, যদি এটি টুল বেছে নেয়, প্যারামিটার সেট করে এবং পুনরায় চিন্তা করার জন্য লুপে ফিরে আসে, তবে আপনার একটি এজেন্টের প্রয়োজন। সেই ডায়নামিক রাউটিং-ই হলো বিভাজন রেখা। কেবল একটি নতুন API ব্যবহার করার ইচ্ছায় ভুলবশত এই রেখাটি অতিক্রম করবেন না।
The Hidden Tax
ডেমো এজেন্টগুলোকে ঘর্ষণহীন বা সহজ মনে করায়। প্রোডাকশনে এমন চারটি ট্যাক্স বা খরচ প্রকাশ পায় যা দ্রুত বৃদ্ধি পায়।
নন-ডিটারমিনিজম। একই